simultaneous loops at different operating speeds

[Cramer]

I have one loop that is used for data aquisition that I control the rate with a time delay, and the other loop has no delay, when I made a simple loop time indicator for that loop it claimed it was cycling every 6ms, when I would like it to be able to cycle every 1ms, the odd part was I added a 2ms time delay nad the loop still read 6ms to complete a cycle which makes me wonder if I am missing something.  I would highly appreciate any suggestions

Thank you

[Dennis_Knutson]

First, every loop should have some wait in it. Even wiring a 0 to the wait will allow other threads to execute. Second, unless you are running on a real-time OS and using Real-Time LabVIEW, your waits are going to be subject to interuptions by the OS. It's a windows/linux/mac thing that you can't avoid. So, your software timed data acquisition is not going to be very accurate or repeatable. If this is analog data you are acquiring, you should be using hardware timed acquisition instead if you want a sample every msec. If it's digital, then you can use hardware timing if the board supports it. What is the daq device you are using.

[altenbach]

Dennis is of course absolutely right.

Still, I am a bit curious about your application. Your descriptions is not clear to me:

So you have a data acquisition loop (=loop1) containing a delay and another loop (=loop2) without delay.

• Whch of the two loops are you timing? (Your description can be read either way)
• How do you measure loop time? (What is a "simple loop time indicator"?)
• How much code is in each loop?
• What is the purpose of the loop without any delay??? Since it is not data acquisition, it is difficult to imagine what could be so important that you cannot afford a delay?
• As Dennis mentioned, a loop without delay will spin multiple times before allowing other loops to get a turn. A wait statement (even 0ms) will give other loops a chance after each iteration, potentially running things a bit smoother. (see also http://ideasinwiring.blogspot.com/2005/05/55ms.html)
• If you have a newer version of LabVIEW, consider using a "timed loop", its timing will be a bit more accurate (as much as the OS allows).

[Cramer]

Sorry I wasn't clear, the loop that needs to run at a very fast rate is a control loop for a stepper motor drive (MID-7602, 4/2 axis stepper motor drive) I am using Labview 7.1, computer has a 2.8Ghz proccessor and XP 2002 OS.  The deal is I am trying to get the stepper motor drive to update the required velocity because i am trying to make a constant strain rate tensile tester.  strainrate * length = velocity, as it strains or lengthens the input length has to be recalculated to get a higher velocity.  The idea is to have this done at a fast enough rate that the actual strain of the sample is held close to a constant value.

I might add that I am a moron when it comes to anything but the basic programming logic, I have no electronic background or in depth understanding of computers, so any help in the form of suggestions to what i am trying to do or a better alternative i am all ears.

thanks

[DuffmanSays]

Cramer,

While this application sounds interesting, I think that the real issue we are dealing with is a bit more low level. What I mean is that you have some bit of code in which your loops do not run at the rates you expect. As mentioned by altenbach, you cannot guarantee loop timing on a non-RT operating system. However, if you are able to live with a non-deterministic application, then we should be able to determine why the code does not follow the expected timing. In order to do this, altenbach's additional questions are a good starting point. Namely, how is it that you are measuring loop time, and how much code is in each loop? Perhaps a screenshot of your two loops might help to clarify what it is that you are using. Thanks,

Mike D.

[altenbach]

In addition, a loop that contains hardware interaction complicates things even more. How do you communicate with the stepper motor?

There is also a documented issue that on certain CPU architectures (hyperthreading?), a 1ms wait will give you 2ms most of the time. (I don't know if this is still true with newer LabVIEW versions). See the very old discussion starting with THIS POST.