Step 7 Merker wird zurückgesetzt

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Siehe Beitrag #2.

Stimmt, Jesper, aber in #2 steht nur lapidar "überlappender Zugriff" und dekuika zählt sie Verdächtigen dankenswerterweise fast lücklos auf (d.h. MB38 sollte der Vollständigkeit halber auch noch genannt werden).
Ich finde, man sollte vorsichtshalber auch danach suchen, ob die aufgezählten MW und MD und das MB irgendwo gelesen werden.
Jawohl, gelesen. Denn selbst, wenn irgendetwas davon nur gelesen aber laut QVL nie geschrieben wird, dann könnte/dürfte das ein Hinweis darauf sein, dass der Bereich irgendwie z.B. von "extern" beschrieben wird. HMI oder NC oder what ever.

 

[DeltaMikeAir]

Ich finde, man sollte vorsichtshalber auch danach suchen, ob die aufgezählten MW und MD und das MB irgendwo gelesen werden.

Das wird in dem Fenster aus #2 alles gelistet ( insofern vorhanden ).

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das wird in dem Fenster aus #2 alles gelistet ( insofern vorhanden ).

Ja, Michael, aber man könnte denken "wird nur gelesen - das brauche ich mir nicht näher anzusehen".
Holzauge sei wachsam, wenn nur gelesen und laut dem Fenster aus #2 nicht geschrieben wird.
Warum sollte jemand etwas lesen wollen, das vermeintlich nie beschrieben wird?

 

[EBS_Concept]

Ich habe den Merker jetzt erstmal geändert.
Ist zwar nicht die Lösung meiner Wahl aber wenn jetzt alles rund läuft habe ich mit M38.5 eine "Doppelbelegung"

In der HMI habe ich nichts finden können, kontrolle der "gelesenen" MD,MW,MB,M's brachte auch keine Lösung.

 

[DeltaMikeAir]

Wenn du magst, kannst du dein Programm hier ja mal einstellen ( als ZIP )

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Möglicherweise hast du auch noch einen FC bei dem das Merkerbit als IN-Parameter übergeben wird. Und in dem FC wird der IN Parameter beschrieben. Dann taucht dieser Zugriff in der Querverweisliste als R (lesend) auf, wird aber beschrieben. Das habe ich schön öfters bei AWL-"Experten" gesehen, und das funktioniert auch nur wenn der FC in AWL aufgerufen wird.

 

[Heinileini]

Möglicherweise hast du auch noch einen FC bei dem das Merkerbit als IN-Parameter übergeben wird. Und in dem FC wird der IN Parameter beschrieben. Dann taucht dieser Zugriff in der Querverweisliste als R (lesend) auf, wird aber beschrieben. Das habe ich schön öfters bei AWL-"Experten" gesehen, und das funktioniert auch nur wenn der FC in AWL aufgerufen wird.

"Was nicht sein darf, das nicht sein kann." ... und muss folglich ignoriert werden?
Ich bin überrascht (enttäuscht - im wahrsten Sinne des Wortes), dass die QVL bei Siemens anscheinend nach diesem Motto arbeitet.
Danke für diesen Hinweis, Thomas!

 

[Thomas_v2.1]

"Was nicht sein darf, das nicht sein kann." ... und muss folglich ignoriert werden?
Ich bin überrascht (enttäuscht - im wahrsten Sinne des Wortes), dass die QVL bei Siemens anscheinend nach diesem Motto arbeitet.
Danke für diesen Hinweis, Thomas!

Ich dachte erst, das käme von alten S5-Programmen her. Aber das hätte man damals auch schon nicht machen müssen. Und das habe ich auch schon bei neuen Programmen gesehen. Das funktioniert aber eben auch nur in AWL, und auch nur bei elementaren Adressen, und nicht vollqualifizierten DB-Adressen wie DB1.DBX0.0 sondern nur mit DBX0.0. Gleiches gilt bei FCs auch für Out-Parameter die von den gleichen Experten gelesen werden. Das funktioniert dann nicht mehr wenn du an den Ausgang DB1.DBX0.0 parametriert. Üblicherweise sind solche Bausteine dann Know-How geschützt, man weiß wieso.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das funktioniert aber eben auch nur in AWL, und auch nur bei elementaren Adressen, und nicht vollqualifizierten DB-Adressen wie DB1.DBX0.0 sondern nur mit DBX0.0.

Die nicht vollqualifizierten Adressen sind aber auch DER Härtefall, um daraus irgendwelche aussagekräftigen QuerVerweise zu generieren.
Das geht prinzipiell gar nicht, da ja der aufgerufene DB/DX/DI zur Laufzeit des Programmes durchaus variieren kann und nicht mit dem einfachen, linearen Lesen des Programmes zu entschlüsseln ist.
Zu S5-Zeiten hatten wir deshalb eine eigene QVL-Generierung für Daten aus DBs/DXs praktiziert UND bei der Programmierung bereits darauf Rücksicht genommen.

 

[PN/DP]

Das funktioniert aber eben auch nur in AWL, und auch nur bei elementaren Adressen, und nicht vollqualifizierten DB-Adressen wie DB1.DBX0.0 sondern nur mit DBX0.0.

Das liegt daran, daß die Aktualparameter da per Reference übergeben werden, und bei vollqualifizierten DB-Adressen und bei FUP/KOP per Value (Wert-Kopie in den Lokaldaten). Wenn der aufgerufene Baustein die Adresse (Referenz) des Aktualparameters bekommt, dann kann er den Aktualparameter "natürlich" lesen und schreiben, egal ob als Input oder Output deklariert. Da liegt es lediglich am Wissen und der Disziplin der Programmierer, daß die Parameter nur so wie deklariert verwendet werden. (TIA hat da jetzt ein etwas übereifriges Auge drauf)

Ich meine, die classic QVL qualifiziert die R- oder W-Zugriffsart bei Bausteinübergabe-Parametern lediglich danach, ob die Aktualparameter an Input, Output oder In_Out übergeben werden.

Harald

 

[Thomas_v2.1]

TIA hat da jetzt ein etwas übereifriges Auge drauf

Ich meine mich zu erinnern, dass es zumindest in Step7 Classic in FUP bei einer Version auch nicht möglich war (d.h. rot und Baustein nicht speicherbar), einen Eingang zu beschreiben. Aber mit einem Update wurden ja mal alle sinnvollen Überprüfungen wieder entfernt. Vielleicht gab es da einen großen Kunden oder eine Eigenentwicklung die auf solche "Effekte" gesetzt hat, man weiß die Gründe nicht.

Nur sind mir jetzt schon drei Fremdprogramme unter die Finger gekommen in denen so programmiert wurde. Beim ersten hab ich noch gedacht, das ist ein konvertiertes S5-Programm gewesen, aber dann noch zwei Mal? Vor allem weil das ja auch nur bei Merker-Programmierung "funktioniert", ich weiß nicht woher das stammt.

 

[LNy]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin!

Ich habe den Beitrag nur überflogen und hoffe das ich nichts Übersehen habe, würde aber eine defekten Merker nicht ausschließen.

Bei einem Projekt 2013/2014 hatten wir ein ähnliches Problem mit einer 317. Immer wenn die Maschine stehen blieb wurde ein Merker nicht neu beschrieben sondern musste nur seinen Zustand halten. Allerdings wechselte der Merker nach etwa 20 bis 30 Minuten zu FALSE, wenn die Verwendungsstelle beobachtet wurde trat dieses Verhalten nicht auf.
Da in deinem Programm gesetzt wird, und nicht Zugewiesen, würde ich diese Möglichkeit nicht ausschließen (auch wenn so ein Fehler sehr selten auftritt). Wenn du sonst nichts findest einfach mal einen anderen Merker ausprobieren.

Begründung von einem erfahren Ingenieur: Beim Beobachten erfolgt ein refresh der Speicherzellen, ansonst verliert die Speicherzelle langsam ihre Ladung bis ein Wechsel nach FALSE erfolgt. Nach Austausch der SPS konnte durch Versuche der defekte Merker bestätigt werden.

 

[PN/DP]

würde aber eine defekten Merker nicht ausschließen.
(...)
Begründung von einem erfahren Ingenieur: Beim Beobachten erfolgt ein refresh der Speicherzellen, ansonst verliert die Speicherzelle langsam ihre Ladung bis ein Wechsel nach FALSE erfolgt.

Ja klar, der altbekannte Mythos der Bitkipper
Vergiss diese Schwachfug-Erklärung, der Ingenieur glaubt bestimmt auch daß Wasser ein Gedächtnis hat...

Harald

 

[LNy]

Ja klar, der altbekannte Mythos der Bitkipper
Vergiss diese Schwachfug-Erklärung, der Ingenieur glaubt bestimmt auch daß Wasser ein Gedächtnis hat...

Harald

Glaub es, oder glaub es nicht!
Ich gebe dir in so fern Recht das dieser Fehler äußerst selten auftritt!

Wenn ich es nicht selbst gesehen hätte würde ich es auch kaum glauben. Aber gib mir eine andere vernünftige Erklärung für das verhalten der SPS! Nach dem Austausch haben wir ein Testprogramm zum beobachten des defekten Merkers geschrieben und konnten damit den Bit-Kipper bestätigen (damit waren Pointer oder sonstiges ausgeschlossen).

Ich will nicht sagen das der OP dieses Problem hat, ausschließen will ich es aber auch nicht.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Begründung von einem erfahren Ingenieur: Beim Beobachten erfolgt ein refresh der Speicherzellen, ansonst verliert die Speicherzelle langsam ihre Ladung bis ein Wechsel nach FALSE erfolgt.

Stimmt. Und man sollte beim beobachten noch einen Aluhut auf die SPS setzen und im Kreis um die SPS tanzen.

 

[PN/DP]

Wenn ich es nicht selbst gesehen hätte würde ich es auch kaum glauben. Aber gib mir eine andere vernünftige Erklärung für das verhalten der SPS! Nach dem Austausch haben wir ein Testprogramm zum beobachten des defekten Merkers geschrieben und konnten damit den Bit-Kipper bestätigen

Und wie hat Dein Testprogramm den Wert des defekten Merkers beobachtet, ohne ihn "mit refresh" zu "Beobachten"?
Es gibt ganz sicher eine andere rationale Erklärung, z.B. Änderung durch Kommunikation von außerhalb der SPS.

Harald

 

[thomass5]

...gab es nicht auch mal Firmwarestände wo an Taktmerker usw. angrenzende Bereiche mit manipuliert wurden....

 

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es gibt ganz sicher eine andere rationale Erklärung, z.B. Änderung durch Kommunikation von außerhalb der SPS.

Vielleicht gab es tatsächlich eine eksterne Partner der die Merkerbyte geschrieben hat. Und die unterschied zwischen offline und online kann man vielleicht erklären mit Verbindungsressourcen die frei bzw. nicht frei waren.

 

[DeltaMikeAir]

Hier wird diskutiert und diskutiert. Vom TE hört man momentan nichts mehr. Es wird halt wie so oft eine ganz ganz simple Erklärung geben.

 

[ducati]

Ja klar, der altbekannte Mythos der Bitkipper

bei uns heisst das "korrupte Datenpakete"