KI2Plc

Die Möglichkeiten einer SPS-Programmierung, um diese am Geschehen der künstlichen Intelligenz zu beteiligen

Fragen zum Thema:

Was soll das mit den Bits und Bytes?

Der Titel wurde geändert! Es stimmt, dass dieses Thema nicht nur für die Simatic und damit das TIA-Portal assoziiert. Deswegen die Änderung im Titel.

Das hat bei vielen Lesern zur Verwirrung geführt, denn Python-Programmierer suchen Python im TIA-Portal 😊 und TIA-Programmierer verstehen die Welt nicht mehr und fragen nach einer neuen TIA-Version.  Danke für die Hinweise und ich denke so ist es gut – zumindest vorerst.

Meine Antwort zur Frage der Zukunftsaussichten einer SPS nur mit Hochsprachen programmierbar:

Die SPS wird nach meiner Meinung in Python oder anderen Hochsprachen nicht so programmierbar sein, dass diese nur aus einer Komponente der Hochsprache besteht.

Frage zum Einsatz einer SPS mit pyPlc:

Hier soll eine Hardware, welche als SPS bezeichnet wird, über Python programmierbar werden. Die Übersetzung aus Python wird in eine Byte-Sequenz sein, so dass diese von einer SPS lesbar wird. Also kein integrierter Python-Interpreter.

So kann die SPS die Vorteile ihrer Bestimmung beibehalten und gleichzeitig der entsprechende SPS-Typ (Gerät) fast beliebig ausgewählt werden. Es wird eine pyPlc.py erstellt, welche die Programmierung in Richtung IEC 61131-3 lenkt und dieses überhaupt so möglich macht, dass in der SPS-Welt ein neuer Weg vorstellbar ist.

Warum die Schreibweise M0.0, MW0, usw.:

Und so kommen auch die Bits und Bytes in Spiel, denn die Peripherie einer SPS lässt sich in Bits und Bytes sehr gut interpretieren. Eingänge sind, so auch Ausgänge, meist in Gruppen organisiert. Das ist beispielhaft bei einem Arduino und auch bei einer S7-1200 so.

Dadurch entsteht automatisch der Eingang mir I0.0 und bedeutet, dass die Gruppe 0 mit der Bitadresse 0 angesprochen werden soll. Für den Ausgang Q0.0 ist es ebenso. In den meisten Programmen wird der Eingang in einen Bit-Merker kopiert und der Ausgang ebenfalls nicht direkt im Anwender-Programm, sondern über das Merker-Bit  M0.0 gesetzt. Die Umsetzung zum tatsächlichen Ausgang erfolgt dann ganz am Schluss nach der Anwendung (Treiberteil). 

Nur so kann eine Anwendung sehr gut getestet werden, ohne gleich etwas kaputt zu machen, da der Treiberteil in der Testphase nicht aufgerufen wird.

Deswegen wird das Bit als Input (I0.0), Merker (M0.0) und Output (Q0.0) in pyPlc.py bleiben.

Die Merker- und Doppelworte können auch zusätzlich über eine Variable bezeichnet werden. Das gilt auch für Bit-Variablen! So könnte der Python-Programmierer sich von den Bezeichnungen MW, MD usw. entfernen. Also alles im Lot 😊

Im Trainings-Video wird das alles sehr detaliert erklärt. Die Webseite ist in Arbeit und auch das erste Trainings-Video 😎. Zudem gibt es auf der Webseite einen Blog, welcher hoffentlich besser funktioniert wie dieser ...

Ich reagiere gerne auf weitere Fragen 🙋