Real-Time Application doesn't run; source code works fine

[thutch79]

I have a project that has been building successfully through many versions until now. My latest release is working just fine in dev code, but when I build an exe, it fails to run. Doing some remote debugging has uncovered that it never gets beyond launching the first actor and Actor.vi is broken. Attached is a screenshot of the block diagram from the remote debug. Looks like the AF Debug VIs are missing. I tried adding the AF Debug to the project and even putting it in the "always include" section of the build. No luck. I tried mass compiling the Actor Framework folder. Again, no luck. I don't know where to look next. Any ideas?

In case it matters, sbRIO 9651 and Labview 2017 SP1

Thank you!

[thutch79]

Potential clue. I rolled back to my latest, working executable and redeployed that. I then did a remote debug to see how Actor.vi looked when working properly. To my surprise, it wasn't listed under "Browse Relationships -> Unopened SubVIs" like it is in the non-working code. No idea if that is a clue...

[thutch79]

Further clues. I'm digging through subVIs and I found broken malleable VIs. These are a new addition. Our friends at Composed Systems have started using them in their libraries and I recently adopted them. They are broken, but there is no indication on their block diagrams that they are broken, nor are any subsequent subVIs broken within them. Has anyone had success using malleable VIs on a RT target yet? Is this a known issue?

[thutch79]

Confirmed. I isolated the VIMs in question into a very simple VI to build into an executable. It did indeed break when deployed as an executable. I can back this change out, but I'm still curious as to why VIMs don't seem to be working in an executable on a RT system. Is it all VIMs, or just these?

[BertMcMahan]

I don't know which RT platform you're using and I'm not familiar with the VI's you're using, but is there any chance they're calling some other VI's dynamically?

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LskSAE&l=en-US

[thutch79]

I mean, yes, that’s how actor framework works, but I don’t think that’s root cause here. Like I said, the program has been built many times before and the new additions aren’t actors or anything called dynamically. If I didn’t already mentioned it, I did a round where I literally put everything in the “always include” section and it still failed. The VIMs are definitely broken so they’re at least part of the issue. This is the first I’m building malleable VIs into anything so that’s probably where I’m falling down. 

[cbutcher]

As you of course already know, it's perfectly possible to build the Actor Framework onto an RT target and run it successfully.

My understanding with regards to VIMs is that one of the most significant benefits is to aid in processing on FPGAs with different types of FXP numbers, so I can't imagine (although I don't believe I'm currently using) that they wouldn't also work on RT targets.

If you think the problem is related to AF_Debug, and you're not too bothered about having that functionality, it's fairly easy to remove. I've attached an example zip with my copies of AF (and the extra messages) here, which you could use or see and then copy/modify if you like. They're saved for 2017.

Spoiler

In my case, I'm using to build them into PPLs (which is impossible with my library partitions and AF_Debug, since the debug library depends on the Time-Delayed Send Message (not a part of AF, often people place all the messages inside AF to avoid this problem), which depends on AF, which depends on AF_Debug...)

[thutch79]

It is very curious that AF Debug seems to be missing, but I'm not sure that's the issue (or at least it's not the only one). As I stated above, I isolated the VIMs that are definitely broken. Now, I agree it's unlikely that VIMs in general are not working on RT. They're old enough at this point and I'm sure I'd be able to google up something that says there's an issue, but so far I've found nothing to support that. It could also have something to do with those VIs that doesn't have to do with them being malleable. I don't believe the developer of those has tried them on RT yet. They do use a "by reference" design, so maybe that has something to do with it.

My current plan is to roll back to a version of this library that is known to work on RT and in our code. I'll see if that allows things to work correctly. It's not a particularly important change going to the new library. It's just a nice utility to read/write to configuration files. The old stuff is still ok. I had just wanted to stay on their active side of development.

[cbutcher]

Can you meaningfully share the VIMs? Perhaps there's something that would work with a little modification?

If it's too complicated (sounds like it might be) then nevermind!

[thutch79]

Come to think of it, I definitely think the AF Debug stuff is a red herring. The calls I'm seeing missing are in the conditional disable structure. The run time engine may just not load those if not needed. I'm not sure. I don't think I've come across a conditional structure while debugging an exe before. It's tough because LV gives no information on why a VI is broken when using remote debugging. If it's not obvious by broken wires or broken subs, it's tough to tell.

I think the Actor stuff was broken because the calls to this library are in my pre-launch init of one of my actors.