LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

running from front panel vs block diagram

Running my vi from the run button in the block diagram, everything is ok.
Using the run button from the front panel delivers error. How can that be?
Is the functionality of the vi dependent on whether you will "run" it from the block diagram or front panel?
0 Kudos
Message 1 of 6
(3,399 Views)

It shouldn't make any difference whether you click run from the diagram or front panel. What is the error code that you are getting?

In another post of yours, you were using LabVIEW 7.1. Is that still true? Can you post your VI?

0 Kudos
Message 2 of 6
(3,386 Views)

Labview 7.1, indeed.

The error is : Error -200279 occurred at DAQmx Read (Analog 1D Wfm NChan NSamp).vi

Attaching also the vi. Just have in mind that i have physically connected the output directly to the input channel.

Running from the block diagram, always ok. Running from the front panel sometimes ok but most of the times delivers error.

 

thanks in advance.

0 Kudos
Message 3 of 6
(3,371 Views)

I got the error when I started it from the block diagram and the front panel. The reason for the error is your Wait Until Next ms Multiple. You've set the DAQ Read for continuous acquisition but then pause the transfer with the wait. Eliminate the wait statement and the error goes away.

You also want to move the Start Task in the AO chain to outside the for loop and before the DAQmx Write.

0 Kudos
Message 4 of 6
(3,351 Views)
Eliminating the Wait Until Next ms Multiple and placing the Daqmx Start Task vi outside the loop before DAQmx Write,doesn't fix the "run from front panel or block diagram" problem. If after doing these, you could run without error, i must concider problem with or inefficiency of my PC. Can you suspect of anything else?
 
On the other hand, the idea for my vi is that i would like  two things: 1. a non-stop sine output and 2. a timed input so that i could acquire my waveform (sine) and save my amplitude values periodically. That was  actually the purpose of the Wait Until Next ms Multiple vi, timing the loop.
Placing the Start Task where you suggested, creates some kind of asynchronization, because on the saved file there are many zero values occuring. And this has to do simply with the input channel trying to read while the output does not give out samples.
0 Kudos
Message 5 of 6
(3,321 Views)

You seem to have a contradictory setup. You can change the number of samples read by the DAQmx Read. Currently, you have it set to -1 which is to read all samples in the buffer and with any delays, you are going to get that error message because you can't read the buffer continuously. Putting a wait statement does not do anything for synching the ao and ai and I don't understand why you would get zero values in the DAQmx Read. The analog output is set for continuous so I think it should always be generating a signal. Having the Start Task inside the loop and the DAQmx Write set to autostart may be the cause but I'm not sure.

Also, if you want to periodically write, you might want to do that in a different loop and pass data with a queue.

0 Kudos
Message 6 of 6
(3,296 Views)