MB_CLIENT - Mehrere Unit-IDs abfragen

[sukram]

Hallo!

Ich stehe hier gerade mit ein paar Fragezeichen da. Ausgangssituation:

Wago 880 SPS, Codesys 2.3, OSCAT Basic 333 und Network 135.

Modbus TCP - RTU Gateway (AVR-NetIO mit Ethersex Firmware)

Modbus RTU Stromzähler Saia ALE3 bzw. ALD1
Modbus RTU 1-Wire Sensorbaustein (Eigenbau auf AVR Basis)

Die Abfrage der Modbus-RTU Geräte über PC funktioniert einwandfrei, es können nacheinander alle Daten abgerufen werden.

Ich versuche jetzt in meinem SPS-Programm, die verschiedenen RTU Unit-ID nacheinander abzufragen. Dazu Übergebe ich an eine MB_CLIENT Instanz alle Parameter und setze Enable auf TRUE. Der FB (und die IP_CONTROL dazu) wird in jedem Durchlauf wieder aufgerufen. Sobald "BUSY" wieder auf False geht und ERROR gleich 0 ist, werden die Werte aus Data[..] herauskopiert und weiterverarbeitet sowie Enable wieder auf False gesetzt. Leider bekomme ich so nur einmal die Daten aus dem ersten Gerät und dann nur noch 0, es wird kein Error gesetzt. Wenn ich den Code umstelle, sodass Enable nicht auf False gesetzt wird, wird immer nur das erste Gerät abgefragt, aber kein anderes.

Wie muss der Ablauf richtig sein? Geht das überhaupt, MB_Client parametrieren, eine Abfrage senden, neu parametrieren, eine Abfrage senden? Oder muss ich für jede Unit-ID eine extra MB_Client Instanz aufziehen (das will ich vermeiden wg. Speicherbedarf, es sollen > 30 Geräte werden)

Code kann ich noch nachliefern, ist aber etwas umständlich, weil ich viel mit Structs arbeite, um Daten/Geräte zu abstrahieren.

[sukram]

Hallo,

es gibt Neuigkeiten: Ich war in meinem Programm zu optimistisch/ungeduldig mit dem Timing. Korrekt muss der Ablauf mit einem (langsamen) TCP-RTU Gateway so aussehen:

Code Auswählen Erweitern


MB_CLIENT und IP_CONTROL2 in jedem SPS-Zyklus abfragen
IP_Control2 wird mit der Gateway-IP/Port vorkonfiguriert, kurzes Timeout

Step 1:
MB_CLIENT mit den Daten (FC, Unit-ID, Lese/Schreib-Adressen) füttern, kurzes Delay (bei mir t#15ms) einstellen

Step 2:
Auf erstes /BUSY warten -> jetzt ist die Abfrage im Gateway

-- hier läuft jetzt das interne Delay von MB_CLIENT.

Step 3:
Auf zweites /BUSY warten -> jetzt kommen die Daten zurück
jetzt liegen die Abgerufenen Daten im DATA[..] Array

Step 4:
MB_CLIENT kann jetzt neu gefüttert werden
-> zurück auf Step 1, und wiederholen bis alle Unit-IDs abgearbeitet sind


Hat mich ein paar Nerven und Tassen Kaffee gekostet, um da drauf zu kommen, aber eigentlich ist es logisch, das Gateway kann die Daten ja gar nicht sofort parat haben...