Generating Custom errors without using Labview error cluster

[HaRiNaraYanan]

I have a requirement of generating custom system level errors for highlighting error conditions to the user of the application. These errors are generated across different VIs in my application and are intended only for user notification. I merely display these errors to the user and not react on that. Unlike LV errors, these errors do not in any way affect the application functioning.

In my previous project, I had used hard-coded strings. But they were difficult to maintain due to issues like

- Same error code with different error messages.

- Different error codes with same error message.

- Inability to trace all errors.

- Export all errors to a file (If I want to create a error table for user manual, it was always manual work of going to each subVI and copying all the constant strings.)

I tried to use the LabVIEW error code editor and Gpower error and warning tool-set but both of them were using LV error cluster to propagate the errors. This will not work in my case because the errors I generate are just notifications. I do not want to stop other LV blocks from executing when this custom error is generated.

Is there any way to do this in a way that can be scalable and maintainable and also when I want to export out as a file, I can do it easily.

[FireFist-Redhawk]

---

@HaRiNaraYanan wrote:

I tried to use the LabVIEW error code editor and Gpower error and warning tool-set but both of them were using LV error cluster to propagate the errors. This will not work in my case because the errors I generate are just notifications. I do not want to stop other LV blocks from executing when this custom error is generated.

---

Any dialog that comes up is going to be blocking unless you call it asynchronously or have it in its own loop. In general, if you get an error, want to display it, but don't want your code to stop running, you could just clear the error in your "error handler" state of your VI and call the simple/general error handler asynchronously.

[cbutcher]

It's not exactly clear which bit of the problem you're facing is your problem, but you could consider using "Warnings" rather than "Errors".

These won't trigger an Error Case and so they can slip by unnoticed if you're not careful (which is a good reason not to use them... but you can consider it).

If you want to try and tie a code to a message, you could consider having each module (or clump of VIs, library, class - whatever was a suitable grouping for you) define an "Inject Error.vi" or similar and convert an enum (defined via typedef in the module) into a message or similar, or popup a dialog (if that's what you wanted - that should be 'shared' code via a subVI etc so you don't have to code it repeatedly for every module).

Then you could use VI scripting to find all "Inject Error.vi" (or "Inject <something> Error.vi") VIs and read the value of the enum in a control on the Connector Pane for documentation generation.

[HaRiNaraYanan]

Yes, that's one way of doing it. But I do not want to clear out errors. I may miss out on the application level LV errors which would occur which i want to find out before building the application. 

[cbutcher]

I guess I still don't really know what your requirements are, but perhaps a globally available queue (see spoiler) and either a string or enum (in the simple case) or an object (with enclosed code, description, timestamp, whatever you wanted) as the datatype might meet your needs?

You could have a single dequeuer which "notified the user" when an 'error' occurs, in whatever manner suited your application (popup, status bar string, etc).

Spoiler

Globally available named queues are another potentially dubious practice, but you can at least mitigate this by using a public accessor VI and a privately scoped queue reference, perhaps stored in a FGV with a randomly generated name on first call (see e.g. How to Generate a MessageID/GUID/UUID With LabVIEW? or Google for alternative VIs/solutions, or just create a random number and format to a string appropriately).

[HaRiNaraYanan]

---

@cbutcher wrote:

It's not exactly clear which bit of the problem you're facing is your problem, but you could consider using "Warnings" rather than "Errors".

These won't trigger an Error Case and so they can slip by unnoticed if you're not careful (which is a good reason not to use them... but you can consider it).

Exactly for the said reason, I do not want to use warnings.

To give more context, I generate these custom error messages primarily (but not limited to) when

1. Process related errors occur e.g test invalid or input parameters incorrect (just to notify to the user)

2. LV error occurs, instead of showing LV message, i provide a generic more understandable error message to the user like software error/file missing.

As a developer for me to figure out the error, I have unique 4-character alphanumeric error codes followed by the error description. The first two characters indicate the module where the error occurred and the next two are numbers. e.g. "Error DB02 - Invalid field entry error" would mean that the error has occurred in the database module and description gives me an idea as to what has triggered that error.

My main requirement is that instead of hard-coding each of these messages in a string constant i would like to have some way of making this more maintainable, so that I can reuse it in different parts of my application / different project.

So, I tried one way where in I create a custom typedef cluster (like the labview error cluster) in which I have three elements,

1. An error type (typedef enum) with 3 entries i.e. error, warning, no error

2. Error category (typedef combo box) which will indicate the module where the error occurs (I use this to get the first two characters for the error code)

3. Error description (non-typedef enum) where I have multiple error message descriptions (I used the values for the error code digits which will make them unique)

I will have one "Get notification VI" which will format the cluster input as a string "Error DB02: Invalid file parameters"

My idea was that I will create a copy of this cluster for every module and then add the error messages for that module in the non-typedef enum. Can this be done in a better way?

I am attaching a sample demo VI (LV2014). Pls check it out.

[FireFist-Redhawk]

---

@HaRiNaraYanan wrote:

Yes, that's one way of doing it. But I do not want to clear out errors. I may miss out on the application level LV errors which would occur which i want to find out before building the application. 

---

If this was a response to my suggestion, you wouldn't be clearing all errors, only the custom ones that you have created for your use case.

[HaRiNaraYanan]

---

@FireFist-Redhawk wrote:

---

@HaRiNaraYanan wrote:

Yes, that's one way of doing it. But I do not want to clear out errors. I may miss out on the application level LV errors which would occur which i want to find out before building the application. 

---

If this was a response to my suggestion, you wouldn't be clearing all errors, only the custom ones that you have created for your use case.

---

Got it. I could implement a logic for clearing only my custom errors. But it would make things a lot easier if there is a way to just display them and forget (like i did with earlier with hard coded strings). Only need here is to make those strings reusable across VIs.

[billko]

Under Tools --> Advanced there is an option to edit error codes.  This will lead you to a dialog that walks you through creating your own error codes and saving them to a file that LabVIEW loads when it first boots up.  In fact, this is how NI adds their own error codes for drivers and stuff not included with basic LabVIEW.  It's klunky, to say the least, but it might be what you are after.