Codesys, Prozessabbild (PAE, PAA) mit Raspberry, I2C-Baugruppen und Multiplexer

[Bytebeisser]

Hallo,

ich bin neu hier und habe eine Frage zum Prozessabbild der Eingänge bei einer "Codesys-SPS".

Die Frage lautet: Wie erstellt man in Codesys -auf korrekte Art- PAE und PAA, wenn man Ein- und Ausgänge multiplexen muss?

Ich verwende einen Raspberry mit I2C-Baugruppen und möchte mehr digitale Ein- und Ausgänge verwenden, als an einen Bus "dranpassen". Deswegen verwende ich einen Multiplexer, um nacheinander zwei Bussegmente einzulesen bzw. zu schreiben.

Einen Teilerfolg habe ich schon erzielt, bin mir aber nicht sicher, ob ich es richtig gemacht habe. Deswegen die allgemeine Frage.

Ich formuliere mein Problem gerne ausführlicher und kann auch ein paar Worte zum Projekt und meinem Hintergrund liefern aber ich möchte nicht gleich mit meinem ersten Beitrag das Forum "zumüllen".

Danke fürs Lesen

[asci25]

So etwas habe ich nie gemacht und werde es wohl nie brauchen. Eine Vorstellung davon habe ich aber:

Das Prozessabbild wird in dem Fall nicht gemultiplext.

Du musst Dir das PAE auf zwei virtuelle PAE, die Du zusätzlich anlegst, im richtigen Timing ummappen.

Genauso musst Du zwei virtuelle PAA anlegen und diese im richtigen Timing abwechselnd auf das echte PAA ummappen.

"Virtuell" heist hierbei, einfache Variablen ohne echte IO-Anbindung verwenden.
Mit "richtigem Timing" meine ich, dass Du synchron zu der verwendeten Hardware-Multiplex-Technologie sein must.

[Bytebeisser]

Hallo,

danke für deine Antwort.
Mein Ansatz sieht so aus:

Das "Gerüst" is in AS programmiert.
Schritt 1: Es wird BUS0 ausgewählt und alle Eingänge in Variablen (Satz 1) übertragen
Schritt 2: Es wird BUS1 ausgewählt und alle Eingägne in Variablen (Satz 2) übertragen.
Schritt 3: Hauptprogramm mit Aufrufen von Unterprogrammen oder FBs je nach Bedarf. Alle Ergebnisse werden nicht direkt auf Ausgänge sonder in Variablen gechrieben.
Schritt 4: Es wird BUS 2 ausgewählt und Satz 1 der Ausgangsvariablen wird auf die Ausgänge geschrieben
Schritt 5: Es wird BUS 3 ausgewählt und Satz 2 der Ausgangsvariablen wird auf die Ausgänge geschrieben

Grundätzlich scheint das funktionieren, wobei ich einige Effekte beobachten konnte. Die Eingangsvariablen "flattern" zum Beispiel. Ist and BUS 0 Eingang 1 gesetzt und an BUS 1 nicht, ist im Online/Debug-Modus ein kippen der beiden Variablen zu sehen.
Erst wenn ich das das Schreiben der Einänge in die Variablen in eine IF-Schleifen packe, die nur aufgerufen wird, wenn ein "Merker" (ich nenne ihn mal so, ich glaube der Begriff Merker ist eigentlich für etwas anderes Reserviert) für den jeweiligen Schritt gesetzt ist, hört das Flattern auf. Dies wundert mch, da ich annahm, dass die Anweisungen in einem Schritt nur abgearbeitet werden, solange der Schritt aktiv ist. Aber viellicht herrscht hier eine "Race Condition", die ich erst mit den "Merkern" bändigen konnte.

Die grundsätzliche Frage ist aber, ob mein Ansatz überhaupt richtig ist oder ob es evt. schon Bausteine gibt, die PAE und PAA sicher handhaben können.

[asci25]

Wenn ich es richtig verstehe, schaltest Du BUS0 - BUS3 per PAA um.

Da sollte man im Sinn haben, wie eine SPS funktioniert.

Start - PAE einlesen - Programm abarbeiten - PAA ausgeben - Ende

Wenn Du, ich vermute mal, den Bus aus dem Schritt über das PAA selektierst, sind bereits die Eingänge eingelesen und die kommen für einen Zyklus noch aus der falschen (vorherigen) Selektion, weil das PAA wird ja erst danach geschrieben. Durch Deine If-Bedingung scheinst Du das dazu passend um einen Zyklus zu verzögern.

Wenn Du AS nutzt, kannst Du auch die Schritte anders organisieren:

1. Bus0 auswählen --> über PAA?
2. PAE aus Bus0 einlesen
3. Bus1 auswählen --> über PAA?
4. PAE aus Bus1 einlesen
5. Programm abarbeiten
6. Bus2 auswählen --> über PAA?
7. Ergebnisse für Bus2 in PAA schreiben
8. Bus3 auswählen --> über PAA?
9. Ergebnisse für Bus3 in PAA schreiben

Das sollte Dein Problem auch lösen.

Bausteine wirst Du wohl nicht finden - ich weiß es jedenfalls nicht -, weil normalerweise steht heutzutage genug IO-Breite zur Verfügung, so das man das normalerweise nicht braucht.

[Bytebeisser]

Was meinst du mit 'per PAA' umschalten?

Vielleicht eine Erklärung dazu (ich könnte auch auf die Seite verlinken, von der ich mein Material habe aber ich will nicht ungefragt Werbung machen. Bin noch neu hier und halte erstmal den Ball flach, bis ich weiss wo der Hase langläuft).

Also: Ein- und Ausgangsbaugruppen sowie der Busumschalter (Multiplexer) sind alles I2C-Geraete. Den Muxer steuere ich ueber einen FB an und die Ein- und Ausgaenge ueber "Baugruppentreiber" (oder wie man die auch immer nennen soll).

Ich spreche also zwei verschiedene Eingangsbausteine nacheinander unter derselben I2C-Adresse an, wobei ich zwischendurch den BUS umschalten muss.


PAE und PAA kenne ich von meinen leichten Beruehrungen mit S5 und S7 for 25 bis 30 Jahren auch noch. Da hiess es, dass eine SPS immer mit mit Prozessabbildern (zumindest bei digitalen Werten) arbeite. Allerdings war das die Siemens-Welt. Hat der kleine Raspberry mit Codesys das auch?

Hmm, da faellt mir grad was ein. Ich koennte mal die Intervallzeit auf 5 Sekunden oder noch mehr setzen. Wenn dann die SPS in einem der Leseschritte ist, betaetige ich mal mehrfach einen Schalter.
Eigentlich sollte dann ja der zugehoerige Eingang nciht mehr aendern oder?

[asci25]

Was meinst du mit 'per PAA' umschalten?

...Den Muxer steuere ich ueber einen FB an...

Damit hast Du die Frage selbst beantwortet. Aus dem FB geht es über das PAA zum MUX. Aber da hast Du die Eingänge schon längst einmal (falsch) eingelesen. Du musst aber zuerst den MUX umschalten und darfst erst dann die Eingänge verwenden.

Bei den Siemens-SPS'n ist es so, dass die Prozessabbilder begrenzt waren (256 oder 512 Byte). Darum hat man für Anloge Baugruppen gerne höhere Adressen verwendet und die über die peripheren Adressen (statt EW schreibtst Du PEW) eingelesen. Diese gehörten nicht mehr zum Prozessabbild und wurden quasi synchron aus dem IO-Speicher gelesen. Dadurch waren die Werte aber nicht mehr konsistent, wie bei dem PAA und PAE. Man konnte analoge Werte aber auch innerhalb des Prozessabildes addressieren - wenn man nicht zu viele digitale Signale hatte. Diie digitalen waren über die peripheren Adressen nicht so einfach anzusprechen, weil die gingen nur Byteweise. PE 334.7 war nicht möglich, E 34.7 aber schon. Aber dass geht jetzt in die falsche Richtung.

Jedenfalls die SPS und auch Codesys läuft heute immer noch genau nach dem Prinzip, nur mit dem Unterschied dass die Prozessabbilder größer geworden sind. Und wenn Du einen MUX aus dem FB ansteuerst, dann geht das eben nur über das Prozessabbild, das erst zum Ende des Zykluses aktuallisiert wird. Und erst danach kannst Du im nächsten Zyklus die richtigen Eingänge auslesen.

[Bytebeisser]

Ach so meintest du das. Danke fuer die Erkärung. Ja ich wähle den Bus über das PAA aus.
Stimmt, ist mir garnicht so bewusst geworden aber wenn man mal drüber nachdenkt....

Ich wüsste aber auch nicht, wie ich es sonst machen sollte.

Und im Prinzip mache ich es ja auch so, wie von dir vorgeschlagen, nur halt so, dass es so zusammengefasst ist:


Schritt 1
1. Bus0 auswählen --> über PAA?
2. PAE aus Bus0 einlesen

Schritt 2
3. Bus1 auswählen --> über PAA?
4. PAE aus Bus1 einlesen

Schritt 3
5. Programm abarbeiten

Schritt 4
6. Bus2 auswählen --> über PAA?
7. Ergebnisse für Bus2 in PAA schreiben

Schritt 5
8. Bus3 auswählen --> über PAA?
9. Ergebnisse für Bus3 in PAA schreiben

Im Prinzip wird also, aus Sicht der SPS, ein PAE gelesen und ein PAA geschrieben, wobei das in Schritt 3 eine "Nullrunde" ist, weil keine Ein- und Ausgänge erwähnt werden. Richtig?


Die "nur" 256 oder 512 Byte klingen klingen zunächst mal nach lächerlich wenig, vor allem in der heutigen Zeit von RAMgrössen im Gigabyte-Bereich. Aber es sind ja doch mal grad locker 2000 Ein- und/oder Ausgänge bereits bei 256Byte.

Aber es stimmt, ich muss ich auf jeden Fall erstmal in die Arbeitsweise einer SPS reindenken. Bis ich das erfolgreich hinter mich gebracht habe, könnte ich noch mit der einen oder anderen naiven Frage auffallen.

[asci25]

Und im Prinzip mache ich es ja auch so, wie von dir vorgeschlagen, nur halt so, dass es so zusammengefasst ist:


Schritt 1
1. Bus0 auswählen --> über PAA?
2. PAE aus Bus0 einlesen

Schritt 2
3. Bus1 auswählen --> über PAA?
4. PAE aus Bus1 einlesen

Schritt 3
5. Programm abarbeiten

Schritt 4
6. Bus2 auswählen --> über PAA?
7. Ergebnisse für Bus2 in PAA schreiben

Schritt 5
8. Bus3 auswählen --> über PAA?
9. Ergebnisse für Bus3 in PAA schreiben

1 ud 2 sowie 3 und 4 solltest Du sauber trennen, wenn Du das "Kippen" beim Debugging nicht sehen möchtest.
Aber es ist auch egal, weil ein AS-Schritt läuft mindestens 2 Zyklen und beim 2. Zyklus hast Du bereits die richtigen Werte, bevor Du dann in das "Programm" wechselst.

Im Prinzip wird also, aus Sicht der SPS, ein PAE gelesen und ein PAA geschrieben, wobei das in Schritt 3 eine "Nullrunde" ist, weil keine Ein- und Ausgänge erwähnt werden. Richtig?

"...,weil die Eingänge nicht vom Programm gelesen und die Ausgänge unverändert zurückgeschrieben werden..." dürfte das etwas genauer umreisen. Eine Nullrunde aus Sicht der Aktuallisierung von PEA und PAA ist es zumindest nicht.

[Bytebeisser]

#Edit. Fehlte ein kleines aber wichtiges Wort, habs in rot eingefügt#

Aaahhh, *patsch*
natürlich kann ich NICHT die Aktionen 1 und 2 bzw 3 und 4 in jeweils einen Schritt zusammenfassen (Obwohl, "können" tue ich das schon aber dann wirds halt Mist).
Ja du hast es geschrieben, aber hat was gedauert aber so langsam klingelt es.


Ich schreibs nochmal hin, um zu prüfen ob ich es verstanden habe:

Wenn ich in einem Schritt den Muxer setze und die Eingänge lese zäume ich Pferd quasi vom Schwanz her auf. Ich lese die Wert des Busses, der vorher ausgewählt war. Im nächsten Schritt käme dann der Bus dran, den ich gerade eben gesetzt habe (und annahm, gelesen zu haben) usw.
Bei Ausgängen kann das evtl. noch klappen (weil nur geschrieben wird) aber bei Eingängen ist das böse. Das führt nämlich zu einer Vertauschung der Variablen: Die "Merker" für Bus 0 haben die Werte für Bus 1 und die "Merker" für Bus 1, die von Bus 0.
Und jetzt darfst du mal raten, an welchem Problem ich die ganze Zeit noch geknabbert habe. Ich dachte schon der FB wäre falsch, aber nein, das Problem sass vor dem Computer.

Also, vielen Dank. Du hast mir die richtigen Denkanstöße gegeben.
Ich verwende nun je Bussegment zwei Schritte:
Im ersten wird der Muxer gesetzt übers PAA
Im zweiten wird das PAE des Bussegments gelesen
danach wirde wieder umgeschaltet usw.
Das mache ich nun auch mit den Ausgängen, damit es auch da kein Gedöns gibt.

Danke für deine Hinweise und die Geduld beim Erklären.

[asci25]

Yeah, well done!