DIO Modul wird nicht erkannt

Ingo · Post by **Ingo** » 07 Oct 2019, 18:06

Hallo,

kann ich da auch einmal mein Senf dazu geben?
Gehen wir es doch einmal Systematisch an.
Bitte Versucht nur den Core und das DIO Modul zu betreiben ohne das Gateway. Sollte das klappen, Ok
Dann bitte das Gateway links an den Core anstecken wenn Ok dann so lassen. Wenn nicht Ok dann Verbindung zur Maschine trennen
Es kann auch sein das der Fehler von der Maschine kommt nun nicht einmal die Hardware das Problem verursacht. Könnt Ihr das auch ohne Datenverbindung zur Maschine Testen?

Ich kenne das zugut von meinem Problem. da habe ich auch zeitweise Rot gesehen aber das lag an dem Modbus der keine Daten Empfangen hat weil es dort ein Problem gab und somit das DIO auch auf Rot gewechselt hat.
Ihr solltet erstmal nur die Hardware Core+DIo+Gateway in Betrieb nehmen und schauen ob es noch immer zu diesem Problem führt. wenn nicht dann wisst ihr schon einmal wo der Fehler zu suchen ist.

flowp · Post by **flowp** » 08 Oct 2019, 06:57

Ingo wrote: ↑07 Oct 2019, 18:06 Hallo,

kann ich da auch einmal mein Senf dazu geben?
Gehen wir es doch einmal Systematisch an.
Bitte Versucht nur den Core und das DIO Modul zu betreiben ohne das Gateway. Sollte das klappen, Ok
Dann bitte das Gateway links an den Core anstecken wenn Ok dann so lassen. Wenn nicht Ok dann Verbindung zur Maschine trennen
Es kann auch sein das der Fehler von der Maschine kommt nun nicht einmal die Hardware das Problem verursacht. Könnt Ihr das auch ohne Datenverbindung zur Maschine Testen?

Ich kenne das zugut von meinem Problem. da habe ich auch zeitweise Rot gesehen aber das lag an dem Modbus der keine Daten Empfangen hat weil es dort ein Problem gab und somit das DIO auch auf Rot gewechselt hat.
Ihr solltet erstmal nur die Hardware Core+DIo+Gateway in Betrieb nehmen und schauen ob es noch immer zu diesem Problem führt. wenn nicht dann wisst ihr schon einmal wo der Fehler zu suchen ist.

Hallo,

Also DIO Modul und Core Modul einzeln hatte ich (glaube ich) noch nicht probiert, werde ich aber gleich mal tun.
Ich hab soweit es geht alles ausgeschlossen, was von der Maschine kommen könnte. An der Modbus Verbindung sollte es nicht liegen, zum einen habe ich Sie schon getestet und Sie funktionierte eigentlich einwandfrei und zum anderen läuft auf dem RevPi aktuell kein Programm. (Habe gestern Jessie neu installiert und seitdem nur die Konfiguration in PicTory vorgenommen.)
Das Ding ist ja, es ist nur beim Starten der Maschine bzw. des RevPi. Sobald ich danach die Treiber im PicTory resettet habe funktioniert es tadellos.

Ich werde es jetzt nochmal probieren, nur die beiden Module Core und DIO zu betreiben.

UPDATE

Ohne Gateway Modul funktioniert es tatsächlich, aber es erschließt sich mir trotzdem nicht warum es an der Modbus Verbindung liegen soll wenn nichts läuft was aktuell irgendwie mit dem Modbus oder den Ein-/Ausgängen interagiert.
Zumal es, wie gesagt, auch mit dem Modbus Gateway funktioniert nachdem ich die Treiber zurückgesetzt habe.

Grüße,

Florian

Ingo · Post by **Ingo** » 08 Oct 2019, 09:08

Da es ja mit den core und die funktioniert kannst du als nächstes einmal ein vituelles modbus tcp/IP Modul verwenden. Ich habe bei meinem Aufbau auch nur die virtuellen teile in Benutzung und da hatte ich solche Erscheinungen nicht. Sollte es damit auch funktionieren dann hat es womöglich mit dem Gateway zu tun.
Frage? Hattest du in der pictory den modbus schon auf aktiv gesetzt gehabt?

nicolaiB · Post by **nicolaiB** » 08 Oct 2019, 09:25

Hallo Florian,

so wie ich deine Beiträge lese, verwendest du immer noch das Jessie Image. Sofern es dafür keinen speziellen Grund gibt aktualisiere bitte auf das letzte Stretch-Image und spiele dort auch alle Aktualisierungen mit apt-get update && apt-get upgrade ein. Hier gab es mit dem Stretch-Image und dem aktuellen Kernel sehr viele Änderungen bezüglich der PiBridge und Gateway-Kommunikation.

Gruß Nicolai

flowp · Post by **flowp** » 08 Oct 2019, 09:40

Hallo Nicolai,

Das neuste Stretch Image ist installiert, war mit den Versionen verwirrt und hab deswegen in den Post hiervor von Jessie geredet.

Code: Select all

pi@RevPi20356:/etc $ cat /etc/revpi/image-release
2019-03-14-revpi-stretch.img

Alle Updates über die Paketverwaltung hatte ich direkt nach der Neuinstallation von Stretch (Gestern) ausgeführt und installiert.

Ich hab mir noch einmal die Logs angeschaut und noch etwas gefunden was mir irgendwie komisch erscheint:

Code: Select all

[  239.162340] piControl: Device  0: Addr  0 Type  95  Act 1  In   6 Out   5
[  239.162343] piControl:            input offset   1024  len   6
[  239.162347] piControl:            output offset  1030  len   5
[  239.162351] piControl: Device  1: Addr 32 Type  96  Act 1  In  70 Out  18
[  239.162355] piControl:            input offset   1035  len  70
[  239.162358] piControl:            output offset  1105  len  18
[  239.162363] piControl: Device  2: Addr 31 Type 32861  Act 0  In 512 Out 512
[  239.162366] piControl:            input offset      0  len 512
[  239.162370] piControl:            output offset   512  len 512
...
[  239.535340] piControl: search for left mGate 93
[  239.535343] piControl: found mGate 2

Außerdem die RS485 Fehler, welche in einem vorherigen Beitrag stehen. Kann es vllt wirklich sein, dass es gar nicht das DIO Modul sondern das Gateway Modul ist? Die ID vom Modbus TCP Gateway sollte doch "93" sein oder?
piTest -d zeigt die ID allerdings korrekt an. Allerdings auch erst nach einem Treiber Reset.
Vorher zeigt mir piTest -d den Type vom DIO Modul als Address: 32 module type: 32864 (0x8060) RevPi DIO V0.0 an.

nicolaiB · Post by **nicolaiB** » 08 Oct 2019, 11:14

Hallo Florian,

ich habe erst jetzt deine Anmerkung zum fehlgeschlagenen Firmware Update im ersten Beitrag gelesen. Hast du es seitdem noch mal versucht bzw. konntest du die aktuelle Firmware einspielen?

Gruß Nicolai

flowp · Post by **flowp** » 08 Oct 2019, 11:47

nicolaiB wrote: ↑08 Oct 2019, 11:14 Hallo Florian,

ich habe erst jetzt deine Anmerkung zum fehlgeschlagenen Firmware Update im ersten Beitrag gelesen. Hast du es seitdem noch mal versucht bzw. konntest du die aktuelle Firmware einspielen?

Gruß Nicolai

Gute Idee.

Habe es also gerade probiert und piTest -f springt sofort zurück in die Bashprompt.

Code: Select all

pi@RevPi20356:/lib/firmware/revpi $ piTest -f
pi@RevPi20356:/lib/firmware/revpi $

Und danach sieht die Ausgabe von dmesg folgendermaßen aus:

Code: Select all

[  306.241370] piControl: piright: timeout
[  306.351381] piControl: stop data exchange
[  306.351410] piControl: piIoComm_gotoGateProtocol returned 0
[  306.421371] piControl: error: cannot open file /lib/firmware/revpi/fw_00095_001.fwu
[  306.421380] piControl: update 0 addr 0 ret -2
[  306.421390] piControl: error: cannot open file /lib/firmware/revpi/fw_00093_000.fwu
[  306.421395] piControl: update 1 addr 32 ret -2
[  306.473768] piControl: piright: id request
[  306.476022] piControl: piright: id response (module type 93 hw V0 sw V1.2 svn 13933 serial 2856 mac c8:3e:a7:00:5d:02)
[  306.541320] piControl: start data exchange

Inhalt des Ordners /lib/firmware/revpi:

Code: Select all

pi@RevPi20356:/lib/firmware/revpi $ ls
fw_00096_001.fwu  fw_00097_001.fwu  fw_00098_001.fwu  fw_00103_001.fwu

Das Paket revpi-firmware ist aber installiert und aktuell:

Code: Select all

pi@RevPi20356:/lib/firmware $ sudo apt install revpi-firmware
Reading package lists... Done
Building dependency tree
Reading state information... Done
revpi-firmware is already the newest version (20180323-1).

nicolaiB · Post by **nicolaiB** » 08 Oct 2019, 13:38

Hallo Florian,

die aktuelleste Firmware findest du hier:
https://www.kunbus.com/modbus-tcp-gateway-module.html

Gruß Nicolai

flowp · Post by **flowp** » 08 Oct 2019, 14:55

nicolaiB wrote: ↑08 Oct 2019, 13:38 Hallo Florian,

die aktuelleste Firmware findest du hier:
https://www.kunbus.com/modbus-tcp-gateway-module.html

Gruß Nicolai

Danke für den Tipp, habe nie daran gedacht mal auf der normalen Kunbus Seite zu schauen...immer nur auf der RevPi Unterseite.

Hab das Firmware-Update installiert, und direkt neue Probleme:

1.) Ist die Firmware-Version die auf der Seite verlinkt ist nicht die aktuelle. Es ist (V1.1) und wenn Ich den Link ändere, nämlich vom verlinkten https://www.kunbus.com/files/media/bugf ... 88_R02.zip in https://www.kunbus.com/files/media/bugf ... 88_R03.zip kriege ich eine Zip-Datei mit Firmware-Dateien deren Timestamps neuer sind als die der verlinkten.

2.) Funktioniert jetzt nach dem Firmware-Update (Oder besser Downgrade) das Passwort 1701 nicht mehr und ich komme nicht mehr auf den FTP. Ich muss aber auf den FTP um den web Ordner zu übertragen. (Ein Fehler meinerseits wahrscheinlich. Ich ging davon aus, dass ich auch nach dem Firmware-Update noch problemlos auf den FTP kommen würde.)

Hat diese Firmware-Version eventuell ein anderes Passwort?

Habe als Fix probiert, die aktuellere Firmware Version entsprechend umzubennen und in den Ordner /lib/firmware/revpi kopiert.
Nach einem piTest -f zeigt dmesg zwar an, dass er ein Firmware-Update von V1.1 auf V1.2 gefunden hat aber es schlägt trotzdem fehl.

Post by **Eduard** » 09 Oct 2019, 13:43

Hallo Florian,

danke für deinen Hinweis, wir haben den Link aktualisiert.

In der neuen Version sind die Logindaten in der password.xml Verschlüsselt deswegen kannst du dich nicht mehr einloggen.
Du musst beim Update auch die „targetFiles“ mit kopieren.

Kannst du dein Aufbau an Kunbus schicken, wir würden diesen hier bei uns analysieren.
Ein RMA Formular bekommst du noch.

Gruß,
Eduard