I have problem with compiled VI: after 422 seconds run VI stopped without any error message.
If I close VI: message - VI reset, NI-DAQ-USB box is busy - can not restart VI.
Restart machine- USB Box founded - VI start - the same problem.
Labview 8.6 and 8.6.1 Base with Application Builder, NI-DAQmx 8.7, NI USB-6211
the problem is not depends on version (8.6/8.6.1) and run mode (in Labview/standalone EXE)
VI contains 2 DAQ-Assistent for reading and writing data from USB-Box.
Samples rate:1000 Hz, No of samples:100
Signal output: Sinusoid with frequenz 0 Hz..200 Hz
By 20 Hz - OK, By 200 Hz - failure.
Can you post your code? It appears that something triggers a stop of the code. Which kind of sounds like a counter but this is a wild guess. We would need to see the code to give appropriate advice.
VI contains Periodic Trigger from OpenG
VI hangs up, NI USB Box is busy - only after system restart can be used.
The main question: sampling rate=? and samples to read=? by output frequenz = 180 Hz.
IMHO this is the main problem.
P.S. my thread in german:
You will need to design your VI in a much better way. I cannot pinpoint the problem right now but you will be getting race conditions, synchronization problems and user interface errors if you run this VI.
1) Use a producer/consumer architecture (events) for saving and loading your data
2) Use event structures to communicate with the controls on your front panel.
3) Place your DAQ assistants for input and output in separate loops.
4) Use queues as buffers (again producer/consumer) to take care of the analysis part after the data is acquired.
I would recommend that you go through event structures in LabVIEW Help and have a look at the producer/consumer templates for data and events. These can be found when you navigate to File -> New...
If you have any questions, be sure to let us know.
>2) Use event structures to communicate with the controls on your front panel.
In Base version there is no event structure.
Is there alternative in OpenG or another free libraries?
okay... understood. Now your post makes sense..
Maybe a State Machine with producer/consumer architecture may be your solution.