NI TestStand

Showing results for 
Search instead for 
Did you mean: 

Getting the step's sequence name from a pre-step callback

I was using ResultList[ ].TS.StartTime to get each step's start time. I converted it to seconds for LabVIEW by adding 2082844800 + Engine.SecondsAtStartIn1970UniversalCoordinatedTime to it.


In that method, however, if the computer clock is adjusted after the TS Engine initializes, I get wrong timestamps from TS.StartTime afterwards. And there is a high chance that the system clock will indeed be changed from time to time in my application so I am trying to avoid using TS.StartTime all together.


So instead, in a pre-step callback, I get a timestamp from a simple VI using the Get Date/Time In Seconds function for step start time. This works fine because it always directly uses the system clock.


Now the problem is that, I also have to get a particular sequence's start time. In the pre-step callback, I want to check if the step's sequence name is the target name. If so, I want to check if the step's local index is 0. If so, then get a timestamp because it is the start of the target sequence. Before, I was able to get the sequence name from Caller.Sequence.Name. But now using the pre-step callback, I can't find a way to get the name of the sequence to which the step belongs.


Another approach may be using Seconds(False) - Seconds(True) instead of RunState.Engine.SecondsAtStartIn1970UniversalCoordinatedTime.


Any help or suggestions for better solutions will be appreciated.



0 Kudos
Message 1 of 7

I found this works with TS.StartTime.


RunState.Engine.SecondsSince1970UniversalCoordinatedTime - RunState.Engine.SecondsSinceStart


This accounts for all changes in system time. It is essentially the same as Seconds(False) - Seconds(True) on TS Watch View.

0 Kudos
Message 2 of 7

Hello pomirobotics


I would like to know how it is going with that.

Do you have any update?



0 Kudos
Message 3 of 7

Using Engine.SecondsSince1970UniversalCoordinatedTime [1] - Engine.SecondsSinceStart [2] instead of Engine.SecondsAtStartIn1970UniversalCoordinatedTime [3] solved the problem instantly.


[3] is a fixed value once the TS Engine starts but [1] - [2] changes if system time changes because [1] is adjusted accordingly. [1] is always in sync with the system clock.


I attach a figure I created for reference.

0 Kudos
Message 4 of 7

Hello pomirobotics


I see. Is there any possibility to don’t change the system clock?  Just to avoid that.



0 Kudos
Message 5 of 7

Occasional system clock changes are a given situation that I have to deal with. The clock may not even change at all. I just have to make it robust in any situation.

0 Kudos
Message 6 of 7

Hello pomirobotics


I see. So with the diagram I could understand partially in a general perspective however I would like to you bring to me the result was expected and one that was unexpected (changing the system clock)



0 Kudos
Message 7 of 7