Hallo zusammen,
ich bin auf der Suche nach einer geeigneten Anlagensteuerung auf den RevPi gestoßen und würde diesen gerne für mein Projekt nutzen, bin mir bei der Komponentenauswahl aber unsicher.
Die gesamte Anlage besteht aus 3 Komponenten, die räumlich getrennt sind. Der Aufbau des Netzwerks ist auf dem angefügten Bild hoffentlich ganz gut zu erkennen. (Die Verbindung an sich funktioniert, wurde schon mal mit Siemens SPS Komponenten getestet).
RevPi1 und 2 nehmen analoge Umweltdaten (z. B. Pegeldaten, gelöste Sauerstoffkonzentration, o.ä.) auf. Diese fließen in die Steuerung, welche durch den dritten RevPi erfolgt, ein. Im Wesentlichen könnte auf diesen ersten beiden RevPis auch schon die Auswertung erfolgen, sodass an den dritten RevPi nur noch die Information True/False weitergegeben wird (Es wird geprüft, ob Umweltbedingungen erfüllt sind, die den Betrieb der Anlage erlauben).
Der dritte und wichtigste RevPi erhält durch Endschalter, Bedienungsschalter (Hand, Automation, Off, etc.) zahlreiche DIs. Bei den Outputs reichen 10 DOs aus, über die Elektromotoren und Pumpen angesteuert werden. Dieser dritte Pi befindet sich auf einer schwimmenden Plattform (Stromversorgung erfolgt über Kabelleitungen im Wasser, die Powerline hat bisher ihren Zweck erfüllt).
Ich habe die folgenden Komponenten herausgesucht und würde gern wissen, ob das Sinn macht. Insbesondere zur Pi2Pi Verbindung konnte ich nicht so viel finden:
- 3x RevPi Core (oder ist eine Kombination mit RevPi Connect sinniger?)
- 2x RevPi AIO
- 1x RevPi DI
- 1x RevPi DIO
Viele Grüße und vielen Dank
Ricarda
Pi2Pi Communication - Automatisierung auf dem Wasser
Pi2Pi Communication - Automatisierung auf dem Wasser
- Attachments
-
- Netzwerk.png (67.67 KiB) Viewed 15547 times
Re: Pi2Pi Communication - Automatisierung auf dem Wasser
Hi Ricarda, das klingt ja spannend, hoffentlich spendierst Du dem RevPi 3 dann Schwimmflügel... 
Also Deine Überlegungen sind richtig und mit der Hardware Konfiguration kannst Du Dein Projekt umsetzen.
29 DI und 10 DO kannst Du mit 1x DIO und 1x DI umsetzen. Dann hast Du 14 DI und 14+16 = 30 DO.
Pro AIO Modul hast Du 2 Eingänge und 2 Ausgänge zur Verfügung.
Da Du geschrieben hast "2-3 analoge inputs" brauchst Du also auch 1 oder 2 AIOs.
Was passiert wenn von RevPi 1 oder RevPi 2 keine Daten mehr kommen?
Dann muss Anwendung auf RevPi 3 darauf reagieren indem die Anlage in einen sicheren Zustand gebracht wird.
Also Deine Überlegungen sind richtig und mit der Hardware Konfiguration kannst Du Dein Projekt umsetzen.
29 DI und 10 DO kannst Du mit 1x DIO und 1x DI umsetzen. Dann hast Du 14 DI und 14+16 = 30 DO.
Pro AIO Modul hast Du 2 Eingänge und 2 Ausgänge zur Verfügung.
Da Du geschrieben hast "2-3 analoge inputs" brauchst Du also auch 1 oder 2 AIOs.
Was passiert wenn von RevPi 1 oder RevPi 2 keine Daten mehr kommen?
Dann muss Anwendung auf RevPi 3 darauf reagieren indem die Anlage in einen sicheren Zustand gebracht wird.
Re: Pi2Pi Communication - Automatisierung auf dem Wasser
Hallo Dirk,
vielen Dank für die schnelle Antwort. Die Schwimmflügel sind schon eingeplant
Guter Hinweis, danke. Bei der Anlage handelt sich um eine Plattform, die über Winden die Position auf einem Gewässer verändert. Eine Pumpe nimmt vom Gewässergrund Schlamm auf, das Gemisch wird dann in ein anderes Gewässer abgegeben . Die analogen Eingangssignale sind hauptsächlich Daten zum Wasserstand und der Trübung in diesem anderen Gewässer und der Förderleitung. Der Transfer soll aussetzen, wenn bestimmte Grenzwerte überschritten werden.
Wenn keine Daten die den dritten Pi erreichen, muss eigentlich nur eine Pumpe abgeschaltet werden, alle anderen kritischen Zustände werden über Überlastrelais abgefangen. Hohe Reaktionsgeschwindigkeiten sind auch nicht erforderlich, d. h. ob die Pumpe noch eine Minute länger läuft oder nicht, macht an sich keinen Unterschied. Zu prüfen, ob alle Komponenten eingebunden sind, müsste sich über die Programmierung lösen lassen, oder? Ich habe das bisher nur bei der Siemens SPS Variante gesehen, da wurde das Programm quasi einfach abgebrochen und die Pumpe ausgeschaltet, wenn eine von den S7 nicht mehr verfügbar war.
Viele Grüße
Ricarda
Viele Grüße
Ricarda
vielen Dank für die schnelle Antwort. Die Schwimmflügel sind schon eingeplant
Guter Hinweis, danke
. Bei der Anlage handelt sich um eine Plattform, die über Winden die Position auf einem Gewässer verändert. Eine Pumpe nimmt vom Gewässergrund Schlamm auf, das Gemisch wird dann in ein anderes Gewässer abgegeben . Die analogen Eingangssignale sind hauptsächlich Daten zum Wasserstand und der Trübung in diesem anderen Gewässer und der Förderleitung. Der Transfer soll aussetzen, wenn bestimmte Grenzwerte überschritten werden.Wenn keine Daten die den dritten Pi erreichen, muss eigentlich nur eine Pumpe abgeschaltet werden, alle anderen kritischen Zustände werden über Überlastrelais abgefangen. Hohe Reaktionsgeschwindigkeiten sind auch nicht erforderlich, d. h. ob die Pumpe noch eine Minute länger läuft oder nicht, macht an sich keinen Unterschied. Zu prüfen, ob alle Komponenten eingebunden sind, müsste sich über die Programmierung lösen lassen, oder? Ich habe das bisher nur bei der Siemens SPS Variante gesehen, da wurde das Programm quasi einfach abgebrochen und die Pumpe ausgeschaltet, wenn eine von den S7 nicht mehr verfügbar war.
Viele Grüße
Ricarda
Viele Grüße
Ricarda
-
RevPiModIO
- KUNBUS
- Posts: 335
- Joined: 20 Jan 2017, 08:44
- Contact:
Re: Pi2Pi Communication - Automatisierung auf dem Wasser
Das ist echt ein cooles Projekt!
Wenn es mit Python entwickelt werden würde, wäre sicherlich RevPiNetIO interessant! Da müsste mal mal schauen, ob auf dem RevPi3 das Steuerungsprogramm läuft und der RevPi2 als slave mit eingebunden werden könnte...
Das NetIO habe ich damals für solche Zwecke entwickelt, dass es eine Master-Steuerung gibt und die Slaves darüber bedient werden... Mittlerweile ist es natürlich auch für Visualisierungen oder für andere Datenquellen erweitert worden
Gruß, Sven
Wenn es mit Python entwickelt werden würde, wäre sicherlich RevPiNetIO interessant! Da müsste mal mal schauen, ob auf dem RevPi3 das Steuerungsprogramm läuft und der RevPi2 als slave mit eingebunden werden könnte...
Das NetIO habe ich damals für solche Zwecke entwickelt, dass es eine Master-Steuerung gibt und die Slaves darüber bedient werden... Mittlerweile ist es natürlich auch für Visualisierungen oder für andere Datenquellen erweitert worden
Gruß, Sven
python3-RevPiModIO - https://revpimodio.org/ || Der RevPi ist das Beste, was passieren konnte!
Re: Pi2Pi Communication - Automatisierung auf dem Wasser
Ja das ist ein schönes Projekt und danke für Deine konstruktiven Ideen Sven. Und zu den Fragen kann ich sagen ja, die Prüfung musst Du in der Anwendung durchführen und die Pumpen abschalten.
Re: Pi2Pi Communication - Automatisierung auf dem Wasser
Hallo Sven,
vielen Dank (auch an Dirk für die Antwort)
Die Entwicklung erfolgt über Python und ich war mir bisher auch noch nicht sicher, wie die Kommunikation der Pis erfolgen kann. RevPiNetIO klingt eigentlich perfekt. Ich würde über die Slave-Pis 1 und 2 gern schon Auswertungen machen lassen, sodass sie an den Master im Prinzip nur ein True oder False weitergeben bzw. ggf. auch einfach als interrupt.
Viele Grüße
Ricarda
vielen Dank
(auch an Dirk für die Antwort)Die Entwicklung erfolgt über Python und ich war mir bisher auch noch nicht sicher, wie die Kommunikation der Pis erfolgen kann. RevPiNetIO klingt eigentlich perfekt. Ich würde über die Slave-Pis 1 und 2 gern schon Auswertungen machen lassen, sodass sie an den Master im Prinzip nur ein True oder False weitergeben bzw. ggf. auch einfach als interrupt.
Viele Grüße
Ricarda
-
RevPiModIO
- KUNBUS
- Posts: 335
- Joined: 20 Jan 2017, 08:44
- Contact:
Re: Pi2Pi Communication - Automatisierung auf dem Wasser
In dem Fall würde dich in Richtung RevPiNetIODriver forschen. Das ist eine Ableitung von NetIO. Der Vorteil dabei ist, dass sich die Pis 1 und 2 mit dem Prozessabbild vom Pi 3 verbinden und dort ihre Daten in ein virtuelles Device schreiben. Ist auf jeden Fall die bessere Variante.
Man erstellt auf dem Pi3 zwei virtuelle Devices über piCtory. Nennt die dann z.B. pi1 und pi2. Dann schreibt man auf dem Pi1 und Pi2 Steuerungsprogramme mit einer Instanz RevPiModIO um die lokalen IOs zu verwalten und mit einer zusätzlichen Instanz von RevPiNetIODriver gibt man dann die IP und den Namen vom virtuellen Device auf dem Pi3 an. Das jeweils lokale Programm kann dann Daten auswerten, steuern usw und übergibt die relevanten Daten in das Prozessabbild vom Pi3, auf dem wiederum ein Steuerungsprogramm läuft, welches die Daten auswertet und darauf hin IOs steuert.
Auf den Pi3 müsste man auch nur RevPiModIO verwenden, da das Prozessabbild ja die Werte lokal vom Pi1 und Pi2 in den virtuellen Devices enthält.
RevPiPyLoad muss auf dem Pi3 auf jeden Fall dann installiert sein, da es der "Server" für das Prozessabbild ist. Auf den anderen kann es aber auch gerne installiert werden um das Python Programm auszuführen und dir eine Schnittstelle zu bieten um die IOs zu checken oder generell dein Programm darauf zu spielen. Alles über die grafische Oberfläche von RevPiPyControl dann
Zu so einem Projekt würde ich gerne ein Beispiel auf meiner Seite mal machen.
Das ganze NetIO-Zeug stellt außerdem auch Funktionen bereit, sollte die Verbindung mal abreißen. Beide Seiten könnten dann darauf reagieren - z.B. Pumpen abschalten. Eine Neuverbindung wird vom NetIO automatisch versucht!
Bin gespannt!
Man erstellt auf dem Pi3 zwei virtuelle Devices über piCtory. Nennt die dann z.B. pi1 und pi2. Dann schreibt man auf dem Pi1 und Pi2 Steuerungsprogramme mit einer Instanz RevPiModIO um die lokalen IOs zu verwalten und mit einer zusätzlichen Instanz von RevPiNetIODriver gibt man dann die IP und den Namen vom virtuellen Device auf dem Pi3 an. Das jeweils lokale Programm kann dann Daten auswerten, steuern usw und übergibt die relevanten Daten in das Prozessabbild vom Pi3, auf dem wiederum ein Steuerungsprogramm läuft, welches die Daten auswertet und darauf hin IOs steuert.
Auf den Pi3 müsste man auch nur RevPiModIO verwenden, da das Prozessabbild ja die Werte lokal vom Pi1 und Pi2 in den virtuellen Devices enthält.
RevPiPyLoad muss auf dem Pi3 auf jeden Fall dann installiert sein, da es der "Server" für das Prozessabbild ist. Auf den anderen kann es aber auch gerne installiert werden um das Python Programm auszuführen und dir eine Schnittstelle zu bieten um die IOs zu checken oder generell dein Programm darauf zu spielen. Alles über die grafische Oberfläche von RevPiPyControl dann
Zu so einem Projekt würde ich gerne ein Beispiel auf meiner Seite mal machen.
Das ganze NetIO-Zeug stellt außerdem auch Funktionen bereit, sollte die Verbindung mal abreißen. Beide Seiten könnten dann darauf reagieren - z.B. Pumpen abschalten. Eine Neuverbindung wird vom NetIO automatisch versucht!
Bin gespannt!
python3-RevPiModIO - https://revpimodio.org/ || Der RevPi ist das Beste, was passieren konnte!
Re: Pi2Pi Communication - Automatisierung auf dem Wasser
Danke auch an Dich, Sven (@RevPiModIO) .
Re: Pi2Pi Communication - Automatisierung auf dem Wasser
Hallo zusammen,
nach einigen Wochen habe ich nun endlich die Revolution Pis bestellt, aber einige Änderungen vorgenommen. Die Core Module 2 und 3 werde ich nun zusammenfassen, sodass ich insgesamt nur noch 2 Module benötige.
Ich benötige einen MID und einen Trübungssensor als analoge Inputs, Zahlreiche Taster/Schalter zur manuellen Bedienung sowie induktive und mechanische Sensoren etc. als Inputs sowie die Outputs für Pumpen und Windenmotoren.
Ich muss zugeben, dass ich deine Beschreibung, @Sven, was ich benötige noch nicht ganz durchschaut habe. Nach jetzigem Stand kann ich die Kommunikation mit dem zweiten Pi aber auch erst später hinzufügen.
Gerade versuche ich mich erst mal daran, die analogen Signale zu erhalten. Da bin ich mir leider nicht sicher, was ich wie wo anschließen muss. Falls ihr im RevPiTeam noch immer noch Video-Tutorials vorbereitet (die haben mir wirklich geholfen), dann wäre der beispielhafte Anschluss eine analogen Eingangs großartig.
Viele Grüße
Ricarda
nach einigen Wochen habe ich nun endlich die Revolution Pis bestellt, aber einige Änderungen vorgenommen. Die Core Module 2 und 3 werde ich nun zusammenfassen, sodass ich insgesamt nur noch 2 Module benötige.
Ich benötige einen MID und einen Trübungssensor als analoge Inputs, Zahlreiche Taster/Schalter zur manuellen Bedienung sowie induktive und mechanische Sensoren etc. als Inputs sowie die Outputs für Pumpen und Windenmotoren.
Ich muss zugeben, dass ich deine Beschreibung, @Sven, was ich benötige noch nicht ganz durchschaut habe. Nach jetzigem Stand kann ich die Kommunikation mit dem zweiten Pi aber auch erst später hinzufügen.
Gerade versuche ich mich erst mal daran, die analogen Signale zu erhalten. Da bin ich mir leider nicht sicher, was ich wie wo anschließen muss. Falls ihr im RevPiTeam noch immer noch Video-Tutorials vorbereitet (die haben mir wirklich geholfen), dann wäre der beispielhafte Anschluss eine analogen Eingangs großartig
.Viele Grüße
Ricarda
Re: Pi2Pi Communication - Automatisierung auf dem Wasser
Hallo zusammen,
wir haben die weitere Tests durchführen können und mit "nur" einem Core-Modul funktioniert der Betrieb nun weitestgehend, die Einbindung eines analogen Signals erfolgt noch, aber während der Tests hatte das auch schon ohne Probleme funktioniert.
Da ich nach den restlichen Tests gern den zweiten Core hinzunehmen möchte, hätte ich noch eine Frage an dich Sven (revpimodio und co ist übrigens super danke dafür). Ist es richtig, dass ich Folgendes tun muss, damit Daten zwischen den Cores (bzw. nur von einem zum anderen) gesendet werden können (Ich kann es leider hier nicht testen, nur vor Ort):
Auf dem "MasterCore":
- RevpiPyLoad installieren und plcslave = 1 setzen
- IP des "SlaveCores" unter /etc/revpipyload/aclplcslave.conf eintragen
- Zugriff auf die IOs des "MasterCores" über die Zeile
revpimodio2.RevPiNetIO (ip-addresse des "MasterCores", [autorefresh = False, usw.]) ermöglichen bzw. ggf. auch nur Zugriff auf ein einzelnes Device des "MasterCores"
Auf dem "SlaveCore":
- Zugriff auf das virtuelle Device vom "MasterCore" über
revpimodio2.RevPiNetIODriver(ip-Adresse des "MasterCores", virtdev des "MasterCores", usw.)
Wenn ich das gemacht habe, kann ich dann auf dem "SlaveCore" über
z.B. rpi.io[bezeichnung des virtuellen Devices auf dem Master].value = 1
die Information an den Master geben?
Lieben Gruß und Danke
Ricarda
wir haben die weitere Tests durchführen können und mit "nur" einem Core-Modul funktioniert der Betrieb nun weitestgehend, die Einbindung eines analogen Signals erfolgt noch, aber während der Tests hatte das auch schon ohne Probleme funktioniert.
Da ich nach den restlichen Tests gern den zweiten Core hinzunehmen möchte, hätte ich noch eine Frage an dich Sven (revpimodio und co ist übrigens super
danke dafür). Ist es richtig, dass ich Folgendes tun muss, damit Daten zwischen den Cores (bzw. nur von einem zum anderen) gesendet werden können (Ich kann es leider hier nicht testen, nur vor Ort):Auf dem "MasterCore":
- RevpiPyLoad installieren und plcslave = 1 setzen
- IP des "SlaveCores" unter /etc/revpipyload/aclplcslave.conf eintragen
- Zugriff auf die IOs des "MasterCores" über die Zeile
revpimodio2.RevPiNetIO (ip-addresse des "MasterCores", [autorefresh = False, usw.]) ermöglichen bzw. ggf. auch nur Zugriff auf ein einzelnes Device des "MasterCores"
Auf dem "SlaveCore":
- Zugriff auf das virtuelle Device vom "MasterCore" über
revpimodio2.RevPiNetIODriver(ip-Adresse des "MasterCores", virtdev des "MasterCores", usw.)
Wenn ich das gemacht habe, kann ich dann auf dem "SlaveCore" über
z.B. rpi.io[bezeichnung des virtuellen Devices auf dem Master].value = 1
die Information an den Master geben?
Lieben Gruß und Danke
Ricarda
