|
In this 4th post in this Program the Device series I develop a Virtual Instrument Initialize block.
I'm designing LabVIEW Virual Instrument blocks (Init, Close, basic Read and Write, and some advanced blocks to set and get favourite values, e.g. Set Freq, Get Freq, Set Waveform, ...) |
Initialize block design
In the draft flow that I made in post 2 and 3, I put raw DLL calls on the canvas of my functional flow. That was the easiest way to test if things work: an unstructured prototype.
I now know that the approach works. Time to split the example up into reusable blocks. Blocks that use the typical LabVIEW VI pattern.
The functionality of this first block is identical to what happens on the proto. I'll explain that first.
But I morphed the return status handling in the standard LabVIEW error handling process. This is covered at the end of this post.
The block diagram is very similar to what we saw before:
The dll function is uci_Open(). Its setup and use has been reviewed in post #2.
The inputs are exactly the same:
- connectstring: optional, defaults to the one that matches my instrument
- timeout in: optional, defaults to 6000 ms - the default value used by the UCI api.
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: handle to the UCI session.
Used by the functional blocks downstream. Needs to be closed by the (to be written) Close block. Invalid in case of error. - timeout out: a pass-through of the input value. Can be used downstream if you settle for a single wait throughout your process.
In a design, this is how you'd use this:
In the next posts, you'll see that also the downstream flow will be turned in to the functional blocks.
Error block design
This first iteration of the driver build is a good time to introduce a first utility block: handling UCI api errors.
The dll uses return values to report success and failure. In LabVIEW, this is commonly done with their specific error handling mechanisms.
What this error block does, is check if an api error occurred.
If yes, it generates a custom error (-8999, in the custom error range of LabVIEW), with the dll error code provided in the text.
In the example below, the device USB cable wasn't connected.
Snippet of the text message reference. You'll find error -1060 back:
image: snippet of UCI api help document
The next blocks are going to be similar. I'll take the prototype steps and turn them in reusable components.
While doing that, I'll allow for additional functionality, like choosing the instrument channel, ...
Related blog:
