Codefehler bei KOP und FUP Programmierung

[Atlas]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hab es mitlerweile schon ein paarmal erlebt, dass Step7 bei Projekten die sehr Änderungsaintensiv sind und noch in gemischten Sprachen geschrieben wurden, also AWL, KOP und FUP immer wieder Fehler rein bringt indem automatisch vergebene temporäre Variablen die zur Darstellung in KOP und FUP benötigt werden falsch/doppelt vergibt.

Leider hab ich aktuell ein relativ großes und sehr änderungsintensives Projekt, das teilweise ein echt "seltsames" Verhalten hat und bereits zweimal so eine falsche Variable die Ursache war. (Zur behebung habe ich das betroffene Netzwerk nochmal komplett neu erstellt und das alte gelöscht - dann gings)

Gibt es hier einen automatismus mit dem ich z.b. das ganze Projekt neu kompelieren kann und sowas dann ausgebügelt wird.

Was gibts da sonst noch alles?

 

[Thomas_v2.1]

Ich würde darauf achten alle lokalen Variablen mit einem Symbol zu deklarieren, und keine direkten Zugriffe wie
L LW2
zu verwenden, sondern alles symbolisch.

Dann passt der Editor die Adressen eigentlich immer so an dass es keine Konflikte gibt (geben sollte).

 

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich würde darauf achten alle lokalen Variablen mit einem Symbol zu deklarieren, und keine direkten Zugriffe wie
L LW2
zu verwenden, sondern alles symbolisch.

Dann passt der Editor die Adressen eigentlich immer so an dass es keine Konflikte gibt (geben sollte).

nicht, wenn es in KUP erstellt wurde, da wird einfach mal auf andere adressen, als die vereinbarten zugegriffen um die darstellung zu ermöglichen ... in AWL sollte aber alles vorhanden sein und so sollte dann wohl auch thomas sein beitrag verstanden werden.

 

[Atlas]

Selstverständlich deklariere ich alle temporären variablen wennich diese verwende.

Es geht hier aber um variablen die Stap7 für die darstellung in KOP nutzt. Da scheint ab und an der wurm drinn zu sein. Ich suche nach einer möglichkeit wie ich sowas im programm überprüfen und reparieren kann.
(Die antwort sollte jetzt bitte nicht sein "prog einfach alles in AWL" oder "besser alles per hand aus")

Mein Programm verhällt sich teilweise sehr komisch. Z.B. Sind Merker gesetzt, obwohl diese von mir zurückgesetzt werden. Per hand konnte ich den Fehler dadurch beheben, dass ich das betroffene netzwerk einfach nochmal "abgemalt" habe und das alte gelöscht hab....

 

[MSB]

Die einzige mir bekannte Möglichkeit:
Wenn du einen KOP/FUP Baustein vorfindest, in dem die Lokaldaten für die Schnittstellenübergabe o.ä. genutzt werden,
und vor allem das so nach "Siemens-Standard" ausschaut, z.B. BLD103 nach der Lokalzuweisung,
dann die Lokaldatendeklaration im FUP-Editor durchführen.
Die ganzen "inoffiziellen" FUP-Lokalvariablen wandern dann automatisch auf das nächste freie Wort in den Lokaldaten.

FUP deshalb weil der FUP-Editor alles darstellen kann was "grafisch" programmiert wurde,
der KOP-Editor hingegen z.B. ein XOR nicht.

Allerdings:
Obiges funktioniert logischerweise nur vorher, bevor man irgendwas geändert hat.

Mfg
Manuel

 

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es geht hier aber um variablen die Stap7 für die darstellung in KOP nutzt. Da scheint ab und an der wurm drinn zu sein.

das halte ich für ein gerücht!
welche Stap7 [sic!] Version benutzt du denn?

 

[Approx]

Vielleicht bringt ja die Funktion "Bausteinkonsistenz prüfen" einige Informationen diesbezüglich...

gruß

 

[Atlas]

das halte ich für ein gerücht!
welche Stap7 [sic!] Version benutzt du denn?

5.4 SP 3.1

Vielleicht bringt ja die Funktion "Bausteinkonsistenz prüfen" einige Informationen diesbezüglich...
gruß

Das hab ich schon durchlaufen lassen, brachte aber auch nicht wirklich was. Kann ich ein Projekt irgendwie neu übersetzen lassen und dann komplett nochmal runterladen?

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

(Die antwort sollte jetzt bitte nicht sein "prog einfach alles in AWL" oder "besser alles per hand aus")

Das schicke an diesen Konstrukten ist, dass sie sich irgendwann zu einer Armada von bedingten Sprüngen entwickelt, die sich (auch in AWL) dann nur noch schwer debuggen läßt. Wie sieht denn das Netzwerk des Anstosses in AWL-Code aus, wenn du die Ansicht wechselst ? Oder ... wieviele SPB-Befehle (und Varianten davon) werden darin verwendet ?

Vielleicht solltest du doch mal erwägen, über den Tellerrand zu schauen ...

Gruß
LL

 

[Atlas]

Das schicke an diesen Konstrukten ist, dass sie sich irgendwann zu einer Armada von bedingten Sprüngen entwickelt, die sich (auch in AWL) dann nur noch schwer debuggen läßt. Wie sieht denn das Netzwerk des Anstosses in AWL-Code aus, wenn du die Ansicht wechselst ? Oder ... wieviele SPB-Befehle (und Varianten davon) werden darin verwendet ?

Vielleicht solltest du doch mal erwägen, über den Tellerrand zu schauen ...

Gruß
LL

Jaja, ich habe auf diesen oder einen ähnlichen spruch schon seit meinem ersten post gewartet...

Stimmt, ich kann AWL nicht so gut wie es eventuell notwendig wäre um alles was ich jeh (in KOP oder FUP) programmiert habe alleine in dieser form zu verwirklichen. Aber über den Tellerrand hinausschauen? Sicher, aber da guck ich lieber wo anders. Ich hatte einfachmal vorausgesetzt, dass eine Steuerung + Software die schon seit relativ langer zeit auf dem markt ist soweit ausgereift ist, damit sowas geht. Hey, willkommen im 3. jahrtausend. Oder würdest du bei einem problem das ein C programmierer hat argumentieren, dass er doch besser in assembler coden soll... Mag sein, dass dein argument dennoch zur lösung führen könnte, aber dann seh ich mein problem nicht in meinem unwissen sondern in der fehlerhaften funktion von Step7...


Leider kann ich keinen codeauszug posten, da es sich hier nicht um einen "bestimmten" absatz oder so handelt... Die frage sollte allgemein gelten wie ich sowas vermeiden kann.

 

[Thomas_v2.1]

Mag sein, dass dein argument dennoch zur lösung führen könnte, aber dann seh ich mein problem nicht in meinem unwissen sondern in der fehlerhaften funktion von Step7...

Mit 99,9%iger Wahrscheinlichkeit sitzt das Problem vor der Tastatur. Sonst würde man andauernd von zufälligen Fehlern hören.

Wenn du meinst das ist ein Step 7 Fehler schicke die Sache dem Siemens-Support, und hilfst damit auch gleich allen anderen Programmierern.

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Leider kann ich keinen codeauszug posten, da es sich hier nicht um einen "bestimmten" absatz oder so handelt... Die frage sollte allgemein gelten wie ich sowas vermeiden kann.

Also ich kenne das Problem so nicht.
Es gibt nur, wenn ein Projekt aus Quellen manchesmal ein Problem wegen den Zeitstempel, das aber durch eine geänderte Kompilierreihenfolge behoben wird.
Dass eine Sprungmarke auf einmal mehrmals vorhanden ist, habe ich nur gehabt, wenn das Projekt gecrashed hat.

bike

 

[vierlagig]

was ich mir an dieser stelle noch vorstellen könnte, wäre das zusammenkopieren von KUP-inAWL-code ... aber da schimpft der editor ja allein schon beim speichern

 

[Flinn]

Hallo,
ohne jetzt alles genauestens gelesen zu haben:
Kann es sein, dass du einen Baustein in FUP oder KOP hast, dann diesen Baustein auf AWL umschaltest, und dann neue Temp-Variablen anlegst?
Genau dann hättest du dein beschriebenes Verhalten. Dann hat der Editor nämlich für die KOP/FUP-Darstellung bereits absolute Lokaladressen belegt und Deine neuen Lokalvariablen überschneiden sich mit diesen. Und dass dann "komische" Programmreaktionen kommen ist ja klar.

Wenn dem so ist, immer an folgendes denken:
Sollte ein FC/FB FUP/KOP-Darstellungen haben, dann auch immer in diesen Ansichten arbeiten, insbesondere beim Ergänzen von neuen Temp-Variablen.

Ey, isses dat? Samma!

Gruß
Flinn

 

[bike]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ohne jetzt alles genauestens gelesen zu haben:
Kann es sein, dass du einen Baustein in FUP oder KOP hast, dann diesen Baustein auf AWL umschaltest, und dann neue Temp-Variablen anlegst?

Aber da kommt doch eine Meldung die einen warnt.

bike

 

[Flinn]

Aber da kommt doch eine Meldung die einen warnt.

bike

Yep, die kommt. Wird aber vielleicht von einigen trotzdem nicht beachtet.... Who knows? Wäre dann einer der 99,9 % Fälle vor dem Rechner... Aber vielleicht isset dat ja auch nicht...

Gruezi
Flinn

 

[MW]

Aber da kommt doch eine Meldung die einen warnt.

bike

und die kann man nicht mal mit nem Häckchen bei "diese Meldung nicht wieder anzeigen" verbannen.

Hilfe zu der Meldung von Step 7:

Meldung 34:162

Beschreibung:

Ihre eingegebene Deklarationszeile aus dem VAR_TEMP kollidiert mit einem absoluten
Zugriff auf den L-Stack im Programmrumpf des aktuellen Bausteins. In Ansicht AWL könnte
das bedeuten, daß vom KOP/FUP Compiler angelegte compiler-interne Lokaldaten zu
Anwender-Lokaldaten werden. Dann ist die Umschaltung in Sicht KOP/FUP nicht mehr möglich.

Behebung:

Wenn Sie ausschließlich in AWL programmieren, können Sie diese Meldung ignorieren.
Als KOP/FUP Programmierer sollten Sie solche Deklarationen nur in der Ansicht
KOP/FUP durchführen, auch wenn Sie einzelne Netzwerke in AWL editieren.