Sonstiges Zähler Variablen auf 2 bis n SPS Synchron halten

[EleXier]

Zuviel Werbung?
-> Hier kostenlos registrieren

Zähler Variablen auf 2 bis n SPS Synchron halten

Guten Tag

Ich habe die Aufgabe Zählervariablen (ms Zähler) auf 2 bis n(max ca. 100) SPS‘en (S7 1500) möglichst Synchron halten.

Suche eine Lösung mit der sich die Zähler über zB. UTP mit geringerAbweichung Synchronisieren lassen.

Gruess Willi Meier

 

[Wincctia]

Hallo Willi,

etwas mehr Infos währen gefragt wie sind die Sps mit einander Verbunden?
Welche Switche wären bei Ethernet im Einsatz ?
Sind alle im Gleichen Subnet?
Was heist geringe Abweichungen ?


Das wohl efektivste wäre ein I Slave als Profinrt Tn da wär sogar Irt möglich.


Mit freundlichen Grüßen Tia

 

[EleXier]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hier noch einige Ergänzenden Angaben zu den Fragen von TIA

Ziel ist es, CPU‘s der S7-1500 Familie, untereinander Synchron zu halten.
Es muss mit Standard Netzwerkkomponenten realisiert werden können.
Die CPU’s sind alle im gleichen Sub-Netz eingebunden.
Die Zahler-Abweichung sollte 50ms nicht übersteigen.

Die jetzige Lösung eine CPU als Synchron-Master, die weiteren CPU’s als Synchron-Slave werden vom Master über UTP Synchron gehalten. Die damit erreichte Genauigkeit ist zu ungenau, es sind Abweichungen von über 200ms möglich.
Ziel ist eine Abweichung von unter 50ms zu erreichen.

Der Synchronzuhaltende Zähler dient für den Blinktakt. Es soll erreicht werden das alle Blinkend angesteuerten Verkehrssignale anlagen weit Synchron Blinken.

Gruess Willi

 

[_Eddi_]

Sowas hier? https://support.industry.siemens.co...imatic-verfahren-konfiguriert-?dti=0&lc=de-WW

 

[Wincctia]

Hallo Willi,

evtl mal mit Profinet und i Device Versuchen
https://support.industry.siemens.co...der-profinet-i-device-funktion?dti=0&lc=de-WW

hier die Siemens Anleitung zu.

Wenn du ohne Irt ( Taktsynchronität) Arbeitest Sollte das auch mit Normalen Netzwerk funktionieren.

Mit freundlichen Grüßen tia

 

[Fabpicard]

Zuviel Werbung?
-> Hier kostenlos registrieren

Blöde Frage vielleicht, aber warum synchronisiert ihr die ganzen SPSen nicht auf einen ordentlich genauen Timeserver und lasst dann die Echtzeituhr in der 1500er die Arbeit für euch erledigen?
NTP selbst schafft über das Internet ja schon bis runter auf 10ms, im eigenen Intranet mit ordentlichem Zeitnormal könnte man da sogar runter bis aus 200 Microsekunden Gut, das wird die SPS nicht mehr mitmachen

MfG Fabsi

 

[EleXier]

Sali Fabpicard

Die Urzeit wird vom Verkehrs-Rechner Vorgegeben, der Synchronisiert die SPS Steuerungen mit einem Telegramm. So kann die Urzeit nicht genau genug Eingestellt warden.

Gruess Willi

 

[PN/DP]

Die Urzeit wird vom Verkehrs-Rechner Vorgegeben, der Synchronisiert die SPS Steuerungen mit einem Telegramm. So kann die Urzeit nicht genau genug Eingestellt warden.

Ist der Verkehrs-Rechner uralt und beherrscht noch nicht die schon laaange üblichen Standardprotokolle zur genauen Uhrzeitsynchronisation? Kann das nicht eingestellt/nachgerüstet werden?


"Synchronisieren" = es muß ein Signal übertragen werden, was von allen SPS gleichzeitig empfangen wird (oder der Zeitversatz muß bekannt sein und kompensiert werden)

Wie weit sind die SPS voneinander entfernt? Man könnte ein (24V-)Synchronsignal per Kabel (+ ggf. Optokoppler) an alle SPS verdrahten.

Kann die S7-1500 schon "direkten Datenaustausch (Querverkehr)" als Profinet-I-Device?
Kann eine S7-1500 eigentlich Broadcast-Nachrichten im Anwenderprogramm empfangen?

Harald

 

[EleXier]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo PN/DP
Die Kommunikation mit dem Verkersrechner Basiert auf TLS (Protokolle/Telegramm Definitionen von der Bundesanstalt für Strassenwesen DE) die über TCP/IP übertragen werden.
Das kann/darf nicht geändert warden.

 

[smoe]

Wenn du "neben" der TLS Kommunikation eine zusätzliche Kommunikation machen darfst, kannst du ja einen zentralen Timeserver nehmen. Wenn der "Verkehrsrechner" das nicht kann, gibt es Alternativen. Das könnte dann zb ein DCF77 oder ein zentraler GPS Empfänger sein. Gibst auch von $iemens. Das Uhrzeit Telegramm vom TLS musst du dann aber auf den Steuerungen ignorieren. Kannst/Darfst du das überhaupt?

 

[Onkel Dagobert]

.. Die Kommunikation mit dem Verkersrechner Basiert auf TLS (Protokolle/Telegramm Definitionen von der Bundesanstalt für Strassenwesen DE) die über TCP/IP übertragen werden.
Das kann/darf nicht geändert warden.

Dürfte denn Profinet über das selbe Netzwerk laufen? Wahrscheinlich eher nicht, oder? Profinet würde ich würde ich als einzige Netzwerk-Lösung für deine gehobenen Ansprüche ansehen. Andere Kommunikationsarten über TCP/IP scheitern wahrscheinlich schon an der Anzahl der Verbindungen. Ich bin in Sachen Kommunikation allerdings nicht gerade der mit dem ganz großen Überblick.

Habt ihr Stromzähler in euren Anlagen? Dort könnte man den 1/4h-Impuls zum Synchronisieren verwenden. Den habe ich zum Korrigieren der Uhrzeit in Einzelanlagen schon verwendet. Wie exakt synchron dieser ausgegeben wird, weiß ich aber nicht. Weiß das jemand genauer?


Gruß, Onkel

Korrektur:
DCF77 ist gar nicht so geeignet, lest selbst.
Ich habe das mal aus meinem obigen Beitrag entfernt.

 

[EleXier]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sali smoe

Telegramme von den SPS Steuerungen an den Verkehrsrechner enthalten Zeitstempel, der muss in „etwa“ mit der Urzeit des den Verkehrsrechner übereinstimmen, sonst werden die Telegramme verworfen. Die Urzeit wird von Verkehrsrechner vorgegeben. Es ist nicht sinnvoll den Blinktakt-Zähler und die Urzeit zu koppeln.

 

[PN/DP]

Ist es denn überhaupt sinnvoll, örtlich verschiedene Verkehrssignale synchron blinken zu lassen oder ist das ein Hobby von Dir?
Suchst Du eine patentfähige Lösung?
Dürfen die SPS überhaupt über selbstgestrickte Protokolle untereinander kommunizieren und die Blinktakterzeugung beeinflussen?

Wie genau bzw. ungenau ist denn die Uhrzeitsynchronisation durch den Verkehrsrechner? Wie sehr schwanken die UDP-Telegrammlaufzeiten in dem Netzwerk? Wenn sie nur sehr wenig schwanken, könnte man die Laufzeiten dynamisch messen oder einmalig Korrekturwerte ermitteln und in den Steuerungen hinterlegen. Der Sync-Master müsste die Telegramme nur sehr exakt ge-timed absenden. Wie hoch ist die Zykluszeit der SPSen?

Harald

 

[smoe]

Also wenn du die lokale Uhrzeit des Verkehrsrechners nicht verstellen kannst, bring es auch nichts die Uhrzeiten der Steuerungen zu verstellen. Dann musst du das ganze Uhrzeitsystem lassen wie es ist.

Also brauchst du ein "Synchronisierungssignal" abseits der Uhrzeit. Das kann sein, wie schon erwähnt ein Hardwaresignal (24V Eingang) oder ein UDP Broadcast Telegramm von einer der Steuerungen an alle anderen oder per Profinet verbund von einer als Controller definierten Steuerung zu den anderen als Device. Profinet funktioniert auch paralell in deinem bestehenden Ethernet netzwerk sofern alle Steuerungen und die Switche das können.
Allerdings bei so vielen Teilnehmern würde ich zu UDP Broadcast neigen. Du musst darauf achten die ungenauigkeiten die durch deinen CPU Zyklus entstehen zu berücksichtigen.

 

[_Eddi_]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was spricht denn dagegen, zwei Uhrzeiten zu verwalten, eine für die Synchronisation, und eine für die Kommunikation mit dem Zentralserver? Bzw. über "übliche" Protokolle zu synchronisieren, aber das Ergebnis nicht als neue Uhrzeit zu nehmen, sondern ein Offset verwalten.

 

[Thomas_v2.1]

Meiner Meinung nach wäre auch NTP hier die Lösung der Wahl. Wenn du eine Zähler- oder Zeitsynchronisation selber programmieren müsstest, würdest du früher oder später auf die gleichen Probleme stoßen, die im NTP-Protokoll alle schon gelöst sind.
Die Signalleuchten an Windrädern in Windparks werden soweit ich weiß auch per NTP synchronisiert. So wie ich mal gelesen habe gibt es da eine Masteruhr für den gesamten Park mir der sich alle Windräder synchronisieren.

Vielleicht ließe sich da etwas mit einem separaten CP lösen. Bei der S7-300 und Sinaut-Baugruppen ist es möglich, dass sich nur die einzelne Baugruppe per NTP synchronisiert, aber nicht unbedingt mit der SPS Uhrzeit synchronisiert. Bei manchem CPs der 3007400er gibt es auch die Option, eine Baugruppe als Uhrzeitmaster oder Slave zu parametrieren.

Oder was wirklich Hochpräzises wie dieses hier:
https://www.meinberg.de/german/prod...itserver-ieee-1588-master-slave.htm#Downloads

Bei der Anzahl würde ich vlt. mal bei Meinberg anfragen ob sie dir eine passende Lösung anbieten können.

 

[Fabpicard]

Die Kommunikation mit dem Verkersrechner Basiert auf TLS

Mal von 0 angefangen: TLS ist lediglich die Sicherungsschicht damit keiner an den übertragenen Paketen unterwegs "rumfummeln" kann... Was da jetzt genau geschickt wird, steht dann wohl in den Unterlagen von der BASt...
Was dir auch völlig egal sein kann, denn:
Du änderst nichts an diesen Geschichten, du packst eine weitere Funktion ins Netzwerk. Was du ja mit UDP usw. eh machen möchtest...
Dann erhöhst du die Prozesssicherheit, weil ja der Verkehrsrechner wie du sagtest (zitat) "gibt die Uhrzeit vor...
Wenn also jetzt der Verkehrs(leit)rechner die Uhrzeit jetzt einfach zusätzlich noch genauer an seine untergebenen Teilnehmer verteilt, diese für TLS ebenfalls damit arbeiten, hast du einen Gewinn!

So und nun liest du dich bitte hierein mal ein:
https://de.wikipedia.org/wiki/Network_Time_Protocol#tlsdate

Das ist genau Das, was du gerade suchst

Dürfte denn Profinet über das selbe Netzwerk laufen?

Da deren Kommunikation aus Sicherheitsgründen per TLS geschützt laufen muss, würde ich solche Spiele mit zus. Profinet lassen, da sonst alle Steuerungen große Scheunentore bekommen

Korrektur:
DCF77 ist gar nicht so geeignet, lest selbst.

Naja, die sog. Kurzzeitstabilität ist nicht sonderlich berauschend... Aber man packt ja auch keinen DCF77-Empfänger an eine SPS um daraus ein gutes Zeitsignal zu erhalten.
Wenn nimmt man hier ein ordentliches Frequenznormal, welches als Grundbasis in dem eigentlich Zeitnormal über DCF77 lediglich die "Zeitkorrektur" erhält und das Frequenznormal über Wochen und Monate immer schön leicht nachjustiert...
Damit erreichst du dann nach >6 Monaten Laufzeit auch schon Werte die bei Abweichungen von <1ms liegen.

Ist bei GPS aber nicht sonderlich anders, wenn du ein solches Teil einschaltest dauert es auch mehrere Stunden bis Tage, bis dort dauerhaft sauber eine brauchbare Zeit raus kommt...

MfG Fabsi