Read block design

Read a setting from the instrument.

In post #2 I used the raw uci_ReadX() api call. This block does the same, and transforms the dll errors into LabVIEW errors.

The inputs are the same:

• session in: handle to an open device session
• timeout in

The outputs have one signal less. The DLL error handling is no longer a status you have to check for.
It's encapsulated and becomes part of the error signal. It's separately handled in the Error block that I describe below.

• session out: a pass-through of to the UCI session. 
• data out: the raw 8 bit 
• timeout out: a pass-through of the input value.

In a design, this is how you'd use this (The double out block will be documented in the next post, but you can see how it works in post #2):

All rp@ calls return a 8 bit array that represents a double.
Some other calls (such as IDN? that returns a 54 char string) return a different output.

Write block design

Change a setting on the instrument.

In post #2 I used the raw uci_WriteSimple() api call. This block does the same, and transforms the dll errors into LabVIEW errors.

The inputs are the same:

• session in: handle to an open device session
• command string that includes channel, parameter and value, all correctly formatted please
• timeout in

The outputs have one signal less. The DLL error handling is no longer a status you have to check for.
It's encapsulated and becomes part of the error signal. It's separately handled in the Error block that I describe below.

• session out: a pass-through of to the UCI session.
• timeout out: a pass-through of the input value.

In a design, this is how you'd use this:

Close block design

Close the active instrument session, close all handles and release memory.
Call this at the end of your flow, to allow other programs to use the instrument.

In post #2 I used the raw uci_Close() api call. This block does the same, and transforms the dll errors into LabVIEW errors.

The input is the same:

• session in: handle to an open device session

In a design, this is how you'd use this:

What you can see in each of these blocks, is that I was able to reuse the dll-to-LabVIEW error handling block in all of my new blocks.
This is an efficiency booster during design and test. Once that block is known to work correctly, you can just rely on it and save brain space.

Here's a flow that uses all of these blocks:

Next post: the high level functional blocks that know how to talk to a channel and understand the instrument's registers.

Related blog: