Append Control Image to Report stops Source Distribution from working

[herbert.niesler@emsolutions.com.au]

I have a top level built executeable that calls various external vi's using the "Call by Reference Node" function.  This seems to work ok, to a point.  An additional point here is this is code that I had running well in LV8.2 and am now trying to get running in LV2010 as there have been some significant changes in LV that have impacted on this project and this has forced me to change things.

The external vi that is called is stored in a "Source Distribution" directory structure, which has been generated via its own project specifications.  An examination of the directories and vi's stored at the destination looks like everything should be there. 

When it comes to running the vi in the source distribution directory (from the top level built executeable) I get the following error message "Error 1003 occurred at Open VI Reference in Run HTML Report Generation VI LV10.vi->Generate Reports.vi", with the additional suggestion " The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.".  So it looks like there is something missing in the "Source Distribution" directories.

Doing as suggested, opening the vi in the "Source Distribution" with the development environment, shows that it has no broken arrow.  My suspicion is the development environment is supplying whatever it is missing.

Using the built top level application, using trial and error and using the diagram disable structure, I have narrowed down the location of the problem to an "Append Control Image to Report" sub vi (its from the NI Report menus).  Disabling this vi at the level it is called, allows the "Source Distribution" vi to run.  "Append Control Image to Report" is part of a class structure and I must say I have not used class structures so my understanding of their implications is very limited.

If I instead dive into "Append Control Image to Report" vi and disable the vast majority of its diagram (everything in the "No Error" case), the original error pops up again.  Bit strange considering there are only controls and indicators and a case statement left.

I would appreciate any suggestions, as this has got me stumped.  Hopefully I have made myself clear enough as it is all a bit complicated.  Let me know if I haven't.  Thanks.

[charris]

Herbert:

If disabling everything in the "No Error" case of the "Append Control Image to Report" still gives us an error, it's likely the error case is being activated. If that's true, then the error is being passed into the subVI. To test this, would it be possible to add a boolean indicator to the subvi that will light up if the error case is executed or stay unlit if the "no error" case is executed? This will tell us if the error is being passed from the calling VI or originating in the subVI.

[herbert.niesler@emsolutions.com.au]

Hi Caleb,

             that won't work, as the problem is the called sub vi cannot even start to run as its broken some how.  My diagram disable stucture approach, in narrowing down where the problem is, works because sections of code are removed and this allows me to identify which section of code is looking for something it can't find.  So I have identified the unhappy area of code through this approach.

  To use your approach I would have to disable that part of the code in the called vi that is causing the problem and that would result in no run time errors anyway.

  So another way of saying this is that in the "Source Distribution" directory structure, there is a compile time error in that there is some resource that is missing, that  "Append Control Image to Report" needs but can't find.  If I open it in the development environment there is no apparent problem as the development environment must be supplying it.  Its when I run it from a built application that there is a problem, as the built application is not able to supply the missing resources.

  Thats the picture I am getting so far.  Thanks for the suggestions.

     Cheers

             Herbert

[herbert.niesler@emsolutions.com.au]

I have realised I can open the offending vi in the built application on the target computer.  In doing this, the vi opens with a broken arrow and reports a "2302200" error message and says it needs the full development environment to fix the problem.

This however is not true as I have built another small executeable that allows me to load the offending vi into that executeable and run it and there is no problem.  So the first bigger built application is obviously confused.  The question is why?

[charris]

Herbert:

When the VI displays the broken arrow and displays that error in the dialog, does it take you to a particular diagram component? Does the diagram have any broken arrows or something?

I'm wondering if there's a type def or something specific (that got left out of the build, like your hunch) that the larger (malfunctioning) application is trying to use.

[herbert.niesler@emsolutions.com.au]

    Hi Caleb,

      "When the VI displays the broken arrow and displays that error in the dialog, does it take you to a particular diagram component? Does the diagram have any broken arrows or something?"...      it doesn't take me to a particular diagram.  Is this possible in the RTE?  If it is how do I enable it?

   I can follow the chain of broken arrows (front panel only) down to my vi that calls the NIreport vi that is causing the problem.  However I am unable to open the NIreport vi's in the RTE, so cannot chase this any further down the call chain.

  I have tried opening the offending top level vi (on a network drive) and it opens ok.  When I close it, it wants to save some changes which i think might point at where the problem is.  The attached file shows the screen shots of the "Explain Changes" window.  Hopefully they mean something to you.

       Cheers

                Herbert

[charris]

Herbert:

I should have checked on this sooner (thought you already did it): If you go to the build specification in your development environment, you can select "enable debugging" in the "Advanced" section. If you do that, the block diagram will be included in the build, and we may be able to get a little more information about it at run-time.

If we can include the block diagram in the build, we can hopefully wring a little more info out of it on the target and figure out what's changing.

One other question: what operating systems are you running on your development and target machines?

[herbert.niesler@emsolutions.com.au]

Hi Caleb,

       can't see how this is going to help.  You'll have to explain.  The vi's in the "Source Distribution" area (where the problem exists) already have their wiring diagrams with them.  As noted on 10-17-2010 "... I have tried opening the offending top level vi (on a network drive) and it opens ok. ", so I have opened this vi in LV2010 and there is no problem (but then maybe the development environment is supplying what ever is missing or another alternative is that something got screwed up in the compilation of the main application).  Also note from 10-15-2010 "...This however is not true as I have built another small executeable that allows me to load the offending vi into that executeable and run it and there is no problem.".

  So the problem appears to be my main big application has a problem running the "Source Distribution"  vi's because of an issue with a vi in NIReport after it is compiled.  Yet I can build a smaller app and the problem does not occur.

  My development environment is in Vista and the target machine is W7.

         Cheers

                     Herbert

[charris]

Herbert:

Sorry to keep running in circles with this. I'm working with a couple other engineers here to see what we can come up with.

---

herbert.niesler@emsolutions.com.au wrote:

 I have realised I can open the offending vi in the built application on the target computer.  In doing this, the vi opens with a broken arrow and reports a "2302200" error message and says it needs the full development environment to fix the problem.

---

To clarify the behavior: when it's broken, is it the calling (top-level) VI that breaks? In the post I quoted, it sounded like the subVI was what returned the broken arrow.

If it was the subVI, then it's likely that perhaps one polymorphic instance is having the error while another is not. When you created the simple executable that used the VI (I'm assuming it was "append control image to report"), were you creating the same type of report (I think it was HTML)?

If you change the report type in the original application, does the error persist?

[herbert.niesler@emsolutions.com.au]

  Hi Caleb,

          yes language is a real issue when dealing with these tricky problems.  It is the called sub vi that comes up with the broken arrow.

   In the mean time I have opened up another front on this problem with another NI engineer, who had helped me with a previous problem.  He made a number of suggestions, here is the key part of what he said -

"I did a quick search on our portal about the error you were getting and this seems to happen when building a VI that includes a subVI containing a Shared Variable.
Here are some potential workarounds:
1. Check the Enable debugging option in the Advanced category of the application executable properties.
2. Disable the Remove Panel option for all SubVIs containing Shared Variables in the build.
3. Uncheck the Disconnect type definitions and remove unused polymorphic VI instances option, also in the Advanced category of the executable properties.
4. Move shared variables to the top level VIs and pass the data through the SubVI connector. "

  I have experimented with suggestions 1-3 and have found item 3 is the one that gets rid of the problem.  1 & 2 seem to make no difference and 4 I didn't check as I have no shared variables in the vi's I've created.

  Thanks for the input.  This has been a tricky one and I recognise that it is hard to narrow it down.

          Cheers

                   Herbert