Ich denke es ist vlt über die TIA Openness auch möglich. Ich schau nächste woche mal ob ich was hinbekomme und stells dann hier vor.
Hast du dir das schon mal angesehen?
Ich habe mal etwas rumprobiert, weil mich ja doch interessiert was sich damit automatisiert erledigen lässt. Denn auch wenn ich eine einfache Funktion schreibe, so muss ich diese trotzdem einmal testen (ich mache das zumindest). Also warum manuell etwas durchprobieren, was sich auch definieren und dann automatisieren lässt.
Bei Step7 v5 habe ich zumindest alle Werkzeuge um das zumindest prinzipiell vollständig automatisiert ablaufen zu lassen.
Einen Standard für eine Unittest-Beschreibung scheint es nicht zu geben. Ich habe mir mal Googles "googletest" angesehen, das scheint auch von anderen so in der Art verwendet zu werden:
https://github.com/google/googletest/blob/master/googletest/docs/Primer.md
Daran könnte man sich zumindest grob orientieren um nicht das Rad komplett neu erfinden zu müssen, und um auf evtl. bestehende Tools zurückgreifen zu können.
So ganz passt das natürlich nicht mit der SPS-Programmierung zusammen, leichte Anpassungen sind unumgänglich.
In meiner "Sprache" für eine Testdefinition könnte ein Test für eine Addierfunktion so aussehen:
Code:
TEST(AdditionTest, BasicTest) {
VAR
retval : INT;
END_VAR
BEGIN
retval := FC_ADD(IN1 := 1, IN2 := 2);
EXPECT_EQ(3, retval);
END
}
Das Test-Ausführungsprogramm (bei mir z.Zt. in Python geschrieben) übersetzt diese Definition in einen entsprechenden Test-FB in SCL. Diese Quelle wird dann automatisiert übersetzt und geladen (in Plcsim oder eine echte CPU, die Step7 Kommandoschnittstelle verwendet das was erreichbar ist). Die Ergebnisse der Tests könnte man dann in einem DB als String o.Ä. ablegen, und dann über S7comm auslesen ("AdditionTest.BasicTest failed").
Dei Addier-Funktion ist trivial und nur ein Startpunkt. FBs wie z.B. ein Fifo mit diversen Datentypen müssten so auch geprüft werden können. Prinzipiell sehe ich da aber kein Problem.
In meinem obigen Beispiel würde ich alles zwischen VAR/END_VAR als VAR in einen FB einfügen (RAW_VAR), alles zwischen BEGIN/END als Code in einen FB (RAW_CODE). D.h. die Syntax-Prüfung delegiert man dann an den Step7-SCL-Compiler.
EXPECT..() wäre als Funktion oder als Code aufzulösen (wie ein C-Makro, aber abhängig vom Datentyp), welcher die Prüfung vornimmt und das Ergebnis in einem definierten Speicherbereich der SPS ablegt.
Das ist bei googletest und C++ natürlich wesentlich einfacher, weil das dort (d.h. diverse Datentypen) über C++-Templates abgefrühstückt wird (d.h. die Aufgabe löst der Compiler), und Ausgabe der Ergebnisse nur über Kommandozeile. Um Makros aufzulösen bräuchten wir hier zumindest einen rudimentären SCL-Parser. Da SCL für Step7 V5 und TIA-SCL verschieden sind, dementsprechend zwei (herzlichen Dank an den IEC ST Sprachstandard, an den sich keiner hält).
Wenn externe Ressourcen wie FCs/FBs aus Systembibliotheken, Unterfunktionen oder nicht-elementare Datentypen wie UDTs verarbeitet werden, wird das alles nicht mehr ganz so einfach.
