Beckhoff SYSTEMTIME_TO_DT liefert plötzlich nur 1970'er Datum

C

cpalm

Level-1
Beiträge
19
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Jahrelang lief mein Coding in dem Bereich völlig problemlos. Nun ganz plötzlich wird meine zentrale DATE_AND_TIME Variable nicht mehr richtig errechnet. Scheinbar arbeitet ganz plötzlich die Konvertierungsfunktion SYSTEMTIME_TO_DT nicht mehr korrekt. Der Input-Parameter presetTime ist - wie im Screenshot zu sehen - richtig mit aktuellen Werten gefüllt.

Leider wird die Variable dtCurrentLocalTime immer auf den 01.01.1970 00:00 gesetzt.

Was ich kontrolliert habe:
- Aktueller Build von TwinCAT PLC V2.11.2307
- Bibliotheken aus aktuellen TwinCAT Build SYSTEMTIME_TO_DT ist in TcUtilities.lib Version 5.02 vom 3.2.16

11-04-_2021_21-49-46.jpg


Und bis zur technischen Obergrenze bei diesem internen 32-bit Wert von 06.02.2106 06:28:15 sollte ich noch ein bisschen Zeit haben, so dass ich hier aktuell nicht mit einem Overflow á la Jahr 2000 Problem rechne...

Danke für jeden Hinweis!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also der Screenshot zeigt ja schon die globale Variable presetTime aus fbGetLocalTime mit den aktuellen Werten (roter Rahmen rechts oben). Der Wert von presetTime sieht gut und richtig aus.
 
Ups, da hast Du recht. Hatte wohl meine Brille noch nicht auf. Aber kann es sein, dass dtCurrentLocalTime irrtümlich überschrieben wird?
 
Jegliches Überschreiben habe ich überprüft. Es sollte nicht stattfinden. Als Test habe ich mir auch einmal TIMESTRUCTs aufgebaut und selbst statisch initialisiert. Resultat: Die Funktion SYSTEMTIME_TO_DT liefert immer das gleiche, falsche Resultat! Zu gerne würde ich in die Beckhoff Implementierung dieser Funktion nachsehen, um zu prüfen, wo es intern schief läuft.

Zum Glück gibt es noch eine andere Funktion die in einen DATE_AND_TIME Typ konvertieren kann: FILETIME_TO_DT. Hier habe ich mal ein alternatives Szenario aufgebau und siehe da: Diese Funktion arbeitet korrekt.

Hier die Screenshots mit der "vollständigen Beweiskette" aus dem Debugging:
12-04-_2021_15-04-34.jpg

Jetzt müsste ich eigentlich mal Beckhoff kontaktieren... Ich dachte aber: Das muss doch mal vorher jemandem aufgefallen sein, das diese FUNCTION nicht (mehr) funktioniert.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich glaube Dir ja, dass Du tsTestTime2 mit gültigen Werten vorbelegt hast, aber in der "vollständigen Beweiskette" fehlt die Ansicht. ;)
Scheint dann aber tatsächlich ein Fall für Beckhoff zu sein. Bist Du denn erst kürzlich auf die genannte Lib-Version umgestiegen?
 
Stimmt. Ich hatte tsTestTime2 nicht aufgeklappt ;-) Hatte es aber natürlich selbst genauestens überprüft.
Die Lib-Version ist steinalt von 2016 und hat sich nicht verändert. Das ist ja auch das, was ich merkwürdig finde. Irgendeine andere "externe Bedingung" innerhalb oder außerhalb der Library muss dazu geführt haben, dass die Funktion nicht (mehr?) das tut, was sie soll.
 
Ich programmiere nicht in FUP, also mal die Frage, warum ist die Variable presetTime hellgrau? Wenn in der Bausteinübersicht etwas hellgrau ist, wird es nicht verwendet, aber im Programmteil kenne ich das nicht. Ist die Variable global deklariert?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mehr oder weniger durch Zufall konnte ich vor einiger Zeit das oben geschilderte "Problem der Merkwüdigkeiten" lösen. Echt eine kleine Gemeinheit, auf die man so nicht einfach kommt.

Ich benutze intern ein Array, was einfach zu klein dimensioniert war. In der Folge kam es zu einem Überlauf, da ich kein manuelles Bounds-Checking programmiert hatte. Als Entwickler dachte ich "das wird schon reichen...", aber es war einfach nicht so.
Der Überlauf zerstörte intern scheinbar irgendwelche Datenstrukturen und es gab keine Fehlermeldung oder Ähnliches um mich auf diesen Zustand hinzuweisen.

Nur das halt bestimmte Bausteine eingebundener Bibliotheken nicht mehr so funktionierten, wie erwartet.
 
Zurück
Oben