Asynchronous VI Run : Get explicit error message when VI is broken ...

[manu.NET]

Hello,

In many of my applications i had to run dynamic assynchronous VIs using a VI path.

When the VI you want to launch has some problems (VI broken, missing ressources, ... ) you get the generic error 1003. (The VI you want to launch may be broken ... ? )

This error can be easily solved when you are using LabVIEW IDE. 

But sometimes, this error can occured in an executable you have deployed to your final user computer.

And then, the error 1003 (The VI you try to call may be broken ... ) is a little bit poor in order to analyse the problem.

This error occurs, for example, when the dynamic VI tryes to access missing DLL's.

It would be nice, if the error 1003 message, could be filled out with and additionnal "error description", giving more informations about the error source.

For example, an error list, like the error list in the LabVIEW IDE. (Broken arrow error list !)

Thanks a lot.

Manu.

[StephenB]

Kudos. There is a hidden property node called linker errors I use sometimes to debug these errors but this whole experience needs improvement

[SteenSchmidt]

Mega-kudos!

Errors due to code breaking in the runtime environ while being fine in the dev environ are heavy to debug. Usually they stem from missing dependencies, like dlls as you mention or code optimization done during the build-process (libs being stripped of some member functions, or public/private scope being changed due to a poly-VI getting replaced with its instance etc.).

There are also similar errors during the build process which needs enhanced error explanations. Some just throw a dialog with a single number in them, like 200222, and no further text. Others throw an ABB-proxy something error that doesn't mean anything if you can't find an internal NI doc mentioning it.

/Steen

[AristosQueue (NI)]

Can't you attach a remote debugging session from the IDE and get these answers? We have developers trying to reduce the size of the runtime engine (RTE) and bloating it back up with debug information seems like the wrong way to go. Even making this functionality a separately loadable DLL would still add it to the overall install size of the RTE. Is there something that keeps you from using remote debugging to diagnose these cases?

[manu.NET]

Hello AristosQueue,

Most of the time, the final users didn't have any IDE installed on their target computers.

So remote debuging the final application is not possible ! 

And, also, we cannot have access to these computers using remote access due to network protection strategies. 

The only way to debug is for us, to go to the final user, and trying to solve the problem, step by step ... in a blind debug mode !!! 

In textual langages, C#, VB.net,Java, when the final application is generated in debug mode, and not obfuscated ... the exception thrown by third party code let you easily point to the origin of the problem. (With a standard runtime)

I have understand your answer ... the functionnality to get the real error message is in the IDE not in the Runtime.

=> Thats why i have posted the Idea ! => Give us the ability to get detailled error !

=> If a 1003 error is raised, it would be nice to be abble to call a tool which could analyse the detailled error source !

     An addon tool would be nice ! 

For some of my applications, i really need these fonctionnality : I have build an application, where final users can insert their own dynamic VI's. (Like pluggins or callbacks) => These VIs are launched by Assynchronous VI calls, and are not compiled with the full application ! It would be nice if i could get an error more appropriate than "VI may be broken...".

Every time i get these kind of error i get a call for my final users saying "Your application is Bugged ..." ... so each time i have to investigate, analyse the user code ... and say him ... It's your code which has problem.

And every time, my final users says ... could you please replace this "generic error" by the real one ?

I hope i am clear ... with my approximate english !

I know the problem is not simple ... but here, this idea is only a "nice to have" ...

Thanks a lot for your answer, and your help.

Manu.

[AristosQueue (NI)]

I think I understand. Thanks for clarifying.

[kegghead]

Please don't do anything to make the RTE bigger. Please. I realize the problem but distributing the runtime is already ridiculous. Debug info has no place in the RTE if you ask me. Alternatively if it is deemed a worthy feature, segmenting the RTE should be far easier and the debug info should be optional.

I can't think of any situation where I expect to get debug information from release builds on client machines. That is not the job of a RTE. If I release debug versions, I expect to have to attach to the process with my (not a client's) IDE. I realize you can't always do this, but my opinion is you shouldn't expect debug information for these cases.

In your case if your client is loading VIs that they have written, they have access to the IDE and should be able to debug it? I seem to remember issues attaching to dynamically loaded VIs, but that is another issue.

[manu.NET]

Hello Kegghead,

I completly aggree with you ! The RTE should not be bigger.

If something is done for this idea (?) ... it should be done as an addon tool !

You say that my customers has the IDE to create the their custom VI's ...

I say yes, but I also use custom VI's in RT applications (RT, CompactRio) ... and then the execution environnement is given by the "startup.exe" package ... Debugging the custom VI can be successfull using the IDE, and unsuccefull using the real RT exe.

(Because the ressources you can access using the IDE are different than in the RT Exe package)

=> Then you will be happy to have some more informations about the real error !

Perhaps what should be done rapidly is to generate an error which make the difference between missing VI (Bad VI path) and VI broken ! For the moment both error sources generates the 1003 error !

Thank all for your interest.

Manu.

[SteenSchmidt]

On attaching the remote debugger;

For my part at least, this is only a problem on real-time targets. Which incidently covers 90% of my work.

1) On real-time I have not had a single instance where the Real-Time Execution Trace Toolkit (RTETT) did work. RTETT either didn't return any data, or it returned only a very small and random amount of data. I've spoken with NI about this issue, and have until now only received answers along the path of "Try to reduce the length of the names of your VIs, as in RTETT there is a buffer allocated to hold the info from each VI, and that breaks if the fully qualified VI name is above 32 chars or thereabouts.". As I use libs or classes together with clones, the fully qualified VI name is often above 32 chars. And no, I'm not going to rename a code base of several thousand VIs to debug with RTETT...

2) Attaching the remote debugger to a Real-Time target is often fruitless, as we cannot debug reentrant VIs on Real-Time, and we of course can't debug inlined code at all. And somehow most of my problems happen within those. Probably because any type of advanced architecture will involve reentrancy and inlining to a large degree.

3) Any sort of debugging, remote or otherwise, is made sort of harder than it probably has to be, due to the fact that debugging must be enabled on a per VI basis. I'd be thrilled about a better way of managing debugging on a per library, per project, or per environment level. I don't mind bulding and deploying a debug app, but I do mind modifying thousands of VIs to enable debugging. There isn't even a bulk-editor for such flags built-in. There soon will be, but that will be released by GPower, not NI 😉

Other than that, debugging in LabVIEW is easy...

Cheers,

Steen

[SteenSchmidt]

I forgot one thing about the remote debugger that often disqualifies it from my use; The remote debugger uses a dynamic port number for communication with the target, and that in practice requires all ports to be open on the network between debugger and target.

The networks I operate on with Real-Time targets are usually closed, in a way that it requires hard persuasion skills to get even one specific port opened. Having all ports open won't happen on those networks, and thus I can't connect with the remote debugger. Not unless I physically move the target(s) onto a closed network which I have complete control over, but that's rarely possible.

I do not wish to have the RTE blowing up in size either, nor am I pounding on the good work that is undertaken in NI R&D. I'm just pointing out that there are some issues - especially with Real-Time targets - that isn't addressed with the current set of debugging tools in LabVIEW.

/Steen

[AristosQueue (NI)]

> and that breaks if the fully qualified VI name is above 32 chars or thereabouts.".

What a ridiculous limitation. I don't think I have any meaningful VIs that would fit in that length for their fully qualified name. Heck, you'd lose 12 of those characters just for ".lvclass:" and ".vi"!

> as we cannot debug reentrant VIs on Real-Time

I didn't know about that limitation.

> and that in practice requires all ports to be open on the network between debugger and target.

Another detail I didn't realize. I've never had to do remote debugging on an RT system... I pretty much work exclusively on the desktop.

Thanks -- to all of you -- for laying out the details underlying this idea.