Kommunikation EnOcean<-->Modbus

[Stefan mit F]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich muss mal wieder stören.

Meine Aufgabe ist es von SR04P-Temperaturfühler und SAB02-Stellantrieben jeweils die Daten auslesen. Diese Geräte senden an ein STC65-RS485 Modbus Gateway via EnOcean, welches zu meiner Wago 750-881 über Modbus sendet und empfängt.

Nun folgendes Problem:
Der ModbusMaster gibt mir in unregelmäßigen Abständen einen CRC-Error aus, ist aber den größsten Teil ohne Fehler. Die Modbusparametrierung habe ich geprüft und (soweit die Datenblätter mich das haben lesen lassen) angepasst. Bytesize und Stopbits habe ich in allen Variationen vertauscht und geändert ohne das sich ein stabiler fehlerfreier Zustand eingestellt hat.
Davon habe ich mich dennoch nicht abschrecken lassen und angefangen das Telegramm meines Temperaturfühlers auszulesen. Die ersten zwei Register sind kein Problem, bloß sobald ich mehr möchte, wirbelt der Fehlerausgang im .typModbusResponse wild mit Meldungen um sich.

Könnte einer von euch mir helfen?

Mit freundlichen Grüßen
Stefan

 

[Stefan mit F]

Okay... ich bin jetzt mal über die Configurationssoftware von Thermokon aufs Gateway gegangen, wo ich super alles auslesen kann. Prinzipiell hab ich auch keine Fehlermeldung, außer nach durchschnittlich 7min meldet er Kommunikationsproblem, welches aber verschwindet, wenn ich den Port schließe und öffne. Innerhalb dieser Software bleiben die Werte auch da, wo sie hingehören, im Gegensatz zu meinem CoDeSys-Programm, denn dort tritt seit heute ein neues Problem auf. Wenn ich über die Modbus-Dienste eine Adresse abfrage, dann schreibt er mir die auch ordentlich in die .Data. Danach schreibt er dort aber auch eine komplett andere Adresse drüber, die ich nicht in diesem Slave-Aufruf abfrage (mehrfach und mit unterschiedlichen Registern)

Der Wago und Thermokon Support konnten mir bisher nicht helfen. Hat einer von euch eine Ahung, was dieses Chaos verursachen könnte?

Grüße
Stefan

 

[Markus Rupp]

Zuviel Werbung?
-> Hier kostenlos registrieren

Um das zu beurteilen müßte ich erstmal genaueres wissen über die programmierung haben, imo erscheint es mir als würdest du im codesys den datenpuffer nicht konsistent zu halten. es empfiehlt sich den datenpuffer telegrammorientiert aufzubauen. wie sieht dein modbus-steuer-allgorithmus aus?

 

[Stefan mit F]

Hallo,

ich benutze den Baustein ModbusMaster mit den Kommunikationsparametern (bCom_Port, cbCOM_BAUDRATE, cp_COM_PARITY, csCOM_STOPBITS, cbs_COM_BYTESIZE, cfCOM_FLOW_CONTROL) und der SlaveList als Eingang. Ausgang ist MB_Error. Mit der SlaveList greife ich dann via Modbus-Dienste auf die jeweilige Adresse zu, z.B. so:

SlaveList[6].typModbusExtendedQuery.SlaveAddress:=2;
SlaveList[6].typModbusExtendedQuery.Functioncode:=3;
SlaveList[6].typModbusExtendedQuery.Read_StartAddress:=13; //laut Datenblatt sollte das Data-Byte-3 des Sensors 2 sein
SlaveList[6].typModbusExtendedQuery.Read_Quantity:=2;
SlaveList[6].typModbusExtendedQuery.Write_StartAddress:=0;
SlaveList[6].typModbusExtendedQuery.Write_Quantity:=0;
SlaveList[6].tTimeOut:=T#0s500ms;

Das macht er auch und schreibt mir meinen Wert in die .Data und kurz darauf wird das mit den ID-Bytes überschrieben.

Zum Thema Datenpuffer kann ich dir leider nichts sagen, da ich zugegebenermaßen noch ziehmlich grün hinter den Ohren bin :-?

Grüße
Stefan

 

[Markus Rupp]

kann es sein das es auch schreibbefehl gibt?

du solltest den datenbereich .Data wegsichern, bedingtes move wäre hier hiflreich.

ich hab mir damals ne lib geschrieben die auf der modbus-lib von wago aufsetzt aufsetzt.

 

[Stefan mit F]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

vielen Dank für die Antwort.

Ich habe jetzt mal nur das Modbusprogramm in der Taskkonfiguration abarbeiten lassen und anscheinend muss ich nicht alles falsch gemacht haben, da es so tadellos funktioniert. Sogar die 10 Register pro Sensor lassen sich schnell und richtig auslesen. Bloß wenn ich wieder mein PLC-Programm plus Visu und I/O-Beleg aufspiele, überträgt er nun keine Daten mehr, soll heißen die .typModbusResponse bleibt leer. Verschieben von Priotritäten und Zykluszeiten blieb erfolglos. Ich hab keine Ahnung, was da schief läuft

Grüße
Stefan

 

[Markus Rupp]

kann es denn sein, das du im programm statische adressierung verwendest? für mich klingt das nun nach zwei möglichkeiten:

entweder liegt dein udt .typmodbusresponse in einem doppelt referenzierten speicherbeich (beispielsweise io-ebene am modbus-tcp) oder es wird im plc_prg unkoordiniert durch direkte adresszuweisung beschrieben.

nimm mal alles aus der i/o-belegung raus, hier dürfte normalerweise alles ok sein und der modbus funktionieren.
danach nimmst du netzwerk für netzwerk aus dem original plc_prg und baust es ins testprogramm ein.


irgendwann sollte der fehler auftretten und das verursachende netzwerk gefunden sein.

 

[Stefan mit F]

Hallo,

nochmals Danke für die Hilfe, jedoch hat sich nun mein Chef für eine andere Lösung entschieden und ein weiteres Bearbeiten in diese Richtung ist damit hinfällig.

Mit freundlichen Grüßen
Stefan