Jump to content

Building a large complex executable in labVIEW 8.5.1


Recommended Posts

Hi Guys

Paddling with my head above "lurksville" to ask of the wise ones :)

I have two relatively large and complex LabVIEW source code applications that we use internally with equips and sensors etc.

I just upgraded both of these applications to 8.5.1 from 8.2.1. ( and that was actually quite a ride but at least 8.5.1 seems more stable in certain areas.)

Both applications work in the LabVIEW environment however, When I try to use the build feature to get a preview, distribution or a build

I am sumarily (and rather quickly) booted out to windows on both apps, which are on different machines.

One app uses labVIEW classes the other does not yet they both crash so that notion is out.

Both apps have large number of VI's (800 to 1000+ (never counted))

Both apps were upgraded from 8.2.1 to 8.5.1 successfully, (howbeit not easily by any stretch of the imagination)

In both apps a number of VI calls are dynamic and many calls create independent instances to allow other processing dataflow(s) to continue yada yada

Both apps use dynamically called VI's, GOOP inheritance toolkit VIs , VISA and Field point resources however I am not thinking these in themselves pose any problems

that would cause the builder to crash. I just don't fully get it.

I'll admit building exe's is not something I do often yet I would have expected at least some error messages from the builder utility. Instead I cannot get a preview at all on either app.

I was wondering if anyone has

experience crashing into this proverbial wall with 8.5.1.

ANY clues would be appreciated :beer:

Thanks in advance.

Link to comment

Hopefully you still have a backup in the previous version. Sometimes when upconverting, some indicators seem to get corrupted and have to be replaced with one from the new version.

In the past, I have had to replace the IMAQ image display in all my VI's because the upgrade (frm 8.5.1 to 8.6) and saving to the new version would cause LV to crash on opening the newly saved VI's in a project.

Maybe you can figure out by building a simpler part of your main VI and see if that goes smoothly; if not then find out which VI is causing the build to fail.

I can't remember how I isolated the IMAQ display as the culprit, but replacing that with a new one caused the VI's to open and build to work.

How about toolkit VI's? Have they also been upgraded (if you are using any of them).

Look through your project paths and see if any of them are pointing to older versions of VI's in some other folders.

Make sure your project isn't referencing any VI's in the 8.2.1/vi.lib

Try deleting the build spec and making a fresh one.

Another thing: I remember reading somewhere that its recommended to keep the size of the exe down below 10MB. Maybe you can change your build to store VI's in additional llb's instead of within the single large executable.

Neville.

Link to comment

QUOTE (TG @ Jan 5 2009, 12:56 PM)

Hi Guys

Paddling with my head above "lurksville" to ask of the wise ones :)

I have two relatively large and complex LabVIEW source code applications that we use internally with equips and sensors etc.

I just upgraded both of these applications to 8.5.1 from 8.2.1. ( and that was actually quite a ride but at least 8.5.1 seems more stable in certain areas.)

Both applications work in the LabVIEW environment however, When I try to use the build feature to get a preview, distribution or a build

I am sumarily (and rather quickly) booted out to windows on both apps, which are on different machines.

One app uses labVIEW classes the other does not yet they both crash so that notion is out.

Both apps have large number of VI's (800 to 1000+ (never counted))

Both apps were upgraded from 8.2.1 to 8.5.1 successfully, (howbeit not easily by any stretch of the imagination)

In both apps a number of VI calls are dynamic and many calls create independent instances to allow other processing dataflow(s) to continue yada yada

Both apps use dynamically called VI's, GOOP inheritance toolkit VIs , VISA and Field point resources however I am not thinking these in themselves pose any problems

that would cause the builder to crash. I just don't fully get it.

I'll admit building exe's is not something I do often yet I would have expected at least some error messages from the builder utility. Instead I cannot get a preview at all on either app.

I was wondering if anyone has

experience crashing into this proverbial wall with 8.5.1.

ANY clues would be appreciated :beer:

Thanks in advance.

FWIW, I'm now using 8.6 having migrated code (over the years) from LV 5...through 8.5.1. My app is over 1400 VIs, with dynamic VI calls, VISA (now starting as of 8.5.1) but no Field Point and no use of GOOP inheritance. I have no difficulty with builds although, in the past, there could be problems related to specifying the dynamic VIs correctly, esp in including them in the build EXE or by other reference processes. I include everything in the EXE for security related reasons and you MIGHT want to try that just to see if you can do the build or at least force an error message. Another difference between your situation and mine is the use of FP and GOOP but why those would make any difference isn't at all clear to me (esp since I don't use them and don't know them).

What problems did you have in the translation of the overall code? That may be where things are falling down a bit and might point to some issues for further follow up.

I hope this helps.

Link to comment

We have a pretty big app, and we build it frequently without crashing LV. I would just use a divide and conquer approach. Take the top-level VI and delete half of the subvis, patch up the loose wires, and build it. If it doesn't crash, delete the other half of the VIs and see how that goes. Naturally you will want to try eliminating all calls to various features like VISA, GOOP (if possible), et cetera. It sounds tedious, and it is, but in one afternoon you should be able to finger the culprit. Then NI Tech support should be able to help you if the fix is not obvious at that point.

Good luck!

Link to comment

QUOTE (Ton @ Jan 6 2009, 06:52 AM)

First fix:

Place any dynamically called VI inside a Strict VI reference, this will force the builder to include the dynamic VIs inside the executable.

One question, were you able to build the executable inside 8.2?

Ton

Sorry, was away for a day or two. Actually I never tried the full executable in 8.2 but I do remember having better luck with portions of it.

I've read all the responses (Thx btw, u guys always impress with the level of expertise ) and I am thinking for now at least I should look mainly into the GIT toolkit as the most likely cause of severe problems as in not even seeing error dialogs yet.

I would guess dynamically called VI's without strict references would be the second suspect.

The divide and conquer approach is probably where I'll start. I am used to getting away with LV 7.1 where everything at least gave an error. It was tedious but at least there was an endpoint. We really do not need to make executables out of these programs for long time yet so I have option of looking into it a little at a time.

Ive got a number of GIT 3.05 classes made and it makes sense to me to start there, maybe try to remove dependencies

and encapsulate them a little better and try to make some executables out of them piecemeal first.

Boy I wish I had been keeping up with this when developing these two beasts. Hehe.

Might take awhile But I'll report my progress as it goes.

Thx again :beer:

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.