Coordination of library error codes in top level applications.

[David_Grucza]

First the background: I'm writing a LabVIEW wrapper library for a dll that is used to control one of my company's products. The dll functions return an unsigned integer error code which I use to generate a LabVIEW error cluster. I can translate these codes into a range reserved for user error codes, but the problem with this is that other libraries could be using the same codes. After speaking with a LabVIEW AE it seems that NI has not included a scheme for dealing with this aspect of error handling in 3rd party driver development (Please let me know if I am wrong about this). I ended up creating a functional global that holds a base value to translate the returned dll codes by. This allows library users to move the codes from each library to a unique range (If they do set a base, a default value is returned).

What I'd like NI to do: It would be valuable if NI were to develop a documented scheme for coordinating library error codes in a calling application so that library developers have a model to follow. If what I've done is reasonable it would be good if NI includes VI's in the library template for setting the error base for a library. Also, in order to be able to right-click an error indicator and show error details it is necessary to create an XML file (I forget where this lives) containing error codes and the desired explanations of the errors. This works fine for fixed codes, but if a base is changed the values in the file will need to be changed. I can do this programmatically inside of my Set/Get Error Base functional global, but it would be much easier if LabVIEW had a VI for doing this. I think there is a wizard for creating the XML files, but I haven't found it yet and I don't know if it has an API.

For LabVIEW to be useful for robust applications there really must be a way of programmatically identifying errors uniquely, but this requires coordinated effort among library developers. If NI has not addressed this, hopefully they will.

[David_Grucza]

After creating an error code file I've found that it cannot be changed programatically because LabVIEW only reads the error code files when it starts. So even though I can allow App Developers to change the error codes associated with a library when initializing an App, I cannot change the codes for error messages that get reported when "Explain Errors" is selected. Explain Errors is really only useful in the development environment, so developers would have to stay with the default base while troubleshooting their systems. I think NI needs to come up with a better system, perhaps giving a library an Error Code Base property, and maybe even a place to put error codes and explanations in the .lvlib file.

[AristosQueue (NI)]

Ah, error codes. What follows is something of a brain dump, so keep plodding through the paragraphs and see if anything in here helps you out. Believe it or not, I do discuss your idea eventually. 😉

First of all, the General Error Handler and Explain Error dialogs are perfectly happy if the same error code has multiple definitions. The description field will list all of them. NI began having the same problem that you are having 11 years ago. Since then, we have untangled most of our products by having a universal error registry -- the only remaining overlap is between 50 or so error codes of LabVIEW and GPIB because both products are so deeply entrenched, so error code 2 is both "out of memory" and some GPIB failure. But because of that, the system is designed to handle overlaps in the error code text files. If your library happens to return the same error code as some other library, that's ok insofar as anyone reading the error translation will see your description in the list of possible reasons. In general, that's fine because the source of the error is known and that makes it relatively straightforward to determine which error message is the one for this situation. Ideal? Obviously not, but it is how the system works (keep reading... I will address your idea directly, I promise).

An error code cluster can include more than just the location of the error in its "source" string. It can also include the text description of the error, overriding what's in the error code database for that particular error cluster. Use the "Error Cluster From Error Code.vi", found in the palettes, and wire the "message" terminal to build one of these error clusters. This gives you a mechanism, if you want, to force a particular description to be shown.

That brings me to your idea (you thought I'd forgotten, right?). I do not believe a system for remapping error codes dynamically would be generally useful because programmers can access the code portion of the error code cluster directly, without any guarantee of going through any sort of translation layer. A translation layer built into the General Error Handler wouldn't have any effect on user code that is filtering an error or otherwise reacting to a particular error code. In other words, while it is fine to do various tricks to translate the error code at the moment that it is displayed as a string, it would be bad for a library to actually return different error codes every time it is executed because the programmer using that library may not account for that translation when checking the error code in their VIs.

The best idea, in my opinion, to fixing this, is to take away direct access to the error code, forcing users to go through some sort of access function. Let's see... what feature of LabVIEW behaves just like a cluster but keeps its data private except through accessor VIs? Ah... LabVIEW classes. It's a drum I've been beating on for a while now. If you'd like to help my campaign to replace the error code cluster with an error object, which would allow us to directly tackle problems like the one you're having, please tell your local Field Sales Engineer and comment on the forums and spread the word through your local LV user groups. At the moment, it isn't seen by most people as a significant enough issue to incur the disruption of migrating the primitive functions of LabVIEW. But that's my personal soapbox and I'll get off it now and get back to solutions that might help you today...

You are correct that you cannot programmatically update the error code database, as you noted in your comment. You can, however, supply error code translations dynamically by wiring them into any particular call to General Error Handler.vi (GEH). If you do implement your own dynamic error code allocation scheme for your own applications, using the GEH gives you a way to provide the dynamic translation of those error codes. No, it won't help the Explain Errors dialog in the menus. You'll have to add your own menu item and route it to your own GEH call.

All of the above should be helpful (if not necessarily a full solution) for your needs as long as your library of VIs is meant for distribution within your own organization. If your library is meant for distribution to the LabVIEW community generally, I can offer you one solution: if you join the NI Partner's Program, you can ask to have your own range reserved in the universal NI error code database. You can contact labviewpartnerprogram@ni.com if you are interested in such access.

I hope some of that was helpful. Ultimately, though, my summary is that I'm against your proposed solution given the current design of errors in LabVIEW.

[SteveChandler]

@AQ ""The best idea, in my opinion, to fixing this, is to take away direct access to the error code, forcing users to go through some sort of access function. Let's see... what feature of LabVIEW behaves just like a cluster but keeps its data private except through accessor VIs? Ah... LabVIEW classes. It's a drum I've been beating on for a while now. If you'd like to help my campaign to replace the error code cluster with an error object, which would allow us to directly tackle problems like the one you're having, please tell your local Field Sales Engineer and comment on the forums and spread the word through your local LV user groups. At the moment, it isn't seen by most people as a significant enough issue to incur the disruption of migrating the primitive functions of LabVIEW. But that's my personal soapbox and I'll get off it now and get back to solutions that might help you today...""

You should post an idea here!

There is something I have often pondered. I know that xcontrols are intended for displaying data but I have tried to think of a use for them as a replacement for the error cluster controls. I have not come up with anything that could not be done in a cleaner and more efficient way using other methods. Everything I come up with is too Rube Goldberg. But there is this itching in the back of my brain that tells me it could be useful.

It seems very obvious to replace the error handling with a class! But first you have to implement this idea

[David_Grucza]

@Aristos :

First, thanks for adding to this discussion. All I really want to do is to get someone at NI to address this. I want my company’s customers (very engineer, not programmer centric) to be able to write robust software with LabVIEW that they can include in products. Deployed software must be able to resolve problems with a minimum of user input, and at least must be able to give users concise instructions for how to resolve problems. I don’t see that LabVIEW is up to this task.

Now, some comments:

- Registering Error Codes is not reliable because anyone can use any error code they like. No one is checking and enforcing the assignments.

- I think your objection is really the point I want to make. The translation is not built into the general error handler. The error code is being translated inside the library and is never available outside of the library untranslated. Yes, users can always edit the library to expose the untranslated error codes, but you can always hack a library, class based or not. I don’t see that registering error codes is effective, and would add overhead most library developers would deal with. By letting them label their errors 1 thru N and building application developer translation into the libraries you give developers a relatively easy way to send unique error codes.

- Classes have been very slow to gain traction with almost all LabVIEW developers. I use OOP in everything I write, but the LabVIEW OOP programmer pool is very shallow.

Also, something I wanted to add: Beyond identifying errors, it is useful to know which piece of hardware generated the error because multiple pieces of hardware can be using the same driver library. I’ll likely add a reference (as a string) or something like the VISA alias to the error cluster source string surrounded by a delimiter. I realize that you can usually poll, but in a complex system this is unreliable. Again, NI has to decide on a standard way to handle this so that application developers don’t have to figure it out for every library.

[David_Grucza]

Just had time to play around with error clusters some more. I didn't realize that the Source field is displayed as XML. This makes it easy to include library specific information. But as with everything it would be good to document some standard practices so library users know what to look for, and library developers know what to include.

[David_Grucza]

@Steve

Your "this idea" seems to be an end-run around OOP Data Hiding. I'm considering a class's identity as implicit class data that should not be exposed outside of the class. Dynamic Overiding should be used to carry out actions appropriate to the particular class.

[AristosQueue (NI)]

> I didn't realize that the Source field is displayed as XML.

It isn't really. There's just two delimiters handled by the GEH: <err> and <append>. These can't be called tags... they're never closed. The former replaces the error code database. The latter appends to the text in the database. It also supports <b> </b> tags for boldface, but no other formatting.

[David_Grucza]

Shows how little I know about XML! I saw the <> and the </> and assumed it was.

BTW: I like the your idea od an error class. I just don't think there would be much interest by LabVIEW programmers given the resistance I've found to OOP. But providing Property and Invoke nodes for an error class would certainly be better than bundling and unbundling a cluster. How would you transition? You'd have to leave the error cluster in place for backward compatibility, and somehow phase in the class. I know NI can make drastic changes and have them propagated backwards, since you control the entire environment though.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

[David_Grucza]

I've realized that this is not a good idea. It is overly complicated. This scheme belongs at the application level, if anywhere. I suspect that the SEH from the NI Architects group is a better way to go.