Rif.: Manage Error Codes of DQMH module

[Konan__]

How do you usually do this?

If I have a module "A" with error codes from 5000 to 5100, and another module with error codes from 5000 to 5100 ?

I noticed that in the error handling part of the template, there is the "Module Name" so I can say which module error 5000 belong to.

But I can't figure out how to manage these errors on the deployed computer. I usually deploy all in the same folder.

Do you use an XML file (with "NI style" error codes) with all the codes of a module and you load it at startup? does it work? is it recognized by general error handler?

I dont want to use "installer deploy error codes", I prefer something in local folder, alongside the main exe of my application. 

I can imagine having a error code file for every module (that would be easy to translate too)

thanks

[Konan__]

I made a quick test using the Tools -> Advance -> Edit Error Codes

this seems neat but if you create 2 files with the same error code inside, you are screwed because the General Error Handler will display BOTH errors.

It's neat that you can create a file with all error codes and messages of a module. This file will be placed in \user.lib\errors

and it will be automatically loaded at labview startup (at least on development machine, I still dont know what happens on production machine, I will test if these files can be placed along with exe).

We are forced to use "general error handler" because inside there are the db calls to all NI errors.

At the same time this is not so "general" because it merges all errors in one central place, that's a bad design architecture.

[FabiolaDelaCueva]

Hi Konan,

I am afraid this is one of those that there are as many answers as there are architects!

For DQMH, we have the --error.vi in the modules. We put there the DQMH related errors and we have a range associated with them. 

The way we do it at Delacor, is we assign a range for each module and use the --error.vi to keep track of the errors for each module. We can extract the error codes for reports, etc, using scripting by looking for all the VIs that have the --error.vi.

We moved away from using the error file because of things like the one you discovered about reporting all errors. We prefer to use the error ring and provide relevant information related to where an error occurred. Check out the --error.vi that are added for your DQMH modules.

I am curious to see what others suggest.

Thanks,

Fab

[joerg.hampel]

I can add that I've tried lots of different things in the past, none of them proved to be a silver bullet though.

Nowadays, we do like constant VIs, also for errors, just as Fab says. We maintain a document where we keep track of error code ranges.

What I personally don't like about error rings is the fact that you cannot easily search - i.e. through LabVIEW's default search dialogue - for the error codes you specify inside the ring (see this idea).

[Konan__]

thanks for the follow up

1----

What is the difference between the "Error cluster from error code" and "Error Ring" with custom error code?
I noticed that the latter builds up on the internal database of installed errors families + all the additional error codes files installed in user.lib (you can define ModuleX--errors.txt, ModuleY--errors.txt, etc...)

2----

Why do you create multiple VIs just for constants.... instead of concentrate all error numbers in 1 single VI for the entire module?

I think I will explore a bit more the Joerg Hampel solution, I noticed that the error ranges are quite large.

To fix the collisions issues, I will explore a custom error handler window

It's obvious that collisions of error codes will happen: everyone will start his library ranges with 5000 or 500000, so imagine something like "github", you pull in my library, boom... 

[FabiolaDelaCueva]

---

@Konan__ wrote:

What is the difference between the "Error cluster from error code" and "Error Ring" with custom error code?
I noticed that the latter builds up on the internal database of installed errors families + all the additional error codes files installed in user.lib (you can define ModuleX--errors.txt, ModuleY--errors.txt, etc...)

On the error ring scroll down to the Custom error codes, you can add your custom error code but more importantly, you can use string formatting and create new inputs, this allows you to give timely information on your error. Here is an example:

---

@Konan__ wrote:

Why do you create multiple VIs just for constants.... instead of concentrate all error numbers in 1 single VI for the entire module?

One major reason: "Find all instances". With an error VI, I can right-click on the VI on the project and find callers. I can right-click on the icon and find all instances. Most of the time, while I am debugging, I want to find the places where a certain error occurs.

Another reason is the additional information we can add to the error like the example above.

I hope that helps.

Regards,

Fab

[Olivier-JOURDAN]

I take the opportunity of this thread about error code management to:

• Agree with Fab and Joerg's answers
• Remind that I posted an idea about an error scripting tool that could help managing and listing module's errors 😋

[Konan__]

---

---

@Konan__ wrote:

Why do you create multiple VIs just for constants.... instead of concentrate all error numbers in 1 single VI for the entire module?

One major reason: "Find all instances". With an error VI, I can right-click on the VI on the project and find callers. I can right-click on the icon and find all instances. Most of the time, while I am debugging, I want to find the places where a certain error occurs.

Another reason is the additional information we can add to the error like the example above.

I hope that helps.

Regards,

Fab

---

Do you maintain a document will all error codes to avoid clashes?

With "Error VIs", the developer doesn't think about error codes, but error semantic.

Example: in the block diagram , I place a "Timeout---error.vi" or "Output1---error.vi", and I dont know that inside they have 500123, or 5123 error code.

So a central document is needed, unless one develop a custom solution like "error classters" of Dimitry. 

I figured out I am re-doing what he's doing.

Some years ago I asked if error cluster could be a class, but the idea was rejected. 

[Konan__]

@fabiola

another question on the topic

why

"Delacor_lib_QMH_Error Handler - Event Handling Loop.vi"

and

"Delacor_lib_QMH_Error Handler - Message Handling Loop.vi"

??

inside they are the same. Does it mean we should customize it? when?

I dont understand the rationale of this

[joerg.hampel]

The reason for having two separate Error Handler VIs for EHL and MHL is, as you say, to let you more easily extend them with your own, project-specific logic if you need to. 

As for the if and when, that depends on your needs. Maybe some extended filtering, maybe sending messages to different places...