The Industrial Raspberry Pi Forum

Sehr geehrte Damen und Herren,

Benutzt wird ein Revolution Pi Connect+. Dieser wird auf Port A als Modbus TCP Master eingesetzt. Programmiert wurde die Steuerung mit Node-Red (Java-Script).
Nun soll der zweite Port benutzt werden, damit die Zentrale als Modbus Master auf den Revolution Pi Connect+ zugreifen kann. Dafür würde ich gerne eine Datei (ich dachte an CSV bin aber offen für jedweden Dateityp) auf dem RevPi ablegen. Auf diese Datei sollen dann "beide" Modbus Systeme zugreifen können. Einerseits soll die Steuerung von der Zentrale überwacht werden, Fehlercodes und Messwerte sollen übergeben werden andererseits, soll die unterlagerte Steuerung je nach Zustand auch von der Zentrale abgeschaltet werden können.

Der
Mit freundlichen Grüßen
Michael

Hi das klingt ja spannend. Ich kann dir empfehlen, das z.B. mit https://revpimodio.org/revpipyplc/revpipyload/ zu machen. Allerdings für technische Fragen ist der kompetente Ansprechpartner der Sven im Forum "RevPiModIO". Gerne verschiebe ich Deinen Thread dort hin.

Hallo dirk,

ich habe mir gerade RevPiModIO angeschaut, weiß aber nicht so recht, wie es mir weiterhelfen kann.
Gerne kannst du meinen Thread verschieben ich lasse mir gerne zeigen, wie mir RevPiModIO weiterhelfen kann.

Gruß Michael

Hi @RevPiModIO siehe Verlauf. Es geht um die Vernetzung von mehreren Systemen. Kannst Du dazu etwas sagen?

Wenn das alles über Modbus schon läuft, dann würde ich die Vernetzung auch über Modbus lassen. Aber eine "Datei" mit Parametern hin und her schieben ist auch nicht so cool.

Ich würde die Parameter über Modbus austauschen und in die jeweiligen virtuellen Devices ablegen. Also die Zentrale (ModbusMaster) schreibt in das Slave-device auf dem RevPi Werte, die die Steuerung dort dann als Parameter verwendet. Wenn die Zentrale nicht zwingend auf Modbus laufen muss, kann an der Stelle natürlich auch mit Python und RevPiModIODriver gearbeitet werden. Dann könnte man über RevPiNetIO Werte in ein normales virtuelles Device schreiben - Ist am Ende aber an sich das selbe.

Wenn im virtuellen Device zu wenig Platz für alle Einstellungen ist und NodeRED verwendet wird, könnte man über die HTTP Knoten ja eine Art REST-Requests mit der Zentrale austauschen. Dann würde die Zentrale die Parameter über REST (HTTP) abfragen und schreiben - Das wäre dann z.B. im JSON Format.

Gruß, Sven

Hallo Sven,

wie ist der Zugriff der virtuellen Geräte denn geregelt? So wie ich das verstanden habe, muss ich ja beide Ethernet Ports einzeln in PiCtory konfigurieren. Und da sich die beiden Ports nicht im selbem Netz befinden, besteht ja keine ModBus Verbindung zwischen den beiden Ports. Wie kann denn der Port A (Master Steuerung) auf die Werte der Register des Port B (Zentral-Slave) zugreifen?

Grüße

Michael

RevPiModIO wrote: ↑21 Apr 2020, 07:54
Ich würde die Parameter über Modbus austauschen und in die jeweiligen virtuellen Devices ablegen. Also die Zentrale (ModbusMaster) schreibt in das Slave-device auf dem RevPi Werte, die die Steuerung dort dann als Parameter verwendet.

Hallo Sven,

genau das ist der Lösungsansatz, den ich auch mit meiner CSV Datei verfolgt habe. Nur da ich Anfänger bin, weiß ich nicht, wie ich diesen Zugriff regeln kann.

Meinem Verständnis nach, besitzt der Connect+ 2 LAN-Ports, die beide frei konfigurierbar und unabhängig sind. Die Schnittstelle, die diese beiden Ports verbindet ist der RevPi selbst. Nun dachte ich, dass es am sinnvollsten sei, die eingegebenen Werte aus in den Speicher des RevPi zu schieben, da beide sich diesen Speicher "teilen".
So wie ich dein Zitat verstehe, ist es jedoch möglich die Daten direkt per virtuellen Geräten hin und her zu schieben. Wie ist dies möglich, wenn ein Gerät ein Master ist, der normalerweise nicht von einem Slave beeinflusst werden können sollte, bzw. wie kann ein zweiter Master auf einen Slave zugreifen?

Für mich persönlich wäre jedoch wichtiger, dass die Steuerung funktioniert. Deshalb würde ich dich bitten, vor allem mir diese PiCtory Einstellungen für die virtuellen Geräte zu erklären, sodass ich die Daten austauschen kann.

Mit freundlichen Grüßen

Michael

Hi Michael!

Ich starte mal beim technischen Aufbau, vergiss dazu vorerst mal Modbus und alles andere . Der Connect selber hat ja zwei Netzwerkschnittstellen A / B. Diese sind Beide vom Betriebssystem verwaltet - Quasi ein Rechner mit zwei eingebauten Netzwerkkarten. Jede "Netzwerkkarte" bekommt eine eigene IP-Adresse aus verschiedenen Netzen - (also A=192.168.0.1/24 und B=192.168.1.1/24). Dementsprechend ist jede Netzwerkkarte in einem eigenen Netzwerk, das Betriebssystem (also RevPi) ist in "beiden" Netzwerken. Er kann also Teilnehmer im Adressbereich A und im Adressbereich B erreichen und kann von allen Teilnehmern im Netz A auf Schnittstelle A und von allen Teilnehmern im Netz B auf Schnittstelle B erreicht werden.
Ein Fehler wäre es, wenn man den Schnittstellen jeweils eine Adresse aus dem selben Netzwerk geben würde! Also z.B. A=192.168.0.1/24 und B=192.168.0.2/24 [NICHT GUT].

INFO: Man könnte den Connect natürlich auch als Bridge benutzen. Dann könnte man, wie man es von manchen Industrieteilnehmern kennt, sein Netzwerk durchschleifen. Also die Leitung kommt z.B. vom Switch, geht direkt an Port A (RevPi) und dann geht ein weiteres Kabel vom Port B (RevPi) an ein weiteres Device. Bei der Konfiguration wären alle Teilnehmer im selben IP-Netz und auf dem RevPi müsste eine Bridge über beide Ports erstellt werden. Dann hätte der RevPi auch nur noch EINE (!) IP Adresse auf der virtuellen Netzwerkkarte, welche an die Bridge geht - Das nur mal der Vollständigkeit halber

Also von der Seite aus, siehst du alles genau so, wie es ist. Das Betriebssystem und dessen Speicher sind "von beiden Netzen geteilt". Aber natürlich auch das Prozessabbild in piCtory

Wenn du also in piCtory ein Modbus-Master einrichtest, der Daten mit einem Slave in Netz A austauscht, schreibt dieser die Daten dann ja in das Prozessabbild. In den Speicherbereich des Modbus-Masters. Wenn du nun zusätzlich noch einen Modbus-Slave (TCP) in piCtory einbaust und den z.B. an die IP der Schnittstelle B bindest, kann ein Modbus Master aus dem Netz B auf diesen zugreifen und Daten lesen und schreiben. Dabei aber natürlich auch nur in dem Speicherbereich des Modbus Slaves im Prozessabbild!

Der Komponente, die diese IOs aus den beiden Speicherbereichen zusammenfügt ist dein Steuerungsprogramm. Das würde ich "natürlich" in Python schreiben um direkten Zugriff auf die IOs des Modbus Master und Modbus Slave zu bekommen.

Kleines Gedankenspiel:
Der Slave hat die IOs "anlage_an" und "fuellmenge", der Master "band_starten", "klappe_auf", "waage".
Mein Python Programm würde nun zyklisch mit meine Funktion im .cycleloop(funktion) prüfen ob der IO "anlage_an" = True ist.
Wenn der Master aus Netz B diesen setzt, würde meine Programm "band_starten" und "klappe_auf" auf True setzen (Das wäre ja auf dem Slave in Netz A).
Dann würde ich immer vergleichen "waage" >= "fuellmenge" und wenn das True ist
"klappe_auf" auf False setzen und nach einer Nachlaufzeit "band_starten" auf False setzen...

So kann der Master aus Netz B nicht den Slave aus Netz A direkt steuern, was ich ja auch gar nicht will, aber über das Steuerugsprogramm auf dem RevPi kann ich die Werte eben "zusammenbringen".

Bleibt man nun in der Python-Welt und ist nicht darauf angewiesen Modbus im Netz B zu verwenden, könnte man das "beeinflussen" der Steuerung auch komplett mit Python machen. Dann würde man statt einem Modbus-Slave in piCtory ein "normeles" virtuelles Device auf dem RevPi erstellen. Das Steuerungsprogramm würde dann die IOs "anlage_an" und "fuellmenge" mit Python .replace_io(...) erstellen und genau wie oben beschrieben verarbeiten. Im Netz B hätten wir nun z.B. eine Visualisierung in Python geschrieben, die mit RevPiNetIODriver("ip-revpi-netz-b") auf den RevPi zugreift (RevPiPyLoad muss installiert und konfiguriert sein). Und wenn jemand auf der Visualisierung die Füllmenge einstellt, wird der wert direkt in das virtuelle Device geschrieben, wenn jemand den Button "start2 drückt, wird der IO "anlage_an" auf True gesetzt. Alles über das Netzwerk B.

RevPiPyLoad empfehle ich eh zu installieren, weil es dein Python Programm ausführt und überwacht. Du kannst dann auch mit dem grafischen Tool "RevPiPyControl" über das Netzwerk auf den RevPi zugreifen und die IOs checken, alles als GUI.

Gruß, Sven