Finding Root Cause of Broken Deployed RT VI

[billtrib]

I made the mistake of writing a LabVIEW RT application depending on front panel property nodes. It works perfectly from the development environment. The deployed VI will not run. When called up in the remote debugger it shows a broken vi, i.e. it cannot run.

This is a cRIO9068 (linux) with dual cores.  Development environment is LV2014 (NOT sp1) on Windows 7.

So I am now trying to disable things to just get the broken vi to go away without regard to application functionality. I have done the following things:

• Configured the depolyed vi to strip all typedefs.
• Unchecked the link to typedef option in the Open FPGA Reference node.
• Drawn diagram disables around everything that uses front panel property nodes.

The development version still shows a white run arrow, but the deployed vi is still broken. So, I have these questions:

1. Is it OK to use local variables to read the value front panel controls?
2. Is it OK to use local variables to set the value of front panel controls?
3. If front panel property nodes are enclosed in a Diagram Disable box is that enough to get the vi to compile?
4. Because the debugger is looking at the RT system, hovering over the broken arrow reveals a "Show Errors" tooltip just like normal, except this tip is not active (i.e. selecting it does nothing). Is there any way to get the RT system to tell me where the problems are? Blin king the LED is not an option, because the VI is just broken, it won't run at all.

I've got over 3 months of development time into this. The Application Builder was not available to me during development, otherwise I would have stumbled on this a lot faster. Any help appreciated.

Best regards,

Bill

[nathand · Accepted solution]

I think you're looking for the solution in the wrong place. Property nodes won't work properly on RT targets, but they won't cause the VI to be broken (in my opinion, they should break the VI, but that's a separate discussion). Have you checked the Error Log? Right-click the target in the project explorer, and see if there's anything helpful there. If the VI is set as startup, and it can't run, it will probably log some sort of error there. My guess is you're missing a VI that somehow didn't make it into the compiled application.

If the error log doesn't help, then start eliminating other parts of the code, but don't focus on the front-panel interaction.

Below are comments on your questions. Note that none of these will cause a VI that's not broken in the development environment to break when built into an application.

---

@billtrib wrote:
The development version still shows a white run arrow, but the deployed vi is still broken. So, I have these questions:

1. Is it OK to use local variables to read the value front panel controls?
2. Is it OK to use local variables to set the value of front panel controls?
3. If front panel property nodes are enclosed in a Diagram Disable box is that enough to get the vi to compile?
4. Because the debugger is looking at the RT system, hovering over the broken arrow reveals a "Show Errors" tooltip just like normal, except this tip is not active (i.e. selecting it does nothing). Is there any way to get the RT system to tell me where the problems are? Blin king the LED is not an option, because the VI is just broken, it won't run at all.

---

1 - 2. Local variables work normally in RT, although their use, as usual, is discouraged - especially in RT where there's no front panel.

3. As mentioned above, property nodes will not cause a VI to be broken (they just won't work right), and the diagram disable box won't affect this.

4. Check the error log.

[billtrib]

Interesting. The error logs just say the VI is broken, they don't give any clues as to why. Thanks for the comment on the property nodes, what I think you are saying is that including them won't break the vi but running them will throw errors. This is good news, because what it means is that I can still use all that code behind button push events that can only happen if a panel is connected.

[billtrib]

So, I guess the big question is short of stripping everything out and rebuilding is there a way to get better logs or some other way to see what's broken?

[billtrib]

I will look this over more closely tomorrow. Fortunately I have this thing in version control, so I can quickly restore it to the initial state before all the changing to make it work took place. More tomorrow.

[nathand]

---

@billtrib wrote:

So, I guess the big question is short of stripping everything out and rebuilding is there a way to get better logs or some other way to see what's broken?

---

I've never seen this particular problem, and I haven't worked with a Linux cRIO (although I've used other RIOs), so unfortunately I don't have any better ideas. Does the Linux cRIO have a console output? If so, you might hook up a monitor and see if anything shows up there. I would think that the error log would contain the same information, but maybe not.

With access to the code I might be able to identify areas where I think there might be a problem, but without any access to code I don't have a better suggestion than pulling it apart (or putting it back together) piece-by-piece until you find the problematic section.

[billtrib]

This was it. I should have carefully parsed and dealt with the log. I had two controls that were on disk but not part of the project anywhere. The development environment picked them up, but the Application Builder did not flag them as missing. Turns out it's not good enough to have them in the general section of the project, you must have them in the RT target section.

Now all I have to deal with are the dependencies on control properties that are empty. This should be straightforward.

You beat phone application engineering support, I showed them the logs when I called them a couple of weeks ago before my vacation, they did not steer me in this direction. They were going down the trail of property nodes, etc.

Thanks again,

Bill

[tdcpopiou]

Hi, I was dealing with the same issue, after investigating I find out that the problem comes from one of my VI file names who were containing a special character that Linux RT cannot read. "A beginner's mistake !" say one of my colleagues ^_^ !