LabVIEW
Developing device driver for MKS 972B DualMag - proper error handling?
Hello!
I am recently developing for our new experimental rig, where I have a couple of instruments which do not have LabVIEW driver available, but their communication protocol is well documented. My "first victim" is the 972B DualMag sensor from MKS, and later I also want to create another driver for the MKS 937B controller.
For my recent project I do not need to use too many features of this product, so I could just "hard code" those I need right now, and it would be a short work. However, I might need more features of these devices later, and others might also find such LabVIEW driver useful, if I create one.
In order to create a proper driver and follow the official guidelines, I try to follow the steps described here: "Developing LabVIEW Plug and Play Instrument Drivers"
I created the starting project using the "Create New Instrument Driver Project" from the Tools menu, and I selected the "General purpose (message-based)" option.
I am seeking advice what would be the best error handling strategy for this device. In the following, I will refer to pages in the attached manual (Communication protocol section starts from page 10). Some important info regarding to the sensor: I did not find any option to do Error Query, so no such command, neither option to read error status registers. The device is very simple to use, from page 10 some info regarding to the command/query/response syntax:
"Query and Command Syntax
Queries return current parameter settings; commands change the parameter setting according to the value the user enters into the command syntax. Each query or command must begin with the attention character @ and end with the termination ;FF."
Command syntax for an information query: @<device address><query>?;FF Command syntax for a command: @<device address><command>!<parameter>;FF
"Response Syntax (ACK/NAK)
The ASCII characters 'ACK' or 'NAK' preface the query or command response string. The ACK sequence signifies the message was processed successfully. The NAK sequence indicates there was an error."
The response to a query or a successful command is: @<device address>ACK<data>;FF The response to a message with an error is: @<device address>NAK<NAK code>;FF
"The following list provides descriptions of the NAK codes that may be returned."
NAK Code Error description 8 Zero adjustment at too high pressure 9 Atmospheric adjustment at too low pressure 160 Unrecognized message 169 Invalid argument 172 Value out of range 175 Command/query character invalid 180 Protected setting (locked) - 195 Control setpoint enabled (ENC)
The generic "Error Query.vi" is shown here:
I wonder what would be the best way to alter this VI without changing the generic error handling idea in this generic project. My idea is the following, please comment whether this is the proper way to go, or not? Thanks! 🙂
So, whenever any of my driver VI captures a "NAK" error response instead of a proper "ACK" response, I would generate an error into the error wire right in that place, plus calling a modified "Error Query.vi" (actually I would rename it to "Error parsing") to change the NAK code into the string part of the custom instrument error, error code -1074000000. Thus this error can propagate through any other VIs, and also outside of the driver API VIs. It is up to the programmer, if she or he wants to erase/handle/etc this driver error in the calling codes.
I just finished developing the first version of the driver (find it zipped in LV2015 and LV2017 versions, project style).
I tried to follow the guidelines as much as I could, but for sure there is still large room to improve it 🙂
I implemented almost all the features of this sensor, except the Relay functions, due to the fact that my sub-model does not have relays. Otherwise I tested almost all the functions, and they work nice and reliable in my application!
Some remarks:
- I set the proper termination characters at the Init:
;FF
I give enough timeout for the VISA. Still, the device was throwing timeout errors. So I included a 100 msec wait for all the subVIs (not between the VISA Write+Read combos, but after each request; it seems the sensor "does not like" if we poll it without little waits between functions. EDIT: here is a snippet explaining this: - I managed to create a nice palette set with custom subfolders and generated the mnu files ok. However, when I back-saved the whole project into LV2015, the imported driver folder under the instr.lib lost its custom subpalette icons. Is there a proper way to migrate such project style device driver?
- Below I show some snippets and screenshots. I will also submit the driver "as it is" here: http://sine.ni.com/apps/utf8/niid_web_display.sub_driver But if someone needs this driver, just download it from here and copy it under the instr.lib folder. Note: you might need to manually add the top level mnu palette file, it did not work for me automatically, even after LV2015 restart...
Tree.vi:
