TIA Unittesting mit TIA

Zuviel Werbung?
-> Hier kostenlos registrieren
Noch ein paar Sachen zum Thema:
Was in der SPS schlechter funktioniert ist das Protokollieren. Hier gibt es eigentlich nur einen großen Array-DB, der mit den Protokolleinträgen gefüllt wird. Das ist leider nicht besonders flexibel und recht stark limitiert. Besser wäre die Möglichkeit, ein Logfile auf die SD-Karte schreiben zu können. Das ist mir aber bisher noch nicht gelungen. Zwar gibt es über Rezepturen die Möglichkeit, Daten auf die SD-Karte zu schreiben. Dieses System ist aber so limitiert, dass man es nicht so einfach für Logfiles missbrauchen kann. Oder hat hier jemand eine Idee?
Grüsse!

Man könnte über den Program_Alarm loggen, dieser kann zur Laufzeit Meldungen mit 10 Begleitwerten erzeugen. Diese können dann mit WinCC empfangen und Archiviert werden. Ein Export von Meldungen ist auch möglich. Setzt man kein WinCC ein können die Meldungen mit GetAlarm ausgelesen werden.
 
Man könnte über den Program_Alarm loggen, dieser kann zur Laufzeit Meldungen mit 10 Begleitwerten erzeugen. Diese können dann mit WinCC empfangen und Archiviert werden. Ein Export von Meldungen ist auch möglich. Setzt man kein WinCC ein können die Meldungen mit GetAlarm ausgelesen werden.

Program_Alarm wäre prinzipiell das genau passende dafür. In TIA kann ich die Alarme auch ohne HMI empfangen wenn ich den Haken für "Meldungen empfangen" setze. Dann ist in einem Unter-Unter-Unterfenster eine Karte mit "Meldungsanzeige".

Der Test läuft dann aber nicht mehr auf einer 1200, weil kein Program_Alarm vorhanden.
Die Einstellung des Meldetextformats von Program_Alarm ist über eine SCL-Quelle nicht möglich. D.h. man müsste Teile des Testprogramms vorher manuell erstellen (eine einzige Meldung und alles andere über Begleitwerte?) Wenn ich nur eine Meldung anlege, dann muss ich zum Triggern einer weiteren immer min. einen Zyklus abwarten. Darum wäre es eigentlich optimal, pro Testfall eine eigene Instanz zu erzeugen.

Zum Abgreifen / Speichern der TIA-Meldungsanzeige ist ein manueller Schritt notwendig, also wenn dann doch über ein HMI.

Geschätzt ist das Ablegen der Ergebnisse in einem String-Array dann doch einfacher.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wir bekommen bei uns eine plcsim advance lizenz, da werd ich mal testen was möglich ist. Da soll ja auch tcpip funktionieren, dann kann man ja die alarme pet getalarm auslesen und per tcp versenden.
 
Alarm generieren, dann wieder auslesen und versenden? Scheint mir reichlich kompliziert.
Ein oder mehrere String-Array-DBs in nicht-optimierten DBs funktionieren überall, einfach umzusetzen. Eine Begrenzung auf eine maximale Anzahl an Alarmen hast du bei Program_Alarm nämlich auch.
 
Oder per GetAlarm auslesen, und den Datensatz in einen Nicht-Optimierten DB ablegen und dann ganz "normal" auslesen. Ob das speichersparender ist als direkt einen String zu erzeugen?
Hat den Vorteil, dass dir Program_Alarm wegen den Variant-Datentypen die Begleitwerte passend formatiert. Wobei das Format ja im Meldetext angegeben werden muss.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Test läuft dann aber nicht mehr auf einer 1200, weil kein Program_Alarm vorhanden.
Die Einstellung des Meldetextformats von Program_Alarm ist über eine SCL-Quelle nicht möglich. D.h. man müsste Teile des Testprogramms vorher manuell erstellen (eine einzige Meldung und alles andere über Begleitwerte?) Wenn ich nur eine Meldung anlege, dann muss ich zum Triggern einer weiteren immer min. einen Zyklus abwarten.

Das mit der 1200er stimmt.

Die Alarme könnten aber schon in quellen generiert werden. Der Begleitwert kann ja ein lokaler definierter String sein, der fest mit den Begleitwert verschaltet ist. Bei einer Meldung kann der Inhalt des Strings dann passend beschrieben werden.
Auch mehrere Meldungen können mit einem Alarm erzeugt werden. In einer kleinen Schleife den Alarm erzeugen, den Trigger zurücksetzen, Program_Alarm mit Trigger 0 aufrufen und die Schleife verlassen.
Ich habe das schon mal so gemacht um Verwendungsstellen eines Materials in Rezepturen zu suchen, das hat sehr zuverlässig geklappt.
 
Ich kanns mir mangels Plcsim Advanced nicht ansehen, und Quellcode wird auch keiner mitgeliefert.
Warum wird denn zwingend Advanced benötigt? Das funktioniert so wie es aussieht so wie ich es hier beschrieben habe, d.h. Ergebnisse werden im DB abgelegt und dann ausgelesen.

Wie sieht denn so eine xml-Beschreibung eines Tests aus?

Etwas mehr Nachdenken benötigt es im übrigen wenn man Real-Zahlen vergleichen möchte. Da gibt es dann verschiedene Möglichkeiten das zu prüfen, prüfen ob in bestimmtem Bereich (Float-Epsilon), ULP Differenz.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PLCSIM Advanced liefert eine API mit, welche einer anderen Anwendung direkten Zugriff auf das Prozessabbild der simulierten PLC gibt, aber auch die PLC steuern kann (bspw. stoppen).
Ich werde mir das mal zu gemühte ziehen, aber wieso keine Quellcode hinterlegt ist, versteh ich nicht :(
Schade...
 
Ich denke PLCSim ist notwendig damit ich auch Bausteine testen kann die mit KnowHow Schutz versehen sind. Ich glaube PLCSim kann das bis heute nicht.
Auch lässt sich mit PLCSim nur eine CPU testen, somit fällt Kommunikation auch flach.
 
Siemens hat das letzte Woche in Stuttgart vorgestellt. Geschützte Bausteine lassen sich nur testen wenn es Siemens Bausteine sind! (wer braucht das auch?)
Ich denke das wird gar nicht schlecht. Wir warten nur noch auf die Lizenz und den Downloadlink!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wofür denn Lizenz, für Plcsim Advanced?

Ist ja die Frage ob Plcsim Advanced nur für die Kommunikation benötigt wird, oder auch um die Bausteine hochzuladen usw.
Was mir überhaupt nicht gefällt, ist dieses feste Raster um die Tests in dem Programm festzulegen, und dann wieder in xml-Dateien zu speichern die ich nicht (sinnvoll) händisch bearbeiten kann. Da fand ich meine Lösung mit der googletest-ähnlichen Syntax aus #29 für einen Test zumindest praktischer. Funktionierte in meinen kleinen Experimenten auf jeden Fall ganz gut.

Aber das Siemens-Programm sieht mir etwas nach einem kleinen Experiment aus, vielleicht will man erst einmal die Reaktionen abwarten, und dann wird mehr Arbeit reingesteckt und ggf. ein kostenpflichtiges Programm..
 
Wow, hier überschlägt sich Siemens ja geradezu.

Da wird hier im Forum ein Produkt gefordert und keine 3 Monate später präsentiert Siemens die V1.0 einer Lösung. Das kann doch kein Zufall sein!

:)
 
Zurück
Oben