TC3: Wer nutzt TwinCAT C++ (TC1300) und wofür?

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
nachdem ich gerade böse auf die Nase gefallen bin, wollte ich einmal wissen, wer hier TwinCAT C++ nutzt und zwar nur die TC1300 nicht irgendwie mit MATLAB oder Simulink?
Ehe Fragen aufkommen wie ich auf die Nase gefallen bin, es war nach vorn.
Aber im Ernst. Ein Messgerät wird bisher über ein externes Programm angesprochen und dieses Programm hat dann die Daten an TwinCAT per ADS gesendet. Jetzt wurde überlegt, dass man das ja mit TwinCAT C++ eleganter direkt machen könnte und so legte ich los. Ich war richtig happy, dass ich anhand der Doku ein erstes Übungsprogramm zum Laufen bekommen habe, aber dann bahnte sich die Katastrophe an. Nun fügte ich eine Header-Datei an, die für das Messgerät gebraucht wird und wurde beim nächsten Übersetzen mit Meldungen überhäuft.
Was war passiert? Das Programm nutzt Funktionen der Windows API und es wird auch noch eine DLL benötigt und beides geht in TwinCAT C++ nicht, was aber nur indirekt etwas mit TwinCAT C++ zu tun hat. Die Programme werden als Kernel-Mode Treiber ausgeführt und da hat man keinen Zugriff auf die Windows API und darf auch keine DLLs einbinden.

 

[Neals]

Moin Oliver,
wir nutzen TwinCAT C++ überall wo es darum geht besonders performant zu sein, große Datenmengen zu verwalten oder Schnittstellen zu implementieren. Es gibt viele Aufgaben, welche sich in C++ wesentlich effizienter umsetzen lassen als in PLC, wie komplexe Mathematik, Regler und Filter.

# Performance
- Die Performance von einem optimierten TwinCAT C++ Treiber ist schon wesentlich besser als bei den meisten PLC Projekten.
- Es gibt Ausnahmen, aber dann ist die Performance von C++ immernoch gleichwertig zu PLC.
# Datenmengen
- Wenn es darum geht z.B. irgendwelche Konfigurationen in großen Tabellen zu verwalten.
- Oder es sollen viele Signale schnell zwischengespeichert, verwaltet und irgendwo abgelegt werden.
- Speziell dynamischer Speicher lässt sich in C++ einfacher verwenden, auch mit den STL (vector, map, ...)
# Schnittstellen
- Das implementieren von Schnittstellen wie Ethernet, TCP/UDP, ADS aber auch Seriell empfinde ich einfacher in C++ umzusetzen.
- Das parsen der eingehenden Daten ist mit Pointern und Strukturen einfacher und schneller.

Am Ende finde ich aber die Erfahrungen und Vorlieben von Entwickler fast entscheidend. Man sollte einem erfahrenem PLC Entwickler nicht zwingen eine Aufgabe in C++ zu lösen... dann werden die Vorteile von C++ nicht wirken. ;-)

Gruß, Neals

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

- Das implementieren von Schnittstellen wie Ethernet, TCP/UDP, ADS aber auch Seriell empfinde ich einfacher in C++ umzusetzen.
- Das parsen der eingehenden Daten ist mit Pointern und Strukturen einfach
Am Ende finde ich aber die Erfahrungen und Vorlieben von Entwickler fast entscheidend. Man sollte einem erfahrenem PLC Entwickler nicht zwingen eine Aufgabe in C++ zu lösen... dann werden die Vorteile von C++ nicht wirken. ;-)

Hallo Neals,
vielen Dank für Deine umfangreiche Antwort.
Ich habe vor Jahren mal C++ gelernt und mir danach C# etwas beigebracht. Mit C++ habe ich immer nur Kleinigkeiten programmiert und mit C# nur ein Projekt gemacht. Alles liegt schon viele Jahre zurück, so das mein Wissen etwas eingerostet ist und ich bei vielen Konstrukten gar nicht weiß, was die machen.
Was mich jetzt etwas wundert ist, wie Du in Beckhoff C++ auf Ethernet zugreifst, dafür muss man doch vermutlich auch auf eine DLL oder die Windows API zugreifen und beides soll ja laut Infosys nicht gehen.

 

[Neals]

Was mich jetzt etwas wundert ist, wie Du in Beckhoff C++ auf Ethernet zugreifst, dafür muss man doch vermutlich auch auf eine DLL oder die Windows API zugreifen und beides soll ja laut Infosys nicht gehen.

Entweder direkt auf Ethernet... (Siehe https://infosys.beckhoff.com/content/1033/tc3_c/112615051.html)
oder mit TCP/UDP über TF6311. (Siehe https://infosys.beckhoff.com/content/1033/tf6311_tc3_tcpudp/index.html)

Unter den "Limitations" findest du eine knappe Liste mit Möglichkeiten um Funktionen der Win32 API zu ersetzen: https://infosys.beckhoff.com/content/1033/tc3_c/674760331.html

 

[oliver.tonn]

Unter den "Limitations" findest du eine knappe Liste mit Möglichkeiten um Funktionen der Win32 API zu ersetzen: https://infosys.beckhoff.com/content/1033/tc3_c/674760331.html

Den Infosys Beitrag hatte ich dann, als ich auf die Probleme gestoßen bin, auch gefunden. Habe gerade gesehen, dass im PDF Dokument auch die Limitierungen drin stehen, aber leider so weit hinten, dass ich bisher nicht bis dahin gekommen bin.
Die WinAPI ist ein Problem, kritischer ist aber, dass das Messgerät zur Kommunikation das VXI-11 Protokoll nutzt und der Hersteller des Messgerätes eine DLL zur Versügung stellt, die ich nicht nutzen kann.