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

[Chickentree]

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.

[Chickentree]

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.

[David22JRA]

Hello pomirobotics

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

Do you have any update?

Regards

[Chickentree]

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.

[David22JRA]

Hello pomirobotics

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

Regards

[Chickentree]

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.

[David22JRA]

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)

Regards