Hallo!
Ich habe einen RevPI mit 1xDI und 1xDO Modul im Einsatz.
Euren Thread über die Ansteuerung des Prozessabbilds via Python (viewtopic.php?f=10&t=32)
habe ich verstanden und durchgearbeitet. Mein Programm (kleine Fabriksimulation) funktioniert soweit gut.
Allerdings benötige ich noch die Möglichkeit, Flanken von z.B. Lichtschranken via Interrupt auszulesen.
Bei normalen GPIOs kein Problem, aber wie ist dies über das Prozessabbild mit Python möglich?
Danke und Viele Grüße!
Benjamin
Interrupts mit Python
-
RevPiModIO
- KUNBUS
- Posts: 335
- Joined: 20 Jan 2017, 08:44
- Contact:
Hi Benjamin.
Du meinst sicher die Funktionen "add_event_detect" und "add_event_callback", oder?
Das wird in der Form bei dem RevPi nicht gehen - wobei da warten wir mal die Antwort von Volker hab...
In unserem RevPiModIO Modul haben wir solche Funktion über "Events" eingebaut. Das Prozessabbild wird zyklisch synchronisiert und auf Änderungen geprüft. Wenn eine bestimmte Änderung da ist, wird eine Funktion ausgeführt. Diese Funktion läuft dann im Hauptthread oder kann auch in einem neuen Thread gestartet werden.
Du machst sicher etwas wie unseren Revolutionsumbau momentan, oder? https://revpimodio.org/blogs/revolutionsumbau/
Dort registrieren wir z.B. Lichtschranken als Events die uns dann Merker setzen... Oder verwenden die "wait" Funktion:
Gruß, Sven
Du meinst sicher die Funktionen "add_event_detect" und "add_event_callback", oder?
Das wird in der Form bei dem RevPi nicht gehen - wobei da warten wir mal die Antwort von Volker hab...
In unserem RevPiModIO Modul haben wir solche Funktion über "Events" eingebaut. Das Prozessabbild wird zyklisch synchronisiert und auf Änderungen geprüft. Wenn eine bestimmte Änderung da ist, wird eine Funktion ausgeführt. Diese Funktion läuft dann im Hauptthread oder kann auch in einem neuen Thread gestartet werden.
Du machst sicher etwas wie unseren Revolutionsumbau momentan, oder? https://revpimodio.org/blogs/revolutionsumbau/
Dort registrieren wir z.B. Lichtschranken als Events die uns dann Merker setzen... Oder verwenden die "wait" Funktion:
Code: Select all
# Funktion self.set_metall ausführen, wenn Sensor "s_metall" eine RISING Flanke bekommt
self.rpi.devices["di02"].reg_event("s_metall", self.set_metall, edge=revpimodio.RISING)
# Anderer Ansatz für "Schrittkette" wartet auf Änderung
self.rpi.devices.wait("di02", "s_magazin2")python3-RevPiModIO - https://revpimodio.org/ || Der RevPi ist das Beste, was passieren konnte!
Hallo Benjamin,
ich denke, ich verstehe, was Du gerne hättest. Aktuell ist das aber so mit PiControl nicht machbar. Ich erkläre kurz was der Hintergrund ist:
In der Automatisierung unterscheidet man bei der Steuerungssoftware zwischen zyklischen Steuerungen und dne entsprechenden Sprachen FUB, ST, etc. (EN61131-3) auf der einen Seite und Event-basierten Steuerungen mit den entsprechenden Sprachen nach EN61499 auf der anderen Seite. Moderne Programmiersprachen für Desktop-Applikationen und Web sind immer ereignis-gesteuert. Aber in der Automatisierung hatte man gute gründe, sich skeptisch gegen diese Art der Programmierung zu verhalten, da die Vorhersehbarkeit und Prüfbarkeit eines ergeinis-basierten Systems extrem komplex ist. Das ist ein grund, warum Steuerungen in Maschinen in der Regel so absolut zuverlässig arbeiten, während PC-Applikationen gerne auch mal unter bestimmten Umständen unvorhersehbar in Zustände geraten, die unerwünscht sind.
Der Nachteil von "linearen" Steuerungsabläufen ist hingegen die enorme verschwendung von Systemressourcen durch ständiges Pollen von Eingängen sowie ein erheblich größerer Aufwand bei der Realisierung von verteilten Systemen. Es hängt nun daher von einer Anwedung ab, ob man eher die Sicherheit einer EN61131-3 basierten Software erwartet oder wegen schwacher Systemressourcen lieber eine EN61499 basierte Software realisieren will.
Wir haben uns bei der Konzeptionierung von PiControl zunächst für die EN61131-3 Unterstützung entschieden. Daher muss man das PA pollen, um an die Daten zu kommen.
Wir sehen aber die Notwendigkeit im bereich von IoT und verteilten Systemen hier parallel auch eine Möglichkeit für EN61499-basierte Software zu schaffen, bei zuvor konfigurierten Events entsprechende Nachrichten an Applikationen zu senden, die dann per IRS darauf reagieren können. Dies wird aber immer eine Softwarelösung sein (so wie unter Windows eine Applikation die Nachricht bekommt, dass die linke Maustaste gedrückt wurde). Die direkte Erzeugung von HW Interrupts durch IOs ist bei einem modularem System mit Backplanebus nicht oder nur mit erheblichen Einschränkungen und Limits realisierbar. Wenn es Dir also nicht um Systemressourcen geht, sondern um reaktionszeiten, dann ist der Weg nicht der, auf eine Erweiterung von PiCtory zu warten, sondern eher der, an eine externe Hardware zur Vorverarbeitung zu denken.
Wir haben solche "intelligenten" Sensoren zum Beispiel über USB angebunden. Eine entsprechende Treibersoftfware kann dann zwar auch die Daten ins PA schieben, aber gleichzeitig auch Events erkennen und entsprechend reagieren (z.B. mit einem MQTT request o.ä.). Es wird von uns sehr bald auch einen industriellen Arduino geben, der als vorgeschaltetes Subsystem solche zeitkritischen Aufgaben erledigen kann. Auch der RevPi Core home, der dieses Jahr auf den Markt kommen wird, wird mit direktem Zugang zu GPIOs über Pfostensteckverbinder ausgestattet sein, die man prinzipiell dann auch für Interrupts verwenden könnte. Aber diese GPIOs haben dann keine Eingänge mit Schaltschwellen nach industriellen Standards!
Eine Lichtschranke nach einer Flanke sollte man doch eigentlich auch mit Polling schnell genug bedienen können. Es sei denn, sie dient zur Abschaltung von rotierenden Teilen o.ä., was dann Safty-Technik wäre, für die der RevPi Core definitiv nicht eingesetzt werden sollte (und bei Einhaltung von Gesetzen im gewerblichen Bereich und nicht eingesetzt werden darf -> Maschinenrichtlinie).
ich hoffe, ich konnte mit dieser ausführlichen Erklärung Dir und allen anderen Interessierten Lesern vermitteln, warum es aktuell so nicht geht und was die Zukunft möglich machen wird.
ich denke, ich verstehe, was Du gerne hättest. Aktuell ist das aber so mit PiControl nicht machbar. Ich erkläre kurz was der Hintergrund ist:
In der Automatisierung unterscheidet man bei der Steuerungssoftware zwischen zyklischen Steuerungen und dne entsprechenden Sprachen FUB, ST, etc. (EN61131-3) auf der einen Seite und Event-basierten Steuerungen mit den entsprechenden Sprachen nach EN61499 auf der anderen Seite. Moderne Programmiersprachen für Desktop-Applikationen und Web sind immer ereignis-gesteuert. Aber in der Automatisierung hatte man gute gründe, sich skeptisch gegen diese Art der Programmierung zu verhalten, da die Vorhersehbarkeit und Prüfbarkeit eines ergeinis-basierten Systems extrem komplex ist. Das ist ein grund, warum Steuerungen in Maschinen in der Regel so absolut zuverlässig arbeiten, während PC-Applikationen gerne auch mal unter bestimmten Umständen unvorhersehbar in Zustände geraten, die unerwünscht sind.
Der Nachteil von "linearen" Steuerungsabläufen ist hingegen die enorme verschwendung von Systemressourcen durch ständiges Pollen von Eingängen sowie ein erheblich größerer Aufwand bei der Realisierung von verteilten Systemen. Es hängt nun daher von einer Anwedung ab, ob man eher die Sicherheit einer EN61131-3 basierten Software erwartet oder wegen schwacher Systemressourcen lieber eine EN61499 basierte Software realisieren will.
Wir haben uns bei der Konzeptionierung von PiControl zunächst für die EN61131-3 Unterstützung entschieden. Daher muss man das PA pollen, um an die Daten zu kommen.
Wir sehen aber die Notwendigkeit im bereich von IoT und verteilten Systemen hier parallel auch eine Möglichkeit für EN61499-basierte Software zu schaffen, bei zuvor konfigurierten Events entsprechende Nachrichten an Applikationen zu senden, die dann per IRS darauf reagieren können. Dies wird aber immer eine Softwarelösung sein (so wie unter Windows eine Applikation die Nachricht bekommt, dass die linke Maustaste gedrückt wurde). Die direkte Erzeugung von HW Interrupts durch IOs ist bei einem modularem System mit Backplanebus nicht oder nur mit erheblichen Einschränkungen und Limits realisierbar. Wenn es Dir also nicht um Systemressourcen geht, sondern um reaktionszeiten, dann ist der Weg nicht der, auf eine Erweiterung von PiCtory zu warten, sondern eher der, an eine externe Hardware zur Vorverarbeitung zu denken.
Wir haben solche "intelligenten" Sensoren zum Beispiel über USB angebunden. Eine entsprechende Treibersoftfware kann dann zwar auch die Daten ins PA schieben, aber gleichzeitig auch Events erkennen und entsprechend reagieren (z.B. mit einem MQTT request o.ä.). Es wird von uns sehr bald auch einen industriellen Arduino geben, der als vorgeschaltetes Subsystem solche zeitkritischen Aufgaben erledigen kann. Auch der RevPi Core home, der dieses Jahr auf den Markt kommen wird, wird mit direktem Zugang zu GPIOs über Pfostensteckverbinder ausgestattet sein, die man prinzipiell dann auch für Interrupts verwenden könnte. Aber diese GPIOs haben dann keine Eingänge mit Schaltschwellen nach industriellen Standards!
Eine Lichtschranke nach einer Flanke sollte man doch eigentlich auch mit Polling schnell genug bedienen können. Es sei denn, sie dient zur Abschaltung von rotierenden Teilen o.ä., was dann Safty-Technik wäre, für die der RevPi Core definitiv nicht eingesetzt werden sollte (und bei Einhaltung von Gesetzen im gewerblichen Bereich und nicht eingesetzt werden darf -> Maschinenrichtlinie).
ich hoffe, ich konnte mit dieser ausführlichen Erklärung Dir und allen anderen Interessierten Lesern vermitteln, warum es aktuell so nicht geht und was die Zukunft möglich machen wird.
Unser RevPi Motto: Don't just claim it - make it!
Hi,
vielen Dank für die schnellen Antworten!
@Volker: Danke nochmal für die sehr ausführliche Antwort! Ok, das macht Sinn und ich kann das verstehen. Ich hatte nur überlegt dass es mit Interrupts ganz nett wäre, die Flanken asynchron auswerten zu können.
Aber klar, in der Industrie ist alles linear. Es klingt auf jeden Fall sehr spannend was ihr noch so vor habt
.
Kurze Frage noch: Welche "intelligente" Sensoren meinst du genau? Hast du hier ein Beispiel? Ich würde den ganz gerne ausprobieren
@Sven: Cooles Projekt! Das schau ich mir mal an. Ja, so etwas ähnliches habe ich auch vor Allerdings etwas simpler, ist mein erstes Projekt gerade mit dem RevPi.
Gruß,
Benjamin
vielen Dank für die schnellen Antworten!
@Volker: Danke nochmal für die sehr ausführliche Antwort! Ok, das macht Sinn und ich kann das verstehen. Ich hatte nur überlegt dass es mit Interrupts ganz nett wäre, die Flanken asynchron auswerten zu können.
Aber klar, in der Industrie ist alles linear. Es klingt auf jeden Fall sehr spannend was ihr noch so vor habt
. Kurze Frage noch: Welche "intelligente" Sensoren meinst du genau? Hast du hier ein Beispiel? Ich würde den ganz gerne ausprobieren
@Sven: Cooles Projekt! Das schau ich mir mal an. Ja, so etwas ähnliches habe ich auch vor
Allerdings etwas simpler, ist mein erstes Projekt gerade mit dem RevPi.Gruß,
Benjamin
-
RevPiModIO
- KUNBUS
- Posts: 335
- Joined: 20 Jan 2017, 08:44
- Contact:
Das python3-RevPiModIO Modul kann eigentlich für beide Bereiche verwendet werden...
Allein bei uns im Haus gibt es diese zwei Lager
Die einen, aus dem Siemens Bereich, würden eine Endlosschleife nehmen, am Beginn die Inputs einlesen, dann alles Verarbeiten und am Ende die Outputs schreiben.
https://revpimodio.org/spiegel-der-endl ... putoutput/
Die Anderen, die "Desktopanwendungen" programmieren, arbeiten mit Events, die über das Modul Softwaretechnisch realisiert werden:
https://revpimodio.org/events-mit-dem-mainloop/
Die Events werden standardmäßig vom Hauptthread ausgeführt. Wenn du eine Eventfunktion asynchron starten willst, kannst du noch den Parameter "as_thread=True" zum reg_event hinzufügen. Das ist momentan bei uns noch in der experimentellen Phase - Entspräche dann aber quasi "add_event_callback", da wird die Funktion ja auch als neuer Thread gestartet...
Der Event-Funktion, die aufgerufen wird, wird der Parameter thread übergeben. Das ist dann ein RevPiCallback-Objekt, welches von threading.Thread erbt. RevPiCallback erweitert das Threading um die stop() Funktion und hat das Attribut exit, welches ein threading.Event ist. Damit könnte man dann die Funktion frühzeitig beenden if thread.exit.is_set(): Wie gesagt... noch experimentell, aber bereits im Modul enthalten.
Total unüblich ist sicherlich unsere "wait()" Funktion, wo das Programm wirklich auf einen Input "warten" kann In der Version 0.8.8 sogar mit angabe von edge=RISING/FALLING/BOTH für BIT-Inputs!
Wenn du Anregungen hast, komm gerne durch!
Gruß, Sven
Allein bei uns im Haus gibt es diese zwei Lager
Die einen, aus dem Siemens Bereich, würden eine Endlosschleife nehmen, am Beginn die Inputs einlesen, dann alles Verarbeiten und am Ende die Outputs schreiben.
https://revpimodio.org/spiegel-der-endl ... putoutput/
Die Anderen, die "Desktopanwendungen" programmieren, arbeiten mit Events, die über das Modul Softwaretechnisch realisiert werden:
https://revpimodio.org/events-mit-dem-mainloop/
Die Events werden standardmäßig vom Hauptthread ausgeführt. Wenn du eine Eventfunktion asynchron starten willst, kannst du noch den Parameter "as_thread=True" zum reg_event hinzufügen. Das ist momentan bei uns noch in der experimentellen Phase
- Entspräche dann aber quasi "add_event_callback", da wird die Funktion ja auch als neuer Thread gestartet...Der Event-Funktion, die aufgerufen wird, wird der Parameter thread übergeben. Das ist dann ein RevPiCallback-Objekt, welches von threading.Thread erbt. RevPiCallback erweitert das Threading um die stop() Funktion und hat das Attribut exit, welches ein threading.Event ist. Damit könnte man dann die Funktion frühzeitig beenden if thread.exit.is_set(): Wie gesagt... noch experimentell, aber bereits im Modul enthalten.
Total unüblich ist sicherlich unsere "wait()" Funktion, wo das Programm wirklich auf einen Input "warten" kann
In der Version 0.8.8 sogar mit angabe von edge=RISING/FALLING/BOTH für BIT-Inputs!Wenn du Anregungen hast, komm gerne durch!
Gruß, Sven
python3-RevPiModIO - https://revpimodio.org/ || Der RevPi ist das Beste, was passieren konnte!
