Elapsed Time Problem

[Slurpee23]

Hello. I have a technical lab question that I was hoping someone could help me with.

One of the subs (Elapsed Time) in my system is acting strange. For some reason it is not running deterministically at sampling rates above 4 Hz. I've attached a simplified VI using this sub. I need to
run my system at 50 Hz, which should run with a "dt" of 0.02 seconds. But it actually runs at different rates (see for yourself). But at 4 Hz, it correctly runs at a "dt" of 0.25 seconds. I don't understand what is wrong and how to fix this problem. Any ideas? Thoughts?

Thank you in advance. Any help would be much appreciated.

[ceties]

You didn't attach the second VI.

[Chris_Cilino]

Slurpee23,

Since you've used the word "deterministically", we assume you're using LabVIEW RT and an RT OS. Is that correct? If you aren't using an RT OS, such as windows, then determinism is a bad word. It doesn't exist in Windows.

Chris C

[Slurpee23]

There is no second VI. You can adjust the sampling rate by entering 4 Hz ot 50 Hz on the front panel then hit reset.

So Windows cannot run a simple program like this deterministically? Even in simulation? When I am using this in a control system, its important to have deterministic "dt"s but I do not have LabView RT. Is there an evaluation version available?

Thanks.

[Dennis_Knutson]

You didn't include the subVI called 'Untitled 3'.

About the best you could do with windows would be the timed loop. It has 1msec resolution. It won't guarantee that the rate will be met but it will tell you if it's late.

[Slurpee23]

I will try to implement that. There has to be another method to tell the loop to run at a specific rate dt. The untitled3.vi was simply the Elapsed Time subVI. I've attached a new one.

[altenbach]

OK, here are two versions:

1. using a plain loop
2. using a timed loop

The timed loop is pretty good, even at high loop rates. Of course, as others have said, these things are not fully deterministic under a multipurpose OS. 😉

[Slurpee23]

Yes. I like the Test_loopMOD_Timed.vi. It seems to be quite stable. I'm not a big fan of the spikes, but I will implement it into my control system to see what type of effect it has. Thanks.

[Chris_Cilino]

Slurpee23,

The reason why windows isn't a deterministic environment is that the OS has to share the CPU with multiple processes. For example, if you have your while loop running and then decide to open up Internet Explorer, Windows has to share the CPU so that the Explorer can open. Consequently, your while loop will probably take longer to execute. The only way to get around this is to run on a real time operating system. There is no evaluation version of LabVIEW RT but you can find out more information about it here.

Something to bear in mind before making the investment is what is the maximum jitter you can afford in your program. In other words, what's the largest spike in execution time you're willing to tolerate? If we're talking (+)10-100ms then Windows will probably work fine for you. If you need absolute reliability, windows probably won't cut it for you.

Another option is to change the priority that the VI is running at. This can be done through the VI properties under the execution category. If you set the priority to "time critical" you'll notice that your jitter will be decreased, however, you may completely lock up your computer such that you'll have to preform a hard reboot to get control back.

Post to let us know if you have other questions.

Chris C

[Slurpee23]

Alright guys. I have a new related issue. Now that my "dt" is somewhat stabilized, I'm trying to record some sample data by writing to a file. I've attached the files. Just hit save to save the data to a text file. Now, when you open it in notepad or excel, you will notice that the actual "dt" does not match up with the calculated. Its very inconsistant. Any ideas?

Thanks.