Problem mit S7 Lokalvariablen

[mrcmm300]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
vor ein paar Tagen habe ich beim Kunden ein neues Maschinenteil
aufgebaut und in der SPS einen neuen FC im Programm für dieses neue
Maschinenteil angelegt!
Bei der Programmierung musste ich ein paar Werte vom Typ Integer
berechnen und dafür habe ich ein paar Lokalvariablen angelegt.
Alles so weit so gut, der eigentlich neu programmierte FC funktionierte
auch einwandfrei und ich weiss das in anderen FC's auch Lokalvariablen
angelegt wurden und wohl auch alles einwandfrei arbeitet.

Jetzt war folgendes Problem aufgetreten: In einem anderen FC wurde ein
Schieberegister programmiert (schon bei Auslieferung der Maschine) das
nach der Programmierung des neuen FC's keine Daten mehr geschoben hat.

Ich habe dann nach langen hin und her probierens, rausgefunden das die
Lokalvariablen in dem neuen FC Schuld daran waren, das das
Schieberegister nicht mehr arbeitete, habe dann die Lokalvariablen durch
Merkerworte ersetzt und das Schieberegister lief wieder!

Hat das schonmal jemand gehabt oder kann mir jemand sagen voran das
wohl gelegen hat???

Gruß, Mathias

 

[jabba]

Hallo mrcmm300,

waren die Lokaldaten im FC als Temp, ohne die irgendwo zu sichern, und arbeit das Schieberegister eventuell auch mit Temp ?

Diese könne sich beeinflussen, man sollte die dann sichern, oder einen FB mit Instanz-DB verwenden. Das verwenden von Temp im einem FC kann jahrelang laufen, und bei einer kleinen Änderung geht nix mehr. Die Temp-Variablen müßen mit bedacht verwendet werden, da die beim verlassen des Bausteines die Gültigkeit verlieren.

 

[mrcmm300]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo jabba,

ja, die von mir benutzten Lokalvariablen waren Temporär, den FC mit dem Schieberegister kann ich leider nicht einsehen (KnowHowProtect).

Gruß Mathias

 

[MSB]

Ich bezweifle, dass man dir im herkömmlichen Sinn einen Vorwurf machen kann.
Die Lokaldaten (Temp) müssen überhaupt nicht mit Vorsicht angewendet werden, sondern nur richtig, für was diese gedacht sind,
nämlich die etwas durchsichtigere Version eines Schmiermerker-Bereichs.

Wenn irgend ein Schieberegister danach nicht mehr getan hat, dann war dieses zu >90% im Temp-Bereich deklariert,
oder das Schieberegister hat Daten aus dem Temp-Bereich bezogen.

Mfg
Manuel

 

[mrcmm300]

Und ich hab mir gedacht, das die Werte die ich da berechnen wollte und nur in diesem Baustein benutzen wollte auch nur Auswirkungen auf diesen Baustein haben! Aber falsch gedacht!

Wie kann ichs den das nächste mal richtig machen?
Was sollte ich beachten wenn ich Lokalvariablen verwenden will?

Gruß Mathias

 

[jabba]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo mrcmm300,

so wie MSB ja aufgeführt hat, hast Du ja eigentlich nix falsch gemacht,
aber vieleicht der das Schieberegister geschrieben hat.
Meine, ganz eigene Meinung, meide die Temp-Variablen.
Auch wenn von vielen hier verpöhnt , ich nehme dafür Merker, einen DB oder einen FB mit Instanz-DB.
Ich habe einige Anlagen, wo ich früher gerne auf die Temp´s zurückgegriffen habe, bei vielen gab´s unerklärbare Fehler.
Und ich habe die Temp´s auch nur zum wandeln benutzt, oder für Grenzwertberechnungen, die wurden in jedem Zyklus auch vor der Auswertung neu berechnet, und trotzdem kam manchmal Müll raus.
(Es gab da auch keine Unterbrechungen ala OB35 oder so)

 

[MSB]

Also ich meide Temps nicht grundsätzlich, aber ich denke wenn man die richtig verwendet, dann passiert auch nichts.
Sonst würde sich Siemens wohl kaum bei KOP/FUP Programmen in dem Maß darauf verlassen.

Ich verwende die Temps zum Beispiel um Rechenergebnisse oder Verknüpfungsergebnisse zwischenzuspeichern.
Die Verwendung der Ergebnisse, erfolgt in jedem Fall in den nächsten 5 Netzwerken,
und immer vorm Aufruf eines neuen FC/FB's.

Der Temp-Bereich ist insgesamt halt irgend ein x-Byte breiter Speicherbereich (Datenblatt der CPU),
und diesen Speicher teil die CPU halt mehr oder weniger willkürlich auf die deklarierten TEMP-Variablen usw. auf.

Mfg
Manuel

 

[Onkel Dagobert]

Oh, das ist ja eine ganz böse Falle.

Oh, das ist ja eine ganz böse Falle. Ich mache auch oft und äußerst widerwillig in fremden Anlagen rum. Immer mehr Kunden verderben es sich mit den Maschinenherstellern und dann kommen sie zu uns. Das ist neuerdings der Trend. Und wir machen alles, ist ja kein Problem, jedenfalls nicht für meinen Chef :???: . In fremden Programmen herum zu schreiben ist ohnehin schon etwas abenteuerlich. Und dann auch oftmals bei laufender Anlage. Wenn man nun, wie Mathias, auch noch ein solch stümperhaftes Programm vorfindet, kann das ganz böse enden.

Ich werde in Zukunft in solchen Fällen wohl ausschlisslich mit statischen Lokaldaten arbeiten. Ausserdem sollte man eine Lizenz zum Programmieren einführen!!!

Danke für den Tipp!


Gruß, Onkel


..oder besser zwei Lizenzen. Eine für FUP und KOP, und eine uneingeschränkte.

 

[mrcmm300]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute, Danke für Eure Antworten.

Ich werde wohl in Zukunft vielleicht auch eher zu statischen Variablen tendieren! (Ich muss nur dran denken, beim nächsten mal)

Zum Thema "Für meinen Chef is'nix unmöglich" kann ich Dir nur beipflichten.

Und zum Thema Lizens zum Programmieren: Ich hab eine und der der das Programm mal geschrieben hat, hat auch eine, aber der hat die Firma
gewechselt und auf Grund dessen konnt ich Ihn auch nicht fragen.

Gruß an alle, Mathias

 

[MSB]

Das du eine Lizenz hast, keine Ahnung,
aber das der eine hat, der das Programm ursprünglich mal geschrieben hat,
ist definitiv auszuschließen. :???:

 

[Thomas_v2.1]

Zwei Punkte die mir bei der Verwendung von temporären Variablen aufgefallen sind, auf die man achten sollte:

1)
Wird in FUP (evtl. auch KOP?) programmiert, so werden für die Aufrufe Daten im Temp-Bereich verwendet. Schalte ich auf AWL um und füge eine neue Temp-Variable ein, so kann es sein dass sich die Adressen mit denen der FUP-Aufrufe überschneiden. Step7 meckert zwar, aber ich habe den Verdacht dass es nicht immer so ist. So können evtl. einzelne Bits in einem Real-Wert gesetzt werden.
Wenn ein Baustein in FUP ist und ich ein Netzwerk in AWL schreiben will, so deklariere ich die Temps immer in Ansicht FUP und schalte dann auf AWL um.

2)
Nicht initialisierte Temp-Variablen:
Der Startwert der Temp-Variablen ist undefiniert (hängt auch vom vorigen Programm ab). Gefährlich ist das, wenn im Programm mit bedingten Zuweisungen (wo evtl. über eine hinweggesprungen wird) gearbeitet wird, und der Wert nachher im Baustein nochmal abgefragt wird.
Wird hier mit einem nicht initalisierten Wert gearbeitet, so können die oben beschriebenen Phänomene auftreten. Das Programm läuft bisher immer (weil evtl. in den Variablen immer 0 stand), und nach einer Änderung ändert sich dieser Wert.
Diesen Fehler hab ich selber mal in einem FC gemacht der in einem FB aufgerufen wurde - da hab ich auch über seltsame Programmfehler gestaunt

 

[MSB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Punkt 1 ist definitiv ein Problem das Siemens bescheiden gelöst hat.
Falls man dieses Verhalten überhaupt Lösung nennen kann.

Punkt 2:
Das ist vollkommen logisch und in keinster Weise verwunderlich.
Aus dem Grund heißt das "Temporäre Variable".

Eine Temp-Variable muss IMMER beschrieben werden, wenn diese im entsprechenden FC/FB ein Zuweisung auslöst (z.B. einen Ausgang o.ä.).
Notfalls am Anfang des Bausteins mit einem "definierten" "L 0", CLR, SET, was auch immer,
hauptsache definiert.

Mfg
Manuel

 

[Kieler]

Hi ...,

schönes Thema. Zu meinen "spannenden" Projekten gehört auch genau ein solchens. Ich sollte eine vorhandenes Step7 Programm um ein neues Anlagenteil erweitern. Alles schön in neuen Bausteinen geschrieben um nicht mit dem alten Programm in Konflikt zu kommen. Trotzdem gab es Probleme mit dem alten Programm. Ich konnte erst garnicht glauben, daß es mit meinen Programm zusammen hängt. Nach einem "langen Wochenende" habe ich dann begriffen, daß der Iststand eigentlich nur versehntlich funktionierte. Mein Vorgänger hat nicht begriffen was temp. Variablen sind. Aber mach das mal einem Maschinenbauer klar. Das geht natürlich nicht. Also habe ich das Programm überarbeitet und dann ging ja auch alles. Schuldfrage klar.

J.

 

[jabba]

Ich hatte meine Variablen immer im Netzwerk, oder eines davor zugewiesen, dann direkt ausgewertet. Es gab keine Unterbrechungs-OB und trotzdem kam es zu Fehlberechnungen. Erst nach Abänderung aller Temp´s auf definierte Variablen war der Fehler weg.

OT:
Wer seine ersten Programme auf S7 schreibt, kann auch schnell darauf reinfallen. Ich würde hier keine verurteilen, der ein Programm geschrieben hat was jahrelang lief, und nun durch eine Änderung nicht mehr läuft.
Ich denke wir werden (hoffentlich) alle mit den Aufgaben wachsen, und ich hab noch keinen getroffen, der vom ersten Tag an perfekt war. Bei einigen meiner ersten S7 Programme graust es mich selber, aus heutiger Sicht. Diese werden immer wieder nach Möglichkeit bei Umbauten "Fehlerbereinigt", wie z.B. auf Temp´s prüfen.
Ich bezeichne mich selber nicht als guten Programmierer, aber wenn ich manchmal sehe was die angebliches Profis für Ideen entwickeln ...
In einer Maschine selbstgeschriebene C# Oberfläche die vom Kunden nicht Änderbar ist, mit Kommunikation die nicht kontrollierbar ist, einen Ventilbaustein für alle Ventile der Maschine mit 23Kb Größe. Eine Freude beim beobachten und ändern. Oder andere die nur noch einen Baustein für alle Ventile haben, und den pro zyklus mit einem Datensatz aus einem DB mit Pointern füttern, und sich wundern, das eine schnellere CPU die Maschine schneller macht.
Bei der ersten aufgeführten Anlage wurde ich angefragt Änderungen zu machen, da hab ich nach dem C# Quellcode gefragt, die Anwort lautete in etwa so an meinen Kunden: Wir raten Ihnen von einer Beauftragung an dritte ab.... wenn selbst ernannte Helden sich versuchen in komplexe Programme und Aufgaben einzuarbeiten, deren Reichweite sie nicht überschauen können....
Naja, war ein Volltreffer ich habe den Auftrag erhalten, die komplette Maschine neu zu programmieren, die Stillstandszeiten sind um 90% gesunken, der NIO Anteil um 80%, die Taktzeit um 25%. Das zu Profi´s , ich denke mir es gibt sicher viele gute Programierer , aber ich programmiere so, das es jeder verstehen kann, und mache keinen Multiinstanzfähigen FB für jede noch so kleine Kackabfrage, die ich in einem Netzwerk erledigen kann.
OT Off

 

[Slartibartfass]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo!

Ich hatte meine Variablen immer im Netzwerk, oder eines davor zugewiesen, dann direkt ausgewertet. Es gab keine Unterbrechungs-OB und trotzdem kam es zu Fehlberechnungen. Erst nach Abänderung aller Temp´s auf definierte Variablen war der Fehler weg.

Da würde mich mal die genaue Ursache interessieren.
Ich mache selbst sehr regen Gebrauch von lokalen Variablen. Eigentlich nehme ich sie für alle Gelegenheite, bei denen ich ein Zwischenergebnis benötige, welches in keinem anderen Baustein gebraucht wird und in jedem Zyklus neu berechnet werden muß. Beachtet man die Regel, daß der Zustand der Variablen zu Baustein Beginn undefiniert ist (undefiniert im Sinne von, es kann alles mögliche darin stehen) und auch keine Ergebnisse vom letzten Zyklus erhalten bleiben, kann man meiner Meinung nach nichts falsch machen.
Bisher bin ich damit nie auf die Nase gefallen. Lokale Variablen haben mir zwar schon den ein oder anderen Streich gespielt, aber das hing entweder mit der Mißachtung o.g. Regel zusammen (Initialisierung wurde bedingt übersprungen) oder lokale Variablen wurden durch die FUP-Umsetztung doppelt benutzt.
Ein paar Meinungen zu dem Thema sahen auch einen Zusammenhang in einem "eigenwilligen Verhalten" durch Benutzung lokaler Variablen und dem OB35. Bisher habe ich mir darüber noch nie Gedanken gemacht, da ich es für garantiert hielt, daß die lokalen Variablen durch die Unterbrechung nicht ihre Werte verlieren.
Dadurch, daß hier erfahrene Leute von der Benutzung eher abraten, bin ich ein wenig irritiert, habe ich etwa all die Jahre etwas falsch gemacht?

Bis dann

 

[jabba]

Hallo Slartibartfass,

ich wäre auch froh wenn mir einer genau sagen könnte was ich falsch gemacht habe, aber auch die Programmierer von meinem Kunden haben nix finden können. In der Anlage war auch kein OB35. Wenn mir einer einen Fehler zeigen kann bin ich eher froh, da ich dann diesen beheben kann, bei so Anlagen die durch ein paar Änderungen einfach wieder laufen, ist man nie sicher das der Fehler weg ist, er taucht halt eventuell nicht auf.

Ich hab die auch genau so wo Du immer für diese Zwecke benutzt, es gibt ja einige die ohne Probleme laufen, aber bei wenigen treten Probleme auf. Ich wollte das mal versuchen einzugrenzen, aber dazu habe ich zu wenige Anlagen. Bezeichnender weise waren es immer 315-2DP, was aber nicht unbedingt was zu bedeuten haben muss. Wir haben die Temp´s auf Variablen geschrieben und mit dem SPS-Analyser aufgzeichnet, die Werte waren immer OK, aber trotzdem kam bei manchen Berechnungen eine 0 raus, obwohl die Berechnung was anderes sagte. Nach dem ändern ist nie wieder was aufgetreten.

 

[zotos]

Also ich glaube das nicht.

Es gibt sicher Fehler die man bei Temp Variablen machen kann. Das es Systembedingt Probleme mit den Temp Variablen geben sollte und diese innerhalb eines Ablaufs ihren Wert vergessen halte ich für höchst bedenklich.

Zum Glück habe ich mit der Seuche7 nichts mehr am Hut. Aber selbst als ich noch damit zutun hatte waren mir solche Phänomene nicht aufgefallen.

Die viele Standard FC nutzen ja Temp Variablen. Wenn man in FUP/KOP Programmiert sind die Lokalen Variablen ja automatisch in Verwendung.

Also dann müsste z.B. Scale(FC106) auch das Problem haben.

 

[jabba]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich werde mal nach dem alten Projekt suchen. Anfangs lief die Anlage ja, dann kamen Änderungen vom Kunden, und irgendwann fing das an.
Ich hab nie in AWL mal geprüft, ob da vielleicht überschneidungen der Lokalvariablen auftraten. Hab gerade mal ein Netzwerk aus einem Baustein in einen anderen kopiert, bei Kop und Fup kein Problem, wird dieser jedoch als AWL kopiert, so werden die Lokaldaten nicht angepasst.
Dies könnte natürlich solche Fehler verursachen.

Wieder was gelernt, und das am Sonntag . Dann kann ich ja weiter das Masterdrive Motion control Handbuch (1515 Seiten) lesen:twisted:

 

[IBN-Service]

...
Die Lokaldaten (Temp) müssen überhaupt nicht mit Vorsicht angewendet werden, sondern nur richtig, für was diese gedacht sind,
nämlich die etwas durchsichtigere Version eines Schmiermerker-Bereichs.

...

Mfg
Manuel

Hallo Manuel,

150% ACK.

Klassischer Fall von "Nagel auf den Kopf getroffen" :sm10:

...
Ich werde in Zukunft in solchen Fällen wohl ausschlisslich mit statischen Lokaldaten arbeiten. Ausserdem sollte man eine Lizenz zum Programmieren einführen!!!
...
Gruß, Onkel

Hallo Onkel,

dann bist du aber gezwungen, mit FB zu hantieren und ggf. für jede noch so
kleine Funktion einen Instanz - DB zu "verschwenden", oder auf Multiinstanzen auszuweichen.
Dass mach m.E. das Programm nicht gerade transparenter...

Bevor ich zu einem FB greife versuche ich, eine FC mit einem DB zu benutzen.

Den DB kann ich global einsetzen und individuell gestalten,
ich unterliege nicht den "Instanz-Zwängen".


CU

Jürgen

.

 

[hovonlo]

Also mir fällt zu diesem Lokaldaten"problem" mehrerlei ein:

1) Warum wird hier immer der OB35 angesprochen? Es gibt doch auch 'ne ganze Menge anderer asynchron aufgerufener Bausteine - außer OB1 und OB100 eigentlich alle, oder?

2) Andererseits läuft jeder dieser anderen OBs in einer anderen Prioebene und hat somit seinen eigenen Lokaldaten-Stack (ok, manche OBs laufen in der gleichen Prio-Ebene, können sich dann aber nicht gegenseitig unterbrechen wie z.B. OB81 bis OB87 bei der 318-2AJ00 auf Prio 25 laufen)

3) Der Ausdruck Temporär sagt doch alles: Man kann nicht davon ausgehen, dass von einem Aufruf des Bausteins zum nächsten irgendetwas erhalten bleibt (obwohl das manchmal tatsächlich klappt!)

4) Ein anderer sehr schöner Fehler, der in die gleiche Kategorie fällt, ist bei FCs die Verwendung einer IN oder OUT Variablen, die an sich INOUT sein müßte. Das funktioniert auch oftmals, wenn der betreffende Baustein der letzte in der Aufrufhierarchie ist - dann kann der Wert nämlich durchaus bis zum nächsten Aufruf erhalten bleiben.

Meiner Erfahrung nach waren bisher alle derartigen Fehler auf lausige Programmierung unter (versehentlicher/unbedachter) Ausnutzung von 3) oder 4) zurückzuführen.