PiCtory und Modbus Konfiguration / Modbus Master Runtime

[Ingo]

sorry Volker, aber ich bin derzeit nicht zu hause oder in deutschland.
Daher kann ich auch nicht viel sagen oder machen. Also heißt es warten. dauert aber noch ne weile.
gruß

[Ingo]

Hallo Volker,

ich habe mich nun weiter mit dem Modbus befasst und bin noch keinen echten Schritt weiter gekommen.
Wenn die Konfiguration geöffnet wird und ich anfange die Einträge in der Extended Data zu machen Funktioniert es nicht wirklich.
Zur Veranschaulichung was da genau passiert habe ich das einmal per Video aufgezeichnet.
https://www.youtube.com/watch?v=O0U7PoJ ... e=youtu.be.
Wie du sehen kanns habe ich einen Eintrag gemacht, aber beim versuch einen weiteren zu machen springt es einfach wieder um so das der Eintrag nicht mehr vorhanden ist.
Ich konnte nicht nachstellen warum das so ist. Denn ab und zu Funktioniert es ja.
Da wir noch am Testen sind und weitere Probleme auftreten über die aber Mathias schon eine Mail bekommen hat ist es besser du schaust dir das mit Mathias einmal an.

gruß

[volker]

Hast Du die neuen Pakete gezogen?
Zu dem Thema mit dem fehlenden automatischen Start des Servers wird es noch ein Update geben. Das hat aber nichts miteinander zu tun.
Das Video kann ich leider nicht einsehen, das es "privat" geschaltet ist. Könntest Du es bitte öffentlich schalten (wenigstens für einen begrenzten Zeitraum)?

[Ingo]

probier es noch einmal, sollte nun gehen

[Ingo]

Hallo,

ein Herzlichen Dank an Mathias für die schnelle Reaktion und dem neuen Update für das Master Modul. Es wurde getestet und der Master macht nun genau das was er machen soll. Die IDs werden nun an der richtigen Stelle gesetzt.
auch ist das mit der extremen CPU auslastung nicht mehr so extrem das wenn die Netzwerkverbinung getrennt ist oder der Slave auf der gegenstelle nicht arbeitet. Die PBright stürzt nicht mehr ab.
auch haben wir ein Tool gefunden womit es möglich ist Master und Slave auszulesen oder zu setzten. was die Arbeit sehr vereinfacht hat zum testen.
http://www.modbustools.com/download.html

Nun können wir weitermachen und euch bald das ergebniss vorstellen. Visualisierung via Nodejs.

gruß
Ingo

[volker]

Für alle, die den Thread mitgelesen haben:
Analysen im Debugger vom Browser bei Ingo haben ergeben, dass sein Browser leider wegen timeouts nicht alle notwendigen Daten vom Webserver des RevPi bekommt und daher die GUI nicht korrekt laufen kann. Warum bei Ingo der Browser so viel langsamer Daten vom Webserver bekommt ist unklar, aber es kann an sehr vielen Faktoren liegen, die im Einzelnen schwer zu ermitteln sind (möglicherweise ist die Systemlast der insgesamt ausgeführten Tasks auf einem CM1 für das System einfach zu hoch oder aber anderer Traffic auf dem selben Netz blockieren oder es ist ein Problem des Physical Layers / Kabel etc.).
Generell läuft PiCtory ztusammen mit Modbus auf CM1 Geräten problemlos, daher muss es an Eigenheiten der INstallation liegen, die sich hier ungünstig auswirken.

[volker]

Im Rahmen eines Themas, welches hier in diesen Thread hineinkopiert wurde, hatte Ingo diverse Probleme mit der PiCtory Konfiguration und Modbus Master (extended data / erweiterte Daten) beschrieben.
Eins der Probleme basierte auf einem Bug, der inzwischen durch aktuelle Updates beseitigt wurde und andere Probleme basierten auf einer individuellen problematischen Netzwerkauslastung auf Ingos System.
Hier das gelösteProbleme mit dem Modbus Master Konfigurator:
Löschen von Augeben/Tasks aus der Mitte der Liste führten zu einer Zerstörung der Konfiguration, dies sich nur durch Löschung der _config.rsc wieder auflösen ließ.

Auch in der Modbus Runtime gab es zwei Fehler, die inzwischen beseitigt wurden:
1) Bei Verwendung von mehr als 8 einzelnen ReadCoils auf jeweils nur 1 Register in hintereinanderliegenden Aufgaben/Tasks wurden die Ergebniswerte nicht korrekt im Prozessabbild abgelegt. Dieser Fehler konnte durch Read multiple Coils auf N Modbusregister mit N>8 umgangen werden. Dieser Bug bestand auch für write Coils. Der Fehler ist inzwischen behoben.
2) Der Modbus Master (RTU und TCP) lief nach einem Systemreset oder Kaltstart unter Jessie im aktuellen Stand des images nicht von alleine an, so9ndern musste durch ein Reset von PiControl (z.B. piTest -x) manuell ausgelöst werden. Dieses Problem ist inzwischen behoben und kann durch ein Update auch für bestehende Sywsteme vermieden werden.

[volker]

auch haben wir ein Tool gefunden womit es möglich ist Master und Slave auszulesen oder zu setzten. was die Arbeit sehr vereinfacht hat zum testen.
http://www.modbustools.com/download.html

Dies ist ein schönes Programm, weil man auch einen Slave/Server simulieren kann und daher setze ich es auch zum Testen ein. Allerdings ist zu beachten, dass es KEIN KOSTENLOSES TOOL ist, sondern nur 30 Tage Test zulässt und dann bezahlt werden muss. In diesen 30 Tagen Testzeit muss das Programm alle 10 Minuten neu gestartet werden, läuft also nicht kontinuierlich durch. Wer lediglich einen Master/Client simulieren will, der ist mit QModbus als fantastischen kostenlosen Tool besser bedient.

[Ingo]

Hallo Volker,

Ja ich weiss das es nur 10min läuft und auch nur 30 tage zum testen geeignet ist. Aber für die Sachen hat es ausgereicht um zu sehen was passiert. wir hätten es auch über unser script laufen lassen können, aber da bekommen wir noch alle Informationen ausgegeben was der Modbus überträgt. das wurde auf dauer zu unüberschaubar. Daher dieses kleine Tool.

Wichtig war nur das der Modbus nun genau macht was er soll. Daten an die Richtige Adresse senden. Das einzige was mir noch aufgefallen ist. Das System läuft nun seit 2 Tagen ganz ordendlich, nur hatte ich gestern das Problem das ich die gegenstelle vom Modbus einmal vom Netzwerk trennen musste da andere Verlegung der Netzwerk Kabel notwenig gewesen ist. Und genau da hatte sich der Modbus Master im PI wieder so aufgeschaukelt das die anderen Dienste nicht korekkt gearbeitet haben und die DIO Module auf Störung gegangen sind. erst als die Verbindung wieder hergestellt war beruhigte sich der PI wieder und alles war normal.
das kannst du auch gerne selber nachstellen wenn du einen Modbus slave von einem anderen rechner mit dem Pi Master betreibst und dann die netzwerkverbing trennst. Da kannst du zuschauen wie die nachfolgenden Module rot anfangen zu blinken oder auf dauer rot gehen.
Dafür sollte es noch mal einen Patch geben irgendwann.

gruß

[volker]

Ich denke mal Dein CM1 ist kangsam mit seiner Rechenpower überforert. Wenn Du einen Feldbus einfach auftrennst ohne den Master runterzufahren, dann entstehen zwangsläufig Timeouts und Reaktionen darauf. Die korrekte Vorgehensweise ist das Stoppen des Dienstes vor dem Auftrennen der Feldbusleitung, wenn Du diese Systemlast vermeidne willst. Solche Busse sind generell nicht per Definition "hot plugable". Wir haben im Master einen Mechanismus eingebaut, der in so einem Fall automatisch versucht, die Verbindung wieder aufzubauen. Da hierbei auch die TCP Verbindung neu aufgebaut werden muss, erzeugt der kontinuierliche Versuch diese Verbindung neu aufzubauen eine Systemlast. Die Alternative dazu wäre die übliche Vorgehensweise einer PLC: Die Steueerung geht auf Kommunikationsstörung und der User muss einen Restart durchführen.
Ein CM3 System sollte mit der Systemlast locker zurecht kommen.