Delacor Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Manage Error Codes of DQMH module

Highlighted

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

 

 

0 Kudos
Message 1 of 8
(333 Views)
Highlighted

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.

0 Kudos
Message 2 of 8
(325 Views)
Highlighted

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



Opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
DSH Pragmatic Software Development Workshop

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 3 of 8
(280 Views)
Highlighted

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).


An opportunity to learn from experienced developers / entrepreneurs (Fab, Steve and Brian amongst them):
DSH Pragmatic Software Development Workshops
Automate the analyzing, testing, documenting, building, packaging and publishing of your projects via CI/CD:
Release Automation Tools for LabVIEW

0 Kudos
Message 4 of 8
(260 Views)
Highlighted

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... 

0 Kudos
Message 5 of 8
(230 Views)
Highlighted

@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:

 

FabiolaDelaCueva_0-1596039382543.png

FabiolaDelaCueva_1-1596039392301.png

 

FabiolaDelaCueva_2-1596039402563.png


@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



Opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
DSH Pragmatic Software Development Workshop

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Message 6 of 8
(209 Views)
Highlighted

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 😋
Olivier JOURDAN

Wovalab | Certified LabVIEW Architect | DQMH Trusted Advisor |
Message 7 of 8
(82 Views)
Highlighted


@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. 

0 Kudos
Message 8 of 8
(33 Views)