07-29-2009 03:13 AM
I want to check that a signal has the good value within 100ms after an input change.
Consider the step1 (or sequence1) which made the input change, and step2 (or sequence2) which return the signal value to check
How can I do with TestStand V4.1 ? Is it possible to work with small timing as 100ms ?
Thanks for your help.
07-29-2009 08:05 AM
I'm a newbie so I don't claim to have the best answer but here is one possible idea that I have come up with.
Make step2 a custom step type with a PreStep substep that calls some external module (in the supported language of your choice) to simply wait 100 ms or a variable amount of time. You can pass the PreStep substep a parameter (I think) and use a local variable or step property to indicate how long to wait. Then when step2 is executed the PreStep substep is called first. It waits the specified time and then the actual step executes.
In the case of sequence2 executing 100 ms after sequence1, you would probably have to use a step at the beginning of sequence2 that simply waited the specified amount of time.
This is just one way. I would be interested in knowing if TestStand has a built-in mechanism. I think it would be a selling feature. I'd also be interested in hearing from more experience folks, as well.
07-29-2009 10:10 AM - edited 07-29-2009 10:12 AM
I'm not sure why you would need a custom step type?
You can do this in TestStand or in your code module. Some tools teststand has for timing are:
1) the Seconds() expression function. Returns the number of elapsed seconds. It is based on the
QueryPerformanceCounter API, so it should have resolution on the order of microseconds or better.
2) The Synchronization>>Wait step type. You can specify how long to wait. The time you specify is a minimum. The actual wait time might be slightly longer depending on your cpu load.
The time it takes to execute a step can be less than 0.1ms, depending on the computer, the step settings, and the module called, so 100ms timing for two steps is not difficult.
Just remember that if you are doing timing in software, Windows is a non-real-time OS. Thus you can never be sure how long it will take to do anything. You might usually be able to execute two particular steps in 0.2ms, but occasionally, it might take 10s because Windows decides it needed to think about something else at just the wrong time. Therefore, when timing matters, you must measure the time and handle any timing violations. For example, in your case you might repeat the measurement in question if the required timing isn't obtained.