How to avoid repeated start/stop task?

[fomine]

To test collisions - open an additional copy of the !SDIO-NI.vi, and run them both at the same time. You will see no problems.

[Dennis_Knutson]

I don't have the time to get into an arguement about collisions. You asked about not calling start and stop task so many times. You either keep them in the subVI where they will be called over and over again or move them to a higher level where they won't.

[fomine]

I have moved the create start and clear task into !SDIO-NI2.vi
Now I get -200288 ot -200547 depending on whether I enable or disable autostart in DAQ Write.vi

What am I doing wrong?

Also, we have to remember, in the real-life application, SDIO will not be called continuously in the loop, it will be called from time to time at random intervals.

Thanks,

Evgeny

[Nathan_R]

Hi fomine,

You are getting the -200547 error because you try to start the task without any data written to the buffer and the task never starts. Then you try to write to the buffer multiple times without the task started and you receive the error -200547. When you turn on auto-start the task starts at the first call of DAQmx write but you receive error -200288 at each successive call because you are doing a finite output and are trying to write more samples than the finite output is set to handle. The only way to reset a finite sample digital output so that you can output more samples is to stop and start the task.

The only way to do this without starting and stopping the task is to use a continuous sample digital output with regeneration turned off. Normally, with regeneration turned on, when the hardware reaches the end of the buffer it starts outputting at the beginning again. With regeneration turned off you have to keep feeding data to the buffer. If the hardware reaches the end of the buffer and has outputted all available data the task will error because regeneration is off and it does not know what to output next. When you do not have data to output you will have to keep feeding the buffer all zeros so that it does not run out of samples and error. A good example of this type of task can be found in the Cont Write Dig Port-Ext Clk-Non Regeneration.vi example VI. This VI can be found by going to the Help menu and selecting Find Examples.... Once the NI Example Finder is open select Hardware Input and Output»DAQmx»Digital Generation»Cont Write Dig Port-Ext Clk-Non Regeneration.vi. Let me know if this helps you.

Thanks,

[fomine]

Now this one is a good idea!
Nathan, please take a look at the attached VIs - is this what you mean?
Top-level GUIs (like !SDIO-NI3.vi) will call SDIO-NI3.vi. On the first occurence, SDIO will create tasks, write first set of data and start DO loop.vi. It will then provide DO loop with all zeroes. On consecutive calls it will update data in DO loop.vi, wait till it is generated, rewrite the data with zeroes.
Questions:
1) On consecutive SDIOs, how do I avoid glitching if there will be any?
2) How do I know that it is time to write all zeroes after sending the SDIO data?
3) Why do I get -200290 inside the loop of DO loop.vo while !SDIO-NI3.vi runs, and it becomes -200429, when !SDIO-NI3.vi finishes?
4) How to fix these errors 😉

Thanks a lot, I'm looking forward to your answer!

[Nathan_R]

Hi fomine,

I’m not sure what you mean by glitching. Can you be any more specific about your concerns with this? I would not have the DAQmx write in a separate VI like DO_loop.vi, because it is going to be very hard to know for sure that the data passed to DO_loop.vi is only used once. It would try keeping the DAQmx write in the SDIO vi. Once you have called a write with your data you can go back to writing zeros, but since DO_loop is running independently of SDIO it is going to be hard to know when this has happened.

Error -200290 means that the hardware has reached the end of the buffer and has nothing to output since regeneration is turned off. To fix this I would try increasing your buffer size. You are only storing 34 samples at each DAQmx write call. This is not very many if you are trying to output at 100kHz. It will be hard for your program to keep the new data in the buffer with such a small write size. Error -200429 is caused by passing an empty string into a task/channels control. I’m not sure what is causing this on your end because I was not able to recreate the error running your VIs. Also you can look up explanations of errors in LabVIEW by going to the Help menu and selecting Explain Errors… Then just type in the error code that you want a description of.

Let me know if I can be of any more help.

Thanks,

[fomine]

Hi Nathan,

Thanks for your reply!
You say "It would try keeping the DAQmx write in the SDIO vi. Once you have called a write with your data you can go back to writing zeros"
Could you please demonstrate how to do it? I don't see the way to implement it 😞

Thank you very much again,

fomine

[J_Thomas]

Hi fomine,

It sounds like what you are really getting after is to continuously reconfigure a non regenerating waveform.   This example program is for an analog output waveform, but could be modified to use a counter to clock a digital output.

DAQmx - Continuous Reconfigurable Waveform Generation Using Non-Regeneration

One suggestion would be to use a shared variable or functional global to continuously update the data being sent to the digital write.

[fomine]

Hi J-Thomas,
In brief, I need to develop a sub-vi that will be called from many independent top-level GUIs. This sub-vi will be responsible for generating digital output (provided by top-level GUI) at a user-defined frequency. The traditional approach (as can be found in examples) - to create counter and DO tasks, generate the DO, and clear the tasks, takes ~50msec. It is HUGE overhead for the DO that lasts only 0.1msec! In certain conditions I need to send hundreds, even thousands of the digital waveforms per second, sometimes, on the other hand, there are 5-minutes idle cycles.
The idea as proposed by Nathan is to have DO running at all times, generating zeroes when not in use, and generating waveforms requested when called. This way there'll ne no overhead on creating/starting/stopping/clearing the tasks.
I just don't readily see how to implement such approach....
Please give me a hand on it!

Thanks,

fomine

[J_Thomas]

If you are really concerned about speed, you should look at using a  High Speed Digital Input/Output board like the PCI-6561.  With these types of boards the digital waveforms are configured in hardware and can be controlled quite easily through software or hardware triggers.  It would be simple to program these type of devices to behave as you are suggested.  Overhead would be a non issue.

To use the 6229, Nathan’s idea is a good one.  I can’t think of a better way to approach the problem.  It seems like the only missing piece is a way to send data to the DO Loop and a way to know when the data has been written.  For this reason I suggested using a functional global (or perhaps a shared variable) to tell the DO loop which data to write.  As far as reading back the data you could use a DAQmx property node.  For example, I believe there is a DAQmx Write property node called CurrWritePos which returns a numeric value representing how many samples have been written.

Have you made any progress on the VIs that you have previously posted?  Are you still getting error messages?