AF PPL on linux RT

[Jonzarwal]

Hi guys,

We are facing a big problem we have not anticipated, and i'd like to have a confirmation from you that it really is a problem.

We have created a whole set of modules based on AF PPL with several levels of inheritance as you can see below:

And it's working pretty well... on Windows. The thing is we always planned to use those modules on linux rt targets, and it seems it was a very bad bet. We tried today, and LabVIEW throw an error when we try to use a VI from those libs in our RT code.

Do you guys confirm that we have to rebuild the whole chain for linux RT (rebuild AF PPL and all the children) ? (please say no!)

[cbutcher · Accepted solution]

Hi,

Yes, you need to rebuild them all.

Be very careful with your linking as you build them, take care not to save the changes in dependencies as you move them into the RT target or else it'll be a pain to develop on Windows.

I'd suggest checking out the source code (use SCC!), then building the PPL, then just immediately resetting or deleting the source without committing anything.

I gave a presentation at NI Week in 2019 that partly covered my build system for RT+Windows PPLs, I'll try dig out a link, although probably there isn't enough detail to copy it all (edit: https://labviewwiki.org/wiki/NIWeek_2019/Code_Trafficking:_Smuggling_Your_Best_Software )

If you're having problems, post again here and I'll try give some thoughts (or someone else might have better suggestions etc)

[Cy.Rybicki]

I'm going through this same process and am running into an issue deploying the AF PPL to the cRIO. I created a simple test VI (see attached) that will launch the root actor from either the packed or unpacked library. The unpacked version deploys and runs without issue, but when I attempt to run the packed version it always fails with the following message:

Deploying Launch Actor.viLaunch Actor.vi loaded with errors on the target and was closed.
Deploying NI-cRIO-9047-01E5DD18 Container
Deployment completed with errors

A few of the things I've tried to solve the problem so far:

• Restarting LabVIEW
• Restarting the cRIO
• Renaming and recompiling Launch Actor.vi
• Rebuilding with/without debugging enabled
• Upgrading the PPL and cRIO drivers from LV2019 to LV2020
• Running from a different computer

I am able to build a child actor into a PPL which will launch if it inherits from the unpacked version of AF, so it doesn't seem that this is simply a PPL issue. Changing the child actor to inherit from the packed AF and rebuilding causes the same inability to launch as described above.

[Jonzarwal]

Hi Christian,

With a huge lag due to business priorities and the end of 2020 celebrations, thank you for your answer. It's a pity that your presentation is in a bad video quality.

We painfully rebuilt all the lvlibs that ended with some dependencies problems. We also discovered that some ppls validated on our cRIO were not compatible with the client's one because of the OS bitness (32bits vs 64bits). Another disappointment with PPL.

The final decision was to forget the PPLs and to duplicate all our libraries in a non compiled format for the cRIO. After a long relinking work, it's now working well. But no PPLs on cRIO, no code reuse with atomic storage of libraries sources, and no plugins on cRIO (as our plugins are statically defined in the cRIO code now).

We love LabVIEW, the actor framework, PPLs and plugins oriented development, but this adventure has been a hard blow to live.

Cy.Rybicki, I don't really know how to help. We decided to stop using PPLs on RT so... Good luck with your problem 😕

[cbutcher]

Hi Jonzarwal,

Glad to hear you 'solved' your issue, sorry to hear that it didn't work out how you'd wanted...

If you want to expand on the bitness issues, I can try make suggestions, but if you're happy to just move on with the lvlibs, of course that can make sense too.

I personally was surprised (although, it shouldn't have been that surprising) to learn the cRIO we have at work is 64-bit Linux - for some reason I'd thought/foolishly assumed it was 32-bit and was rudely awakened to this when trying to use 32-bit .so libraries directly in LabVIEW on cRIO (perhaps this is the sort of thing you're referring to? Although you mention OS, so maybe not).

Outside of calling external (non-LabVIEW) code, I haven't noticed it much one way or the other, but apparently you're hitting some issues.

As to linking - yeah, that pretty much sucks. This was the major motivation for me to create a build system that generated build specifications programmatically in "throw-away" project files to build the PPLs - all of the source code in SCC (git) is linked for Windows, 32-bit LabVIEW, but compiled into cRIO (64-bit Linux, as I learned), Win32 and Win64 PPLs (each with and without debugging enabled). I don't envy your recent experience (and am glad to have mostly forgotten it!)...

[cbutcher]

Hi Cy,

I took a look over your project and didn't see anything immediately obviously problematic.

I have a vague suspicion about the paths (I remember some difficulties when creating my build system) but I don't remember well enough to really describe it, and I'm not certain I didn't just over-complicate the situation when I set my system up - so let's leave that thought for now (hopefully it isn't a real issue).

I've attached my AF PPL(s). I chose to group them differently to you - but hopefully you could try these and see if they work for you (there are debugging enabled/disabled versions, but AF_Debug is stripped if I recall correctly).

They were compiled to target a cRIO-9045, which based on your project (with 9047) is hopefully close enough (although I don't know for sure... 😕 )

Can you confirm (because otherwise, I'm probably looking in the wrong direction) that you can't use your AF PPL on cRIO at all successfully? Have you tried building an RT-EXE and running that instead (rather than interactive running, which is what it sounded like you were doing in your post)?

Edit: A minor additional note - these are the AF libraries taken from LabVIEW 2017 (I'm pretty sure) and compiled in 2019 with forward-compatibility. I use them daily with LabVIEW 2019 SP1, but they should work for 2020 too (I haven't tested closely with cRIO/RT module deployment and different runtime versions, but it works on desktop and it seems sensible to believe the same promises are true for RT...). If you're not able to get them to work in 2020, maybe try in 2019 if you have the chance (although I know changing the RT module versions is a pain, and if you already moved forward, you probably don't want to move back...)

[Jonzarwal]

Hi Christian,

We've been thinking about all this and we want to try it again.
You say you've developed a build system that does the painfull job for you. We want to go further in this way (all our source codes are in Git repos and each is organized in a standard structure). Is it possible for you to give a little bit more informations about your builder / share some of your code to help us start building our own specific build system?

[cbutcher]

Hi again,

Sure, I've been half-meaning to try and publish more of the code/information about this for a while, but without someone actually needing it it doesn't generally rise to the top of my "things-to-do" list.

I'll try write something up and then post here with a link to some description and (probably partial) code.

In the mean time, if you PM me an email address I can send you a zip file (or directly add you to the private repository) for the code I'm using, but it has a bunch of paths and URLs you'd have to change to be able to use it more generally (e.g. it constructs GitHub URLs relative to my organisation's repositories, and the list of repositories I have will certainly not match yours!)

It should still give you some idea of if you want to try it or not though.

[crandiba]

Hi Cy,

Same exact issue here; I was wondering if you had some success with that Cy.

I suspect many others are also fighting with the same issue...

Thanks!