Hallo,
wir haben immer den Kunbus GATEWAY Modul für Modbus TCP verwendet um Daten von Modbus TCP auf Profibus umzuwandeln.
Wir wollen das ganze jetzt mit einen Revolution pi Core lösen. Die Frage ist nur wie richtet man das ganze ein und sorgt für den benötigen Daten austauschen.
Modbus TCP Slave --> Profibus DP Slave
Re: Modbus TCP Slave --> Profibus DP Slave
Hallo,
Folgenden Links werden Ihnen dabei weiterhelfen.
RevolutionPi Gateway Tutorial
How to use the KUNBUS Gateway modules
Zusätzliche Informationen:
PiCtory Checklist
RevolutionPi Checklist
Mit freundlichen Grüßen
Giuseppe Pagano
Eine Plug-and-play Lösung gibt es hierzu nicht. Sie müssen die Geräte in PiCtory konfigurieren und eine eigene Applikation schreiben, um die Daten dann von Gateway A auf B zu konvertieren bzw. zu übertragen.Wir wollen das ganze jetzt mit einem Revolution pi Core lösen. Die Frage ist nur wie richtet man das ganze ein und sorgt für den benötigen Daten austauschen.
Folgenden Links werden Ihnen dabei weiterhelfen.
RevolutionPi Gateway Tutorial
How to use the KUNBUS Gateway modules
Zusätzliche Informationen:
PiCtory Checklist
RevolutionPi Checklist
Mit freundlichen Grüßen
Giuseppe Pagano
-
- Posts: 1
- Joined: 28 Apr 2023, 09:40
Re: Modbus TCP Slave --> Profibus DP Slave
Hallo,
wir haben auch das Kunbus Modbus TCP GATEWAY Modul verwendet, und ich finde es schade, dass das Produkt aufgelassen wurde. Warum wurde es abgekündigt?
Wir werden ev. auch die Modbus TCP Komponente mit einem Core S realisieren. Ev. werden wir aber die Buskopplung in Zukunft mit einem anderen Produkt umsetzen.
Sei wie es sei. So haben wir einen möglichen Umstieg realisiert. Verbesserungsvorschläge sind gerne willkommen, da dies mein erster Kontakt mit einem RevPi Basismodul war.
Beispiel Modbus TCP <-> Profinet:
Konfiguration PiCtory:
Jeweils „Export“ der ersten Input und ersten Output Variable vom Gateway und vom Modbus Slave anklicken, um die „absoluten Adressen im Prozessabbild?“ zu erhalten. Mit diesem Python Prog. werden die Daten im Prozessabbild zwischen Gateway und CoreS kopiert:
Das Python Prog. wurde im Verzeichnis "/var/lib/revpipyload" als „program.py“ ablegen, damit es automatisch gestartet wird.
Müssen wir uns wegen der Datenkonsistenz Gedanken machen? 32 Bit Zählerstände sind die „größte“ Einheit die nicht getrennt übertragen werden soll?
wir haben auch das Kunbus Modbus TCP GATEWAY Modul verwendet, und ich finde es schade, dass das Produkt aufgelassen wurde. Warum wurde es abgekündigt?
Wir werden ev. auch die Modbus TCP Komponente mit einem Core S realisieren. Ev. werden wir aber die Buskopplung in Zukunft mit einem anderen Produkt umsetzen.
Sei wie es sei. So haben wir einen möglichen Umstieg realisiert. Verbesserungsvorschläge sind gerne willkommen, da dies mein erster Kontakt mit einem RevPi Basismodul war.
Beispiel Modbus TCP <-> Profinet:
Konfiguration PiCtory:
Jeweils „Export“ der ersten Input und ersten Output Variable vom Gateway und vom Modbus Slave anklicken, um die „absoluten Adressen im Prozessabbild?“ zu erhalten. Mit diesem Python Prog. werden die Daten im Prozessabbild zwischen Gateway und CoreS kopiert:
Code: Select all
#!/usr/bin/python3
import time
#LED ein- und ausschalten
f=open("/dev/piControl0","wb+",0)
while True:
try:
# Modbus TCP (Unitronics) -> Profinet
# 288 Byte an Daten
f.seek(1035)
x = f.read(288)
f.seek(512)
f.write(x)
time.sleep(0.5)
# Profinet -> Modbus TCP (Unitronics)
# 64 Byte an Daten
f.seek(128)# 128 Byte offset wegen 64Byte Modul im TIA
x = f.read(64)
f.seek(2059)
f.write(x)
time.sleep(0.5)
except ValueError:
time.sleep(50)
Müssen wir uns wegen der Datenkonsistenz Gedanken machen? 32 Bit Zählerstände sind die „größte“ Einheit die nicht getrennt übertragen werden soll?