Error 1003 when trying to launch root actor only in build.

[JohnG3k]

I have an Actor Framework application that I have built and run successfully a couple times. However my most recent build is giving me error 1003 when attempting to launch the root actor.

The application runs without issue in the development environment. Since the last successful build there haven't been any significant architectural changes (no new classes, no changes in inheritance). There are no broken VIs anywhere in the project in the development environment.

When viewing the block diagram when running the exe in debug mode, the wire of the actor I am trying to launch is broken.  

I have also found several of the Actor Core.vi's have broken actor wire, but I have no idea why. In the development environment they are all ok, and all run fine. All broken Actor Core.vi's have a similar structure to below and call similar sub-vi's. None of the sub-vi's shown in the images below are broken, and none have been changed in several months (since well before the first successful build).

I am stuck. Any help would be greatly appreciated.

Thanks,

John

[JohnG3k]

I forgot to mention... LV 2020 SP1

[TurboTobi]

Hello JohnG3k.

Do you load any class via factory pattern sitting runtime?

If so, than you have to add them to the build manually.

It seems to me that something doesn't work with the inheritance hirachy.

---

[p4keal]

Is it possible that you are using some kind of AF debug library? I have no experience with this and I am using LV2020 SP1. In this version, launch root actor.vi does not have the input "capture events".

[JohnG3k]

Hi TurboTobi,

Thanks for the ideas. Yes, many classes are loaded at runtime, but that doesn't happen until after the root actor is launched, which isn't happening due to the error. I agree it seems an issue with inheritance, however there is no issue in the development environment. I have manually added all of the classes to the build that the root actor inherits from and still have the problem (also I didn't do this for previous builds and they were included automatically and build ran successfully).

John

[CaseyM · Accepted solution]

Ah, the good old error 1003. I hate this error. As you mentioned, it seems to pop up from time to time with no good reason. Here's a list of things we've done to fix this in the past (in order from least to most invasive):

• Clear the compiled object cache and restart LabVIEW before your build.
• Check to see if you have any typedefs that are private in scope. If you do, make them public.
• Clear the mutation history of your classes and rebuild.
• Find places where you've used private data property node accessors and replace them with bundle/unbundles or the subVIs directly.

Hopefully one of those works for you.

Other questions... are you using PPLs? Were you able to successfully build and run in the past? If so, I might suggest using your source code control history to figure out which exact commit introduces this behavior.

[JohnG3k]

Hi p4keal,

Yes, I am using a slightly customized AF library. I have added a feature to capture 'events' in a log file (much the same way that Debug Trace is implemented except it sends the events to another actor for logging). The changes are fairly minimal and I've been using this library for over a year without issue, and was using it in the previously successful builds, so I don't think the issue is there.

Thanks,

John

[JohnG3k]

Hi CaseyM,

Awesome, thanks for the ideas. I should have thought about clearing the cash but I wasn't thinking that well at 2am. Done that now and trying a new build with fingers crossed. Still got 30 min till the demo, so a chance I could still get it working 🙂

I don't have any private scope typedefs, but plenty of property node accessors. I will try that next if this doesn't work.

Not using PPLs... honestly I avoid them like the plague after a horrible experience about 8 years ago. Though I gather there is a new feature now that lets you go from PPL to regular library, which likely would have solved all my issues before. I still shutter at the thought of them though.

Yes, I have a build from a week ago that is running successfully. 

[JohnG3k]

Clearing the build cash worked!!! Thank you so much!

[CaseyM]

Glad clearing the cache worked!

---

@JohnG3k wrote:

Not using PPLs... honestly I avoid them like the plague after a horrible experience about 8 years ago. Though I gather there is a new feature now that lets you go from PPL to regular library, which likely would have solved all my issues before.

If you ever do go back to using PPLs, I highly recommend using LV Solution Builder. It will automatically figure out your dependencies and build PPLs in the correct order while still allowing you to work directly with the source code. It great simplifies the PPL build process and we use it all the time now.