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.
