Veristand Alarm Trip Time

[kevin.key]

Hey,

I'm wondering if there is a way to obtain the time an alarm was tripped in a procedure. Maybe there is an easy way that I'm missing, but I'd like to be able to compare the time between two alarms being tripped.

Thanks for the help,

Kevin Key

[kevin.key]

I've found the System Channel, System Time, but it seems like System Time does not reflect a real time, and perhaps thats something to do with the way I've set things up.

If I add a Numeric Indicator Meter, and compare the time passed to the time passed on my stop watch it's not even close. The system time is passing way slower than the time on my stop watch.

Thanks for any help,

Kevin Key

[Jarrod_S.]

System Time refers to the ideal relative time of the system according to the specified rate of the Primary Control Loop. If the Primary Control Loop runs on a real-time target and is never late, then this time should correspond more closely with a wall clock time. On Windows, you can't get deterministic execution, and the Primary Control Loop is often interrupted by other processes, causing its time to get behind.

[kevin.key]

The Primary Control loop does run on a real-time target, but is innaccurate. However when I play with the Primary Control loop rate it seems to become accurate. What exactly am I doing when I change the primary control loop rate?

[Jarrod_S.]

The Primary Control Loop rate is the rate at which the VeriStand Engine samples the I/O and runs any models. So if the rate is 100Hz, the engine acquires HW inputs, ticks the models and produces HW outputs 100 times a second.

If the VeriStand Engine runs on Windows, there are a number of factors that can keep it from running deterministically and at the rate you specified. Windows itself is not a real-time OS, so there are plenty of other operations in the system that can interrupt the Primary Control Loop. This includes things like the Workspace execution as well as other programs in your system, like the virus scanner or whatever.

When you slow down the Primary Control Loop rate, it becomes much more likely that the Primary Control Loop can execute in the desired time. As you increase the loop rate, it will be late more often, which skews the system time.

[kevin.key]

On my Real-time target I am using the Labview RT OS. I deploy my system to the RT target and open the workspace on my PC to interact with it.

So because I have to open the Workspace on my PC it causes the RT to run non-deterministically?

[StephenB · Accepted solution]

If your system time is wrong and you're running on an RT target that likely means your system is unable to maintain the loop rate you requested. Check the actual loop rate, hp count, lp count, and model count channels. If your loop rate desired is reasonable for your hardware, Something in your configuration is likely taking too long to execute. Could be a model, custom device, etc. If that is the case, an execution trace using the real time trace toolkit could be useful. The addon to accomplish this is on the addons page of ni.com/veristand

[kevin.key]

I had a Custom Device that was taking too long to execute, but now I fixed it and now everything works perfect.