LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to debug an error occurring 'at Wire of the block diagram of "XYZ.vi" '

Hi,

 

this is most mysterious to me. See the attached picture of the error message coming from LabVIEW.

 

The program does not throw an error number, as you can see. Nor does it let me debug the exact occurrence location of the error because it pops up just when entering the VI. I have no clue as to how to determine the cause of such an error. Of course, the error itself is known as Error 1...

 

LabVIEW version: 2011 SP1 x64

OS: Windows 7 Home Premium x64

 

Any ideas?

0 Kudos
Message 1 of 9
(2,750 Views)

Is the subVI inlined (wildely guessing here....)? What are it's inputs and what are the values of these inputs?

0 Kudos
Message 2 of 9
(2,731 Views)

Found something out about that. One main input wire into the "BildAufnahme (SubVI).vi" is a Strict TypeDef. When I changed from this to a normal TypeDef, the program would execute normally. I would be happy about any comments on this.

0 Kudos
Message 3 of 9
(2,724 Views)

No SubVI-Inlining. "time-critical priority" is activated, other than that, nothing special about the execution tab of the VI properties.

0 Kudos
Message 4 of 9
(2,723 Views)

Sorry for triple post. The inputs are error cluster and the notorious TypeDef, as attached below.

0 Kudos
Message 5 of 9
(2,716 Views)

Dear comrade

I think that can be your solution:
http://digital.ni.com/public.nsf/allkb/D3E32C4C60BF627486256CB4006D861C

Best regards
Robert

0 Kudos
Message 6 of 9
(2,617 Views)

Thanks for posting this KB link. As I understand it, storing a refnum in a global variable or an FGV is rather "dangerous" and difficult to live with. I never knew that.

 

In fact, my program does use some globals (no refnums here!) and indeed one FGV which incidently stores a file refnum. However, creating and repeatedly retrieving this file reference throughout the entire Testbed software works perfectly as far as I am aware of - I use it to make debug log entries into a text file. I've attached a snippet and the needed VIs in an llb to illustrate the use. This approach saved me the hassle of transferring the logfile refnum in to each and every VI via wires and SubVI connectors (or wiring a "master TypeDef" to all VIs, from which the refnum is extracted using "unbundle by name").

 

So now I am unsure whether I understood the error cause that is explained in your linked KB article: Yes, I do store a reference in an FGV. Yes, there must be a state sometime in the program's workflow where this reference is unused - at least I don't deliberately make sure that there is always at least one instance of the LogActionEngine.vi held open and used. So according to the KB, this should throw me the offending error sometime. But it doesn't ! Now I am confused...

 

Also:

Since the error this thread is about has disappeared so far, even after switching back to the strict TypeDef-version and the program has evolved ever since it's hard to tell, what could have been the cause of error from this current state of the LabVIEW code.

Download All
0 Kudos
Message 7 of 9
(2,611 Views)

Is it possible that you post an example code that creates the error?

Normaly there is no problem using a refnum in a FGV.

0 Kudos
Message 8 of 9
(2,577 Views)

As I just stated:

"Since the error this thread is about has disappeared so far, even after switching back to the strict TypeDef-version and the program has evolved ever since it's hard to tell, what could have been the cause of error from this current state of the LabVIEW code."

 

No chance anymore. But concerning  references stored in FGVs usually don't pose a problem - the KB article you linked to says something different on this matter.

 

I think we can consider this topic closed, as I can't be of any more help in order for anyone to get to the bottom of this business. The error doesn't show up anymore. I was only hoping someone came across a common pitfall in LabVIEW programming where this error usually occurs. Always strive to improve, you know...

 

Thanks @all

0 Kudos
Message 9 of 9
(2,568 Views)