HMI für TwinCAT mit C# über ADS

clumsi

Level-1
Beiträge
137
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin!

Mein Automatisierungsprojekt läuft als TC3-Projekt auf einem Beckhoff CX9020. Als HMI nutze ich aktuell die integrierte PLC-HMI („Target Visu“). Ich merke aber zunehmend, dass das nicht gerade schön ist und ich einige Funktionen vermisse. Alarm- und Meldungsmanagement, Benutzerverwaltung, etc.

Die Beckhoff „TwinCAT 3 HMI“ (TE2000) habe ich auch schon ausprobiert, finde ich aber irgendwie nicht so elegant….

Ich würde es gerne mit einem Visual Studio C#-Projekt probieren und die Beckhoff ADS-Schnittstelle benutzen (TwinCAT.Ads.dll).

Kennt ihr hier schlanke Beispielprojekte, die zeigen, wie man am besten das Variablen lesen und senden organisiert? Mir ist klar, dass es da von Beckhoff keine Fertigen Lösungen wie Alarmmanager etc. gibt, aber kennt ihr hier trotzdem andere Beispiele, die man verwenden kann?

Beste Grüße,
clumsi
 
Klar hat Beckhhoff fertige Lösungen für das Alarm-Management - nennt sich Eventlogger - My favourite.
Und die Einbindung in C# erfolgt ganz einfach über die TwinCAT.Ads.Dll. Die findest Du unter C:\TwinCAT\AdsApi\.NET\v4.0.30319.
Und hier noch die Beispiele.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin asci25!

Danke für die Antwort! Ich habe mich glaube ich etwas missverständlich ausgedrückt....

Mit fertigen Lösungen/Beispielen für das Alarm-Management meinte ich es bezogen auf eigene C#-Programmierung, also bei einem eigenem HMI-System ohne die Beckhoff-HMI.

Die C#-Beispiele kenne ich; Die zeigen auch gut die Funktionsweisen der einzelnen Möglichkeiten. Ich meinte jetzt aber eher ein Komplettbeispiel wie man in einem eigenständigen C#-Projekt eine komplette HMI aufzieht.
 
Nein, Du hast Dich nicht missverständlich ausgedrückt.
Für C# empfehle ich Dir ausdrücklich, den Beckhoff Eventlogger einzubinden. Der feuert Dir dir die Ereignisse zu, die Du dann nur noch verarbeiten musst. Das ist wesentlich einfacher, als da selbst was zu schreiben. Und die Lösung von Beckhoff ist sehr gut durchdacht. Ich mache das nur noch so.

Ich habe einen performanten ADS-Kernel entwickelt, mit dem ich in Visual Studio sehr schnell ein HMI für Beckhoff-Steuerungen zusammenstellen kann.
 
Nachtrag: Wenn Du die einzelnen C# Beispiele kennst, wo genau hängt es dann?
Mangelnde Programmiererfahrung? Unschlüssig wegen der richtigen Architektur?

Also es geht so:
TwinCAT.Ads als Verweis hinzufügen

Dann instaziierst Du einen TcAdsClient im Konstruktor.
Als nächstes rufst Du die Methode Connect auf (Nicht im Konstruktor).

Dann hast Du schon mal einen bereiten Client, mirt dem Du alles Mögliche machen kannst: ADS-Variablen lesen, schreiben, Abonoments einrichten. Du musst hier nur noch die Beispiele richtig kombinieren.

Zum Schluss (Beim Schließen der Anwendung oder bei Verbinbdungsunterbruch) den Client disposen.

So mal ganz grob skizziert.

Das Alarm-Management würde ich erst mal weglassen, aber den Eventlogger im Hinterkopf behalten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mangelnde Programmiererfahrung? Unschlüssig wegen der richtigen Architektur?
genau, vermutlich an beidem etwas. Habe schonmal etwas mit C# gemacht, aber keine komplette HMI-Anwendung. Geht also auch um die FRagen des Aufbaus bei verschiedenen Seiten, etc.

Also es geht so:
[.....]
Vielen Dank für die Darstellung der einzelnen Schritte!! Ich werde damit einfach mal etwas herumprobieren.
 
Als ich damals noch HMIs in C# erstellt habe, sah das ganze etwa so aus:

Main-Form
Menüleiste, Alarmmeldungen, Datum&Uhrzeit
Frame Control
  • Anzeige der verschiedenen "Seite" des HMI



Jede HMI Seite war ein eigenes Form mit allen notwendigen Event-Handlern und Controls zum Darstellen der SPS Werte und Schreiben der Werte zurück an die SPS über ADS Methoden. Über das Menü wurden dann je nach Wahl die gewünschten Forms in das Frame-Control geladen.

Wichtige Meldungen etc. sind als modale Dialoge aufgepoppt.

Bei Design der HMI Seiten, natürlich auf Bedienbarkeit, Sichtbarkeit, allg. Ergonomie achten.

Ein Kollege hatte einen Backgroundworker geschrieben, der in einem eigenen Task lief und die ganze ADS Kommunikation via Summenkommando gehandelt hat. Das war bei kleinen Projekten aber nur "Nice to have". Bei großen Projekten in denen viele Daten zw. HMI und SPS übertragen werden mussten gab das dann aber einen ordentlichen Performance Schub.
 
Zurück
Oben