drfunfrock
Level-1
- Beiträge
- 934
- Reaktionspunkte
- 72
-> 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.
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.