line macro equivalent in labview

[Steve_Block]

I'm trying to be able to identify the location of any errors that occur, when they occur. These errors might occur for any number of reasons after the software is released in its final configuration. Since multiple instances of the same vi can be used, I need to know the file and location where the error flag is set. A grid based location would be useful.

[LV_Pro]

Writing an error logger sub-vi that reports the call chain to the offending vi  is probably the way to go. Salt these througout your code then if an error occurs it logs which vi caused it. As mentioned in an exe there isn't a diagram, so I don't know how a "grid system" would work. As there are a finite number of "things" that should cause errors in an exe (file read/writes, instrument read/writes, etc.) the error logger should narrow down where the problem occured.

[Steve_Block]

In labwindows I'm able to use the _Line_ macro. There is even a way to do this in .net, so there should be a way to also do this in labview. Even if it means creating the block diagram in the executable.

[Ben]

---

@Steve Block wrote:

In labwindows I'm able to use the _Line_ macro. There is even a way to do this in .net, so there should be a way to also do this in labview. Even if it means creating the block diagram in the executable.

---

LabVIEW is data dependant and is not "line oriented" so lines have no meaning in LV. What you want to know is the detials of the error and which call instance was involved. This image illustrates how I do this.

 

The blue sub-VI with a rocket ship caution logo and scroll image launch the back ground task responcible for logging events. It alos registers for an event so that the user can bring up the Event Logger GUI when they want to check for errors.

Once the even logger is running it just wathes for new error and logs thenm to file. What gets logged is Time/date error code, The text that goes with the error and a call chain so I can locate the exact location of the error when reviewing the logs.

The actuall errors are reported when the boolean is true when passed to the "Post Event" VI ( Blue with caution and scroll).

Using this event logging approach my customers can call me after the fact and after a review of the log I can often tell them exactly what went wrong and why.

THe other developers I work with love this and claim that it has saved them many times.

So forget about line numbers, you really want a call chain.

And just in-case that was not enough...

Not shown in the example above is the un-used inputs to the Event Logger which are "Who" "What" "Where" When" and "Why". When I originally developed this utitlity (back in LV 6i) I thought those extra inputs would be helpful. It turned out the extra info was redundant and aded extra work on my part to wire up.

Just trying to help,

Ben

[Steve_Block]

I understand that labview is not line oriented, however, a grid location would suffice for a location.

[Ben]

---

@Steve Block wrote:

I understand that labview is not line oriented, however, a grid location would suffice for a location.

---

Then see above where I talked about manually declaring the grid location. It is possible to import images into the BD (see my image above) so create a jpg of a grid and drop in the BD.

Question:

Where did the requirement of a grid location come from?

Still trying to help,

Ben

[smercurio_fc]

I would still like to know how doing any of this will help, given that, as stated before, the block diagram is removed when an application is built.

[Ben]

---

@smercurio_fc wrote:

I would still like to know how doing any of this will help, given that, as stated before, the block diagram is removed when an application is built.

---

I could understand how the location in the diagram could be helpful if the diagram is very large and contains many un-related operations. The indexes would let someone go back to the source code and locate where the error was declared. On smaller diagrams the indexing would be of little use.

Ben

[smercurio_fc]

---

@Ben wrote:

---

@smercurio_fc wrote:

I would still like to know how doing any of this will help, given that, as stated before, the block diagram is removed when an application is built.

---

I could understand how the location in the diagram could be helpful if the diagram is very large and contains many un-related operations. The indexes would let someone go back to the source code and locate where the error was declared. On smaller diagrams the indexing would be of little use.

Ben

---

I'm not debating that it could be of use, but it's somewhat irrelevant if there's no block diagram to access in a built application, and the OP stated it has to work in a built application as well.

[Ben]

Sometimes I just can't help myself when it comes to solving riddles.

A grid of wires could be dropped on the diagram each originating ata constant for collumn and row. Error reporting would just tie to the closest horizontal verticle wires.

It would make a bad diagram worse but it would be a fully and complete answer to the stated requirements.

And you you wanted to get fancy, make the horizontal and verticle wires classes and customize the wire to look like dotted lines.

Ben