Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Ergebnis 1 bis 6 von 6

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

  1. #1
    Registriert seit
    20.08.2007
    Beiträge
    112
    Danke
    13
    Erhielt 10 Danke für 8 Beiträge

    Standard


    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
    Solls was Rechtes sein, oder darfs auch was von Siemens sein?
    Zitieren Zitieren OOP lässt sich nicht debuggen (Codesys V3 bzw SoMachine Motion)  

  2. #2
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    752
    Danke
    27
    Erhielt 165 Danke für 143 Beiträge

    Standard

    (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.

  3. #3
    wonderfulworld ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    20.08.2007
    Beiträge
    112
    Danke
    13
    Erhielt 10 Danke für 8 Beiträge

    Standard

    Zitat Zitat von StructuredTrash Beitrag anzeigen
    (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
    Solls was Rechtes sein, oder darfs auch was von Siemens sein?

  4. #4
    Registriert seit
    30.08.2005
    Beiträge
    280
    Danke
    41
    Erhielt 96 Danke für 66 Beiträge

    Standard

    (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.
    Bernhard Werner
    3S-Smart Software Solutions (CODESYS)

  5. Folgender Benutzer sagt Danke zu Werner29 für den nützlichen Beitrag:

    wonderfulworld (19.06.2013)

  6. #5
    wonderfulworld ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    20.08.2007
    Beiträge
    112
    Danke
    13
    Erhielt 10 Danke für 8 Beiträge

    Standard

    Hallo,

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

    Zitat Zitat von Werner29 Beitrag anzeigen
    (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

    Zitat Zitat von Werner29 Beitrag anzeigen
    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?

    Zitat Zitat von Werner29 Beitrag anzeigen
    (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
    Solls was Rechtes sein, oder darfs auch was von Siemens sein?

  7. #6
    Registriert seit
    30.08.2005
    Beiträge
    280
    Danke
    41
    Erhielt 96 Danke für 66 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von wonderfulworld Beitrag anzeigen
    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.

    Zitat Zitat von wonderfulworld Beitrag anzeigen
    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".

    Zitat Zitat von wonderfulworld Beitrag anzeigen
    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/64...tml#post448868
    Bernhard Werner
    3S-Smart Software Solutions (CODESYS)

Ähnliche Themen

  1. DB lässt sich nicht bearbeiten
    Von nilsgoetting im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 04.12.2012, 14:18
  2. OP7 lässt sich nicht programmeren!!
    Von Mattle im Forum HMI
    Antworten: 6
    Letzter Beitrag: 20.04.2009, 15:13
  3. Antworten: 50
    Letzter Beitrag: 02.06.2008, 06:54
  4. Step7 lässt sich nicht installieren
    Von Anonymous im Forum Simatic
    Antworten: 1
    Letzter Beitrag: 22.09.2005, 10:33
  5. SPS -S5- lässt sich nicht auslesen
    Von Anonymous im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 26.05.2005, 18:02

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •