Arduino in Test Instrumentation - Part 3a: LabVIEW Driver Intitialisation Block

	Open Arduino Enter Your Project for a chance to win a grand prize for the most innovative use of Arduino or a $200 shopping cart! The Birthday Special: Arduino Projects for Arduino Day! Back to The Project14 homepage	Project14 Home
		Monthly Themes
		Monthly Theme Poll

LabVIEW Driver

A LabVIEW driver is a library that allows you to program an instrument in a intuitive way. It's one layer above the instrument's SCPI interface.

There is a convention that's used by many manufactures: you should provide an init and close block, and blocks to allow to control and query your device.

I am following those conventions for the LabVIEW driver lib that I'm building for the Arduino SCPI switch.

In the next few posts I'll introduce all blocks and an example LabVIEW flow.

Let's start of with the Initialize module.

Initialize

This block sets up the communication with your Arduino UNO.

You'll see that there are a number of settings that define the behaviour of the data exchange, like serial communication settings, ports, timeouts.

There are also some behavioural settings. You can ask the device to reset at initialisation*, or if you want check the ID of the device you're talking to.

All the values that aren't dependent on the firmware are available as parameters.

The communication settings are internal. They have to match the settings that the Arduino sketch uses to initialise serial communications.

From left to right, the flow is opening the communication channel, then optionally verifying if we're talking to the right device, optionally resetting the device,

and if an error occurs, handling that.

The first block opens the communication.

The serial settings are predefined. They are firmware dependent and you don't have to edit them.

The "VISA resource name" is the communication port. This is a parameter that you set before invoking this block.

The "deal with Arduino Communication Reset" parameter is there to do what the label says . An Arduino UNO resets when you initialise serial communication with it.

There are hardware ways to modify the board so that this reset doesn't happen (but that has impact on the functionality of the Arduino IDE Serial Monitor !).

I'm assuming that the code will run on a board that isn't modded. I've added a wait time just after communication starts,  that can be configured.

On my Arduino, 1500 ms isn't long enough. 2000 ms works every time.

I haven't bothered optimising this value, because it only happens once when the instrument is initialised.

Because in a normal flow you have to initialise a number of instruments in parallel at the start of the flow, the 2 seconds are OK, comparable with many other instrument's setup time.

If you know a way to optimise this, please comment on this blog post with your approach.

The next part is a case structure.

Depending of the value of ID Quey you pass, it will either ask the device to show its ID and validate that, or it will not perform that step:

This is the flow that's executed when you select to query the device ID:

You can see in this flow that the SCPI interface is used to retrieve the device ID. In the upper left corner we're sending the *IDN? command.

This much easier flow is run if you say that the flow doesn't have to validate the device:

The next block defines what happens after establishing contact. We'll eather reset or not reset the device.

You'll see that both of these options invoke another driver block for the device.

The Reset option will call our driver's "Reset" module. The other option will call the "Default Instrument Setup" block.

I don't know yet if I will blog about those blocks. That depends on the interest.

In any case, I'll provide the LabVIEW driver lib. That 'll allow you to investigate them yourself.

This is the flow when you ask for a reset. Hint: It 'll call the *RST SCPI command.

This flow is called if you prefer to not ask a reset.

Again, this discussion is moot because a standard Arduino UNO will reset anyways.

The last block deals with error handling. Once more, there are two paths, depending on success or error.

This flow is executed on success:

Indeed, it does nothing. A sucessful flow doesn't require error handling.

When an error occured in the block, this process is executed:

We're closing the device and sending a non-initialised VISA resource to the next block.

This will prevent that the next block sends commands to our device.

*big caviat: an Arduino UNO will always hardware reset the micro controller at start of serial communication, unless you modify the PCB.