TwinCAT 3.1: Externe HMI-Anbindung

LeFish

Level-1
Beiträge
60
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo allerseits,

ich starte ein kleines Projekt (ca. 30 DIOs, 3 NC-Achsen auf einer CX-9020) mit einem externen Partner, die das HMI bereitstellt und möchte mich mit euch darüber austauschen.

Grundsätzlich: Bis dato habe ich immer selbst zu kleinen Anlagen die HMIs erstellt und möchte auch dieses Projekt aus Steuerungssicht gleich aufziehen. Mit OPCUA konnte ich bereits Erfahrung sammeln, mit ADS habe ich bis jetzt nur innerhalb TwinCAT gearbeitet. Wenn die Kooperation gut funktioniert möchte ich das Konzept mit dem externen Partner weiter verfolgen und auf andere (auch größere) Anlagen ausdehnen.

Der Partner verwendet für die HMI-Erstellung das mir gänzlich unbekannte Exor/JMobile und ein Display mit integriertem Rechner auf dem die gesamte Visu inkl. Visu-Logik läuft.

Es gibt also für diese Diskussion 2 relevante Teilsysteme: 1 Visu und 1 Steuerung. Die Anbindung muss keinen besonderen Sicherheitsanforderungen (weder Anlagenseitig noch Kommunikationsseitig.) Genügen und erfolgt mittels Ethernet auf einem Subnetz.

1. Diskussionspunkt "Anbindung": Die Anbindung an die Steuerung soll für mich, wenn Exor-seitig möglich (von Partner zu klären, wir können davon ausgehen, dass es möglich ist), mittels Beckhoff ADS erfolgen. Alternativ dazu habe ich noch Erfahrung mit OPC-UA. Meint ihr auch, dass ADS eine gute Wahl aus TwinCAT-Sicht ist?

2. Diskussionspunkt "Datenaustausch": Der Datenaustausch soll nur über steuerungsseitig angebotene Public-gesetzte Methoden und Properties erfolgen (Kapselung der Steuerungsinternen Daten). Wenn nicht unbedingt nötig möchte ich kein weiteres Layer einfügen, das HMI hat also auf alle am Bus-bereitgestellten und public-gesetzten Methoden und Properties Zugriff, wie aus der Steuerung selbst heraus. Die zur Kommunikation benötigten Datenstrukturen sind mir und dem Partner bekannt und werden von mir in einer API-Dokumentation zur Verfügung gestellt. Der Datenaustausch erfolgt uni-directional gesteuert. Das heißt es werden (asynchron mit dem Takt der Steuerung) Daten durch das HMI von der Steuerung abgefragt bzw. auf diese geschrieben.

3. Diskussionspunkt "Persistente Datenhaltung": Das Projekt beinhaltet eine Rezepteverwaltung, in der Programmparameter verwaltet werden. Die Steuerung persistiert keine Daten aus der Rezepteverwaltung. Das heißt alle Daten müssen zum Programmstart der Anlage an die Steuerung übertragen werden. Die Übertragung erfolgt in einer durch die Steuerung bereitgestellte Methode.

Ihr seht ich bin in der Hinsicht ein blutiger Anfänger... Kennt jemand für mein Vorhaben so eine Art Whitepaper: "BestPractices"?

Danke für Eure Hilfe!

Beste Grüße
LeFish
 
Moin,

zu 1.) Wenn der HMI-Partner wirklich Treiber für eine ADS Anbindung hat, warum nicht. Ansonsten müsstest du, falls du dich für OPC UA entscheidest, ja erstmal einen OPC UA Server aufsetzen und der HMI Partner einen OPC UA Client zur Kommunikation mit eben diesem aufbauen. Dem OPC UA Server würdest du zB über eine ADS Anbindung deine Daten liefern.

zu 2.) / 3.) Klingt für meinen Geschmack zu objektorientiert, aber, wenn du weißt, was du da machst, warum nicht.

Gruß
Plcinrun
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Morgen,
zu 1.) Wenn möglich würde ich ADS bevorzugen. Auf dem CX9020 kannst du auch einen OPC-UA Server installieren. Allerdings brauchst du dann eine Lizenz. Gut, die kostet auf dem CX9020 so gut wie nichts. Aber wenn das Konzept später auf mehrere Anlagen kommt.
zu 2.) Aufruf von Methoden geht über ADS. Allerdings müssen die schon alle im Projekt gekennzeichnet werden. Properties sollten auch gehen, habe ich aber nie verwendet. Also würde ich hier zuerst abklären ob das alles geht.
zu 3.) Klingt plausibel.

Dass das Panel auch Logik hat finde ich nicht schön. Wenn man die Visu wechseln würde, müsste man wieder Logik programmieren?
Gruß
 
Hallo @Hack,
Hallo @plcinrun,

danke für euren Input.

Wenn möglich würde ich ADS bevorzugen.
...
Aufruf von Methoden geht über ADS. Allerdings müssen die schon alle im Projekt gekennzeichnet werden.

Bzgl. ADS PDOs (auch zB Methoden) scheint das gleich wie bei OPC-UA zu sein, was ich damals bei einem CodeSys-Projekt nutzte um mit NodeRed zu kommunizieren:

Man muss freigegebene PDOs kennzeichnen (unter Symbol Configuration). Damit sind nicht gleich alle innerhalb der Steuerung als public gesetzten Objekte gleich auch über OPC-UA verfügbar, was ich sehr gut finde. Auch kann man Read/Write-Rechte vergeben.

Bzgl. der Protokoll Funktionalität müssen wir das bei der Entwicklung checken - sonst eben zB auf OPC-UA switchen. Wichtig ist mir genau dieser objektorientierte Ansatz, den ich bei meiner eigenen Visu verfolgte auch auf dieses Projekt zu übertragen. Sonst kommt ein Chaos heraus.

Auch Danke für Kommentar zu 3. Bzgl. Logik im Panel: Da ich Visu und Steuerung (inkl Datenhaltung) sauber trennen möchte ist Logik in der Visu nötig. Mir ist bewusst, dass die Visu dann nicht übertragbar ist und partnerbezogen ist. Das Risiko gehe ich ein...
 
Zuletzt bearbeitet:
Der UA-Server von Beckhoff holt seine Daten per ADS von der Steuerung. Insofern ist die Voraussetzung für Methodenaufrufe in der SPS für ADS und OPC-UA identisch.
Vorteil OPC: Du kannst mit einem Attribut bei der Variablendeklaration definieren ob die Variable im Namensraum von OPC-UA ist. Bei ADS hat man quasi immer die volle Breitseite (klar - kann man mit einem anderen Attribut auch unterdrücken - dann funktionieren aber Tools wie z.B. das Scope für diese Variablen nicht mehr).
Vorteil ADS: Keine Lizenzkosten für OPC-UA.

Die Frage ist wie "smart/tief" Exor/JMobile das ADS-Protokoll umsetzt. Sind Methodenaufrufe überhaupt dort implementiert? Erfolgt die Datenabfrage per Summenkommando....
 
Zurück
Oben