Executable has broken run arrow, development environment doesn't

[GregFreeman]

I have an RT application which works in the development environment. But, when I created an executable, it wasn't working. So I created this executable as debuggable, and when I looked at the debugging, I saw it had a broken run arrow. Clicking this didn't open the typical dialog telling me where the error was; in fact, it didn't open the dialog at all. So, I started digging around and finally found the broken VIs. They are pickering drivers which are in the instr.lib.

I did a mass recompile to see if it was a linking issue, but it didn't resolve the problem. Does anyone have any thoughts, or has anyone come across something similar?

[K C]

Hi Greg,

Maybe the Pickering VI's needs a DLL from Pickering which can not be found by the executable.

Had some problems with Pickering drivers myself a few years back (and not only the drivers )

Kees

[cirrusio]

Hey Greg,

I am now having the exact same problem.  My application is heavily object-oriented.  If you select View->List Errors you should see errors.  I initially had some issues with the General Error Handler so I removed this from my application but I still can't get the damn thing to execute.  I found a broken wire in which it appeared that one of my classes didn't appear to be properly deployed, so I removed code related to this.  Still broken.  If I click on all of the top-level VIs (those directly located in my RT application), they all indicate no problem.  I think that my next step is to deconstruct the VI and then rebuild it piece by piece.  Have you found a solution?

Cheers, Matt

[KHartley]

Matt,

Will the exe run on the development computer? Don't use an installer because have the runtime engine installed on the development computer can mess up depencies in LabVIEW.

If the exe will run on the development computer then it could be a dll issue like stated above. Make sure you aren't hard coding a paths unless it will always be in the same location on every computer. 

[cirrusio]

Thanks, Kyle.

I apologize.  I don't fully understand what you are suggesting.  Do you mean development environment (rather than computer; this is a real-time application and will run only on the real time machine)?  If you mean environment, then, yes, it will run.  I will look for dependencies but I am fairly certain there are no paths or dlls called that could be hard coded. Still, the debugging environment seems pretty useless if it can't point to why the exe might be broken.

On a similar note - I tried to deploy a similar application (heavily object-oriented) and had to do some major rewrites to get it to run on the chassis (same issue - ran in the deployment environment, not as an exe).  In that case, the error when the startup VI kikced on was fatal and just kicked me out and rebooted three times before rebooting into the minimal RT environment (had a post about this a year or two ago).  That was back in 2009 and I was hoping the 2011 may have fixed this so I am trying to restructure my project as it was originally intended.  So far, no good.

I will let you all know what happens as (once again) I deconstruct this top-level VI and see where it fails.

Cheers, Matt

[cirrusio]

Thanks, Kyle.

I apologize.  I don't fully understand what you are suggesting.  Do you mean development environment (rather than computer; this is a real-time application and will run only on the real time machine)?  If you mean environment, then, yes, it will run.  I will look for dependencies but I am fairly certain there are no paths or dlls called that could be hard coded. Still, the debugging environment seems pretty useless if it can't point to why the exe might be broken.

On a similar note - I tried to deploy a similar application (heavily object-oriented) and had to do some major rewrites to get it to run on the chassis (same issue - ran in the deployment environment, not as an exe).  In that case, the error when the startup VI kikced on was fatal and just kicked me out and rebooted three times before rebooting into the minimal RT environment (had a post about this a year or two ago).  That was back in 2009 and I was hoping the 2011 may have fixed this so I am trying to restructure my project as it was originally intended.  So far, no good.

I will let you all know what happens as (once again) I deconstruct this top-level VI and see where it fails.

Cheers, Matt

[dan_u]

---

@Kyle-H wrote:

Don't use an installer because have the runtime engine installed on the development computer can mess up depencies in LabVIEW.

---

Are you serious about that? Is there a CAR? This sounds like a major problem to me, because we deliver an application to clients (installer including runtime engine). Some of them have LabVIEW development environment installed, some don't. So you're saying it could mess up things in LV when installing the application?

[altenbach]

---

@dan_u wrote:
Are you serious about that? Is there a CAR? This sounds like a major problem to me, because we deliver an application to clients (installer including runtime engine).

---

I don't think this is a general problem. There was a case in the past where accidetally installing the minimum runtime engine on a development computer messed things up:

Quote from the 2009 run time install notes:

"Do not Install the minimum Run-Time Engine on a development machine, doing so will prevent you from including the Run-Time Engine as an Additional Installer when building an installer in LabVIEW. To fix this situation you must install the standard Run-Time Engine on the machine."

(At least I hope there are not more serious problems with dependencies 🐵

[GregFreeman]

I solved this and should have followed up because I can't remember the solution exactly. But, if my memory isn't completely letting me down, I believe I had to put the dlls as always included, or somehow put them on the RT. If you can hang tight til tomorrow i can get back to you if I get a chance to look at the project. My initial thought is though to always include the dlls

[dan_u]

---

@altenbach wrote:

---

@dan_u wrote:
Are you serious about that? Is there a CAR? This sounds like a major problem to me, because we deliver an application to clients (installer including runtime engine).

---

I don't think this is a general problem. There was a case in the past where accidetally installing the minimum runtime engine on a development computer messed things up:

Quote from the 2009 run time install notes:

"Do not Install the minimum Run-Time Engine on a development machine, doing so will prevent you from including the Run-Time Engine as an Additional Installer when building an installer in LabVIEW. To fix this situation you must install the standard Run-Time Engine on the machine."

(At least I hope there are not more serious problems with dependencies 🐵

---

Thanks for the info. I also hope this is what Kyle refers to so there's nothing more serious.