Step 7 Frage zum Erstabfragebit

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

interessant wäre, was die 300er mit Step7 5.5 bei SPB bzw. SPBN macht? Weil da könnte schon eher einer drauf kommen, solchen Code produktiv einzusetzen...

Gruß.

Habs jetzt noch mal mit ner 315-2PN/DP und Step7 5.5 getestet. Bei SPBN ist es eigentlich richtig, bei SPA ist es nicht so, wie man es erwarten würde... Sieht dann doch eher nach einem Bug aus...

 

[ducati]

Hab mal erfahrene Kollegen gefragt, alle 3 haben die Ergebnisse falsch vorhergesagt Aber alle sind der Meinung, dass es eigentlich ein Programmierfehler ist, sowas zu schreiben.

Hab noch mal etwas mit SPB und SPBN getestet, das ist auch nicht nachvollziehbar.

Bei der realen 300er mit Step 7 5.5 sieht das z.B. so aus:



bei der 1513 mit TIA V13 so: (ohne das CLR gabs nen Übersetzungsfehler)




ominös alles... Das ganze scheint also Siemens bekannt zu sein, weshalb sie die komischen Fälle durch den Compilerfehler mit TIA ausmerzen


hier noch das ganze mit der 300er Step 7 5.5 aber in PLCSIM 5.4 SP6:




Also PLCSIM mach hier was anderes als die 300er, was sich schon immer sage. Richtige Tests kann man nur mit der realen CPU machen... Grad für solche Fälle.



Interessant wäre noch ne 300er mit TIA, aber das teste ich nicht, weil ich 300er aus Prinzip nicht mit TIA programmiere

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei SPBN ist es eigentlich richtig, bei SPA ist es nicht so, wie man es erwarten würde... Sieht dann doch eher nach einem Bug aus...

Wenn der Sprung (SPA) ein VKE=0 mitnimmt, dann sieht man daß das "U M.." nicht als Erstabfrage gewertet wird, obwohl /ER=0 ist.
Wenn der Sprung (SPA, SPB, SPBN) ein VKE=1 mitnimmt, dann fällt das problematische Verhalten nicht auf, weil ein VKE=1 weiterverknüpft wird, obwohl /ER=0 ist.
SPB und SPBN setzen VKE=1 egal ob gesprungen wird oder nicht (und setzen zusätzlich das /ER auf 0, so daß die nächste Verknüpfung eine Erstabfrage sein soll).

Harald

 

[ducati]

Wenn der Sprung (SPA) ein VKE=0 mitnimmt, dann sieht man daß das "U M.." nicht als Erstabfrage gewertet wird, obwohl /ER=0 ist.
Wenn der Sprung (SPA, SPB, SPBN) ein VKE=1 mitnimmt, dann fällt das problematische Verhalten nicht auf, weil ein VKE=1 weiterverknüpft wird, obwohl /ER=0 ist.
SPB und SPBN setzen VKE=1 egal ob gesprungen wird oder nicht (und setzen zusätzlich das /ER auf 0, so daß die nächste Verknüpfung eine Erstabfrage sein soll).

Harald

ja, Du hast recht, ich hab schon gemerkt, dass SPB SPBN auch Quatsch macht, wenn man zu nem O M500.5 springt.

Komisch wirklich, dass nen CLR oder SET in dem übersprungenen Teil ne Auswirkung hat.

Wieder was gelernt!

Gruß.

 

[Heinileini]

Was zu InterpreterZeiten ein Feature war, nämlich die "automatische ErstabfragenErkennung", wurde erst anlässlich der Umstellung auf CompilerVerwurstung als Bug eingestuft.
Ist mir so durchaus verständlich und einleuchtend. Dass dies aber quasi heimlich vollzogen wurde und dadurch eine Inkompatibilität entstand, unter dem Deckmantel Inkompatibilitäten zu vermeiden ... das finde ich schlimm. Bei Siemens muss man wohl darauf spekuliert haben "es wird schon keiner merken" und "wer darüber stolpert, ist es selbst in Schuld, wenn er so krauses Zeug programmiert".
Immerhin merkt der Compiler anscheinend doch (gelegentlich?), wenn ein "RisikoFall" vorliegt.

PS:
NOP 0 ist auch nicht mehr das, was es mal war? Habe ich das richtig verstanden? Oder war das nur als Verdacht geäussert?

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

PS:
NOP 0 ist auch nicht mehr das, was es mal war? Habe ich das richtig verstanden? Oder war das nur als Verdacht geäussert?

Wenn man bei einer Erstabfrage aufpassen muss, kann man den NOP 0 auch in Frage stellen.

 

[ducati]

NOP 0 ist auch nicht mehr das, was es mal war? Habe ich das richtig verstanden? Oder war das nur als Verdacht geäussert?

das war nur nen Verdacht, NOP 0 hat m.M. keine Auswirkung...

wenn ichs jetzt richtig verstehe, sieht das Prob folgendermaßen aus:

// das hier macht Ärger:
U M0.0
SPB n01a
U M0.1
n01a: NOP 0
U M0.2 // diese Stelle wäre je nach Erfüllung des SPB ne Erstabfrage oder auch nicht
= M0.3


// das hier macht keinen Ärger:
U M0.0
SPB n01a
U M0.1
S M0.4
n01a: NOP 0
U M0.2 // diese Stelle ist immer ne Erstabfrage
= M0.3

Die beiden Varianten machen natürlich was anderes!

Die erste Varante sollte man so bei S7-300 mit Step7 5.5 nicht einsetzen!

Bei TIA V 13 mit S7-1500 meckert der Compiler das sogar an...

Gruß.

 

[rostiger Nagel]

sind das jetzt mit Absicht bedingte Sprünge?

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

sind das jetzt mit Absicht bedingte Sprünge?

Grundsätzlich kann das auch SPA oder SPBN oder SPB sein... (alle anderen Sprungarten hab ich jetzt nicht getestet)

Wenn in dem übersprungenen Teil die Verknüpfung abgeschlossen wird (durch S R = CLR SET) dann funktionierts, wenn nicht, dann nicht...

So würd ich das jetzt sehen...

Gruß.

 

[Heinileini]

sind das jetzt mit Absicht bedingte Sprünge?

Bestimmt. Vorsicht ist bekanntlich die ElefantenMutter im PorzellanKistenLaden. Ganz wie beim NOP 0.
Jetzt fehlt noch der Sprungbefehl mit bedingten Sprungzielen, der SPL !

PS:
Bei der LOGO! würde er bestimmt analoger Sprung heissen, wenn es ihn gäbe.

 

[ducati]

komisch ist auch, dass sie bei der 1500er nicht das Verhalten von der 400er bzw. PLCSIM übernommen haben, sondern das komische Verhalten der 300er durch ne Compilerwarnung verhindern... Irgendjemand hat sich da schon komische Gedanken gemacht...

Gruß.

 

[Olli_BS]

Zuviel Werbung?
-> Hier kostenlos registrieren

So schlecht ist ein definiertes LOAD (wie z.B. bei CodeSys-Dialekten) statt eine Auto-Hintergrund-Erstabfragen-Erkennung dann also doch nicht ....
Fand ich immer unbequem. Hat aber was eindeutiges ...

 

[Heinileini]

Irgendjemand hat sich da schon komische Gedanken gemacht...

... oder erst zu spät (aber immerhin) gemerkt, dass man sich viel früher hätte unkomische Gedanken machen sollen.
Man wollte anscheinend der FanGemeinde von "ewig-gestrigen" AWL-Anhängern nur gaaanz vorsichtig vor den Kopf treten, so dass es als Wellness-Tat empfunden wird.

 

[ducati]

... oder erst zu spät (aber immerhin) gemerkt, dass man sich viel früher hätte unkomische Gedanken machen sollen.
Man wollte anscheinend der FanGemeinde von "ewig-gestrigen" AWL-Anhängern nur gaaanz vorsichtig vor den Kopf treten, so dass es als Wellness-Tat empfunden wird.

ja oder ne Migrationsgeschichte für 300->1500. Lieber ne Fehlermeldung als nen anderes Verhalten...
(gibt sicherlich mehr Migrationen 300->1500 als 400->1500)

Probleme gibts aber, wenn man 300->400 migriert, oder 300->Vipa, oder ne 300er Programm mit PLCSIM testet, oder ne Soft-SPS...

oje

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

So schlecht ist ein definiertes LOAD (wie z.B. bei CodeSys-Dialekten) statt eine Auto-Hintergrund-Erstabfragen-Erkennung dann also doch nicht ....

Gut, weil eindeutig, ist es auf jeden Fall. Die "automatische" à la Siemens ErstAbfragenErkennung ist für Anfänger nicht so ganz klar und hat "VerwirrungsPotenzial", ist also gewöhnungsbedürftig, aber letztendlich sehr gut beherrschbar.
Um die Philosophie hinter der automatischen ErstAbfrageErkennung zu verstehen, muss man sich in die Zeit zurückversetzen, als von der strukturierten Programmierung auch in den meisten BASIC-Dialekten noch nichts zu spüren war und noch "ganz selbstverständlich" auf ZeilenNummern gesprungen wurde. Damals hatte COBOL noch die VorreiterRolle bezügl. Strukturierung, war aber für technische Anwendungen mehr als ungeeignet.
Bytes sparen war angesagt. In dem ohnehin zu engen Korsett der 1-Wort-Anweisungen auch noch spezielle OP-Codes für ErstAnweisungen unterbringen? In den Varianten mit und ohne Negation und das für diverse OperandenTypen mit ihren AdressRäumen? Das hätte man als Verschwendung empfunden. Lieber die knappen Reserven für andere SprachErweiterungen in der HinterHand haben.
"TrickProgrammierung" durch Springen mitten in VerknüpfungsKetten war zwar auch schon bei vielen verpönt, aber ByteSparen war im ZweifelsFall wichtiger. Vorhersehbar, nachvollziehbar und reproduzierbar - sprich eindeutig - war das Verhalten der CPUs (damals noch!) allemal.

 

[PN/DP]

Ich habe jetzt noch eine CPU 318-2 getestet (318-2AJ00 V3.0.1). Die 318-2 verhält sich wie vermutet anders als andere S7-300 - bei der 318-2 funktioniert die Erstabfrage korrekt wie bei S7-400.

Der "CPU 318 Migration Check" weiß daß sich S7-300-CPUs bei der Erstabfrage anders verhalten als die 318-2. Sprünge in eine Verknüpfungskette werden beanstandet:

Achten Sie bei Programmen für die S7-300-CPUs darauf, dass bei Sprungoperationen das Sprungziel immer der Beginn einer Verknüpfungskette ist (muss nicht bei der CPU 318-2 sein). Das Sprungziel darf sich nicht innerhalb einer Verknüpfungskette befinden.

Harald