Re : The Labview code runs fine but the executable doesn’t start on my cRIO

[Fredrabine]

Hello,

I’ve done my homework so it’s not one of these problems:

http://digital.ni.com/public.nsf/allkb/52E943F7D6E7C0578625720A001DDF6E

I changed the CompactRIO of one my test benches from 9074 to et 9035 (linux based). I programmatically increased a little the depth of the FIFO buffers but, apart from that, it’s the same code. It runs perfectly under Labview 15 SP1 (and all other software/drivers up to date on PC and rio) but the compiled Real time executable does not start, as proven by the user LED which I change the color of before executing anything else.

It’s not a compilation parameter as the rtexe runs when I remove part of my code. Of course, I tried to find which part is my problem but almost anything I add (without any common functions) makes the rtexe unstartable. Anyway, the code used to work and now it does not even start.

Is there something (code, parameter, etc.) that can work on 9074 and not on 9035 if compiled?

I’ve found a workaround by deploying the code and starting the vi automatically instead, but I have other cRIO units to upgrade and I’d like not to have to use the workaround every time.

Clue?:

When I created an RT code distribution Labview reported errors because of “double bytes” characters (French letters) in some VI names. Correcting the names did not solve the rtexe problem. This could this be a clue but there is no such characters in the VI names and the code  I add to a working executable and that renders  it unstartable.

[AllamSamir]

Hello Fredrabine,

Which functions did you remove to make it work ? At first sight, there isn't any element that works with 9074 and not with 9035.

Concerning the end of your post, indeed, it is important to name your VIs and code without any accent. Are you sure that no invalid character remains in your project ?

Best regards,

[Fredrabine]

Update: 

Thank you for the reply. It took me some time to get access to the bench again so I could try out some ideas.

The French letter in a VI’s name was one of 2 problems with the same consequences!

I was at a point where a subVI of my RT Main was preventing the RTexe to run although it had virtually no code left inside. I took what remained outside the subVI and it worked.  The problem was therefore an entry point, probably the FPGA reference control, which would be logical as my FPGA changed when I changed the cRIO controller. It was bound to a typedef as it is good practice for code maintenance  so I disconnected it from the typedef and… the RTexe ran!

I tried putting back the type def by creating a brand new “open fpga VI reference ” node , binding it to a brand new type def control file, and copying and pasting the control created form the exit wire to the subVIs. Rigorously. But this didn’t help.

So disconnecting from the typedef works but why? No broken wire, no red dot, the VI runs under Labview… as far as I’m concerned, it’s Labview bug.

Note: I don’t use any object class as in https://decibel.ni.com/content/message/90192

[Sam_Sharp]

---

@Fredrabine wrote:

It was bound to a typedef as it is good practice for code maintenance  so I disconnected it from the typedef and… the RTexe ran!

So disconnecting from the typedef works but why? No broken wire, no red dot, the VI runs under Labview… as far as I’m concerned, it’s Labview bug.

---

Disconnecting type defs is listed as Solution #9 on the link that you posted in the original post, although I don't believe their reasoning on that article...

I had reported it as a bug in LV2012 SP1 as I had the same problem with network shared variables that were based on a type definition - it looks like the same issue might apply to FPGA references (although I know I have used them in RT in the past so there must be some sort of edge case where it doesn't work). What version of LV RT do you have on the target (there are multiple versions that work with a particular version of LabVIEW)?

Also, does your code call some functions that were supported on the 9074 but not on the Linux RT RIOs - for example, some of the utility functions for getting things like CPU/memory usage were deprecated and replaced with methods/properties from the System Configuration palette.

[Fredrabine]

Hi Sam,

I did check the option to disconnect the typedefs at build time but it didn't help. This time I disconnected in the code to make it work.

I also had issues with utility functions as you said so I removed them altogether.

I currently use the lastest version on LV2015 on PC and RT systems (CompactRIO 15.5). The code used to work with LV2012 on the old cRIO. All I do, now, is code maintenance so I"m unlikely to need the typedef advantages on this particular application. It's just frustrating not to get to the bottom of it.

[Sam_Sharp]

If you have an SSP, it might be worth contacting NI and raising a ticket with them - you can point them to this thread and give them a zip of your project.