Testschaltung für die E/A-Anbindung

Für Themen rund um das Prozessabbild des RevPi Core
Post Reply
Paul
Posts: 5
Joined: 10 Feb 2017, 20:43
Answers: 0

Testschaltung für die E/A-Anbindung

Post by Paul »

Hallo Revolution,

Gibt es für den RevolutionPi eine Methode/Verfahren um Testschaltungen vorzunehmen?

Ich meine Testschaltungen des E/A-Datenaustausches, wie im Dokument 'Arbeiten mit logi.RTS' von logi.cals auf Seite 32 beschrieben.

Für meinen Zweck würde es ausreichen, Eingänge und Ausgänge gleichzeitig aus zu schalten beim Hochfahren von PiControl. Komfortable wäre es natürlich Ein- und Ausgänge getrennt und während der Laufzeit schalten zu können.

Gruss
Paul
User avatar
volker
Posts: 1046
Joined: 09 Nov 2016, 15:41
Answers: 1

Re: Testschaltung für die E/A-Anbindung

Post by volker »

Hallo Paul,
ich weiß nicht zu 100%, was genau Du suchst. Aber ich vermute, dass Dir "piTest" helfen könnte. Bitte schau Dir unbedingt mal die Video Tutorials von Dirk an. Doprt findest Du u.a. eine Schritt für Schritt Anleitung, wie Du die IOs mit piTest testen kannst. Das würde ohne logi.RTS von der Kommandozeile aus (ggf. über SSH) funktionieren. Du musst dafür die Module in PiCtory konfiguriert haben und Dir die Liste der Adressoffsets notiert haben. Damit kannst Du dann über dei Befehlszeile einzelne oder alle Ausgänge schreiben und Eingänge lesen. Oder Du verwendest die symbolischen Namen, die Du unter PiCtory editieren kannst.
Alternatov kannst Du natüprlich in logi.CAD die Debugfunktion nutzen, um alle Prozessvariablen online zu lesen oder zu setzen. Dafür muss der Editor natürlich mit dem Zielgerät über Ethernet verbunden sein. Wenn Du über PiVtory die IOs als ST Deklaration exportiert hast und dann in Dein logi.CAD3 Projekt eingebunden hast, dann stehen alle IOs auf dieser "Life-Liste" zur Verfügung.
Hoffe, das war es, was Du suchst :-)
Unser RevPi Motto: Don't just claim it - make it!
Paul
Posts: 5
Joined: 10 Feb 2017, 20:43
Answers: 0

Re: Testschaltung für die E/A-Anbindung

Post by Paul »

Hallo Volker

Ich möchte nicht die Eingänge lesen und Ausgänge schreiben, sondern die Ausgänge lesen und die Eingänge schreiben.

Hintergrund: Wir haben die Absicht eine (teil-)automatiserte SW-definierte Testumgebung aufzubauen um Funktionstest, Regressiontests und Acceptancetests durchzuführen. Das heisst der zu steuernde 'Prozess' wird in SW simuliert. Die SW liest die Ausgänge bzw. schreibt die Eingänge aus dem resp. in das Prozessabbild,via PiControl.

Dazu müsste der zyklische Prozess der Übertragung der physikalischen Ein- und Ausgänge ins Prozessabbild unterbunden werden können, da ja die DI/DO Module in der Testumgebung nicht beschaltet sind. Im Dokument von logi.cals wird das als 'Testschaltung' bezeichnet.
User avatar
volker
Posts: 1046
Joined: 09 Nov 2016, 15:41
Answers: 1

Re: Testschaltung für die E/A-Anbindung

Post by volker »

Hi,
mal unabhängig von logi.cals, sehe ich da eine einfache Möglichkeit Ausgänge zu lesen:
Das geht einfach mit PiControl als Treiber. wie man mit Python oder C zugreift => siehe Tutorials und Downloads. Allerdings müsste dabei dann logi.cals ausgeschaltet werden, was ja offenbar genau nicht passieren soll.

Schreiben der Eingänge ginge rein theoretisch auch, aber in der Praxis würde PiControl sofort die Eingänge wieder mit den zyklischen Daten vom DIO überschreiben. Dies kann man aber nicht einfach abschalten.

In einer der nächsten PiCtpry Versionen werden wir aber die Logik der Datenverteilung umstellen:
Ein Databroker kann Eingangsdaten auf Asugänge verteilen. Dabei hat dann ein Ausgang immer eine Quelle (Eingang), aber ein Eingang kann mehrere Ausgänge mit Daten beschicken.
Dabei wird jede Software als "Adapter" in PiCtory verstanden, der dort konfiguriert werden muss. Mit einer Erweiterung der grafischen Oberfläche kann man dann die Zuordnungen zwiscchen Ein- und Ausgängen vornehmen. Zur Laufzeit verteilt dann ein Databroker die Daten dynamisch gemäß der Konfiguration. Dieses Konzept ist universeller und logi.cals wird dann dort genauso eingeordnet werden und muss auch konfiguriert werden. Die aktuellen "Export"-Kästchen, die momentan den Datenaustausch zwischen logi.RTS und PiControl steuern, entfallen dann.

In diesem neuem Konzept könntest Du dann zwei Konfigurationen abspeichern: Testbetrieb, bei dem logi.RTS seine Daten mit dem Simulator/Testsoftware austauscht (die dann ebenso ein Adapter ist) und Normalbetrieb, bei dem die Daten statt dessen mit DIOs ausgetauscht werden.

Wir werden zur embedded world einen Modbus-Adapter vorstellen, der genau mit dieser Oberfläche dann konfiguriert werden kann. Sicher werden wir dann sehr bald auch logi.RTS Zugriffe entsprechend umstellen. Wäre damit Euer Vorhaben machbar?

Alternativ müsste logi.cals prüfen, ob eventuell mit deren Bordmitteln auch so ein Testbetrieb möglich wäre. Da dann aber vermutlich die C-Software vom Testablauf als ein Funktionsblock realisiert, wäre es ja leider ein Eingriff in die En61131-3 Steuerungssoftware, die ja gerade mit Deinem Tool geprüft werden soll - vermutlich keine gute Idee?
Unser RevPi Motto: Don't just claim it - make it!
User avatar
RevPiModIO
KUNBUS
Posts: 322
Joined: 20 Jan 2017, 08:44
Answers: 0
Contact:

Re: Testschaltung für die E/A-Anbindung

Post by RevPiModIO »

Wir haben mit unserem RevPiModIO-Modul für Python etwas vorbereitet für einen solchen Testbetrieb. Dabei geben wir als "Prozessabbild" eine x-beliebige Datei an über die die Daten ausgetauscht werden sollen.

Das Fenster auf der linken Seite "simuliert" einen RevPi. Dort können wir die Inputs bearbeiten und dann "schreiben". Die rechte Seite ist unser ganz normaler "Onlineviewer" der die IOs ließt und Outputs "schreiben" kann. Ich denke, das ist genau was du meinst?

Image

Das Problem mit logi.CAD wird sein, dass man es nicht auf eine x-beliebige Datei "verbiegen" kann und, wie Volker schon schrieb, bringt es nichts die Inputs in das /dev/piControl0 zu schreiben, da es sich ständig mit den DIOs aktualisiert...

Gruß, Sven
python3-RevPiModIO - https://revpimodio.org/ || Der RevPi ist das Beste, was passieren konnte!
Paul
Posts: 5
Joined: 10 Feb 2017, 20:43
Answers: 0

Re: Testschaltung für die E/A-Anbindung

Post by Paul »

Hallo Volker,
Die Community hier ist fantastisch. Selbts am Wochenende wird dir geantwortet. Vielen Dank.

Du hast natürlich recht, die Ausgänge kann ich lesen auch wenn die DO's nicht beschaltet sind. Das Problem sind die Eingänge. Solange der zyklische Transfer von den DI-Modulen ins Prozessabbild läuft ist es sinnlos diese zu schreiben.

Wenn du von einem Databroker sprichst, darf ich mir so was wie einen MQTT-Broker vorstellen? Die einen Adapter sind die Provider und andere Adapter die Consumer die Eingänge "abonnieren"?

Dann bin ich gespannt auf diese Lösung. Gibt es dazu schon ein API? Voraussetzung ist aber, dass wir die SPS-Programme nicht anpassen müssen für die Testumgebung, nur allenfalls die Konfigurationen.
Paul
Posts: 5
Joined: 10 Feb 2017, 20:43
Answers: 0

Re: Testschaltung für die E/A-Anbindung

Post by Paul »

Hallo Sven

Hmmm... Über dein Python-Modul habe ich an anderer Stelle hier im Forum schon was gelesen. Tolle Idee. Werde ich bei Gelegenheit auch mal evaluieren. Ich verstehe das RevPiModIO als Wrapper um das PiControl API in Python verfügbar zu machen. ist das korrekt? Ich habe bloss noch nicht begriffen wie ich das abgebildete Tool zur Lösung meines Problems einsetzen kann.

Ich versuche mal mein Szenario mit der einfachsten aller Geschichten zu erzählen:

Das BLINK Programm

Erich hat die Aufgabe ein SPS-Programm zu erstellen das auf Tastendruck eine LED blinken lässt. Die LED soll am Output_Pin_1 angeschlossen werden. Am Input_Pin_1 soll der Taster angeschlossen sein. Wenn der Taster gedrückt wird soll die LED blinken.

Anita soll das SPS-Programm prüfen. Da aber gerade weder Taster noch LED verfügbar sind, erstellt Anita ein Testprogramm in C, C++, Java, Python ... whatever. Es simuliert den Taster, die LED und den Bediener der Taste auch gleich mit. Im Testprogramm sind auch einige Testfälle (Unit-Tests) definiert, die die Testumgebung selbständig abarbeiten kann.

Vor dem Feierabend lädt Anita das SPS-Programm das sie von Erich erhalten hat auf den Test-RevPi und startet ihr Testprogramm in der Testumgebung. Das Testprogramm schreibt via PiControl die Eingangsvariable für Input_Pin_1 (Taster) auf das Eingangsabbild und liest die Ausgangsvariable für Output_Pin_1 (LED) aus dem Ausgangsabbild. Für jeden Testfall schreibt die Testumgebung das Resultat in einen Testreport.

Am Morgen danach schaut sich Anita den Testreport auf dem Test-Webserver an und sendet Erich eine e-mail mit einem Dankeschön weil die Tests gleich beim ersten Mal erfolgreich waren.

Sven, das ist ein Szenario in dem RevPiModIO von Nutzen sein kann wenn das Testprogramm in Python erstellt wird. Aber wo kommt das Tool ins Spiel?
User avatar
RevPiModIO
KUNBUS
Posts: 322
Joined: 20 Jan 2017, 08:44
Answers: 0
Contact:

Re: Testschaltung für die E/A-Anbindung

Post by RevPiModIO »

Hallo Paul!

RevPiModIO ist ein Wrapper für piControl, da hast du absolut recht! Du kannst über die Namen aus piCtory Werte zuweisen und das Modul kümmert sich darum sie an die richtigen Stellen zu schreiben...
Das grafische Tool da oben basiert nur auf dem eigentlichen Modul. Wir haben es für unseren IO-Check benutzt. Um alle Ein- und Ausgänge zu testen.


Zu deinem "BLINK Programm" (gehen wir davon aus, Erich und Anita verwenden beide Python):

Erich verwendet RevPiModIO um das SPS-Programm in Python zu schreiben. Er kann in dem Modul Input_Pin_1 als "event" mit einer Funktion registrieren, die automatisch ausgeführt wird, wenn sich der Wert ändert. Der Wrapper kümmert sich um das lesen/schreiben/beobachten der ganzen Daten aus piControl. In der Funktion, die RevPiModIO bei Wertänderung von Input_Pin_1 aufruft, setzt er als value für Output_Pin_1 abwechselnd True - False...

Anika schreibt jetzt ihr Simulationsprogramm, verwendet auch RevPiModIO und setzt den Parameter "simulation" auf True. Damit verdreht RevPiModIO bei Instantiierung die Ein- und Ausgänge für IHR Programm. Nun kann sie in einer Schleife den Input_Pin_1 mit True setzen (Taster gedrückt) und lesen / protokollieren was Erichs Programm macht, indem sie den Wert von Output_Pin_1 ließt... Die Testszenarien und deren Logik muss man natürlich selber programmieren und sich ausdenken, RevPiModIO bietet dir eben "nur" etwas Komfort dabei. Anika könnte den Output_Pin_1 auch als "event" registrieren und bei dessen Änderung loggt sie die Zeit; Status_Input_Pin1; Status_Output_Pin_1.

Problem: Wie oben ja schon geschrieben - Wenn Erich jetzt logi.CAD benutzt und der RevPi-Core die Daten im piControl ständig überschreibt, bringen die Daten von Anikas Programm nichts. Man müsste logi.Cad also iwie dazu bringen eine andere "Datei" zu verwenden oder die Aktualisierung pausieren können...

PS: Das mit dem "drehen der Ein- und Ausgänge" ist nur wichtig, da das RevPiModIO eine Exception feuern würde, wenn man auf einen Input einen Wert schreiben will...


Mein "Revolutionsumbau":

Mein Vorgehen sieht momentan so aus: Ich programmiere mein Python-SPS-Programm, gebe RevPiModIO eine Datei auf meinem Rechner als "piControl"-Device und schaue mit dem grafischen Tool in die Datei. Wenn mein Programm arbeitet beobachte ich die Ausgänge, die gesetzt werden, bzw. setze über das Tool die Eingänge... Mache es also per Hand... Das ist für automatisierte Testszenarien, wie du sie brauchst, natürlich nicht der richtige Ansatz :D

Ich hoffe, ich konnte das einigermaßen erklären.

Ich denke das "praktische" an RevPiModIO ist einfach, dass man Namen verwenden kann und sich nicht darum kümmern muss an welche Stellen die IO Daten gelesen/geschrieben werden müssen. Das Event-Handling mit dem mainloop() ist auch ganz interessant (an tkinter angelehnt) und das Erstellen eigener IOs auf den Gateway-Modulen, die über mehrere Bytes lang sein können - und mit struct() in das gewünschte Format gebracht werden (verwenden wir bei unserem Modbus TCP Datenlogger)

Gruß, Sven
python3-RevPiModIO - https://revpimodio.org/ || Der RevPi ist das Beste, was passieren konnte!
Paul
Posts: 5
Joined: 10 Feb 2017, 20:43
Answers: 0

Re: Testschaltung für die E/A-Anbindung

Post by Paul »

Hallo Sven,
Jetzt habe ich das auch verstanden. Danke für die Erklärungen.

Es ist nun aber so dass Erich logi.CAD3 benutzt um die SPS-Programme zu erstellen. In der Testumgebung von Anita läuft das Programm aber auf RevPi unter logi.RTS. Da ist logi.CAD3 nicht notwendig.

Die E/A-Anbindung ist im RevPi Treiber (PiControl.ko) enthalten. Gemäss Blog hier getrennt für RS485 Bus (DI/DO-Module) und Ethernet Bus (Gateway-Module).

Deshalb meine ursprüngliche Frage, ob KUNBUS in diesem Treiber die Möglichkeit vorgesehen hat, dass diese zyklischen Prozesse vorübergehend oder permanent angehalten (suspend) werden können.

Da dies aber nicht der Fall zu sein scheint, muss ich mich wohl auf den Databroker warten, den Volker erwähnt hat.

Oder ich poste unter 'Wunsch- und Ideensammlung' einen Vorschlag für dieses Feature.
Post Reply