Will execution of VISA tasks with one DAQ (Dev1) in one VI block VISA tasks with the second DAQ (Dev2) in a second VI?

[phototr0pe]

Hi all,

I have two functional VIs.  One loops a set of read and write tasks with Device 1 (NI USB-6008).  The second loops a set of write tasks with Device 2 (another NI USB-6008).  VI 2 has a massively slower timescale than VI 1, meaning that it must run in a separate loop.  Otherwise, VI 2 was created by copying and modifying VI 1, and shares variable names with it (though not, for example, global variables).  Both VIs are intended to run at the same time on the same PC.

However, if VI 1 is running at the same time as VI 2, none of the read or write operations to Device 1 in VI 1 are executed---but the VISA read and write operations to a serial device do work.  Upon stopping VI 2, all the functions in VI 1 work fine.

Though I configured the channels for the tasks using the DAQmx GUI, I execute the tasks using the DAQmx read and write commands, and have properly set the "create task" and "stop task" VIs outside the beginning and end of my loop, respectively.

Does anyone have suggestions for what might be causing this?  My thoughts so far:

a. Perhaps there is some conflict in variable names in memory between the two VIs?

b. Can LabVIEW for some reason not read and write two devices from two separate VIs? 

c. Do I need to avoid using DAQmx to configure these tasks (some sort of memory conflict)?

I know I can make it all work if I combine everything into one massive VI, but for my application it is far easier and better to have them in two separate VIs.

Thanks in advance for your help!

[Albert.Geven]

They really can run in parallel

[phototr0pe]

Ok, good to know!  I will try a few things to see if I can make it work!

[phototr0pe · Accepted solution]

In case anyone was wondering, I found the solution:

When I copied the original code to a new VI, it turns out that the timed loop structures in the new VI had the same object name in LabVIEW's execution structure as the timed loop structures in the original VI.  This was effectively preventing whichever VI was executed second from executing its timed loop.  (The serial read/write contined to work because it was in a different timed loop.) 

I found this error when I ran the VI in highlight execution mode, and noticed that the "error" output on the timed loop flashed.  When I wired it into my error stream, I found error -808, which explained the problem above.

I fixed it by right clicking on the timed loop, changing it to a while loop, and then changing it back to a timed loop and reconnecting any broken wires.  LabVIEW gave the new timed loop object a new name, and all was well in the universe.

[johnsold]

You also learned that good error handling is important.

Lynn

[phototr0pe]

Yes, and that errors can be generated even by what you thought were reliable, trouble-free elements in your VI! 😉