Wait Step Setting Time Interval

[richjoh]

I enter 3600 seconds for TimeInterval() Wait Step. More than an hour goes by and nothing happens. TestStand 2016 hangs there on the step. 

Is there a limitation on the number of seconds?

I will break this up into multiple sections to get to an hour but also to show that Wait(inseconds) is functional.

[~jiggawax~]

I've not heard of a limitation like that.  Consider the attached example.  You just change the step attribute of TotalTime to be whatever you need (in your case 3600).  The nice thing about this is it shows you in the step status how long it's been counting.

You can reformat what the status looks like and get all sorts of crazy with it if you need to.  This is just a very simplified example.

[~jiggawax~]

I just realized I gave you the one that counts up.  This one counts down.

[crossrulz]

For "long" waits, I will call a LabVIEW VI that does a wait with a progress bar.  It also has the ability to cancel the wait.

[richjoh]

Very Cool. My first instinct is to use Labview but TS was already in use. In your count down TS Wait, I don't know where to find "AsPropertyObject" in your Step.AsPropertyObject.Attributes.TotalTime expression. I looked everywhere in the Expression Browser. Maybe I'm overlooking the property member.

[~jiggawax~]

Every object in TestStand inherits from PropertyObject except for the Engine.  One of the properties of a a PropertyObject are a thing called Attributes.  Think of Attributes as a large container that anything can be put inside of.  I use it for this example so that when you copy the step around you don't have to also copy Local or FileGlobal variables along with it.  Basically I am using a native step type with a step scoped variable by using attributes.  But in order to access that you need to first cast the step to a PropertyObject using the AsPropertyObject method.  Then I can access the attributes. 

In TestStand you can edit the step attributes by clicking on the attributes icon in the General settings of the step:

[bienieck]

---

@richjoh wrote:

I enter 3600 seconds for TimeInterval() Wait Step. More than an hour goes by and nothing happens. TestStand 2016 hangs there on the step. 

---

Are you sure it hangs? It is possible that Wait is waiting longer than specified - 1.5x to 2x longer to execute than the time specified in the step. See this: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAHrSAO&l=pl-PL

[richjoh]

Let me summarize and 1 other question:

Using Labview avoids the returnSecondsSinceStartup(True) problem.

All TS that uses Wait which calls returnSecondsSinceStartup() are subject to incorrect time but less likely if returnSecondsSinceStartup(False). The Report is update Dec 2017 and references MS KnowledgeBase articles that talk about OS up to Windows XP. It's 2020 at the time I write this. Looks like this issue persist.

I like Jiggawax solution to the problem. In any case, I want to set  returnSecondsSinceStartup() to False. Where in TS can I access returnSecondsSinceStartup() ? 

So it appears it is not good idea to use TS Wait(sec) for long wait times.

[~jiggawax~]

Here is a link to the help for the Seconds function: https://zone.ni.com/reference/en-XX/help/370052AA-01/tsfundamentals/infotopics/seconds/

returnSecondsSinceStartup is just a parameter to that function.  Simply use Seconds(False) to set it to false.  You have to do it for each call.  Unfortunately you can't control the one that the Wait step uses underneath the hood.  However, using my solution will mostly eliminate that.  If you need super high precision then I recommend using a code module as there is overhead associated with step looping.

Regards,

[bienieck]

---

@richjoh wrote:

So it appears it is not good idea to use TS Wait(sec) for long wait times.

---

Only if you use machines with AMD processors on Windows 2000, Windows XP, and Windows Server 2003. Given the lack of support for these systems, the good idea would be to consider switch to newer OS (but I understand that it is not always possible 🙁) - just a small remark.

If you have e.g. XP you can run the attached sequence (TS2013) to see if you have this problem. Use Locals.Wait to experiment with the wait time and Locals.ReturnSecondsSinceStartu to compare behavior of Seconds(). Remember to disable OS suspend and hibernation if you plan to test longer wait times.