Agilent - Modbus

[Melanie Hermann]

Die Kommunikation scheint beim Timeout versetzt zu sein:
Anfrage1 -> Keine Antwort
Anfrage2 -> Antwort1
Anfrage3 -> Antwort2
...

Wird TID verwendet?

Kommunikation muss in diesem Zustand wieder in Takt gebracht werden!

[Melanie Hermann]

TID wird nicht verwendet! TID ist immer Null!

[Melanie Hermann]

1.Lösungsschritt:
TId (Transaction Identifier) in Modbus-Master eingebaut.
Das Messwerk antwortet immer mit dem vorgegebenen TId.

[Melanie Hermann]

2.Lösungsschritt:
Falls TId in Frage und Antwort unterschiedlich sind, wird eine Meldung im Diagnose-Log ausgegeben.

TODO: Was tun? Modbus-Master neu starten? Port neu? Warten, dann nochmal Receive?

[Melanie Hermann]

Update: Es gibt 2 Probleme!

1.) Problem: GC9300 - Controller zeigt ein "Timeout" an, obwohl die Kommunikation zwischen Controller und Messwerk weiterhin besteht.

2.) Problem: Modbus läuft asynchron. D.h., dass der Controller auf eine Anfrage immer die Antwort für die vorherige Anfrage erhält. Somit entsteht ein "Timeout".

[Melanie Hermann]

Zeiten der Modbusanfragen ohne/mit MesswerkZeitsync

[Melanie Hermann]

1.) Problem:
Dieses Problem besteht in der aktuellen Version (V1.330-062) nicht mehr!
Aber durch Testen wurde herausgefunden, dass das Problem durch Folgendes verursacht wird:
Der Controller sendet verschieden Anfragen-Pakete an das Messwerk. 'm_SWStatus', 'm_SWStatusChannel[x]' und 'm_SWMesswerte'.
Der Alarm "Timeout" wird dann angezeigt, wenn nicht alle Werte innerhalb der angegebenen Timeout-Zeit vom Messwerk geliefert wurden. ('WerteGuelitg()' in 'HolWerte()' schlägt immer fehl.)
Normalerweise benötigen die Blöcke folgenden Zeiten bis zur kompletten Beantwortung:
'm_SWStatus' ~ 1200 msec
'm_SWChannelStatus[x]' ~ 600 msec
'm_SWMesswerte' ~ 4000 msec
Ein Problem entsteht erst, wenn während der Bearbeitung in 'HolWerte()' ein weitere Modbusanfrage (z.B. Zeitsync an das Messwerk) zwischenreingeschoben wird. Denn dann erhöht sich die Zeit und es können nicht mehr alle Werte rechtzeitig vom Messwerk geliefert werden. Auch wenn das Messwerk nun antwortet und fast alle Werte geschickt hat, erscheint am Controller "Timeout", weil nicht ALLE Werte rechtzeitig geschickt wurden.
Ein zusätzlicher MesswerkZeitsync verlängert die Zeiten der Blöcke folgendermaßen:
'm_SWStatus' ~ 2600 msec
'm_SWChannelStatus[x]' ~ 1900 msec
'm_SWMesswerte' ~ 54000 msec
Da die Timeoutzeit in 'HolWerte()' auf 5000 msec eingestellt ist, entsteht hier ein "Timeout".
Siehe TracTicket-Anhänge.

Lösung:

• Ab V1.330-062 wird der MesswerkZeitsync direkt in CGc verschickt. Somit können sich Sync und Blockabarbeitung nicht mehr in die Quere kommen. In vorherigen Versionen wurde der Sync aus CGcApp geschickt. Somit konnte es passieren, dass dieser Sync genau während einer Blockabarbeitung geschickt wurde.
• Ab V1.331-063 wird die Timeoutzeit in 'HolWerte()' wurde von 5000 ms auf 10000 msec erhöht. Damit bei der Abarbeitung von 'm_SWMesswerte' ein größerer Zeitpuffer besteht.

[Melanie Hermann]

2.) Problem:
Dieses Problem kann nur entstehen, wenn der Controller eine Anfrage schickt und nicht innerhalb der angegebenen Timeoutzeit in 'recvtimo()' eine Antwort erhält.
Der Controller schickt dann die nächste Anfrage. Falls das Messwerk aber einfach zu lange zum Antworten gebraucht hat, hier länger als 5 Sekunden, und dann jetzt erst antwortet entsteht ein Problem. Der Modbus wird asynchron.
Der Controller erhält nun immer die Antwort auf die vorherige Anfrage. Somit passen Frage und Antwort nie zusammen und der Controller meldet ein "Timeout".
Dieses Phänomen ist im TracTicket-Anhang zu sehen.

1.Lösungsteil:

• Erhöhung der Timeoutzeit in 'recvtimo()' von 5 Sek. auf 6 Sek.