Ethernet/IP und Python

[drfunfrock]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe einmal vor langer Zeit ADP von Beckhoff in VB.net und Python implementiert (Ich hatte hier auch einmal Code gepostet) und vor einem Jahr auch Fins von Omron in Python implementiert. Fins ist recht einfach, belastet jedoch die CPU recht heftig, auch wenn ein Request-Block einfach aussieht. Der Versuch 30 4-Byte Float Werte aus der PLS 20mal pro Sekunde auszulesen, solle man faktisch nur mit einer CJ2H machen. Nein, das war nicht meine Idee und ich würde es freiwillig nie machen. Es klappt aber mit der CJ2H sogar mit 2 Clients. Die Antwort auf einen Request kommt innerhalb von 3ms. In dem Augenblick, wenn es zu viele Req gibt und die CPU überlastet ist, gibt es keine Antwort. Ich habe dann daraus habe ich Python-Anwendung mit Plotter auf Qt-Basis gemacht.

Die nächste Idee ist, Ethernet/IP zu nutzen, weil Omron das effizienter implementiert, so meine schwache These. Die recht junge NJ-Reihe hat jedenfalls eine kräftige CPU und es ist es wert ein paar Tests zu machen. Abgesehen davon kann einfach per Symbolnamen auf Variable zugegriffen werden. Zudem andere SPS-produzenten nutzen auch Ethernet/IP. Leider kostet die Spec recht viel.

Ich war dann auf der Suche im Internet und fand ein Python-Packet auf Github (cpppo). Leider dauerte ein Request mind. 20ms und brauchte schnell sehr viel mehr Zeit, wenn mehr Symbolnamen übergeben wurden. Die API war elegant, aber damit nutzlos. Abgesehen davon konnte ich nur 2 Byte Integer auslesen. Ich fand dann TuxEip welches sehr sauber in C geschrieben ist. Auch hier konnte ich nur 2-Byte Integer auslesen und der Grund war eine Begrenzung durch die Implementation und WICHTIGER, die Headerwerte der Antwort sind anscheinend abhängig vom Device, daher abhängig vom Actuator, Sensor oder der SPS. Im Header steht der zurückgelieferte Datentyp und der ist von SPS zu SPS anscheinend manchmal verschieden. Der Code bezog sich auf die Micrologix SPS vor 2006. Kann das jemand bestätigen?

Wenn das der Fall sein sollte, werde ich mit Ethernet/Ip nicht weiter beschäftigen.


Es gibt - gemäss Standard - auch eine implizite Kommunikation über UDP für "Realtime", die aber nicht implementiert ist und anscheinend komplett Produzentenabhängig ist.

 

[bugatti66]

Hallo,
20 Mal pro Sekunde sind ja 50ms für eine Übertragung. Das kann man hinkriegen, selbst wenn die Antwortzeit 20ms beträgt.
Die CJ-CPU wertet die Kommunikation als "unwichtig". In der Standardeinstellung reserviert sie nur 4% der Zykluszeit für die Kommunikation. Wenn das SPS-Programm jetzt auch noch besonders kurz ist, kann man auch nicht viel kommunizieren, es sei denn, man stellt den Parameter unter SPS-Einstellungen / Peripherie-Service / Zeit für alle Ereignisse auf über 40*0,1ms.
Die CPU antwortet immer, es kann nur sein, dass Antworten später kommen.

Ethernet/IP hat zwei verschiedene Übertragungsarten: A-Zyklisch=Explicit Message und Zyklisch=Implicit Message.
Explicit Message bietet bei OMRON den Vorteil, direkt mit den Variablennamen arbeiten zu können, ist aber ungefähr genauso schnell wie die FINS-Kommunikation.
Eine zyklische Kommunikation (bei Omron historisch Data Link genannt) kann Zykluszeiten bis zu 2 ms erreichen, also bis zu 500 Messages pro Sekunde! (eine Message könnte 722 Worte enthalten) Ob die Zeit erreicht werden kann, ist abhängig von der benutzten CPU und EIP-Baugruppe und Zykluszeit der CPU und der Messagelänge. Die eingebaute Schnittstelle der NJ ist langsamer als die CJ2H, die NJ kann aber auf die gleiche Geschwindigkeit kommen, wenn man eine zusätzliche CJ1W-EIP21 steckt.
Für einen Windows-PC gibt es den Treiber "Sysmac Gateway", der in der Software CX-Compolet enthalten ist.
Damit kann man denn auch einen superschnellen Datenaustausch mit einem PC machen.

Das Implicit Messaging ist am Einfachsten für die Kommunikation zwischen Geräten verschiedener Hersteller.
Man vergibt im Konfigurator nur die gleiche Instance Number und die gleiche Anzahl Datenbyte.
Das ist die eigentliche, standardisierte Ethernet/IP-Kommunikation und ist damit nicht Hersteller abhängig.

Ein PC-C-Beispiel für einen Ethernet/IP-Client ist bei der ODVA erhältlich.