« Close

Datasheets and User Guides

App Notes

Software & Driver

 

3 - Operation

The following sections discuss command/response mode and stream mode.

Command/response mode is where communication is initiated by a command from the host which is followed by a response from the LabJack.  Command/response is generally used at 1000 scans/second or slower and is generally simpler than stream mode. 

Stream mode is a continuous hardware-timed input mode where a list of channels is scanned at a specified scan rate. The scan rate specifies the interval between the beginning of each scan. The samples within each scan are acquired as fast as possible.  As samples are collected automatically by the LabJack, they are placed in a  buffer on the LabJack, until retrieved by the host.  Stream mode is generally used at 10 scans/second or faster.

Command/response mode is generally best for minimum-latency applications such as feedback control.  By latency here we mean the time from when a reading is acquired to when it is available in the host software.  A reading or group of readings can be acquired in times on the order of a millisecond.

Stream mode is generally best for maximum-throughput applications where latency is not so important.  Data is acquired very fast, but to sustain the fast rates it must be buffered and moved from the LabJack to the host in large chunks.  For example, a typical stream application might set up the LabJack to acquire a single analog input at 50,000 samples/second.  The LabJack moves this data to the host in chunks of 25 samples each.  The Windows UD driver moves data from the USB host memory to the UD driver memory in chunks of 2000 samples.  The user application might read data from the UD driver memory once a second in a chunk of 50,000 samples.  The computer has no problem retrieving, processing, and storing, 50k samples once per second, but it could not do that with a single sample 50k times per second.

 

2 comments

You have an example LabVIEW vi that controls one Labjack, but do you have an example to control two?

 

Thanks,

K Braswell

Test Equipment Design

McGregor Surmount

With multiple devices you open a handle to each one, and then the particular handle you pass to subsequent sub-vis determines which device is talked to.  See "Multiple U3 EFunction Loop Example.vi".  Note that this example has 2 parallel dataflow paths in the loop (one for each U3), so you don't know the order in which the U3s are talked to.  If you want to control the order of execution more, use the error cluster wired in series to control dataflow.