Visualisierungen / Aufbau/Schnittstellen Backend <> Frontend - Diskussion

[Biiebs]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Community,

ich wollte mal einen allgemeinen Thread starten, der das Thema Visualisierungen / Aufbau und deren Schnittstellen etwas diskutiert. Ziel ist hierbei ein Austausch von Informationen, wie es in anderen Bereichen so gehandhabt wird, sowie neue Wege/Ansätze in Richtung Übersichtlichkeit/Komfort/Wartung/Aufwand bei Änderungen auszutauschen (vor allem bei größeren Projekten). Die Entwicklungsumgebung spielt hierbei keine Rolle, da es hier nur um die eigentlichen Prinzipien und Möglichkeiten geht.

Die prinzipiellen Punkte könnten hierbei nachfolgende sein:

• Allgemein

Entwicklung der Visualisierungsoberfläche in einer Hochsprache oder im vorhandenen Editor in der SPS-Entwicklungsumgebung?
Bei Einsatz einer Hochsprache, welche wird hierbei verwendet und welche Kommunikationsschnittstelle wird hierbei verwendet?

• Oberflächenaufbau:

Wie handhabt ihr das mit dem Visualisierungsoberflächenaufbau?
Baut ihr alle Objekte in einer einzigen Oberfläche auf oder lagert ihr alles in Templates/Frames aus?
Bei variabler Textgestaltung (z.B. bei Buttons), lagert ihr die Texte in Textlisten aus oder statisch in die IN_OUT_Variablen der GUI (oder anders)?

• Schnittstellen:

Wie handhabt ihr das mit der Kommunikationsschnittstelle zwischen Visualisierungsoberfläche und Backend-SW?
Direkte Zuweisung z.B. Buttonsignal von Variablen aus dem Quellcode? Schnittstelle in einer zentralen GVL auf die beidseitig geschrieben/gelesen wird?
Mapping/Aktualisierung der Variablen in einer einzigen Task/PRG, FB? Oder wird für jede Visualisierungsoberfläche ein eigenes PRG spendiert?

----------------------
Aus meiner Erfahrung bisher, kenn ich aktuell nur folgende zwei Ansätze:

1. Ansatz:
Visualisierungsoberfläche wurde in C# entwickelt, die Kommunikation geschah über Twincat und ADS-Kommunikation (Alternative: OPC UA).
Aufgebaut war die Oberfläche in diversen Frames, die entsprechend über C# gehandelt wurden. Der Variablenzugriff geschah SPS-Seitig über eine zentrale
Schnittstelle als GVL zw. Visualisierung und Backend-SW. Die Variablenaktualisierung geschah ebenfalls in einem zentralen PRG.

Ansatz war für ein kleineres Projekt, zentrale GVL und zentrales PRG ist doch sehr unflexibel für Änderungen und Unübersichtlich, der Implementierungsaufwand
war in diesem Fall jedoch sehr gering.

2. Ansatz
Visualisierungsoberfläche wurde in einer SPS-Entwicklungsumgebung entwickelt. Aufgebaut wurde alles in kleine Module, die entsprechend in Frames ausgelagert wurden. Frames besaßen hierbei diverse IN_OUT_Zugriffsvariablen.
Jedes größere Template für die HMI, besaß ein eigenes PRG, sowie eine eigene Struktur zum Handling der Interaktionen.
Kommunikationsschnittstelle: WebVisu keine direkte Kommunikationsschnittstelle. Kommunikation mit TargetVisu über OPC UA.

Aufwand hoch, jedoch flexibel für Änderungen.

3. Ansatz:
Eine Mischung aus den beiden ersten Ansätzen

-----

Wie handhabt ihr das so?

Gruß,

Biiebs

 

[Larry Laffer]

Um da jetzt wirklich etwas dazu sagen zu können müsste man mehr über die Maschinen / Anlagen wissen. Aber ganz grundsätzlich :

Ich kenne beide Varianten - also die Standard-HMI (mehr oder weniger) passend zur Steuerung und die .Net-HMI.
Grundsätzlich kannst du, bei entsprechender Strukturierung, mit beiden eine gute HMI aufbauen.
Tendenziell würde ich aber, aufgrund der ungleich größeren Möglichkeiten, aber die .Net-Variante bevorzugen. Hier kommt es natürlich auf dein finales Ziel an. Mit einem PC-Programm kannst du beispielsweise eine sehr viel mächtigere Rezept- / Parameterverwaltung umsetzen die, wenn man es richtig anstellt, in Sachen (intuitiver) Bedienbarkeit, gewinnt.
Da Maschinen ja immer wiederkehrende Komponenten haben (auch Sondermaschinen) kannst du m.E. hier auch in Sachen Templates eine Menge vorhalten. Hier ist es aber entscheidend, dass der Variablen-Austausch mit der PLC im Grunde weitestgehend festgelegt ist. Das hört sich jetzt komplex an - habe ich aber selber schon so gemacht ... geht also ...
Bei der Text-Zuweisung an Steuerelemente kommt es stark darauf an was deine Steuerelemente selbst hergeben (und natürlich die umgebende SW). Hier ist ja entscheidend, dass zu, wenn du z.B. wenn Deutsch auf Englisch umswitched, nicht unterschiedliche Textgrößen erhältst bzw. die Texte nicht mehr auf das Control passen. Das setzt dann schon ein eigenes Framework mit zumindestens selbst erweiterten Controls voraus.

Soviel erstmal dazu ... da kann man natürlich noch ganz viel mehr dazu schreiben.
Wozu tendierst du selbst ?

 

[Mrtain]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schade, hätte gehofft das hier mehr drüber diskutiert wird da es ja doch ein sehr interessantes Thema ist.

 

[Larry Laffer]

Schade, hätte gehofft das hier mehr drüber diskutiert wird da es ja doch ein sehr interessantes Thema ist.

Das ist es - ohne Zweifel ... es ist aber auch ein ganz schöner Sprung vom WinCCFlexibel-"Anwender" (oder WinCC oder oder) zum .Net-Programmierer ...

 

[R_Grabichler]

Zum Thema,
ich benutze eine Blazor Anwendung als Visualisierung, mit dem Inxton Compiler habe ich meine Variablen automatisch in C#.
Das ist sehr experimentell, funktioniert auch nur, da ich alleine programmiere.
Ich denke, der Ansatz hat den Vorteil, das mit Copilot, Chatgpt etc. Web Programmierung deutlich einfacher und schneller wird.