Absturz der IOT2000

IOT2000  ohne Shield testen

Bei den ersten Schritten mit der SIMATIC IOT2000 fällt auf, dass beide Sketche sich gleichzeitig im RUN befinden können. Das kann sehr Vorteilhaft sein, wenn die Arbeitsaufteilung stimmt und bedeutet, dass die Programme sich nicht in Konkurrenz befinden dürfen. Also entweder die Pins mit der Arduino- oder der Intel® -Welt programmieren, sonst gibt es einen gemischten Salat ☺.

Absturz beim Test der PLC in Kapitel 9 festgestellt

Die Anwendung der  PLC wird in Kapitel 9 vorgestellt. Hier ein Ausschnitt für das Lesen von analogen Werten.

9.2.5 Analogwerte lesen uns skalieren

Das Programm befindet sich auf der Buch-CD unter PLC_IOT200_Kap_9_2_5.

Hier wurde die Funktion von SCALE aus der FUP-Programmierung verwendet und angepasst. Die Parameter error und BIPOLAR (Bild  9.11), wurden nicht übernommen. Tritt ein Fehler auf, z. B. bei falscher Angabe der Grenzen (HI_LIM, LO_LIM), wird der Analogwert auf 0.0 gesetzt. Die Anwendung negativer Werte findet im Baustein nicht statt und kann vom Leser gegebenenfalls nachgeholt werden. In den meisten Fällen ist der negative Wert aus dem Rohwert ein Thema nach der Skalierung, wenn das bei einem Rohwert von 0-1023 überhaupt sinnvoll ist, da dieser nicht negativ werden kann.

Im Beispiel wurde plc.Scale für vier Bereiche skaliert. Jeder Bereich soll einem Ausgang (A0-A3) zugeordnet werden. In Bild  9.11 sind die vier Bereiche (Punkt 1 bis Punkt 4) durch die Schieber optisch dargestellt (diese haben keine Wirkung auf das Programm) und zeigen wie der aktuelle Wert (AI0) von 692 sich im dritten Bereich befindet und deswegen A2 gesetzt ist.

9.3  Das Absturz-Problem mit C++-Klassen bei der IOT2000

Wenn sie eine Klasse nicht im loop() instanziieren (Bild  9.13), dann darf die Klasse im Konstruktor keine Systemfunktionen aufrufen.

Wird im Konstruktor einer Klasse eine Systemfunktion benutzt, wie z. B. Millis(), dann hängt sich die IOT2000 nach dem Hochladen auf (Stand Jan. 2017), wenn die Instanz der Klasse global erzeugt wird.

In Bild  9.13 ist das Beispiel der Deklaration aus den Übungen zu sehen. PLC_IOT plc(&ioSim) wird vor dem loop() deklariert. Der Konstruktor initialisiert dabei die PLC und muss unter anderem auch die Timer zurücksetzen. In der Timerfunktion wird Millis() verwendet. Das würde zu einem Systemabsturz führen, da es Millis() anscheinend noch gar nicht gibt. Aus diesem Grunde wird die Klasse über den Konstruktor keine Systemfunktionen aufrufen. Diese Absicherung ist im folgenden Bild  9.14 zu sehen.

Hier wird das Attribut inRun auf false gesetzt bevor der Konstruktor wirksam wird und somit verhindert, dass die Methode InitPLC() keine Systemfunktionen anwendet (z. B. beim Timer). InitPLC() wird danach inRun auf true setzen, damit z. B. Millis() für die Timer im Anwenderprogramm verwendet werden kann.

Wenn also die Kommunikation zum Simulator ausfällt (Checksum zählt hoch) dann haben Sie vielleicht in einem Konstruktor eine Systemfunktion benutzt, obwohl diese noch nicht instanziiert war und das IOT2000 kennt die Programmanwendung nicht mehr.

Nun können Sie das Problem lösen, indem Sie grundsätzlich keine globalen Deklarationen vornehmen, sondern erst im loop() deklarieren. Das ist für die Programmierer welche z. B. mit Singleton arbeiten nicht möglich, denn diese sind instanziiert, bevor der loop() beginnt. Je nach Auffassung und Begründung gehen hier die Meinungen auseinander, aber abstürzen darf eine Hardware mit den besonderen Eigenschaften der Industrietauglichkeit, nach meiner Meinung nicht.

Übrigens: Bei einem Test auf dem Arduino-Board UNO mit diesem Problem, konnte kein Absturz festgestellt werden!

Vertrieb in Deutschland zum Buch gesucht!

Ist die IOT2000-Arduino kompatibel zur Arduino-Welt?

IOT2000 und die Arduino-Welt

Bei der Erstellung meines neuen Buches zur IOT2000 ist mir zur Programmierung der Arduino-Anwendung aufgefallen, dass die Programme, welche auf einem UNO-Board entwickelt wurden, nicht ohne Anpassungen fehlerfrei übersetzt wurden. Dazu nachfolgend ein Ausschnitt aus dem Buch zu Kapitel 8:

8    Der Arduino-Sketch in der SIMATIC IOT2000 für Ardu_IOsim

Die Anwendung der IO-Simulation Ardu_IOsim hat den Vorteil, dass vorerst keine digitalen und analogen Eingänge verdrahtet sein müssen und der Sketch trotzdem getestet werden kann, bevor man sich ein passendes Shield für die IOT2000 suchen muss.

Der Programmzusatz für den Test mit Ardu_IOsim muss für das eigene Anwenderprogramm so gering wie möglich sein. Die Programmierung des Sketchs darf auch nach dem Einsatz eines Shields für die digitalen und analogen Eingänge keine Programmänderung erfordern.

Diese Forderung ist mit einem kleinen Trick ohne großen Aufwand erfüllbar. Betrachten wir die kleine Softwarestruktur zum Sketch in Bild  8.1.

Das Anwenderprogramm verbindet sich mit einem #include “Ardu_IOsim.h“ mit der Klasse Ardu_IOsim_PLC.cpp und kann so die Eigenschaften dieser Klasse anwenden. Dies ist aber nur dann der Fall, wenn der Anwender dies wünscht. Das wird durch die #define _IOSIM_ festgelgt. Ist das der Fall, dann wird innerhalb serialEvent die Schnittstelle zu Ardu_IOsim (PC) aktiv und kann für das Anwenderprogramm nicht mehr genutzt werden. Auch werden innerhalb des Anwenderprogrammes bestimmte #define-Anweisungen aktiv (nicht im Bild abgebildet). Existiert das Define _IOSIM_ nicht, wird das Anwenderprogramm ohne die Simulation abgearbeitet. Wie sieht das nun in der Praxis aus?

In Bild  8.2 ist das Grundgerüst für das Einbinden der Simulation ersichtlich. Leider verfügt der Editor über keine Zeilen-Nummerierung (Version 1.6.9). Dazu nun folgende Erklärungen:

Die #define _IOSIM_-Anweisung sorgt dafür, dass die Zeilen nach #ifdef _IOSIM_ ausgeführt werden. Soll die Simulation abgeschaltet werden, so ist die Zeile #define _IOSIM_ in Kommentare zu setzen (//#define _IOSIM_). Im Falle der Simulation wird mit Ardu_IOsim iosim; die Instanz der Klasse Ardu_IOsim instanziiert und die darauffolgenden #define-Anweisungen bedeuten, dass die im Programm üblichen Funktionen digitalRead, analoRead und pinMode umgeleitet werden in iosim.DigitalRead, iosim.AnalogRead und ioSim.PinMode. Somit können in der Anwendersoftware diese Anweisungen wie gewohnt benutzt werden.

Im setup werden wie gewohnt die Pin konfiguriert. Hier im Beispiel sind die Pins 2 und 3 als Ausgänge deklariert. Danach wird die serielle Schnittstelle auf 115200 Baud eingestellt und falls Zeichen vorhanden sind, gleich der Buffer geleert.

Der loop zeigt ein kleines Beispiel zur Anwendung der digitalen und analogen Befehle. Ist die Simulation aktiv, werden die digitalen und analogen Eingänge simuliert, ohne dass der Programmierer der Anwender-Software etwas dazu berücksichtigen muss. Im Beispiel wird der digitale Pin_2 auf den digitalen Pin_3 kopiert und der Ana_0 entsprechend bei >=127 der Pin_3 gesetzt oder gelöscht.

Die Funktion serialEvent  ist eine Systemfunktion und wird automatisch aufgerufen, sobald sich Zeichen an der seriellen Schnittstelle befinden. Nur hier muss die #ifdef _IOSIM_-Anweisung eingefügt werden, damit die Methode iosim.SerialEvent nur dann aufgerufen wird, wenn _IOSIM_ auch tatsächlich definiert worden ist.

Damit soll das Prinzip über die Anwendung einer IO-Simulation programmtechnisch ausreichend erklärt sein.

Aufgefallen ist mir, dass das Programm Ardu_IOsim, welches auf dem Arduino UNO entwickelt wurde nicht in der SIMATIC IOT2000 fehlerfrei übersetzt wurde. Damit ist die IOT2000 nicht unbedingt 100% kompatibel zum Arduino-Konzept!

Aus diesem Grunde wurde die Software für die Anwendung in der SIMATIC IOT2000 angepasst. Der Arduino-Kenner sollte sich also nicht wundern, wenn hier einige cast gesetzt wurden, die sonst nicht verwendet werden. Auch die Register zum Atmel-Prozessor (z. B. DDRD, PORTA usw.) wurde durch Funktionen künstlich ersetzt. Zudem auch serialEvent() auch nicht funktioniert, sind einige Anpassungen notwendig (naja - ist ja auch kein Arduino-Board!).

So jagt eine Überraschung die andere.

Im folgenden Kapitel 8.1 wird die IOT2000-Arduino-Version vorgestellt. Die ursprünglich entwickelte Arduino-Version für das UNO-Board befindet sich auch auf der Buch-CD.

Besonders interessant ist, dass beide Module (Arduino-IDE und Eclipse) gleichzeitig lauffähig sind! Das kann zu Überraschungen führen, wenn die Programme bezüglich der Pins konkurrierend sind J.