TIA TIA V16 gewollte Dateninkonsistenz im Zeitgesteuerten OB (30) ???

Zuviel Werbung?
-> Hier kostenlos registrieren
Das Problem liegt jetzt seit fast 2 Wochen bei Siemens in der Entwicklung. (Scheint nicht so einfach vom Tisch zu wischen zu sein)

Habe jetzt noch ein anderes Problem mit Remanenz von Merkern bei Siemens liegen.

Wenn das so weitergeht wirts noch was dauern mit dem nächsten Update :ROFLMAO:

Ich habe mir mal den Astro Baustein reingezogen und im OB1 verwendet und auch Überprüfungstags eingebaut. Weiterhin einen Zähler wie oft der OB1 und der OB30 dran waren...
Da wird nichts mit 0 überschrieben...
Zum Vergrößern anklicken....

Im OB1 funktioniert das auch...
Soweit ich das eingrenzen konnte muß die Systemzeit in einem entfernten Baustein gelesen werden (Typ DTL), die Variable muß vom Typ Time sein und es müssen Lesezugriffe/Vergleiche im Format Time im Programm aktiv sein.

Im übrigen möchte ich hier von Codeeinstellungen absehen, da dies nur zu allemöglichen Kritik und Unverständnis bezüglich meines Programierstiles führen würde und nicht helfen wird.

Ich denke Siemens ist jetzt am Ball.
 
rostiger Nagel schrieb:
Immer dabei Taktmerker und Systemmerker „FirstScan“, „AlwaysTrue“, „AlwaysFalse“
oder das Quitierbyte um aus der HMI Safety wieder einzugliedern.
Warum nicht, funktionieren einwandfrei.
Zum Vergrößern anklicken....

Ja, aber das noch jemand Merker nutzt bei denen die Remanenz entscheidend ist, hat mich doch verwundert.
Habe jetzt noch ein anderes Problem mit Remanenz von Merkern bei Siemens liegen.
Zum Vergrößern anklicken....
 
Hier mal meine (unbegueme) Meinung

Am Anfang hieß es, dass im OB1 mit folgendem Code
#RETURNVALUE := RD_LOC_T("Akt".Localzeit);
"Akt".Uhrzeit := DTL_TO_TOD("Akt".Localzeit);
Zum Vergrößern anklicken....

Probleme gibt, weil durch Unterbrechungen angeblich die Daten zwischen den zwei Zeilen durch eine Unterbrechung des OB30 verfälscht wird.

Das Problem sollte sich also mit einem 10 zeiligen Programm nachstellen lassen.

Jetzt heißt es auf einmal:
Im übrigen möchte ich hier von Codeeinstellungen absehen, da dies nur zu allemöglichen Kritik und Unverständnis bezüglich meines Programierstiles führen würde und nicht helfen wird.
Zum Vergrößern anklicken....

Das macht einen ja schon mal skeptisch. Warum sollten die paar Zeilen große Kritik auslösen.

Der letzte Satz hat mich dann noch in meiner Meinung bestärkt:
Habe jetzt noch ein anderes Problem mit Remanenz von Merkern bei Siemens liegen.
Zum Vergrößern anklicken....

Meine Meinung dazu:
Das Problem sitzt vor dem PC und möchte hier nichts eingestehen....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Faceman schrieb:
.. Das Problem sitzt vor dem PC und möchte hier nichts eingestehen....
Zum Vergrößern anklicken....
Mit solchen Behauptungen wäre ich vorsichtig. Es gibt schon Phänomene, die sich verdammt schlecht erklären oder nachstellen lassen. Vielleicht hängt es ja auch mit der Hardware oder Firmware zusammen.

@NBerger
Wurde das Programm eigentlich mal im Simulator getestet?
 
DeltaMikeAir schrieb:
Ja, aber das noch jemand Merker nutzt bei denen die Remanenz entscheidend ist, hat mich doch verwundert.
Zum Vergrößern anklicken....

Ich Nutze Merker genau wegen der Remanenz und weil TIA Merker nicht ständig reinitialisieren will. Merkerbereiche nutze ich um DB Bereiche die ich auf keinen Fall wegen einer Reinitialisierung verlieren will zu sichern und rückzusichern.
 
rostiger Nagel schrieb:
Immer dabei Taktmerker und Systemmerker „FirstScan“, „AlwaysTrue“, „AlwaysFalse“
oder das Quitierbyte um aus der HMI Safety wieder einzugliedern.
Warum nicht, funktionieren einwandfrei.
Zum Vergrößern anklicken....

Hatten wir bis letztes Jahr auch noch so. Dann hat bei der IBN ein Kollege AlwaysTure auf einen Ausgang eines Bausteines gelegt der meist true war... Der Fehler war echt toll zum finden.

Seitdem gibts diese Merker bei uns nicht mehr. Ist ja auch nicht mehr nötig, da man in 15.1 die Konstanten "True" und "False" auch in KOP und SCL verwenden kann.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Jochen Kühner schrieb:
Hatten wir bis letztes Jahr auch noch so. Dann hat bei der IBN ein Kollege AlwaysTure auf einen Ausgang eines Bausteines gelegt der meist true war... Der Fehler war echt toll zum finden.

Seitdem gibts diese Merker bei uns nicht mehr. Ist ja auch nicht mehr nötig, da man in 15.1 die Konstanten "True" und "False" auch in KOP und SCL verwenden kann.
Zum Vergrößern anklicken....

False oder True mit Querverweis zu suchen kann lustig werden ;)
 
rostiger Nagel schrieb:
False oder True mit Querverweis zu suchen kann lustig werden ;)
Zum Vergrößern anklicken....
Und wozu würde man sich dieses Vergnügen gönnen wollen? ;)

Zu suchen und insbesondere zu finden, wo einem ein "theoretisch-immer-True-Merker" bzw. "theoretisch-immer-False-Merker" zerschossen wird, kann trotz oder wegen (vieler) Querverweise auch sehr spannend werden. Z.B., wenn ein Kollege dazu einen SiemensStandardBaustein per fehlerhafter Parametrierung ungewollt und unbewusst missbraucht hat. :ROFLMAO:
 
Das mit den Querverweisen ist doch kein Problem, für was gibt es die Spalte mit "Lesen,Schreiben,Lesen/Schreiben"? Man muss sie nur breit genug ziehen dass man das Lesen/Schreiben nicht als Lesen liest. Und wenn jemand so einen Merker auf eine E/A Variable geben sollte, dann kann man auch nicht mehr helfen.
 
Ich sage ja auch nicht, man findet nicht wer den AlwaysTrue abschaltet. Wenn dieser jedoch z.b. nur einen Zyklus weg ist, muss man erst mal darauf kommen das das das Problem sein kann, und nicht erst überall anders suchen. Wie gesagt, durch die Konstanten "True" & "False" finde ich hat das im Program nichts mehr verloren.
 
Zurück
Oben