VI not found after building RT application on cRIO

[TintinC]

Hello,

I've just finished an RT application that I want to deploy on my cRIO by building from project explorer.

When I build it I have no errors, but when I run as startup and connect in debugging I see that some VI are not found ...

I don't understand, especially since during compilation I get no errors ...

Do you have any ideas?

[Bob_Schor]

The best (and fastest) way for us to help you is for you to develop a small "Test Project" that does something very simple on your cRIO (like toggle a Digital (or Analog) line up and down at 1 Hz for 20 seconds and then exit).  Include a Build Specification in your Project.

We don't know anything about your LabVIEW environment (because you failed to tell us) -- in particular, we don't know whether you are running 32-bit or 64-bit LabVIEW, nor which Version of LabVIEW you are using.  Many of us are using older versions of LabVIEW (such as 2019 or 2021), it might help to "Save for Previous Version" your Project.  You should then right-click the Project Folder, use "Send to" in the Drop-down, and choose "Compressed (zipped) folder".  Attach the ZIP file, along with information on your LabVIEW environment, and we can probably help you "do what you want to do" (even if it can't be done exactly the way you are trying to do it).

Bob Schor

[TintinC]

Hello Bob_Schor,

I knew I had written this post a little too quickly ...

To answer your question:

• I tested a single VI with a cRIO LED blinking --> It works.
• I'm using the Labview 2024 Q1 64-bit version.
• I can't distribute my code.

Note that I've already compiled other projects on other cRIOs with the same software version.

In the current case, compiling simple code works.

In my opinion, I must have some dependencies that get lost during compiling...

I've already tried to put all the VIs in “always included” but to no avail.

[TintinC]

Small update:

I deactivated several VIs and relaunched the code, see the image below:

I then activated only the “error handler” VI and I see that it, for example, is broken:

 

digging down to the root of the sub vi, I see that the low level is functional but that just above it it's broken, I don't understand, whereas when I run the program via the project I don't get any bugs ...

As a result, this sub VI is used in almost all VIs to collect errors (initial VI in the LabView RT template that I haven't modified and that works with another project).

I don't understand why the VI is broken.

I'm lost ... 

[Bob_Schor]

Except for the very first LabVIEW RT project I "inherited" when starting to learn LabVIEW (a huge monster, hundreds of VIs and TypeDefs, 95% (my estimate) of them with no Description or documentation, running on Windows XP and LabVIEW 7.0, almost all of my LabVIEW RT experience has been with linked Host/Target configurations, with all of the User I/O on the Host, and communication between Host and Target was via Network Streams.  I configured a Target-to-Host Stream that tracked the behavior of the Target (largely by sending to the Host the States of the Target State Machine, with TimeStamp and Argument list), which usually got me sufficient information ("Where were you when the system went awry?") to point me to a likely trouble spot in the Target.  In some cases, I spun up another "Debug" Network Stream that could send time-stamped information about other variables, as needed.

I understand your situation is more complex, and you might want to do more "hands-on" focused debugging, with breakpoints, highlight execution, and probes, on the RT side.  The problem is the RT side may have timing restrictions that make "manual debugging" impractical.  If you can use "streaming debugging", such as listing States entered (for a SM Architecture) with TimeStamps, you might at least get a clue where in your RT code things might be amiss.

When you "find the bug", you might consider at least reporting the nature of the bug, how it arose, and how you fixed it (so we don't do the same thing!).

Bob Schor

[TintinC]

I use this very method to return errors on a network feed (see template labview real time). But since I can't connect to the cRio, I can't receive the bugs.

The cRIO is “blocked” (I wouldn't even know how to say exactly) and I really have the impression that some VI or other is missing.

“When you “find the bug”, you might consider at least reporting the nature of the bug, how it arose, and how you fixed it (so we don't do the same thing!).” --> If I knew, I'd say so! 🙂

Thank you

[TintinC]

okay, I found a few leads:

- I built one of the VIs that was “not found” when the RT project was fully compiled, then I disable all the VI's elements and reactivate them as I go along.

I concluded that, basically, it's the def types that are making the mess:

On this VI, only the def types (and the global variable, which contains def types) mean that when I build the VI it doesn't work.

Any ideas on why def types are messing things up?

Thanks in advance

[Bob_Schor]

Hello, M. TinTin.

     When you say "def types", are you referring to a Type Definition saved as a .ctl file?  Every Enum I define, every Cluster I create, I save as a TypeDef and use it in my code.  Never had a problem with this.

     Unfortunately, the figures you attached a .png files were too small and blurry for me to read and understand.  Can you create a "Debug Project" that include a "problem TypeDef" and a VI that references this TypeDef and attach it so I can begin to understand where the problem might be?  I was going to say that you should "Save for Previous Version", but I might have access to a LabVIEW 2024 system to look at your example ...

... and who knows, maybe building such a Debug demo will "shake something loose" and you'll say, "Oh, there it is ..."  (If this happens, please tell us the source of the problem, and the solution).

Bob Schor

[TintinC]

Hello Bob_Schor,

Thanks for your feedback,
I agree, I've never had problems like this with type def (yes TypeDef and not def type ... )

Before I do the little debugging operation you suggest, I've just noticed something: the VIs that are in the dependencies are “strangely” the .VI/.ctl that causes problems in the code snippets here and there.

When I look at another program, these TypeDef had been duplicated (.ctl for the UI and .ctl for the RT, even though they do the same function) so in dependency there are only vi.lib and .dll.

Could these dependencies be the problem? I'd say they're not included in the compilation, which breaks the VIs? Have you had any experience of this?

For the moment, I'm going to duplicate everything in the dependency and re-test.

If there's no surprise (🙄) then I'll do the little trick you suggest.

Thanks a lot!

[TintinC · Accepted solution]

Hello everyone,

I've solved the problem!

The cause: the VIs in the dependencies ...

In fact, when the code compiles the VIs, they are not found in the cRIO, which is why I get no errors when I build.

Good to know!

On the other hand, I'm having trouble understanding how to keep VIs in dependencies?

To solve the problem, I had to duplicate the VIs between the UI and the RT. So since both share the same def type, I have to create two, which makes programming more complex because everything has to be updated twice...

Translated with DeepL.com (free version)