Get rid of the delays caused by Serial instruments in your LabVIEW based ATS

Equipment manufacturers often make LabVIEW “drivers” available for download on their website. Those tend to be a very good starting point to quickly communicate with their equipment to change setpoints and readback measurements but they are often Application Programming Interface (API). However, many of those calls tend to be “blocking” (Send command, Wait, Read results) to be easier to use by the programmer at the expense of the end user’s test plan.

This is especially true for Serial Instruments (COM port): with 2 or 3 of those instruments, a standard application with sequential execution can be reduced to 1Hz or slower due to the long wait time in between commands.

The solution to this is making sure that all this code executes in different threads. This is what we consider as “Symplify™ drivers”. This typically requires more development but the existing core libraries within our platform makes this operation very easy. The interface (or API) to each driver becomes specific Tags which allows proper encapsulation and protection of their “private data”.

Those drivers can then leverage the manufacturer’s VI  and LabVIEW will make sure that other code can be executed during long wait periods in between commands (or while waiting for a measurement.)

Each VI can also presents a simple User Interface which exposes many more options available from the instruments but were not exposed to the user.

There are higher quality drivers such as NI DAQmx. A lot of the work completed by those drivers is actually done in the background rather than sequentially when the VIs are called. This is pretty much the same concept that we are presenting here and it is one of the many benefits of using NI hardware and drivers. NI invests a lot of time and effort to make sure that the driver support high throughput, low-latency and offer very meaningful information upon a software exception.

The image below demonstrate how a Power Supply driver running in its own thread within a Symplify™ application can free up to 50% of available CPU time that would normally be lost if the communication with the power supply was done sequentially with other actions such as datalogging and supervisory functions.