Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem Building an AF Executable on a RT Target

So the problem is that the debugger doesn't even launch so I am not exactly sure what is happening.  Can't see errors, etc. etc.  I thought there was a wait on debugger option, but I can't seem to find it.

Just to clarify:  your EXE loads broken, correct?  It doesn't load, run, and immediately exit?

And yes, the EXE loads broken, i.e. when attaching a debug session the top level VI the run arrow is broken.

Also, how many actors do you have in this system?

Lots.  Depends on the configuration.

0 Kudos
Message 11 of 20
(1,948 Views)

Can you give an example?

0 Kudos
Message 12 of 20
(1,948 Views)

So, digging through the log file, it is not clear to me that it has pulled everything in.  For instance, I have the NI VI 'Get Terminal Name with Device Prefix.vi' and I can not find this anywhere in the log despite it explicitly being in the dependencies.  Any thoughts on this?  Is there a possibility that the exe could build but not have everything it needs to run?  Seems odd to me.

0 Kudos
Message 13 of 20
(1,948 Views)

Ugh...attempting to debug this is almost untennable.  I have tried to bring to the front the issue of web services and deployment to AEs, but they have stated that the front panels opening on deployment (and apparently when debugging an rtexe) is normal.  And it just gets worse on the rtexe as these things take even longer to pop up (in this build, I have not included the web service so I am not even sure why they are there)...

Anyways, AF messages are not broken but it appears that anything inherited or containing Actor type stuff is broken.

0 Kudos
Message 14 of 20
(1,948 Views)

I think you're missing a dependency.  It's worth looking for what calls Get Terminal Name with Device Prefix.vi and making sure it gets loaded.

At any rate, I think this issue has outgrown the forums.  I am looping in some additional resources to help, and I will PM you with my e-mail address so we can work more easily.

We'll post back here when we have a resolution.

0 Kudos
Message 15 of 20
(1,948 Views)

cirrusio,

I feel your pain, I have been though your exact issue(s) before, and i cannot offer any direct fixes, but i an offer a few things to look for:

1) Try clearing compile cache and rebuilding the executable. Sometime things get a bit mixed up and need to get refreshed.

2) Don't use the arrows on text labels. There was a bug with them that caused me much heart ache. It may have been fixed but I would just steer clear for a few more versions of LabVIEW

3) Follow niACS instructions. He is very knowagable of the subject and had assisted me.

4) If you not using AF from 2015 or newer you may be running into an existing bug that's been fixed in the Launch Actor process. I only mention this because I didn't see a specific LabVIEW version stated.

5) If you are using LVLIBP's make sure you have them deployed in the same folder structure as they are used on the development system.

6) Does the application run interactivly? If so, it probably a dependancy issue. Sometimes things need to be expliciatly included.

I would strip down until you have a running App, then add back in other actors. By running, I mean it executes without being broken.

If you can post the debug window contents after the app launches, that would be most usefull. Theres a debug terminal (i belive the one niACS is refering to). I had just put that in my startup folder to launch when ever i logged in. Very useful to know what's going on.

Good luck and keep us posted!

Brian

Brian G. Shea
Certified LabVIEW Architect
0 Kudos
Message 16 of 20
(1,948 Views)

So, I am currently about on the back channel with Allen et al. and will report back if we make any forward progress.  But, thanks for your response Brian and to answer some of your questions/points above:

1) Try clearing compile cache and rebuilding the executable. Sometime things get a bit mixed up and need to get refreshed.

This has become an unfortunate step in the development process for me.  It took me forever to figure out that when running in the development environment, if I got errors on deployment I need to clear this cache and restart.  This ought to be fixed by NI or at the very least documented because it is a hard earned bit of knowledge for everyone dealing with large projects on RT.

That being said, this is not in the development environment but rather in the RTE.

2) Don't use the arrows on text labels. There was a bug with them that caused me much heart ache. It may have been fixed but I would just steer clear for a few more versions of LabVIEW

Not sure what this means.  As this is RT, there are no front panels so no text labels.  But maybe I am missing something?

3) Follow niACS instructions. He is very knowagable of the subject and had assisted me.

Yup.

4) If you not using AF from 2015 or newer you may be running into an existing bug that's been fixed in the Launch Actor process. I only mention this because I didn't see a specific LabVIEW version stated.

This is 2014.  Can you elucidate on the bug?  I haven't run into anything on other projects concerning a bug.

5) If you are using LVLIBP's make sure you have them deployed in the same folder structure as they are used on the development system.

Don't use packed projects.

6) Does the application run interactivly? If so, it probably a dependancy issue. Sometimes things need to be expliciatly included.

Agreed and that is what we are trying to identify now.

I would strip down until you have a running App, then add back in other actors. By running, I mean it executes without being broken.

If you can post the debug window contents after the app launches, that would be most usefull. Theres a debug terminal (i belive the one niACS is refering to). I had just put that in my startup folder to launch when ever i logged in. Very useful to know what's going on.

Will look into this, but with the build broken it would seem there would be nothing to debug.  And the build log does not indicate any problems.

Thanks for taking the time to respond.  I really appreciate it.

Cheers, c

0 Kudos
Message 17 of 20
(1,948 Views)

If you are using 2014 there was an issue with the way the static reference to “Actor CORE.vi” was being handled. It was fixed in 2015. There are several documented fixes for this on the forums.

You may want to verify that you have applied these fixes.

The label arrows are on the block diagram. In 2014 or may it was 2015 you can drag an arrow off of a text label on the block diagram and attach it to some other item as a reference arrow. Breaks RT deployments. You may not have used them, but other code may have.

Unfortunately, I have switched jobs, and do not have references to the CAR or Bug fixes for the above two items, but I’m sure if you ask niACS he can point you in the right direction.

Thanks,

Brian Shea

Brian G. Shea
Certified LabVIEW Architect
0 Kudos
Message 18 of 20
(1,948 Views)

The label arrows are on the block diagram. In 2014 or may it was 2015 you can drag an arrow off of a text label on the block diagram and attach it to some other item as a reference arrow. Breaks RT deployments. You may not have used them, but other code may have.

Ok...so this is interesting.  When you say "breaks RT deployments", do you mean builds or just deployments from the development environment?  I have these things everywhere...

0 Kudos
Message 19 of 20
(1,948 Views)

I think it was both. It may have been patched as a bug fix since then (about 1yr ago). Please check with niACS. I just know that we wrote a VI using VI Scripting to remove all the arrow’s on all Vis in the project and all Vis referenced by Vis in the project.

Brian G. Shea
Certified LabVIEW Architect
0 Kudos
Message 20 of 20
(1,948 Views)