Warn about front-panel property node use when building RT application

[nathand]

Inspired by this post, and my own experience trying to debug a problem that only appeared when I compiled an RT executable, LabVIEW should warn the user when compiling a real-time application that contains property nodes that require access to the front panel, since those property nodes will not execute properly in an RT application and it can be very difficult to find the source of the problem if you don't know this.

[Tanya_V]

Hi nathand,

Thanks for posting this suggestion. I'm in the process of developing a RT application checker that will look for common problems in Real-Time applications. Suggestions like these help me cover the most common problems.

I'm working on this as a side project, so I can't provide an exact timeline for when to expect the tool. When it's completed it will be posted on the DeveloperZone.

Regards,

Tanya V

LabVIEW Real-Time

[nathand]

Another forum question resulting from the use of property nodes on RT (this one didn't require the front panel, but should generate a compiler warning):

http://forums.ni.com/t5/LabVIEW/Problems-with-startup-vi-s-using-TCP-on-a-cRIO-error-code-63/m-p/182...

[Franjo_Tonkovic]

I wanted to write similar proposal beforeI found this one. I just spent few hours of debugging because of this. My application is rather complex so it took me a while to figure out what was happening. Some kind of warning would be great!

Thanks in advance!

Franjo

[nathand]

And yet another example of property nodes causing difficult-to-debug problems in an RT executable: http://forums.ni.com/t5/LabVIEW/cRIO-Troubleshooting-creation-and-deployment-of-startup/m-p/1968105#...

[kkguner]

I had a similar problem. I spent 2 days for debugging. Some kind of warning about front panel items would be great!

[LabBEAN]

Ryan in AE is looking into the root cause of this, but I ran into an issue where I used a VI written for the PC that used the "Application Directory" primitive, which is not supported in RT (in at least one of the OS's, the primitive reports C:\ni-rt\startup\startup.rt.exe\ as the directory).  Symptom:  the cRIO would start running the startup.rtexe and then spontaneoulsy reboot.  Would be nice if the "RT Application Checker" that Tanya is working on would also check for "Application Directory" useage.  Note:  Application Directory alone did not cause the crash... could be related to feeding the mangled path into Set Permissions.

[Shamloo]

I used "NumItems" propety to extract number of elements in an Enum. This was for Real-Time appication. LabVIEW did not give me any warning or error and I surprised when I noticed the code is not going to work on the RT. It's has been source of bugs and confusion in our compnay.

[Fred.Schimmel]

I was a victim of this pitfall (use of "NumItems" property to retrieve the number of elements in an enum) too, so I agree with the other comments: a warning would be very convenient when in some way a control or indicator is required for execution of the code that is/will be converted to a RT-executable. The way it will be presented is less important; a separate application (like VI Analyzer) or as part of the consistency check before deploying, everything is better than be puzzled why the executable doesn't function correctly.

[GregSands]

I just came across this idea after writing about my own frustrating debugging of the same, and similar, problems (in my case, use of Network Shared Variable nodes, and binding front panel controls to Shared Variables).  As well as a pre-build warning or code check, I would also like LabVIEW to be able indicate why an RT app is broken when it is run, as it may be that a code checker couldstill miss some issues.  Some equivalent of the error list window that is available using Debug Application, or a file that is saved, or a web page with the information - anything would be useful, and save hours of disabling sections of code, rebuilding, rebooting, ... 

Tanya, did your side project go anywhere?  We're now three years on from the original message, and this is still annoying!

[Deborah_B]

Hi all, 

With the LabVIEW 2014 Real-Time Module release we included some RT-specific VI Analyzer tests- this is the output of the initial project Tanya mentioned. The block diagram is searched for "offending" gObjects that meet conditions defined by each test. The analyzer returns a report to the user listing the test failures with a description of the problem, and how to resolve the problem in the RT context.

You can find these tests after you install 2014 here: C:\Program Files (x86)\National Instruments\LabVIEW 2014\project\_VI Analyzer\_tests\Real-Time Module\Front Panel Property and Invoke Nodes.llb

If anyone runs the tests, we welcome any feedback here.