Antwort schreiben 
 
Themabewertung:
  • 0 Bewertungen - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
TimeStamp vs. DateTime.Ticks
03.02.2015, 11:44
Beitrag: #1
TimeStamp vs. DateTime.Ticks
Hallo zusammen,

ein OnCycle Element gibt am Ausgang einen TimeStamp heraus. Nach VEE-Hilfe sind das die vergangenen Sekunden seit 01.01.0001 00:00.
("This Real number represents the number of seconds that have elapsed since midnight, January 1, AD 1 UTC")

Dieser TimeStamp läßt sich auch problemlos mit "AlphaNumeric" wieder als aktuelle Zeit anzeigen.

Unter .NET gibt es ein "System.DateTime.Ticks" was die "Ticks" in 100ns Schritten seit 01.01.0001 00:00 wiedergibt.
("Der Wert dieser Eigenschaft stellt die Anzahl der 100-Nanosekunden-Intervalle dar, die seit dem 1. Januar 0001, 00:00:00 (Mitternacht) vergangen sind")

Auf dieser Wert läßt sich mit .NET Funktion problemlos weiterverarbeiten.

Genau betrachtet sollten diese beiden Werte doch bis auf den Faktor 10hoch7 gleich sein, oder ?

Wenn ich diese Werte allerdings gegenüberstelle erhalte ich immer eine Zeitdifferenz von 47 Stunden (169200 Sekunden), woher kann das kommen ?

Die Frage hat natürlich einen ernsthaften Hintergrund den ich kurz anreiße:

Ich habe ein VEE-Programm läufen, welches im Hintergrund alle 10 Sekunden die Temperatur eines Ofen einliest. (Thread-Objekt mit OnCycle(10) ). Das Programm läuft soweit stabil bis auf einen .NET Aufruf der Statusmeldungen (Buchungen) an einen Server schickt.
Des öfteren stürzt das Programm bei diesen Buchungen ab. Diese Abstürze geschehen ohne "richtige" VEE Fehlermeldung. Nur so nach dem Moto "Error Report senden" dort steht was von "Access Violation ExceptionCode: 0xC0000005". Ich vermute das bei diesem .NET Aufruf (ist eine API Funktion der MES-Software) Speicher verwendet wird, der nicht reserviert wurde oder ähnliches was dann mit dem 10 Sekunden-Thread kollidiert.
Nehme ich den Thread aus dem Programm läuft es stabil. Daher muß es die Kombination Thread und Buchung sein.
Ich möchte jetzt als Workaround nicht buchen wenn eine Temperatur-Einlesung bevorsteht. So nach dem Moto buchen nur erlaubt wenn letzte Temperatur-Einlesung nicht älter als 9 Sekunden (Endlosschleife vor Buchvorgang).
Dazu wollte ich den Wert am Ausgang des OnCycle Elements global zwischenspeichern und mit DateTime.Ticks (vor Buchung) vergleichen.
Ich kann natürlich auch im Temperatureinlese-Thread extra ein DateTime.Ticks aufrufen und das dann extern vergleichen, aber interessieren würde mich das schon, warum beide Funktionen unterschiedliche Werte (Sekunden) liefern.

Habe mal ein Beispielprogramm angehängt. ( benötigt mscorlib !)
Scrennshot schaffe ich nicht einzufügen, oder doch:

   

Gruß Peter


Angehängte Datei(en)
.vee  OnCycle.vee (Größe: 6,57 KB / Downloads: 1)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
04.02.2015, 14:32 (Dieser Beitrag wurde zuletzt bearbeitet: 04.02.2015 14:35 von detlef.)
Beitrag: #2
RE: TimeStamp vs. DateTime.Ticks
Mag sein, dass es einen Unterschied zwischen der VEE Time und der .net Time gibt.
Aber wieso nimmst du dann dotnet time? Bleib einfach in VEE, und nimm das NOW object...
Das, was das NOW liefert, ist identisch mit dem , was in der ONcycle benutzt wird....

Hatten wir nicht sowas aehnliches bei der Umrechnung der Zeiten in Excel?
Einer zeigt seit Christi Geburt, der andere seit 1.1.1990 oder 1900 oder so ?


Wobei ich meine mit bleib in VEE: das sind die von VEE ursaechlich bereitgestellten Funktionen, und nicht die ueber DOtnet oder MATLABSCRIPt zusaetzlich erreichbaren.
FOB halt...Function and Object browser...
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
05.02.2015, 09:48
Beitrag: #3
RE: TimeStamp vs. DateTime.Ticks
Hallo detlef,

.NET bietet mir in meinem Programm mehr Möglichkeiten. Ich kann z.B. aus der aktuellen Zeit und einer Restlaufzeit den Zielzeitpunkt berechnen wann das Teil fertig ist. Auch gibt es über "GetDateTimeFormats()" die Möglichkeit die Zeiten bequem im benötigten Format auszugeben.

Aber du hast recht die "Build-in-functions => Time & Date => now" liefert den gleichen Wert wie "OnCycle", das war mir so nicht bewußt !
Zumal VEE über das Menu "System => DateTime" anscheinend die .NET Funktionen anbietet. Bei Auswahl einer Funktion dort wird automatisch die "mscorlib" eingebunden (war mir so auch nicht bewußt).

Ich habe es jetzt gelöst in dem ich als erste Aktion in dem Thread den aktuellen Wert von "System.DateTime.Now" global speichere und diesen dann als Vergleich anziehe.

Gewundert hat mich eben das beide Funktionen andere Werte bringen, obwohl sie nach Beschreibung (gleiche "Zeitwurzel") den gleichen Wert bringen müßten.

Leider bewahrt diese Programmänderung das Programm nicht vor einem sporatischen Absturz. Vielleicht sollte ich dazu den Foren-Thread "Multithreading (von maxheadroom)" nochmal aufleben lassen, da paßt das am besten rein.

Gruß Peter
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
05.02.2015, 15:02
Beitrag: #4
RE: TimeStamp vs. DateTime.Ticks
Benutzt du Multithread -Objekte?
Vorsicht, da bin ich auch schon auf die Nase gefallen, hab alles wieder rueckgaengig gemacht.
Nur Multithread, wenn wirklich alles voneinander unabhaegig ist.
Die .net Geschichten basieren in VEE auf Version2.5 glaub ich, derzeit ist MS auf 4.5. Kann also sein, dass die .Net Funktionen fehlerhaft sind...oder dein Rechner zu schnell...
Aber gerade schreibt jemand in der VRF ueber ein aehnliches Problem , ich verlinke mal....
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
05.02.2015, 17:22
Beitrag: #5
RE: TimeStamp vs. DateTime.Ticks
Ja, ist mit Multithread programmiert.
Wie im ersten Post beschrieben, wird alle 10 Sekunden ein Temperaturwert über USB/seriell geholt und verarbeitet. (extern speichern + rollierendes Array)

Ohne Multithread müßte ich parallel ein zweites Programm laufen lassen, da das Programm durchaus mal ein diversen Schleifen "hängenbleiben" kann und ich nicht alle 10 Sekunden zum Temperatureinlesen kommen kann.

Ich setze jetzt im Temperatur-Thread gleich am Anfang ein globales Flag. Am Ende des Temperaturthread lösche ich dieses dann wieder.
Vor jedem Aufruf einer externen Funktion habe ich eine "Bremsschleife" gesetzt. (sinngemäß: Repeat until not(Flag))

Das Programm lief jetzt schon auffallend lange ohne weiteren Absturz.

Hat man eigentlich die Möglichkeit die "Absturzbereichte" (VEE-XXXXXX.dmp) irgendwie vernünftig zu lesen. Ein Windows Dump Editor scheint nichts damit anfangen zu können.

Zu deinem letzten Satz: Was ist die "VRF" und wo ist der Link ??

Gruß Peter
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
09.02.2015, 14:28
Beitrag: #6
RE: TimeStamp vs. DateTime.Ticks
Diese Abstuerze hatte ich auch, als ich mehrere Multithreads benutzt hatte, insbesondere Abfragen von Hardware ( hier serielle Schnittstelle) fuehrte da zu Problemen. Das Beste war, die ser nur in einem Thread abzufragen, oder ganz auf das Multithreading zu verzichten. Ist halt immer problematisch, wenn da konkurrierende Aufgaben irgendwann mal gleichzeitig auf ein Register zugreifen wollen, dann crasht es.

Die VRF ist die englischsprachige Mailingliste von VEE, betreut von Agilent jetz Keysight.
Erkennt man auch oben rechts im Menue als tip ..VRF = VEE Reflector Forum oder so...

Dort wurde gerade ein aehnliches Problem eroertert, und schliesslich kam raus, dass die PC Uhr nachging und die Batterie gewechselt werden musste...
Ansonsten wurde da empfohlen, die dotnet Zeit zu nehmen, da auch nanosekunden drin sind...obwohl windows nur in Abschnitten von 50 us oder so genau ist...hmmm...ist halt kein Echtzeitbetriebssystem...
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
09.02.2015, 15:45 (Dieser Beitrag wurde zuletzt bearbeitet: 09.02.2015 18:31 von detlef.)
Beitrag: #7
RE: TimeStamp vs. DateTime.Ticks
Das mit den 47 Stunden ist trotzdem interessant.
Vielleicht hat das mit der Umwandlung von Julianischem zu Gregorianischem Kalender zu tun, aber da muesste dann mehr Differenz rauskommen.. so um 10 Tagen...
Ich frag mal in der VRF, von den alten Hasen da weiss das mal einer hoffentlich;-)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
09.02.2015, 18:15 (Dieser Beitrag wurde zuletzt bearbeitet: 09.02.2015 18:32 von detlef.)
Beitrag: #8
RE: TimeStamp vs. DateTime.Ticks
Also, diese 2 Tage Unterschied ( plus/minus Lokalzeit zu UTC) kommen wohl vom proleptic gregorian calender ---mal googlen, was das ist...
VEE benutzt wohl die UNix art, die Ticks zu rechnen, und Windows die Art mit 2 Tagen weniger.
Bei der String Darstellung ist dann noch die Lokalzeit mit beruecksichtigt- daher also 48-1 ...
Man lernt ja nie aus, und wir koennen uns ja munter streiten, ob nun Christi Geburt im Dezember oder im Januar ist, wenn man mal diesen WIKI ueber den Gregorianischen Kalender liest....
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
10.02.2015, 12:46
Beitrag: #9
RE: TimeStamp vs. DateTime.Ticks
okay , mehr Info zu den verschiedenen Systemzeiten:
http://en.wikipedia.org/wiki/System_time
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
11.02.2015, 10:35
Beitrag: #10
RE: TimeStamp vs. DateTime.Ticks
Hallo detlef,

reichlich Lesestoff. Danke für deine Recherche, werde mir das am Wochenende mal in Ruhe "reinziehen".
Den 47 Stunden Zeitunterschied nehme ich halt mal "zur Kenntnis" für zukünfige Projekte.

Mein anderes Problem mit den Abstürzen ist in der Tat, durch das Setzen des globalen Flags, deutlich besser geworden.

Offen wäre noch die Frage wie oder ob man die Dump-Files lesen kann. Hat das schon jemand probiert ?


Gruß Peter
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
11.02.2015, 16:03 (Dieser Beitrag wurde zuletzt bearbeitet: 11.02.2015 16:22 von detlef.)
Beitrag: #11
RE: TimeStamp vs. DateTime.Ticks
Diese dump files wurden frueher an Agilent geschickt, um die Softwarefehler zu erkennen. Dieser Server dort wurde abgeschaltet, der Aufforderung von VEE braucht man also nicht mehr nachzukommen.
Vielmehr sollen diese Fehler wohl in aehnlicher Form an MS geschickt werden- die dann wieder Keysight informieren. Ob das wirklich so laeuft, keine Ahnung....
Aber selber auslesen nuetzt dir nix.
Nun, ich hatte aehnliche Probleme- Stichwort "Race Condition"- und habe folgende Links zu Lesen bekommen ( Bei Multithread Objects):
http://cp.literature.agilent.com/litweb/...3540EN.pdf

und hier in deutsch:
http://www.google.de/url?url=http://www....RJpP-DROdw
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
Antwort schreiben 


Gehe zu:




Partnerforen: LabVIEWForum.de| DIAdem-Forum.de| Machine-Vision-Forum.de| goMatlab.de| VEEforum.de