TIA LSNTP-Server Status 16#7002 und immer noch busy

B

Boesling

Level-2
Beiträge
22
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Forum,
ich muss einen NTP-Server auf einem OpenController mit Software-CPU 1505SP aufsetzen um die angeschlossenen MTP unified Panels zu synchronisieren.
Programmiert wird in TIA19 Upd3.
Die Installation der Bibliothek war problemlos, allerdings kann ich in der Doku keine weiterführende Aussage zum Status 7002 finden. Nach Aktivierung des FB LSNTP-Server gehen "valid" und "busy" auf true und am Status erscheint die 7002 "Folgeaufruf der Anweisung". Müsste nicht nach erfolgreichem Senden der Zeit das busy-flag auf "FALSE" gehen? Eine Fehlermeldung kommt nicht.
Danke für eure Hilfe und viele Grüße vom Boesling.

SNTP.png
 
Mal nen Trace gemacht? Die Signale könnten auch nur für einen Zyklus wechseln, was du evtl. nicht mitbekommst durch das Beobachten.

-chris
 
Boesling schrieb:
Hallo Forum,
ich muss einen NTP-Server auf einem OpenController mit Software-CPU 1505SP aufsetzen um die angeschlossenen MTP unified Panels zu synchronisieren.
Programmiert wird in TIA19 Upd3.
Die Installation der Bibliothek war problemlos, allerdings kann ich in der Doku keine weiterführende Aussage zum Status 7002 finden. Nach Aktivierung des FB LSNTP-Server gehen "valid" und "busy" auf true und am Status erscheint die 7002 "Folgeaufruf der Anweisung". Müsste nicht nach erfolgreichem Senden der Zeit das busy-flag auf "FALSE" gehen? Eine Fehlermeldung kommt nicht.
Danke für eure Hilfe und viele Grüße vom Boesling.

Anhang anzeigen 86236
Zum Vergrößern anklicken....
Was sagt denn xxx.Diag?
Quark: Das kommt ja erst bei nem Error
 
8.2.2. Fehlerhandling
Allgemeine Informationen zu den Statusausgängen und zur Diagnose der Bausteine dieser Bibliotheken finden Sie im Kapitel 12.2.
Nachfolgend sind die für die Bibliothek "LSNTP" spezifischen Status- und Fehlercodes aufgeführt.
Tabelle 8-4: Status- und Fehlercodes
Status
Bedeutung
16#0000
NTP-Telegramm an einen (S)NTP-Client verschickt
16#0001
NTP-Telegramm eines (S)NTP-Clients erhalten
16#7000
FB wird nicht ausgeführt
16#7001
Erstaufruf der Anweisung
16#7002
Folgeaufruf der Anweisung
16#7003
Baustein wird deaktiviert
16#7F01
Ungültiges Paket erhalten
16#8600
FB befindet sich in einem ungültigen Zustand
16#8601
Fehler in unterlagerter Anweisung "TCON"
Der Fehlercode der Anweisung wird an "diagnostics.subfunctionStatus" ausgegeben. Die Bedeutung des jeweiligen Fehlercodes entnehmen Sie dem TIA Portal Informationssystem.
16#8602
Fehler in unterlagerter Anweisung "TUSEND"
Der Fehlercode der Anweisung wird an "diagnostics.subfunctionStatus" ausgegeben. Die Bedeutung des jeweiligen Fehlercodes entnehmen Sie dem TIA Portal Informationssystem.
16#8603
Fehler in unterlagerter Anweisung "TURCV"
Der Fehlercode der Anweisung wird an "diagnostics.subfunctionStatus" ausgegeben. Die Bedeutung des jeweiligen Fehlercodes entnehmen Sie dem TIA Portal Informationssystem.

Handbuch hier:
Bibliotheken für Kommunikation ....
 
Wenn enable FALSE ist:

1742880451484.png

1742880481068.png


Wenn enable TRUE ist und alles OK:

1742880503621.png

1742880511125.png


Während der Abfrage ändert sich am busy nix, zumindest nicht über die Beobachtung sichtbar. Der error kommt z. B. wenn du eine falsche hwID verwendest. Dann geht auch busy und valid weg.
 
Naja, der Server-Baustein prüft ja permanent ob ein NTP-Telegramm reingeflattert kommt.
Macht also irgendwie Sinn, dass der Baustein ständig busy, also beschäftigt, ist ¯\_(ツ)_/¯
 
Zuviel Werbung?
-> Hier kostenlos registrieren
sirbarny schrieb:
Anhang anzeigen 86246

Frag ihn halt mal ab. IP natürlich von dir nehmen.
Zum Vergrößern anklicken....

sirbarny schrieb:
8.2.2. Fehlerhandling
Allgemeine Informationen zu den Statusausgängen und zur Diagnose der Bausteine dieser Bibliotheken finden Sie im Kapitel 12.2.
Nachfolgend sind die für die Bibliothek "LSNTP" spezifischen Status- und Fehlercodes aufgeführt.
Tabelle 8-4: Status- und Fehlercodes
Status
Bedeutung
16#0000
NTP-Telegramm an einen (S)NTP-Client verschickt
16#0001
NTP-Telegramm eines (S)NTP-Clients erhalten
16#7000
FB wird nicht ausgeführt
16#7001
Erstaufruf der Anweisung
16#7002
Folgeaufruf der Anweisung
16#7003
Baustein wird deaktiviert
16#7F01
Ungültiges Paket erhalten
16#8600
FB befindet sich in einem ungültigen Zustand
16#8601
Fehler in unterlagerter Anweisung "TCON"
Der Fehlercode der Anweisung wird an "diagnostics.subfunctionStatus" ausgegeben. Die Bedeutung des jeweiligen Fehlercodes entnehmen Sie dem TIA Portal Informationssystem.
16#8602
Fehler in unterlagerter Anweisung "TUSEND"
Der Fehlercode der Anweisung wird an "diagnostics.subfunctionStatus" ausgegeben. Die Bedeutung des jeweiligen Fehlercodes entnehmen Sie dem TIA Portal Informationssystem.
16#8603
Fehler in unterlagerter Anweisung "TURCV"
Der Fehlercode der Anweisung wird an "diagnostics.subfunctionStatus" ausgegeben. Die Bedeutung des jeweiligen Fehlercodes entnehmen Sie dem TIA Portal Informationssystem.

Handbuch hier:
Bibliotheken für Kommunikation ....
Zum Vergrößern anklicken....
Ja, das hatte ich schon gelesen, aber die Meldung "Folgeaufruf der Anweisung" fand ich jetzt nicht so hilfreich. Ich hätte eher die 16#0000 erwartet, da der NTP-Server ja funktioniert.
 
Botimperator schrieb:
Naja, der Server-Baustein prüft ja permanent ob ein NTP-Telegramm reingeflattert kommt.
Macht also irgendwie Sinn, dass der Baustein ständig busy, also beschäftigt, ist ¯\_(ツ)_/¯
Zum Vergrößern anklicken....
Ja, wahrscheinlich. Hier wird aber die CPU auf das Windowssystem des OpenController synchronisiert, welches selbst an einem NTP hängt. Die CPU ist dann aber der NTP-Server für die HMIs, da die HMIs über PN keinen Zugang auf das hausinterne Netz haben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
A3Q schrieb:
Mal nen Trace gemacht? Die Signale könnten auch nur für einen Zyklus wechseln, was du evtl. nicht mitbekommst durch das Beobachten.

-chris
Zum Vergrößern anklicken....

Boesling schrieb:
Ja, das hatte ich schon gelesen, aber die Meldung "Folgeaufruf der Anweisung" fand ich jetzt nicht so hilfreich. Ich hätte eher die 16#0000 erwartet, da der NTP-Server ja funktioniert.
Zum Vergrößern anklicken....



So, ich habe mich mal bemüht und habe es kurz simuliert.
Wie im Trace zu sehen bleibt Valid und Busy auf TRUE, solange der Baustein ganz normal arbeitet.

Der Status ändert sich wie in der Dokumentation beschrieben von 16#7002 auf 16#0000 und wieder zurück zu 16#7002, sobald ich ein Telegramm abfrage bzw. mir eins gesendet wird (Befehl in der Eingabeaufforderung). Beende ich das über die Eingabeaufforderung, bleibt der Status bei 16#7002.

Bitteschön.

Link zur Doku und Bibliothek:
https://support.industry.siemens.com/cs/document/109780503/bibliotheken-für-kommunikation-für-simatic-controller?dti=0&lc=de-DE

1742890489111.png



-chris
 
Kann ich bestätigen, ich habe den auch im Einsatz und da ist auch valid, busy true und status 16#7002
Habe es getestet, wenn man bei Geräten mit falscher Zeit den Server einrichtet, werden die ordnungsgemäß synchronisiert (getestet am KRC5)
 
Zurück
Oben