Error 7: File not found for executable

[cirrusio]

Thanks, zenthoef, but that is not a local variable.  That is a node input that is fed in through the main program.

[zenthoef · Accepted solution]

I couldn't tell it wasn't a local in the first shot. Its actually a global! I'm refering to "main_call.png".

This should not be fed in through a global. I'd be willing to be your Call by Reference node is executing before your Config File global has a value set to it. Use a probe on the Config File global's wire into the Call by Reference node, and run your program to confirm this. 

[cirrusio]

Thanks, zenthoef.  That is indeed a global.  I will set this up to make sure the global is properly populated before the VI is called.

m

[zenthoef]

Excellent! I've run into similar situations, although not with a global, so I'm feeling confident this may be your problem. 

[cirrusio]

Thanks, zenthoef. That seems to be the issue.  I solved this little problem by adding an occurrence to indicate when the global has been properly populated.

Cheers, Matt

[zenthoef]

Awesome! I'd also suggest enforcing dataflow by using a wire from where the the path is created to your Run by Reference node (or something like that with an error wire). Simple is better 

[cirrusio]

Since you are getting in to the guts of this, I should probably explain what is going on.  This is code for a commercial instrument which I did not develop.  I have no desire (nor time and money) to rewrite the entire program so I have tried to dump in the addition that my scientists required for operating the instrument in the manner in which they desired.  In this case, the simplest approach seemed at the time to develop an stand-alone application that could be easily integrated into a larger application.  Since I have no desire to heavily edit the main code, I have no choice but to use the structures provided (such as global variables) and therefore have to find a way to use them in a proper manner.  Personally, I don't tend to use globals and only use locals when absolutely necessary (such as in init and config routines).  But the code that you are looking at was written by a CLA and is robust in itself, so I am not really one to question the over all techniques employed; I just have to find a way to use them.

Once again, thanks for all your help.  Cheers, m

[zenthoef]

Ok, that's fine. 

Just making the suggestion because code maintence is expensive over time, as you are finding out with this issue. The CLA that wrote this clearly didn't make it very robust if he/she used globals that can cause a race condition like this to occur....... Just saying...

[cirrusio]

I agree with the maintenance comment.  This is not my style of coding either, but the robustness of the code should certainly not be judged by my ability to properly kludge in a patch; or maybe it should be .

[zenthoef]

Oh, it should be  this should have been a lot easier! But hey, we all make mistakes sometimes... (refering to the CLA that used a global, not you!)