MODBUS TCP und Festo CPX-CEC-M1

[cloidnerux]

Hallo,

ich habe eine Festo CPX-CEC-M1 im Einsatz, die per MODBUS TCP mit zwei Rechnern kommunizieren soll.
Nur will die OSCAT Implementation nicht.
Ich bekomme dauerhaft einen Fehler FD000000 - "253 von Remote beendet", im Wireshark sehe ich viele Pakete und jede mange Daten(Auch solche, die gar nicht gesendet werden dürften?), aber nichts davon ist ein valides MODBUS Paket.

In Verwendung ist CoDeSys 2.3.9.42, oscat basic 3.33 und oscat network 1.3.
Ich habe mein Modul nach dem Beispiel aus der network.lib gebaut, siehe Anhang.
Ich habe die oscat Bibliotheken selber nochmal für mein Zielsystem übersetzt, habe schon versucht SYSLIBSOCKETS_OPTION auf 1 zu setzten, aber nichts hat geholfen.
Woran kann es noch liegen, dass es nicht funktioniert?

Gruß,

cloidnerux

[gelöscht durch Administrator]

[peewit]

hi

in deinem bild kann man so gut wie keine relevanten online zustände erkennen

aber was viel hilfreicher wäre ist der wireshark datenmitschnitt

stelle diesen doch online mit kurzen hinweiss auf den relevanten ip-adressen

[cloidnerux]

Hi,

im Anhang ein Wireshark capture der Kommunikation der PLC *.20 und dem Rechner *.10

[gelöscht durch Administrator]

[peewit]

hi

in wireshark kannst du bei "filter" tcp.port == 502 eingeben dann siehst du nur mehr kommunikation die modbus tcp betrifft.

1. für Festo CPX-CEC-M1 kann ich dir nicht sagen ob das damit überhaupt läuft bzw jemand schon erfolgreich benutzt hat.
    es ist zwar das gleiche codesys aber die tcp-stack implementierung macht jeder kunde selber
    dabei ergeben sich immer individuelle fälle wo sich etwas anders verhällt als bei anderen

2. meiner meinung nach versucht die steuerung ständig eine tcp-ip verbindung aufzubauen
    und interpretiert dann aber eine antwort falsch und beendet daraufhin selber den verbindungsaufbau
    und das ganze in dauerschleife und affenartiger geschwindigkeit.

3. von da an wird es ziemlich schwierig denn grund zu finden, wenn man mit dem ganzen nicht vertraut ist
    da ich keine fest sps habe kann ich dir auch ziemlich schlecht helfen.

4. gibt es von festo selber irgendwelche bausteine die eine tcp-ip verbindung aufbauen die man als referenz heranziehen könnte. ?


5. was genau passiert kann man im baustein "ip_control" ab zeile 293 online sehen (breakpoints setzen ..)
je nach plattform wird aufgrund des wertes von bytes_received erkannt ob ein abbruch erwünscht wird
hier kommt ziemlich wahrscheinlich ein abnormaler wert der dann als abbruchwunsch interpretiert wird.
diesen wert gilt es herauszufinden !
notfalls kannst du mal den case o zweigt mit "c_status := 253;" totbrücken ob probieren was dann los ist.

das wird aber nicht einfach für dich .....


   ELSE
      bytes_received := SysSockRecv(socket, ADR(R_BUF.BUFFER[r_offset]), r_count, 0);
   END_IF;

   (*UDP: IPC returns -1 if no data available or error occured,841 returns -1 if error occured and 0 if no data available*)
   CASE bytes_received OF
   -2147483648..-1: ; (* No data available or error occured *)
    0: IF NOT udp_mode THEN (* TCP-Mode: socket wurde von remote geschlossen *)
         c_status := 253;
         c_ready := FALSE;
      END_IF;
   ELSE (* daten wurden empfangen *)
        r_time := tx; (* Receive Timer ruecksetzen *)
      R_BUF.SIZE := INT_TO_UINT(r_offset + DINT_TO_UINT(bytes_received)); (* aktuelle buffersize eintragen *)
      IP_C.MAILBOX[1] := IP_C.MAILBOX[1] + 1; (* Receive Info *)
      IF IP_C.MAILBOX[1] = 0 THEN IP_C.MAILBOX[1] := 1; END_IF;

[mattsches]

Hallo cloidnerux,

der CPX-CEC kann meines Wissens von Haus aus schon Modbus TCP, entsprechende Bausteine müssten in den mitgelieferten Bibliotheken dabei sein. Hast du es damit schon probiert?

Ich habe gerade keine geeignete Codesys-Installation greifbar und kann nicht mal eben nachsehen. Könnte ich aber zu einem späteren Zeitpunkt nachholen.

Gruß,
mattsches

[peewit]

probiert nein, da ich diese sps nicht besitze und auch relativ selten verwendet wird

[cloidnerux]

der CPX-CEC kann meines Wissens von Haus aus schon Modbus TCP, entsprechende Bausteine müssten in den mitgelieferten Bibliotheken dabei sein. Hast du es damit schon probiert?

Ja, diese Module habe ich schon im Einsatz.
Der Grund warum ich eigentlich auf oscat umsteigen wollte ist der, dass die mitgelieferten Module unter Umständen einen PLC Deadlock erzeugen. Weiterhin ist der Umgang mit Fehlerzuständen nicht so berauschend. Fällt ein MODBUS Teilnehmer weg kann es passieren, dass ich keine Kommunikation wieder aufbauen kann, auch wenn der Teilnehmer wieder online ist.

[peewit]

hi

ich habe ja den verdacht das die integration der ethernet funktion etwas wackelig integriert sind
wenn die origonal bausteine schon so mittelmaessig sind, dann liegt etwas im argen....

[cloidnerux]

Kann es sein, dass die Implementation des Sendens im ip_control2 nicht so super sauber ist?
Im Wireshark log ist ja zu sehen, das ab und zu sehr große Pakete verschickt werden(~500byte).

Ich habe mich jetzt mal durch den Code gewühlt und dabei folgendes gefunden:
Die Maximale Datenmenge wird bestimmt aus der Buffer Größe:

Code: [Auswählen]

s_total := LIMIT(0,UINT_TO_INT(S_BUF.SIZE),r_max_size);Die Anzahl zu versendender Bytes wird aus diesem Maximum berechnet:

Code: [Auswählen]

s_cur_size := s_total - s_cur_pos;
Ich habe ja, wie im ersten Post zu sehen, die DataSize am Modbus-Baustein auf 255 gesetzt. Kann es sein, dass einfach versucht wird mehr Daten als nötig/möglich zu senden?

[peewit]

hi
die frage ist ob die 500 bytes berechtigt sind und einen logischen grund haben

das eine ist die groesse der modbus tabelle , also die anzahl an modbus registern
je nach verwendeten modbus befehls werden dann mehr oder weniger modbus register verarbeitet.

die längenbegrenzung in ip_control ist eine allgemeine

das prinzip ist folgend

du füllst den ip_control datenbuffer mit deinen datenbytes
trägst dann die datenlänge ein, und dass veranlässt den ip_control genau diese menge an bytes zu versenden

wenn dort 500bytes angegeben werden dann werden auch soviel versendet

es wäre von vorteil wenn die den wireshark mitschnitt online stellen würdest
bzw. auch den codeausschnitt mit den modbus-tcp aufrufen

nur so kann dir jemand weiterhelfen....

[cloidnerux]

es wäre von vorteil wenn die den wireshark mitschnitt online stellen würdest

Ich beziehe mich noch immer auf den Mitschnitt, den ich am 25.09 hier als Anhang hochgeladen habe.

bzw. auch den codeausschnitt mit den modbus-tcp aufrufen

Der Aufruf ist als Bild im Anhang zu meinem ersten Post. Ich instantiiere einen FB des Types MB_CLIENT in einem CFC, setze die Eingänge fest und setze dann Enable auf true.

die frage ist ob die 500 bytes berechtigt sind und einen logischen grund haben

Nein, sie haben kein Berechtigung.

Ich werde bei der nächsten Gelegenheit das nochmal testen, im Moment komme ich nicht an die SPS heran.

[peewit]

hi

in deinen bild sind keine onlinezustände und somit einige parameter nicht zu sehen

den alten wireshark mitschnitt habe ich mir doch schon durchgesehen und gesagt das der verbindungsaufbau schon nicht mal funktioniert

woher nimmst du die erkenntnis das 500 bytes grosse datenpakete per modbus ausgetauscht werden ?

was du wahrscheinlich siehst ist die kommunikation zwischen codesys und sps um die onlinezustände zu erfassen


prüfe doch nochmals diese infos...
 

[cloidnerux]

So, der Hauptfehler ist gefunden ab Zeile 298:

Code: [Auswählen]

bytes_received := SysSockRecv(socket, ADR(R_BUF.BUFFER[r_offset]), r_count, 0);
...
CASE bytes_received OF
-2147483648..-1: ; (* No data available or error occured *)
0: IF NOT udp_mode THEN (* TCP-Mode: socket wurde von remote geschlossen *)
c_status := 253;
c_ready := FALSE;Bei der Festo gibt SysSockRecv 0 zurück, wenn er nichts empfangen hat. Der Code hat es als abbruch gedeutet und den Socket geschlossen. Ich habe die Zeilen 0:... Auskommentiert und nun funktioniert die Kommunikation.

[peewit]

das war zu erwarten das hier eine abweichung besteht

es ist nur eines zu beachten
wenn die gegenseite die verbindung beendet, bemerkt deine sps nichts davon und die verbindung bleibt sozu sagen hängen !

wahrscheinlich ist folgendes nun richtig

wert < 0 bedeutet verbindungsabbruch wunsch
wert = 0 nichts passiert....
wert >0  anzahl der empfangenen datenbytes

du musst nun das case auswertung danach korrigieren

dann sollte auch ein beenden von der anderes seite aus funktionieren
ausprobieren: connect / disconnect  / connect von der der andere seite


wie man sieht sind die firmen sehr kreativ und machen inkompatible lösungen !
vielleicht kannst du mal versuchen an die genaue doku von der cpx zu kommen
oder mal beim hersteller nachfragen bezüglich SysSockRecv

[cloidnerux]

wenn die gegenseite die verbindung beendet, bemerkt deine sps nichts davon und die verbindung bleibt sozu sagen hängen !

Jop, das passiert im Moment.

wert < 0 bedeutet verbindungsabbruch wunsch
wert = 0 nichts passiert....
wert >0  anzahl der empfangenen datenbytes

Werde ich mal verifizieren.

vielleicht kannst du mal versuchen an die genaue doku von der cpx zu kommen
oder mal beim hersteller nachfragen bezüglich SysSockRecv

Ich frage mal bei Festo.

Danke für die Hilfe.