N'Abend! In einigen mir bekannten Automatisierungsprojekten wird der CAN-Bus mit CANopen verwendet, da es häufig notwendig ist, aus angeschlossenen PC's oder Mikrocontrollern CAN-Nachrichten zu verschicken, in eine laufende SPS einzugreifen, oder die "SPS" verteilt auf PCs und Mikrocontrollern laufen zu lassen. Bei CAN muss es ja keinen definierten Master geben, jeder darf Nachrichten senden, und wenn es die richtigen Nachrichten sind, kann jeder auch jeden ansprechen und Prozessdaten hinsenden (z.B. Ausgang setzen). Es kann aber auch jeder beliebige PC mit CAN-Interface auf dem Bus mithören und z.B. Spannungen von Analogmodulen mitschreiben. Davon merkt kein anderer Teilnehmer etwas. Der PC hört völlig passiv mit. Es gibt für einige Interfaces C-Bibliotheken mit den grundlegendsten Befehlen (Frame senden und Frame empfangen). Es ist sehr einfach zu bestimmen, was in welchem Frame für Daten liegen. Das sehe ich als großen Vorteil der CAN-Welt. Gibt es solche Möglichkeiten auch mit Profibus oder Profinet? Wenn nein, warum nicht? Kann man bei Profibus auch einfach einen PC anschließen und mit bestimmten Frames einen Ausgang setzen, obwohl es der Master nicht machen würde? Sind solche Zugriffe erlaubt bzw. möglich? Geht das auch bei Profinet?
vorsicht. bei manchen can open implementierungen hört der sender auf seiner ID mit und killt nachrichten die er nicht versendet hat und löst bei mehrfacher verletzung einen fehler aus. (hatte da einen drucksensor der das machte, wie verbreitet das ist, kann ich aber nicht sagen) ja, bei profibus kannst du dich genauso mit einem rs485 usb wandler dazuklemmen. wenn das medium ethernet (powerlink oder so ist) dann ist wireshark das mittel der wahl. bei powerlink ist nur das problem mit den slots. wenn du einem teilnehmer in seinen solt reinbrüllst kann er das als fehler melden. wenn aber nachrichten im allgemeinteil daherkommen kann sein dass sie als falsch verworfen werden. => hören geht immer, schreiben nur unter beachtung der slots oder der implementierung ( ist aber so oder so pfusch)
zoggl schrieb: > vorsicht. bei manchen can open implementierungen hört der sender auf > seiner ID mit und killt nachrichten die er nicht versendet hat und löst > bei mehrfacher verletzung einen fehler aus. Das hört sich interessant an, soetwas habe ich aber noch nicht gesehen. Weiß jemand näheres dazu? Du meinst wahrscheinlich, dass ein Sender einfach Druckwerte auf der Sende-ID vom Drucksensor gesendet hat, oder? Der Drucksender hat das dann "mitbekommen" und versucht den falschen Sender "auszuschalten"? zoggl schrieb: > ja, bei profibus kannst du dich genauso mit einem rs485 usb wandler > dazuklemmen. Das ist dann ja aber kein Profibus-Protokoll. Ich meine schon mit einer spezielleren PCI-Profibus Karte oder einem USB-Profibus Wandler. Ist bei Profibus überhaupt das Protokoll so offen, dass ich wie bei CAN weiß, an welche ID, ich welches Bit im ersten Byte senden muss um einen Kanal zu steuern? zoggl schrieb: > => hören geht immer, schreiben nur unter beachtung der slots oder der > implementierung ( ist aber so oder so pfusch) warum pfusch? Was spricht dagegen, z.B. an einer automatisierten Anlage einzelne Sensoren zu erfassen und nach Verarbeitung im PC-Programm andere Aktoren am Bus anzusteuern? Es muss ja nicht zwangsläufig ein SPS-Eingriff sein.... Und überhaupt: Bussysteme muss man doch nicht nur für SPS verwenden? Beispiel: Eine ganz einfache Ablaufsteuerung kann ich in C programmieren, die Daten gehen dann aus meinem Mikrocontroller über SPI an Relaismodule. Jetzt baue ich mir die Aktoren aber auf dem CAN-Bus auf => funktioniert mit CAN-Controllern oder auch vom PC genauso. Ich muss nur wissen, was man sendet, und das ist bei CAN wirklich sehr einfach: (ID 0x200+NodeID, Länge 1 Byte und das Byte spiegelt z.B. ein 8-kanäliges Ausgangsmodul wieder) Wenn ich mir das gleiche jetzt mit Profibus-Aktoren aufbauen will: Was muss man da beachten? Wie würde das funktionieren?
genau, ist mir bei einer testumgebung passiert. damit hätte ich ehrlich gesagt auch nicht gerechnet. ich wolte die angeschlossene steuerung testen und habe mit einem usb can dongle den sensor simulieren wollen ohne diesen abuklemmen. dieser hat dann laufend errors fabriziert. berti schrieb: > Das hört sich interessant an, soetwas habe ich aber noch nicht gesehen. > Weiß jemand näheres dazu? Du meinst wahrscheinlich, dass ein Sender > einfach Druckwerte auf der Sende-ID vom Drucksensor gesendet hat, oder? > Der Drucksender hat das dann "mitbekommen" und versucht den falschen > Sender "auszuschalten"? berti schrieb: > warum pfusch? Was spricht dagegen, z.B. an einer automatisierten Anlage > einzelne Sensoren zu erfassen und nach Verarbeitung im PC-Programm > andere Aktoren am Bus anzusteuern? Es muss ja nicht zwangsläufig ein > SPS-Eingriff sein.... Und überhaupt: Bussysteme muss man doch nicht nur > für SPS verwenden? das bezog sich auf: berti schrieb: > Kann man bei Profibus auch einfach einen PC anschließen und > mit bestimmten Frames einen Ausgang setzen, obwohl es der Master nicht > machen würde? damit sind plötzlich zwei sender der selben nachricht aktiv. du kannst nicht sagen was passiert stell dir vor master will 01001 und der PC 00101 wechseln nun bit 2 und 3 mit jeder neuen Nachricht ab? => pfusch berti schrieb: > warum pfusch? Was spricht dagegen, z.B. an einer automatisierten Anlage > einzelne Sensoren zu erfassen und nach Verarbeitung im PC-Programm > andere Aktoren am Bus anzusteuern? Es muss ja nicht zwangsläufig ein > SPS-Eingriff sein.... Und überhaupt: Bussysteme muss man doch nicht nur > für SPS verwenden? jetzt gibt es aber nur einen sender (dein PC ) => nicht pfusch ;) berti schrieb: > Das ist dann ja aber kein Profibus-Protokoll. Ich meine schon mit einer > spezielleren PCI-Profibus Karte oder einem USB-Profibus Wandler. Ist bei > Profibus überhaupt das Protokoll so offen, dass ich wie bei CAN weiß, an > welche ID, ich welches Bit im ersten Byte senden muss um einen Kanal zu > steuern? doch. CAN wird auch erst durch die SW zu CANopen (siehe OSI Modell) schau mal hier rein. die haben das auf einen AVR hinuntergebastelt: http://www2.htw-dresden.de/~huhle/mikror/projects/pb_slave/index.htm die verwenden den normalen uart und einen http://www.mikrocontroller.net/part/SN75176 (=RS485 transreciever) wie die steuerung ihre daten haben will steht in der beschreibung sg clemens
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.