Wir entwickeln momentan eine neue Syntax für unser RevPiModIO Modul. „In Zukunft eine 2 an revpimodio hängen“ weiterlesen
Version 0.16.0 – Weniger Python, mehr SPS!
Dieses Update bringt neue Funktionen mit sich, um mit weniger Python mehr SPS zu programmieren!
Wir stellen vor: cycleloop(zyklusfunktion)
- Neuer Cycleloop der in einem festgelegten „
auto_refresh
“ Takt die Eingänge einließt, die übergebene Funktion aufruft und nach Abarbeitung die Outputs schreibt. Wird im Programmdevices.cycleloop(zyklusfunktion)
aufgerufen, blockiert es an dieser Stelle und führt zyklisch die Funktion „zyklusfuntkion
“ aus. Dieser Funktion wird eine Instanz der KlasseRevPiCycletools()
übergeben, welche Werkzeuge wie Taktmerker, Flankenmerker oder Timerobjekte beinhaltet. - Neue Funktion für einfaches Beenden eines zyklischen oder eventbasierten Programms
.handlesignalend(cleanupfunc)
- Sollte die eingestellte Aktualisierungsrate der Prozessabbildaktualisierung (
auto_refresh
) nicht einzuhalten sein, werden Warnungen ausgegeben. auto_refresh
Werte größer 1000 Millisekunden ergaben Fehler bei.wait
undmainloop()
- Modul beendet sich schneller bei
.cleanup()
oder.exit()
- Modul blockiert das Beenden nicht mehr bei Verwendung im interaktiven Modus der Python-Shell
Revolutionsumbau 2.0 freestyle – LEBT!
Nach dem Umstieg von Motorschützen auf einen Frequenzumrichter und die Neuplatzierung der Sensoren „s_rutsche“ und „s_metall“ sieht das ganze so aus:
Revolutionsumbau 2.0 freestyle – Sensoren
Da wir nun endlich den Prüfungsaufbau vollständig modifizieren können, beseitigen wir die größte Schwachstelle des Systems: „Revolutionsumbau 2.0 freestyle – Sensoren“ weiterlesen
Revolutionsumbau 2.0 freestyle – Frequenzumrichter
Bei der ersten Version unseres Revolutionsumbaus war der Aufbau vom Prüfungsobjekt fest vorgegeben. Positionen von Sensoren und Zylinder, aber auch der Ablauf musste strickt eingehalten werden.
Das ist jetzt VORBEI! Wir können alles anpassen wie es uns gefällt! „Revolutionsumbau 2.0 freestyle – Frequenzumrichter“ weiterlesen
Virtuelle Devices statt Programmvariablen
In der ersten Version unseres Revolutionsumbaus haben wir die Magazinfüllstände in unserem Programm als Variablen angelegt. Das hatte natürlich den Nachteil, dass diese Werte beim Programmneustart verloren waren.
Nun wollen wir diese Werte über virtuelle Devices im Prozessabbild speichern!
piCtory Konfiguration
Legen wir uns ein virtuelles Device mit dem Namen „virt01“ in piCtory an:
Altes wheezy Image mit Kunbus Paketquellen verbinden
Solltet ihr noch einen RevPi mit dem wheezy Image haben und dieses behalten wollen, stellt Kunbus dafür auch Paketquellen zur Verfügung! „Altes wheezy Image mit Kunbus Paketquellen verbinden“ weiterlesen
Version 0.15.3
Heute veröffentlichen wir ein Update!
- Es kann nun für alle IOs der Klassen RevPiIO() und RevPiStructIO() eine „byteorder“ konfiguriert werden. Diese ist wichtig für die int() Umrechnung bei Werten, die mehr als ein Byte lang sind, z.B. bei RevPi Gateways (Standard ist „little“)
- Das Klassenattribut „signed“ wurde für die RevPiIO() Klasse eingefügt. Dieses kann auf True gesetzt werden, wenn die int() Umrechnung der bytes() mit Vorzeichen erwünscht ist.
Besonders Interessant bei „Countern“ der DI, DO und DIO Module, welche beim Rückwärtszählen sonst 65535 anzeigen.
rpi.devices["dio"]["Counter_1"].signed = True
rpi.devices["dio"]["Counter_1"].value
Welcher nun -1 anzeigen würde. - Magic Methode __contains__ an RevPiDevicelist und RevPiDevice angefügt. Damit sind nun Abfragen in Form von
"dio02" in rpi.devices
und"I_1" in rpi.devices["dio02"]
möglich, welche prüfen, ob ein Device-Name vorhanden ist oder ein IO-Name. - RevPiDevicelist unterstützt nun auch die Build-In Funktion
len(rpi.devices)
, welche die Anzahl der Devices inkl. Core zurück gibt. - RevPiDevicelist hat die neue Funktion writedefaultinputs(self, virtual_device) bekommen.
- Und weitere wichtige interne Veränderungen, die dieses Update erforderlich machen.
Version 0.15.2
Diese Version hat ein paar kleine Bugfixes, die unter bestimmten Bedingungen auftreten.
- Sollte ein Fehler auf dem /dev/piControl0 Device auftreten, z.B. wegen einem Reset, wird dieser Fehler normalerweise abgefangen. In der Version ab 0.15.0 löst dieser Anfang jedoch selber einen Fehler aus 🙁
- Wenn mit auto_refresh gearbeitet wird und innerhalb eines Programms das RevPiModIO neu instanziiert wird ohne .cleanup() Aufruf, beendet sich der auto_refresh-Modus nicht sauber.
- Monitoringmode repariert
RevPiModIO(monitoring=True)
- Seit Version 0.8.8 können mit reg_event auch Ausgänge in der Eventüberwachung registriert werden. Diese wurden jedoch nicht ausgewertet.
Schnell starten mit dem RevolutionPi
Wir stellen euch hier mal einen schnellen ersten Start mit dem RevolutionPi vor, um IOs zu testen, ohne eine einzige Zeile programmieren zu müssen!
Den Aufbau und die Verkabelung des Revolution Pi könnt ihr wunderbar aus der Kunbus Dokumentation entnehmen. Den benötigten SSH Zugang bekommt ihr dort auch erklärt.
Unser Aufbau
RevPi Core / DIO -> Ausgänge direkt auf die Relais geführt