OOP lässt sich nicht debuggen (Codesys V3 bzw SoMachine Motion)

wonderfulworld

Level-1
Beiträge
114
Reaktionspunkte
10
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich bin gerade dabei mir ein bisschen die OOP-Sachen näher anzueignen und bin gerade ziemlich entäuscht von der Debuggbarkeit von Codesys V3 bzw. SoMachine Motion von Schneider Electric. Vielleicht bin ich ja einfach bis jetzt noch nicht draufgekommen, aber stimmt es wirklich, dass man...

(1) keine Möglichkeit hat Eigenschaften inklusive getter- und setter-Methoden zu debuggen?
(2) keine Möglichkeit hat, die Methoden zu debuggen, ohne das Programm anzuhalten?
(3) Member-Variablen die in der Methode mit this^.memberVariable aufgerufen werden, nicht debuggen kann? (wäre nicht ganz so schlimm)

Mich würde mal interessieren, ob ich da vielleicht irgendwo etwa übersehen habe. (3) wäre jetzt für mich nicht so tragisch, aber (2) schließt eine Nutzung von OOP mit angeschloßener Mechanik aus und (1) eigentlich immer. Wie seht ihr das? Benutzt ihr OOP überhaupt. Ansich ist das schon ne tolle Sache, aber ohne Debuggen geht es bei mir einfach nicht. Hin und wieder macht nämlich die Maschine nur das was ich programmiert habe, aber nicht das was ich wollte. Da ist Debuggen schon sehr hilfreich. Und alles mit Traces zu machen ist dann ja wirklich mühsam.

Also ich hoffe, dass ich mich jetzt umsonst aufgeregt habe und ihr mir sagen könnt wie man debuggen kann.

Gruß
wonderfulworld
 
(1) kann ich bestätigen, und (2) wird wohl auch so sein, weil die Ursache gleich ist. Variablen und Ergebnisse von Eigenschaften und Methoden sind temporär, wie soll man die bei laufendem Programm anzeigen? So schön ist die neue OOP-Welt eben doch nicht, ich selbst entwickle mich da auch ein wenig vom Paulus zum Saulus zurück. Kapselung gibt es mit dem FB schon in CoSeSys2, so dass bei V3 eigentlich nur die Vererbung und die damit verbundene erweiterte Datentypkompatiblität als nützliche Neuerungen bleiben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
(1) kann ich bestätigen, und (2) wird wohl auch so sein, weil die Ursache gleich ist. Variablen und Ergebnisse von Eigenschaften und Methoden sind temporär, wie soll man die bei laufendem Programm anzeigen? So schön ist die neue OOP-Welt eben doch nicht, ich selbst entwickle mich da auch ein wenig vom Paulus zum Saulus zurück. Kapselung gibt es mit dem FB schon in CoSeSys2, so dass bei V3 eigentlich nur die Vererbung und die damit verbundene erweiterte Datentypkompatiblität als nützliche Neuerungen bleiben.

Also an sich finde ich OOP immer noch genial und toll. Besonders Schnittstellen erleichtern einen, unabhängiger zu Programmieren und Sachen wiederzuverwenden. Methoden helfen einen Aufgaben von einander zu kapseln. Das einzige was mich stört ist, dass CoDeSys das Debuggen nicht ausreichend genug unterstützte.
(1) Warum gibt es keine "Haltepunkte" zum Debuggen, die das Programm nicht anhalten, aber den Zustand an dem der "Haltepunkt" gesetzt wurde anzeigen? Variablen in Methoden zu deklarieren ist damit auch hinfällig. Müssen wir halt so wie schon immer, die Variablen im FB deklarieren. Damit ist die schöne Kapselung auch wieder futsch.
(2) Warum kann man Eigenschaften nicht debuggen? Eigenschaften gehören wie alle anderen Variablen eines FBs zu einer einzigen FB-Instanz und müssen deshalb genauso wie Ein- oder Ausgänge debuggbar sein. Tracen kann ich sie ja auch. Im Moment bleibt mir nichts anderes übrig als Eigenschaften nicht zu nutzen.
(3) Warum muss ich für jede Methode ein neues Objekt anlegen? Ich verstehe schon, dass aufgrund der verschiedenen Sprachen, die wir in CoDeSys haben, es schwierig ist, alles irgendwie an einer Stelle darzustellen Aber dass muss möglich sein. Sie haben es ja jetzt immerhin geschafft AWL/KOP/FUP zu einer Sprache mit 3 Darstellungsformen zu machen. Die herumspringerei beim Debuggen ist echt nervig, zeitaufwendig und schlecht.

Meiner Meinung nach ist OOP etwas sehr gutes. Leider hat CoDeSys beim Debuggen einfach noch nicht zu Ende gedacht. Vielleicht kommt das aber noch in ein paar Jahren. Schade ist, dass durch diese schlechte Umsetzung des Debuggings in CoDeSys viele Programmierer den Eindruck vermittelt wird, dass OOP für Echtzeitsystem nichts taugt.

Gruß wonderfulworld
 
(1) Warum gibt es keine "Haltepunkte" zum Debuggen, die das Programm nicht anhalten, aber den Zustand an dem der "Haltepunkt" gesetzt wurde anzeigen?

Man kann die Werte in Methoden aber durchaus darstellen, das Feature nennt sich Flow Control (im Menü Debug). Dann werden im laufenden Betrieb auch in Methoden die Werte ausgelesen.
Im Prinzip passiert genau das: es werden Haltepunkte in der Methode gesetzt, die Werte an der Stelle ausgelesen und die Bearbeitung fortgesetzt.
Dabei muss man beachten, dass diese Funktionalität die Laufzeit beeinflusst.

(2) Warum kann man Eigenschaften nicht debuggen?

Was meinst du mit "ich kann Eigenschaften nicht debuggen". Du meinst die Werte werden im Watchfenster nicht dargestellt?
Auch das geht, aber man muss es der Eigenschaft beibringen, dazu gibt es zwei Attribute:

{attribute 'monitoring' := 'call'}
bzw.
{attribute 'monitoring' := 'variable'}

Details dazu findest du in der Online Hilfe.
standardmässig wird das nicht gemacht, weil die Eigenschaften im ersten Fall wirklich aufgerufen werden, und wenn die Eigenschaft irgendeinen Seiteneffekt auf das Objekt
hat, dann könnte es passieren dass das Objekt durch betrachten im Watch-Fenster verändert wird.
Der zweite Fall hat den Nachteil, dass man nur den Wert des letzten Aufrufs bekommt, der könnte unter Umständen anders sein, als der Wert des nächsten Aufrufs.

(3) Warum muss ich für jede Methode ein neues Objekt anlegen?
Da verstehe ich ehrlich gesagt die Frage nicht.
 
Hallo,

vielen Dank für deine Antworten. Ich glaub ich war ein bisschen vorschnell mit meinen Schlußfolgerungen. Ich hoffe du kannst mir verzeihen.

(1) Warum gibt es keine "Haltepunkte" zum Debuggen, die das Programm nicht anhalten, aber den Zustand an dem der "Haltepunkt" gesetzt wurde anzeigen?

Man kann die Werte in Methoden aber durchaus darstellen, das Feature nennt sich Flow Control (im Menü Debug). Dann werden im laufenden Betrieb auch in Methoden die Werte ausgelesen.
Im Prinzip passiert genau das: es werden Haltepunkte in der Methode gesetzt, die Werte an der Stelle ausgelesen und die Bearbeitung fortgesetzt.
Dabei muss man beachten, dass diese Funktionalität die Laufzeit beeinflusst.
Das Flow Controll ist einfach nur genial. Genau das hab ich mir gewünscht, aber nicht gefunden

Was meinst du mit "ich kann Eigenschaften nicht debuggen". Du meinst die Werte werden im Watchfenster nicht dargestellt?
Auch das geht, aber man muss es der Eigenschaft beibringen, dazu gibt es zwei Attribute:

{attribute 'monitoring' := 'call'}
bzw.
{attribute 'monitoring' := 'variable'}

Details dazu findest du in der Online Hilfe.
standardmässig wird das nicht gemacht, weil die Eigenschaften im ersten Fall wirklich aufgerufen werden, und wenn die Eigenschaft irgendeinen Seiteneffekt auf das Objekt
hat, dann könnte es passieren dass das Objekt durch betrachten im Watch-Fenster verändert wird.
Der zweite Fall hat den Nachteil, dass man nur den Wert des letzten Aufrufs bekommt, der könnte unter Umständen anders sein, als der Wert des nächsten Aufrufs.

OK, dass hilft mir auch schon wieder sehr viel weiter. Plötzlich werden Eigenschaften benutzbar.

Eine Frage hätte ich noch zu Eigenschaften. Und zwar habe ich mal ein bisschen mit den Eigenschaften rumgespielt und in einem FB eine Eigenschaft "myProperty" von Datentyp "ImyInterface" erzeugt. Dann hab ich diesen FB in einem Programm aufgerufen, dass ganze kompeliert und dann bin ich im Simulationsmodus Online gegangen. Das alles ging. Was ich jetzt nicht verstehe ist, auf welches Objekt "myProperty" verweißt. In Java würde es jetzt auf NULL zeigen. Aber NULL darf es doch in CoDeSys garnicht geben?

(3) Warum muss ich für jede Methode ein neues Objekt anlegen?
Da verstehe ich ehrlich gesagt die Frage nicht.
Du hast ja die zwei anderen Fragen sehr gut beantwortet. Bei der dritten, wird das glaub ich ein bisschen schwieriger. Die ist aber für mich auch nicht so wichtig wie die anderen beiden.

Wenn ich in einer Hochsprache (Java, C++) eine Klasse/Interface anlegen möchte, öffne ich eine Textdatei (ich brauche dazu nicht mal eine IDE) und kann meine Methodendefinitionen eine nach der anderen herunterschreiben. Das geht sehr schnell und am Ende habe ich alle Methoden einer Klasse schön übersichtlich in einer Text-Datei. Ich sehe nicht nur ihren Name auf einen Blick, sondern auch ihre Parameter, Rückgabewerte und die in der Methode enthaltene Logik. Wenn ich in CoDeSys eine Methode anlegen möchte dauert das deutlich länger. Ich muss zuerst ein Methoden-Objekt mit Hilfe von einem Wizard erzeugen und einen Rückgabewert + gewünschte Sprache auswählen. Dann bekomme ich für jede Methode eine eigene Datei, die im Editor geöffnet werden muss. Dort kann ich dann anfangen zu Programmieren. Beim Debuggen ist es genauso. Will ich wissen was in der Methode passiert muss ich sie öffnen. Wenn ich mehrere Methoden gleichzeitig beobachten möchte, dann muss ich einen großen Bildschirm haben, der die vielen geöffnetne Fenster anzeigt. Wenn die Methoden alle in einem Objekt wären, könnte man scrollen und sich die verschiedenen Methoden schnell anschauen.

Also nochmal ein großes Entschuldigung für meine vorschnellen Aussagen und vielen Dank für deine Antworten.

Gruß
wonderfulworld
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eine Frage hätte ich noch zu Eigenschaften. Und zwar habe ich mal ein bisschen mit den Eigenschaften rumgespielt und in einem FB eine Eigenschaft "myProperty" von Datentyp "ImyInterface" erzeugt. Dann hab ich diesen FB in einem Programm aufgerufen, dass ganze kompeliert und dann bin ich im Simulationsmodus Online gegangen. Das alles ging. Was ich jetzt nicht verstehe ist, auf welches Objekt "myProperty" verweißt. In Java würde es jetzt auf NULL zeigen. Aber NULL darf es doch in CoDeSys garnicht geben?
Doch, NULL gibt es, wenn auch syntaktisch nur als 0. Wenn du Interfaces verwendest, dann hat die Variable initial den Wert 0 bis man der Variable
eine passende Instanz zuweist. Interface referenzen muss man auf 0 testen bevor man sie sicher verwenden kann.

Du hast ja die zwei anderen Fragen sehr gut beantwortet. Bei der dritten, wird das glaub ich ein bisschen schwieriger. Die ist aber für mich auch nicht so wichtig wie die anderen beiden.

Wenn ich in einer Hochsprache (Java, C++) eine Klasse/Interface anlegen möchte, öffne ich eine Textdatei (ich brauche dazu nicht mal eine IDE) und kann meine Methodendefinitionen eine nach der anderen herunterschreiben. Das geht sehr schnell und am Ende habe ich alle Methoden einer Klasse schön übersichtlich in einer Text-Datei. Ich sehe nicht nur ihren Name auf einen Blick, sondern auch ihre Parameter, Rückgabewerte und die in der Methode enthaltene Logik. Wenn ich in CoDeSys eine Methode anlegen möchte dauert das deutlich länger. Ich muss zuerst ein Methoden-Objekt mit Hilfe von einem Wizard erzeugen und einen Rückgabewert + gewünschte Sprache auswählen. Dann bekomme ich für jede Methode eine eigene Datei, die im Editor geöffnet werden muss. Dort kann ich dann anfangen zu Programmieren. Beim Debuggen ist es genauso. Will ich wissen was in der Methode passiert muss ich sie öffnen. Wenn ich mehrere Methoden gleichzeitig beobachten möchte, dann muss ich einen großen Bildschirm haben, der die vielen geöffnetne Fenster anzeigt. Wenn die Methoden alle in einem Objekt wären, könnte man scrollen und sich die verschiedenen Methoden schnell anschauen.

Als C#-Programmierer kann ich das gut verstehen, aber das sind wesentliche Design-Entscheidungen. Ist halt auch recht üblich bei SPS-Programmiersystemen.
Ich weiss, das klingt ein bisschen nach "das war schon immer so".

Also nochmal ein großes Entschuldigung für meine vorschnellen Aussagen und vielen Dank für deine Antworten.

Kein Problem, dafür ist das Forum ja da. Und wenn jemand die Funktionalität nicht findet die er braucht, dann ist das schon auch ein Problem des Tools.
Schlimm nur, wenn sich solche Mythen verbreiten: siehe
http://www.sps-forum.de/redaktion/64052-wuensche-programmier-und-entwicklungstools-3.html#post448868
 
Zurück
Oben