Re : Re: Re : Re: loop speed too slow for a regulation on the fly

[sylvian]

Hi all,

As you can see attached, I have a loop, which is regulating the parameters of a PWM (in live). The duration of the regulation is around 4 ms, and I would like to have a resolution of 0.1 ms. I currently have a loop speed of 500 loops/sec, so 2 ms per loop (20 times bigger than what I want).

How can I know if my loop is running as fast as it can ? Is there a way to increase the loop speed (except to change my computer 😉 ?

Many thanks in advance for your reply,

Best regards,

Sylvian

[Norbert_B]

Sylvian,

are you working on a Windows system? If so, i would say you are one of the boldest developer i've ever heared of.

This is because Windows itself is not capable to keep a timing of lets say 2ms in 100% of the time. Due to system services, there will be increases at a few loop iterations to more than 10-50 ms. This is called jitter.

A Real-Time system reduces the jitter a great deal, but still it is there (normaly less than us!)

If you need more precise timing, FPGA will be your friend..... 

hope this helps,

Norbert 

[Edit] Using Windows, LabVIEW sets the lowest selectable time frame to 1ms. Less would not make any sense, even 1ms is no garantee.  So you could either set the timing to 1kHz or as fast as your system can.

Message Edited by Norbert B on 04-30-2009 10:02 AM

[sylvian]

Hi Norbert,

Thanks for your answer. If I get it well, I have no chance to reach a rate of 10 kHz only because I use Windows ?? And what if I use Linux ? Does LabView run on Linux ?

Cheers,

Sylvian

[altenbach]

Plain LabVIEW runs on Windows, Mac, and linux. None will be suitable for your purpose.

As Norbert already said, you need LabVIEW RT or LabVIEW FPGA and corrresponding hardware.

btw, what is PMW? Do you mean PWM?

Your code seems flawed because there are possibilities of race conditions. For example you write and read to a local variable (duty cycle) in the inner loop in parallel. Unfortunately, it is not possible to tell what occurs first. Actually, a lot of your code does not make much sense. Could you add some diagram comments?

[sylvian]

Thanks for your remarks Altenbach. I attach with my post my modified diagram.

Huu.. I don't know where you saw PMW.. But it is actually PWM.

And I guess that these two modules are not include with the full version of LV ?

Sylvian

[Ben]

---

Norbert B wrote:

Sylvian,

are you working on a Windows system? If so, i would say you are one of the boldest developer i've ever heared of.

...Norbert 

...

---

Under LV 7.1 I ran multiple hardware clocked timed loop at 2KHz with any "Finished late"s.

I would not use it to control nay life threatening apps but it was fine for acquiring data.

Ben

[altenbach]

---

sylvian wrote:

And I guess that these two modules are not include with the full version of LV ?

---

No, they are extra.

See, now you got rid of the race condition and you can delete the inner 2-frame sequence because correct execution order is fully determined by dataflow. 🙂

I also don't quite understand your use of the express VI. Why do you collect two samples if you actually only use one value later? Carrying dynamic data across several operations seems a bit overkill for a single scalar DBL. 😉

I don't have any DAQ installed here, so I cannot look at most of your code, but what determines the loop rate of the inner loop?

[sylvian]

I collect 2 samples because if I put 1 on that entry, it gives me an error.

And I tried to replace the DAQ Assistant by a DAQ Read, to see if it would work faster. It did, but once I place a filter on the signal, it came back to 1400 Hz, which is really not sufficient to make a regulation (as already said we need ~5000 Hz to do it). So we arrived at the same point that the one mentionned above : impossible to do anything faster than ~ 1kHz in that configuration. :'-(

[Wayne.C]

sylvian,

If you open up the DAQ assistant and set the Acquisition Mode to 1 Sample ( On Demand ) for the Acquisition Mode,  it will only take one sample each time.

[Norbert_B]

Sylvian,

i would expect something about 1-2kHz for this. The PC could get faster (maybe up to something 10nish kHz), but there is no promise in it. If you need to control things, you normally need deterministic timing. Every non-realtime OS does not supply determinism (that means Windows, Linux, MacOS). Please note that there are "real time" Linux systems available (and they maybe are determinstic), but they are not supported by LV, that means, it could work there, but you will not get any help from NI if not.

If you would control heating systems for e.g. living rooms, i'd say go for windows, because cycle times are usually in x seconds, where x >= 1. But not in your case.

@Ben: yeah, external clocksource is a fine stuff to do this. But as you already stated, i wouldn't do this if you need 100% security.....

 hope this helps,

Norbert