Hello LabJack Forum,
I've searched around and can't find anyone else having the same problem in LabVIEW. I think I know where the problem exists and wanted to bring it up for discussion.
In LabVIEW any thread-unsafe DLLs must be executed in the User Interface Thread. Looking at Section 4.1.2, MultiThreaded Operation, of the U6 user guide it says "This driver is completely thread safe. With some very minor exceptions, all these functions can be called from multiple threads at the same time and the driver will keep everything straight. Because of this Add, Go, and Get must be called from the same thread for a particular set of requests/results."
In LabVIEW you either have the choice of making the DLL call execute in the User Interface thread or ANY thread.
Unfortunately the Command/Response mode uses the Add,Go,Get functions that are not thread-safe so they have to execture in the User Interface Thread. That means in LabVIEW when I'm using Command/Response mode my loop rates (and DAQ rate) are all over the place depending on how tied up the user interface is responding to user inputs.
I think I can move to stream mode with my U6 in my appplication to take advantage of the hardware timing so I won't be tied to using software timing for my DAQ rate. The reason I wasn't using stream mode to get hardware timing already is because I wanted to use the internal CJC sensor.
Is there any chance a completely thread-safe driver is on the way so I can run my U6 in command/response mode without being tied to user interface events?