Inserting points for the simulate arbitrary express vi on the front panel

[wiebe@CARYA]

---

@WillemNL wrote:

Hi, I have integrated your idea and it works great, but i have still the problem that the timing i want is not exactly the output timing. There is a time difference of about 2 seconds (measured with an external timer). That is when I have 100 S/s (samples per second). When I change that to 10S/s there is no time difference. Is there some executing limit for this? 

---

There's a limit, but it's hopefully higher then 100 S/s! Unless there are other time consuming things in the loop (inc. a wait >10 ms).

There could be something else causing this. For instance, how do you output these samples? Perhaps the hardware output is limited?

You could post an image?

[WillemNL]

Hi, Here is a image of my code. It is in dutch so my apologies for that. The purpose of the sequence is that the output value goes to zero before the vi stops. At the moment i do not have hardware attached, i use simulated hardware for now. 

[wiebe@CARYA]

Nederlands is geen problem 😁!

[wiebe@CARYA]

I think the timing in your loop is colliding with the acquisition rate. The AI loop has a 20 ms wait, and if you acquire another rate, you'll get weirdness. It's often a good idea to let the DAQ dictate the timing for as much as possible.

[WillemNL]

Haha dat is mooi makkelijk! 🙂

I removed all the other wait blocks (except for one) but i still have the problem. I already found out that it is not the limit of the program why the timing is wrong.  And I have already tried a timed-loop but i could not figure out how this works (yet). I have attached my latest version of the vi now, maybe you see something i can not see (misschien zie jij iets wat ik over het hoofd zie)

[wiebe@CARYA]

Are you sure the timing of the output data is correct? What is the output frequency? Can you be sure it's 1 ms? Or is it hardware timed? The data is 1000 Hz, so are you sure you get that output rate?

Not only can't I run the code, but I'm also not entirely sure what you are expecting, nor what you are seeing.

If I had to guess, I'd say the timing of the ramp isn't the timing you're outputting. I'd keep the timing in the loop (with a shift register, or simply take the time before the loop, and subtract that from the current time in the loop) and interpolate that on the x scale, extrapolate on y scale.

[WillemNL]

On my front panel I configure an array for time and voltage. I multiply the maximum value of time by 1000 so i get a frequency of 1000 Hz. This is my input for the ramp pattern. 

So for example my maximum value of time is 50 seconds. That means 50.000 samples. If i have a wait of 1 ms for each iteration, the total time would be 50 seconds right?   

I do not think it is a hardware issue because what i plot on the front panel is inside the vi before i write it to the task of the module. 

But when i change the frequency to 100 Hz and 10 ms wait the timing is OK. 

But with 1000 Hz and 1 ms wait the timing is wrong. 

And i do not really see how you should work with shift registers in this case, because with shift registers you insert the complete array inside the loop. 

[WillemNL]

I think you can this vi. Here you can change the frequency and waittime and see for yourself :). Try 100 Hz with 10 ms wait and 1000 Hz with 1 ms wait. 

[WillemNL]

I think i found the problem:  https://forums.ni.com/t5/LabVIEW/Real-Time-maximum-loop-speeds/m-p/3690007

[wiebe@CARYA]

Yes, 1ms timing is tricky (not really possible in Windows). But...

I'd think your hardware is capable of setting a 1D array on the output?  1kHz isn't the problem, the problem is the 1 ms timing. A (slightly less then) 100 ms per 100 points would probably work. Then the hardware would be timing the rate, you only need to supply new chunks (before it runs out).

Also, if you send the sample corresponding to that time, on a per-point basis, that would also work. The output wouldn't be smooth, but the overall timing would be correct.

I'd prefer the first solution.