Keps Posted December 7, 2010 Report Share Posted December 7, 2010 I have an executable application that is running on an XP netbook. It is controlling a USB DAQ device from NI (don't have the model number off hand). It is attempting to do things in 10s of milliseconds and the timing, as you might expect is terrible. I understand that but, the timing is too short! This I don't understand at all. It is effectively setting some digital channels to one state for 200ms, changing the state after another 300ms and repeating this over and over again. The timing is all over the place but averages about 60% of what it is programmed from. Any idea how bad timing winds up shortening these intervals? I am using the wait ms multiple function. Any help, advice etc. would be greatly appreciated. Quote Link to comment
crossrulz Posted December 7, 2010 Report Share Posted December 7, 2010 (edited) I'm not sure I fully understand the problem. Posting some code would help the debug process. From my current understanding, it sounds like the Wait (ms) would be the function you want. The Wait Until Next ms Multiple function will sit there until the ms counter reaches a multiple of the programed value. So the first loop you set to 200ms. The Wait Until Next ms Multiple will sit there until the counter reaches 200. Next loop, you set the loop rate to 75. The Wait Until Next ms Multiple will sit there until the counter hits 225. So then you really only had a 25ms loop. Check out this snippet as an example. Note: You may have an output clock value off by 1ms due to Windows timing. Edited December 7, 2010 by crossrulz Quote Link to comment
Keps Posted December 7, 2010 Author Report Share Posted December 7, 2010 Here is the code. It steps through a few array values in each for loop, the first one totaling 200ms and the second 300. The result is timing that sometimes resembles the programmed values, but it is usually much shorter than the 500ms total. I'm not sure I fully understand the problem. Posting some code would help the debug process. From my current understanding, it sounds like the Wait (ms) would be the function you want. The Wait Until Next ms Multiple function will sit there until the ms counter reaches a multiple of the programed value. So the first loop you set to 200ms. The Wait Until Next ms Multiple will sit there until the counter reaches 200. Next loop, you set the loop rate to 75. The Wait Until Next ms Multiple will sit there until the counter hits 225. So then you really only had a 25ms loop. Check out this snippet as an example. Note: You may have an output clock value off by 1ms due to Windows timing. Quote Link to comment
SuperS_5 Posted December 9, 2010 Report Share Posted December 9, 2010 Hi, I am not quite following the desired outcome, but still have something to add. Deterministic timimg on a PC can be difficult. I expect around 100ms interupts to occur every now and then. If 100ms is long compared to total execution time, the system will become non-determainistic. I am guessing that this jitter is causing your problems. Quote Link to comment
crossrulz Posted December 9, 2010 Report Share Posted December 9, 2010 (edited) Here is the code. It steps through a few array values in each for loop, the first one totaling 200ms and the second 300. The result is timing that sometimes resembles the programmed values, but it is usually much shorter than the 500ms total. Yep, you are using the wrong wait. On an aesthetic note, instead of using the sequence structure, you might want to consider using a VI like this for the wait. I admit that I took this function from the Bloomy's LabVIEW Style Book and then edited it a little. It uses the error cluster to keep data flow instead of using the sequence structure. It helps keep my code clean. And if you haven't already, vote up this idea in the Idea Exchange. Wait.vi Edited December 9, 2010 by crossrulz Quote Link to comment
Keps Posted December 9, 2010 Author Report Share Posted December 9, 2010 Thanks for the advice and the vi. It was the wait ms function that I needed. I know it won't be deterministic in windows but it was just terrible. I still don't quite understand when the timer was starting on the wait ms multiple since the timer in the second loop started after the first ended. Anyway it is well behaved now, within the constraints of windows. I like the wait.vi and would use it, but this code is not mine and time is of the essence here. Quote Link to comment
crossrulz Posted December 9, 2010 Report Share Posted December 9, 2010 I still don't quite understand when the timer was starting on the wait ms multiple since the timer in the second loop started after the first ended. See my first post. The Wait ms Multiple doesn't wait for the desired number of ms. I waits until the ms counter (a global counter) reaches a multiple of the input. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.