DEVICE DRIVERS
LABVIEW

(LabView is a product of National Instruments Corporation) 

This page shows a LabView program that reads the temperature. There are new drivers now and the so the LabView functions look different from what is shown below. There are also more error handling options. The new drivers are available for the Model 5C7-001, 5C7-002, and other controllers. To see how you might code using the new drivers click here.

Read Temperature.vi

Here is the Front Panel with an ActiveX control and a Thermometer.

You can use the context sensitive menu to configure the Thermometer to show the digital value. You also use the context sensitive menu to change the precision of the displayed digital value from a default of 0 (zero) to a 1 (one).

The vi diagram looks like this . . .

Notice that the default representation of the Thermometer reading is a Double floating point number. By using the context sensitive menu you can change that to single, and that will then match the value provided by the driver and the oi7_readTemperature function.

Click here to Download the Read Temperature.vi as a self-extracting zip file. Download to an empty directory and then launch the program "Read_Temperature_vi_100.EXE". It will self-extract "Read Temperature.vi". Note: This will not load into the new version of LabView as is. Follow the instructions below and use LabView help to enter the code manually.

Note: The above is configured for the Model 5C7-362 Temperature Controller. When you change the type of controller you  need to re-initialize, in a sense, the Invoke Node items. This may also be true if you are just using a newer version of the device drivers or LabView. Here is what you should try. (These instructions are for LabView 8.2. In older versions of LabView you may have to find other menu selections that allow you to do the same thing.)

1) Load the VI into LabView.

2) If you are not using the "kajei_oi736_visa" device driver (see the upper left of the above diagram), use the associated Automation Refnum's context sensitive menu and select to "Select ActiveX Class..." and then "Browse" Use the "Type Library" drop box to select the appropriate Kajei driver. Select the driver object and click OK.

3) Now change the "modelNumber" value of the first Invoke Node (oi7_sessionOpen) from "5C7-362" to the model number of your controller.

4) Now, in turn, right click on each Invoke Node and select "Select Method..." from the context sensitive menu and when the dialog box is displayed just click OK.

Now you should be able to run the program.

To write a program similar to the one above with the kajei driver, you start with the Front Panel.

You add a kajei driver by following the LabView Help instructions under ActiveX, Calling an ActiveX Object from LabView.

To include the driver, choose ActiveX from the Controls palette.

You will be shown a sub-pallette from which you can choose the Automation Refnum and place it on the Front Panel.

Choose Window->View Diagram to see the diagram page. The LabView Help instruction tell you how to select the ActiveX driver.

For the Model 5C7-362 controller select "kajei_oi736_visa" as the driver. You will then be able to select either "kajei_oi7" or "kernel". Select "kajei_oi7". This contains the functions that pertain to the Model 5C7-362 controller.

You then start adding the other controls you need in accordance with LabView's Help instructions.

Note that you use Automation Open to link LabView to the driver, and Automation Close when you are done with the driver. Automation Close will remove the driver from memory.

Note that you use oi7_sessionOpen to open a session to the controller. In the above case I used COM1 ("ASRL1::INSTR") as the communications port.

The main body of the program is next, and all we did above was read the temperature and send the value to the thermometer.

When you are finished with the conteroller, use oi7_sessionClose to tell VISA you are done with the port.

Q: Is the "error out" parameter implemented?

FIRST ANSWER

Apparently the error out indicates if LabView itself had some error in performing the function. It is not the same as the error generated by the driver.

Not being familiar with LabView, I can only hazard a guess as to how this should be handled. I think my initial approach would be to create a separate vi for error processing. After each function call I would pump the LabView error and the function call error into this vi. If there is no error I would pass the no error code (0) to the next object, otherwise I might warn the user and redirect the program flow elsewhere.

I do the same thing in Visual Basic. I perform the function and if there is a Visual Basic run time error I go to one error handling routine, but if not then I look at the returned error code of the function and handle that as necessary. This is standard error processing when using the NI style function calls, but I do not know enough about the graphical programming environment of LabView to visualize it.

Private Sub ReadTemperature

 On Error Goto RunTimeError

 erc = itTEC_readTemperatureSetPoint(1, temperature) 
 If erc <> 0 Then 
   Msgbox "Could not read the temperature." 
 Else 
   MyTemperature.Text = temperature 
 End If 
 Exit Sub

RunTimeError: 
   Msgbox "Non-fatal run time error in the ReadTemperature procedure."

End Sub

SECOND ANSWER

It seemed to me that the help files for LabView were implying that you should encapsulate the driver in a separate vi and use LabView's special properties' objects to create a vi that has the functions you need. This centralizes access to the driver's functionality and centralizes function call error handling, and I believe it can be used to merge function call handling errors with the vi object error, so that the error output of the vi is just the standard LabView error out connection.

Again, I do something similar in Visual Basic for ThermalMGR by using a particular function to centralize driver functionality and error handling. It does not really take more work to do it this way. Actually, it reduces the programming overhead as time goes on.

THIRD ANSWER

I believe the function error is as specified by National Instruments. That is: "erc=FunctionCall()". Which hopefully means NI has a white paper or general write up on error handling which takes into account this "preferred" method of calling a function.