I'm a LabJack newb, but long-time user of LabVIEW. I'll be using two U3s, and I plan to use a queued state machine for my overall program.
After initializing (opening) the U3 handles, I will put the Add-Go-Get subVI in its own state. I am trying to decide the relative advantages of the Parallel vs Loops examples. The Parallel one will not actually execute in parallel. In fact, it may not even execute in the same order, every time. The Loops one might take longer, but I'm not entirely sure, nor do I know that it will matter, in my application.
Unrelated: I know this shows up in all the examples, but I haven't yet figured out why. What is the (-chan)^2 be fed into the "Value Write" input of the first eGetS command?
Thanks
No speed advantage is expected with either technique. You are correct that you don't know the order of execution of the 2 eAddGoGet calls in "Multiple U3 with Multiple AIN Parallel.vi", but you do know that you will get 1 run of each per loop, unlike the confusing situation where someone makes 2 seperate loops with nothing special to sync the loops.
Similar to the "Parallel" example is "Multiple U3 Efunction Loop Example.vi". A very simple way to work with multiple devices.
The "Multiple U3 with Multiple AIN Loops.vi" example is pretty slick, and lends itself well to bigger programs, but the concept of an array of handles can be a little daunting for some. In your case, I would think this technique would be excellent.
One unique LabVIEW problem to avoid, is discrete Add or Go or Get calls, on the same handle, in parallel. You can get a situation where you think you doing a particular sequence of Add/Go/Get calls, but for example another Add is called during that same time and is thrown into that sequence. This can be avoided with proper dataflow and other execution sync techniques, but also by not using discrete Add/Go/Get calls in these types of programs which means use eAddGoGet, eGet, and other e-functions.