09-19-2012 03:01 AM
hi Stefan,
after looking at your example, I think this method works fine for signal generation which periodical only, am I correct?
I mean, if I'm generating ramp signal, with t_delay & t_ramp are controllable by the user, I might have different step numbers in 1 buffer time.
For example; I'm generating 100 steps ramp for 1 second, and my buffer time = 0,1 sec.
If I have t_delay=0sec, means my first buffer would be full with 10 first steps of my 100 steps ramp (0,1sec).
But if I stop the VI execution, and now I would have t_delay=0,01sec, means my first buffer would be consist of 0,01sec delay and 0,09sec ramp (which is only 9 steps).
Or maybe if I would have 0,005sec delay, means my first buffer would be consist of 0,005sec delay and 0,095sec ramp (which is 9,5steps).
Do you see the problem there? I think my challenge is to keep my splitted ramp connected accurately, so I can write my ramp precisely.
regards,
Yan.
09-20-2012 08:46 AM
Hi Yan,
you should not change rate and number of steps "on the fly".
You only can change Loop rate / number of samples if you stop the task - and this way you will get all the windows jitter stuff you did not want.
If you want to have slower output changes, just fill the card with the same number of samples per time, but do not change the samples if you do not want.
Have a great day,
Stefan
09-21-2012 08:29 AM
hi Stefan,
I'm not trying to change the rate or step numbers "on the fly", what I'm saying, that I generate one ramp signal (with delay), done (means VI stop). Then I change my parameter (delay, step numbers), then generate new ramp. If I may ask, can you please modify the VI that I attached (in 1st post), so that I can implement it into your VI suggestion (example). Would be very appreciated.
regards,
Yan.
09-21-2012 10:07 AM
Hi Yan,
where are your difficulties in adding your VI?
Have a nice weekend!
Stefan