TIA Keine Verbindung zwischen HMI und SPS?

[DeaD_EyE]

Zuviel Werbung?
-> Hier kostenlos registrieren

Selbst ein ESP32 oder ähnliches kann als NTP-Server arbeiten. Da gehört echt nicht viel zu.

Ja, ca. 100 Zeilen Code, wenn man nur das notwendigste implementiert.
Es gibt auch ESP32 mit einem Ethernet-Port auf den Entwicklerboards.
So könnte man sich seinen eigenen stabilen Zeitserver bauen. Ein weiterer Vorteil ist der geringe Energieverbrauch.

 

[trobo]

https://www.teltonika-networks.com/products/gateways/ntp001

keine 100 €, Probleme von gestern.

Vor allem einfach und günstig je Anlage nachrüstbar und weniger anfällig gegenüber einer zentralen Verteilung. Aber ja, es macht alles am Ende komplexer, mehr Teilnehmer und Geräte zu verwalten, nur dass das HMI und die SPS ohne Stress kommunizieren.....

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

keine 100 €

eine Logo! 8 kann auch NTP-Server

 

[trobo]

eine Logo! 8 kann auch NTP-Server

Aber doch nur übers netzwerk?! Der Kasten oben holt sich seine Zeit direkt über GPS

 

[DeaD_EyE]

eine Logo! 8 kann auch NTP-Server

Woher bekommt der NTP-Server dann seine Uhrzeit?

Das ist doch genau das Problem. Man möchte, dass die Geräte mit UTC0 synchronisiert werden und die Geräte sind so konfiguriert, dass sie die Lokalzeit anzeigen inklusive Normalzeit/Sommerzeit.

Der NTP-Server muss selbstverständlich auch die richtige Uhrzeit und Datum haben. Genau deswegen gibt es diese Lösungen: https://www.teltonika-networks.com/products/gateways/ntp001

Die NTP-Server können ihre Zeit von anderen NTP-Servern beziehen und man kann seine eigene Zeit-Quelle haben:

• DCF77
• GPS
• GSM
• RTC + Batterie
• eigene Atomuhr (CSAC) 1400-1800€

Jedenfalls ist es einfacher einen fertigen zentralen Zeitserver einzusetzen. Das hat auch den Vorteil, dass alle Controller im Haus die gleiche Uhrzeit haben. Gerade wenn irgendwas nicht funktioniert, ist es besser, wenn die Zeitstempel der Logeinträge stimmen.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

eine Logo! 8 kann auch NTP-Server

Woher bekommt der NTP-Server dann seine Uhrzeit?

Von der Uhr der Logo.

Sehr oft ist bei einzelnen Maschinen oder kleinen Anlagen gar nicht nötig, dass die Uhren ganz exakt die richtige Uhrzeit haben. Es kommt nur darauf an, dass alle Komponenten mit der gleichen Uhrzeit arbeiten. Wenn einem eine Minute Differenz der Uhr zur offiziellen Weltzeit stören, dann kann man bei Bedarf sehr leicht alle paar Wochen die Uhr der Logo manuell stellen/korrigieren, z.B. direkt mit dem Bediendisplay der Logo. Die Lösung funktioniert ohne jegliche Kommunikations-Verbindungen zur Welt außerhalb der Maschine/Anlage.

Braucht man die exakte offizielle Weltzeit - die Logo 8 kann auch gleichzeitig NTP-Client sein. Dann muss ggf. durch die IT sichergestellt werden, dass nur die Logo mit einem Netzwerkteilnehmer außerhalb der Maschine kommunizieren kann.

Die Logo kann auch einen Bereichszeiger "Datum/Uhrzeit PLC" bereitstellen für Geräte, die die Sommerzeit-Umschaltung nicht automatisch können. (Außer bei den Logo mit Firmware 1.84.x - da ist der Bereichszeiger nicht nutzbar wegen eines Bugs, wo Siemens (oder deren Zulieferer?) anscheinend keine Lust hat, den Bug zu beseitigen.)

Wer gerne seine Maschine/Anlage häufig spannungsfrei ausschalten will, der sollte die Maschine ca alle 2 Wochen mal einschalten, damit der Goldcap aufgeladen wird und die Uhr der Logo weiterläuft. Oder nur die Logo regelmäßig mit Spannung versorgen. Die Gangreserve beträgt typisch 20 Tage. Und falls doch die Uhr stehengeblieben ist oder falsche Uhrzeit hat, dann stellt man halt einmal die Uhr der Logo. Das "lästige" Uhr stellen von SPS, HMI, ... beim erstmaligen einschalten einer Maschine beschränkt sich auf das Stellen der Uhr der Logo. Oder wenn die Uhrzeit nirgends verwendet wird, dann braucht auch gar keine Uhr gestellt werden, weil es ja nur darauf ankommt, dass alle Komponenten mit der gleichen (x-beliebigen) Uhrzeit arbeiten.

Noch ein Vorteil der Logo 8 : für die ca. 100 € bekommt man auch noch günstig einige E/A dazu, z.B. 4 Analogeingänge 0-10V, die man als dezentrale E/A mit einer SPS (oder direkt mit einem HMI ohne weitere SPS) verwenden kann (per ModbusTCP oder S7Verbindung, oder HMI-Verbindung).

 

[ducati]

Der Kasten oben holt sich seine Zeit direkt über GPS

GPS ist da ne feine Sache, aber das Platzieren der GPS-Antenne oft nicht trivial...
Irgendwas ist immer.

 

[van]

Was für ein Aufwand mit dem NTP Server, nur damit die HMI Kommunikation funktioniert ...

Und ab dem Jahr 2037 wird es dann richtig lustig, dann laufen die ganzen Standard Siemens PLC Zertifikate nämlich alle ab.
Vermutlich wegen des Unix 2038 Bug

The Unix Year 2038 problem (Y2K38) is a time-formatting bug affecting 32-bit systems that track time in seconds since January 1, 1970. On January 19, 2038, at 03:14:07 UTC, this counter will overflow, causing systems to flip back to 1901 and potentially crash or fail

Das ist in 11 Jahren, das werden die meisten hier noch aktiv miterleben.

Und dann fangen alle an ihren mühselig installierten NTP Server auf ein altes Jahr zurück zu manipulieren ...

 

[DeaD_EyE]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vermutlich wegen des Unix 2038 Bug

time_t Used for time in seconds. According to POSIX, it is an​

integer type of at least 64 bits.​

Der Bug ist schon lange behoben. Wenn die Hersteller so dumm sind, alte Quellen verwenden, haben sie die kommende Katastrophe verdient.

Das viele SSL-Zerifikate 2037 ablaufen, hat mehrere Gründe:

• 2037 liegt nahe an der technischen Grenze vieler Systeme (Year-2038-Problem)
• Viele Embedded-Systeme nutzen 32-Bit-Zeit (Unix time)
• Maximal sinnvoll darstellbares Datum: 19.01.2038

Wenn die Industrie sich das gefallen lässt, dann ist es das Problem der Industrie. Solange die Industrie nicht handelt, wird sich auch nichts ändern. D.h. 2037 werden viele Anlagen einfach aufhören zu funktionieren. Man kann ja das Ausstellen von SSL-Zertifikaten für Steuerungen als Dienstleistung anbieten.

PS: Der NTP-Server hilft bei dem Jahr 2037-Problem nicht weiter, da die Zertifikate bei richtigem Datum einfach ungültig sind. D.h. man müsste das Datum falsch einstellen, damit die HMIs weiterhin kommunizieren. Die richtige Lösung wäre dann ein Update des SSL-Zertifikats auf dem HMI.

PPS: mittlerweile sind SoC mit 64-Bit die Regel. 32-Bit-SoC findet man immer seltener. Aber selbst für 32-Bit-SoC ist time_t 64 Bit. Die embedded Steuerungen arbeiten noch mit alten Kernel und libc wo time_t nur 32 bit ist.