Hallo zusammen,
ich bin mir ziemlich sicher, dass diese Frage schon gestellt wurde, aber
ich finde Sie nicht im Forum.
Folgendes habe ich vor. Ich habe einen Steuerung, z.B. SPS oder Embedded
Controller und möchte ein HMI bauen, welches nicht auf der SPS oder dem
controller läuft. Ich stelle mir vor, dass ein Webserver z.B. auf einem
Rasperry PI läuft, der mit den entsprechenden Controller Daten gefüttert
wird.
Die Frage ist, wie ist der Weg von Controller über Webserver bis zur
angezeigten Seite, wenn alle Module über Ethernet verbunden ist? Welche
Technologien setzt man heute dafür ein? Wie werden die Daten zum
Webserver übertragen? Wie kommen sie auf die Webseite? Welche Themen
muss ich mir dafür anschauen?
Grüße
stefan
Das dürfte vom Einsatzzweck ankommen. Daraus resultiert wieviele Daten
übertragen werden müssen und welche Latenz zulässig ist.
Zur einfachen und sehr flexiblen Datenübertragung wird zum Beispiel eine
Implementation des Mosquito Protokolls übers Netzwerk eingesetzt:
https://de.wikipedia.org/wiki/MQTT
Nun, der Controller mit dem Webserver muss eine Funktionalitaet, die
ueber den Webserver hinausgeht bereitstellen. Wie auch immer die
Kommunikation mit dem externen Gerate laeuft, muss ein Codeinterface
hin. Wahrscheinlich laeuft ein Thread/Task auf dem Webcontroller der das
Device anbindet.
Falls der Webserver bereits fertig ist, dh ein kommerzieller, muss ein
Interpreter hin, der ueber die Seite geht, und Ausdruecke ersetzt. Falls
der Webserver noch geschrieben werden muss kannst du den Interpreter
gleich einbinden.
zB Tags in die Seite einbinden : <device>readIO_17</device>, die werden
dann durch den Wert des IO_17 ersetzt.
Irgendwelche Rechnereien kann man zB per Javascript dem Client, dem
Browser anhaengen. Falls die Werte waehren einer Seite aendern sollen
waere AJAX die Wahl.
Auf welchem Level soll das Ganze denn laufen ?
Nimm einfach das, was dich begeistert.
Erst mal entscheiden, ob du nur Logging machen willst, einen
Hintergrundprozess schreibst, der die Daten von der SPS in eine
Datenbank holt. Oder ob der Webserver direkt auf die SPS zugreift.
Aus einem Webserver auf die Datenbank oder auf die SPS zugreifen -
beides kein Problem.
Beim Raspi musst du nur auf 2 Punkte achten.
Rechnest du in Schreibzugriffen pro Sekunde, ist die SD-Karte nach einem
Jahr hinüber. Kein Problem, wenn du ein paar Schreibzugriffe pro Minute
hast.
Hauptspeicher ist zu klein für den Apache. Besser einen sparsamen
Webserver wie den Lighttpd nehmen.
Ob du prähistorisches PHP oder hippes Angular nimmst -- Geschmackssache.
Funktionieren tut alles.
Wird das ganze ein Hobbyprojekt, doer was halbwegs industrielles?
Es gibt nämlich auf den Raspberry basierende SPS.
Damit würdest du dir die Zwischenkommunikation ganz sparen und die IOs
bzw. Relais, direkt durch das backend des Web-Servers steuern.
Danke für die Antworten.
Ja, wird industriell. Unsere Firma ist stark in stark in standalone
embedded bzw PLC Applikationen. Wir haben wenig KnowHow in ModBus TCP
aber recht wenig in HMI Entwicklung und WebTechnologien. Daher wird das
Projekt aus extern vergeben. Ich möchte aktuell einmal wissen, wie es
andere tun und was Stand der Technik ist.
Bisher habe ich folgendes verstanden:
Controller(s) liefert Daten per Ethernet an WEbServer Rechner.
Dort läuft eine Applikation, die die Daten empfängt und z.B. in eine
Datenbank schreibt. Der Webserver greift auf diese Datenbank zu.
Kann Apache Webserver direkt mit einem Controller kommunizieren, wenn
ja, wie?
Für Live Daten scheint mir der Zwischenschritt über eine Datenbank
aufwendig. Gibt es eine andere Lösung?
Über PHP oder Angular kann ich dann die Daten visualisieren. Wie legt
man zu visualisierende Daten typischerweise ab?
Grüße
Stefan
> wenn ja, wie?
Der Webserver ist nur Frontend für beliebige CGI-Scripte oder permanent
laufende Hintergrundprozesse. Diese Scripte oder Programme kannst du in
jeder beliebigen Sprache schreiben. Damit kannst du ganz normal auf
alles mögliche zugreifen.
Nun hast du 2 Möglichkeiten. Mit dem ursprünglichem HTML musste der
Benutzer warten, bis der Webserver die Daten von der SPS geholt hat. Mit
HTML5 und Websockets kannst du ein ganz normales Anwendungsprogramm in
Javascript schreiben. Dein Programm zeigt Rahmen und Bedienelemente,
schickt über Websockets eine Auftrag an den Webserver und zeigt die
Daten sobald sie hereinkommen. Fühlt sich an, wie ein normales
Windowsprogramm.
> und was Stand der Technik ist
Stand der Technik kannst du dir z.B. hier anschauen.
https://www.heise.de/newsticker/meldung/LibreOffice-fuer-die-Cloud-CODE-3-0-ist-da-3928198.html
Ob du die alten Html-Oberflächen mit Submit-Button noch lange verkaufen
kannst?
> Wie legt man zu visualisierende Daten typischerweise ab?
Für Logging findet sich hier ein geniales System. Der Zwischenschritt
über eine RRD Datenbank löst einen ganzen Haufen Probleme. in Summe wird
es einfacher.
Bei Live Daten hast du aber das Problem: Ein Update pro Sekunde zerstört
die SD-Karte.
https://oss.oetiker.ch/rrdtool/
Wiso lässt du nicht gleich den Webserver auf der SPS laufen?
Beckhoff TwinCAT HMI
Wenn du umbedingt auf getrennten Geräte narbeiten willst, würde sich zur
Kommunikation ADS, Modbus IP EtherCAT oder sonstiges eignen.
Christian_RX7
Hi,
im professionellen Umfeld würde es etwa so aussehen:
Prozessrechner steuert, misst regelt (wie auch immer) und befüllt eine
lokale Datenbank (bspw. mysql) mit Prozessdaten. Diese werden dann auf
einen Rechner übertragen, auf dem die Anzeige-Datenbank und der
Webserver laufen. Die Anzeige auf der Webseite läuft dann asynchron via
ajax/jquery.
Falls du über die Webseite auch steuern/eingreifen willst, würde die
Webseite Steuerinformationen in die Anzeige-Datenbank schreiben und ein
Script auf diesem Rechner müsste die Steuerinformationen in die
Datenbank des Prozessrechners übertragen.
Für eine Datenanzeige und die Steuerung ist es sinnvoll, wenn die
Datenelemente in den beiden Datenbanken nicht nur den eigentlichen Wert
sondern auch Informationen über Auflösung, Skalierung und einen
Zeitstempel enthalten. Dadurch lässt sich viel Code generisch umsetzen
und man muss nicht bei jeder kleinen Änderung die ganze Datenkette
umprogrammieren.
Der Prozessrechner darf nur auf seine eigene Datenbank zugreifen, damit
im Falle eines Netzwerkausfalls die Steuerung störungsfrei
weiterarbeiten kann. Keinesfalls darf im Programmablauf der Steuerung
auf externe Datenbanken zugegriffen werden. Dies könnte den
Programmablauf minutenlang unterbrechen.
Für einen Dauerbetrieb und Vorsorge bzgl abrupten Spannungsverlust
müsste dein Webserverraspi auf readonly umgestellt werden. Die
Anzeige-Datenbank müsste dann im RAM liegen.
>bzgl abrupten Spannungsverlust
Warum hat sich da eigentlich diese Spielzeugplatine durchgesetzt?
Eine Platine mit Akku, die System und Flash sauber herunter fährt, ist
doch auch nicht wesentlich teurer. Schon alleine ein Log mit
Störmeldungen spart 1000x so viel Zeit, wie die Platine kostet?
Webserver auf SPS geht deswegen nicht, da nicht immer verfügbar. Ein
Prozessrechner ist meist verfügbar und eignet sich als HMI Webserver
vermutlich am besten.
Danke für Eure Hilfe!
Ein Punkt wurde noch nicht behandelt.
Wie dieht die Prozesskette aus, wenn ich ich den Prozess von dem HMI im
Controller verändern möchte?
Also: Z.B. Auf HMI KOmmono per Taste ausgelöst und dann? Wie erhält der
Controller möglichst schnell die Info, dass er etwas tun soll?
Wie schon erwähnt, haben wir verschiedene Zielsysteme?
Wie würde man so eine Schnittstelle vereinheitlichen?
Danke
Stefan
Noch eins: in letzter Zeit lese ich häufig UPC UA is das Protokoll der
Zukunft? Wie ist Eure Meinung dazu? Würde man UPC UA für HMI
Kommunkation einsetzten?
Stefan schrieb:> Wie schon erwähnt, haben wir verschiedene Zielsysteme?>> Wie würde man so eine Schnittstelle vereinheitlichen?
Vielleicht solltest du für dein kommerzielles Projekt einen Consulter
holen, der dir deine ganzen Fragen beantwortet und nicht hier versuchen,
für Lau Beratungsleistungen abzugreifen. Oder kauf dir alternativ ein
Buch über Software-Architektur und lies.
> Auf HMI KOmmono per Taste ausgelöst und dann?
Im Webbrowser sind deine Möglichkeiten recht eingeschränkt.
- Entweder wie früher Formular absenden, im Server bearbeiten und Seite
neu laden. Zu träge, das will keiner mehr.
- Oder mit Javascript nur das Kommando versenden. Ajax war eine Krücke.
Die Websockets sind inzwischen brauchbar.
Auf jeden Fall brauchst du zunächst einen Http-Server, der die
Kommunikation mit dem Browser ab handelt. Dazu dann ein selbst
geschriebenes Programm, das den Auftrag des Browsers in ein Protokoll
übersetzt, was die SPS versteht.
Einen Server in die SPS einbauen, der direkt mit den vom Webbrowser
unterstützten Protokollen zurecht kommt? Praktisch läuft es darauf
hinaus, du musst einen kompletten Webserver in die SPS einbauen.
Ein einheitliches Protokoll für alle unterschiedlichen SPS Systeme? Du
weisst doch selbst: Jeder Hersteller erzählt, er würde Standards
unterstützen. Baut aber so viele Besonderheiten ein, dass es niemals mit
Geräten der Konkurrenz zusammen arbeiten wird.