LabVIEW Real-Time Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
nathand

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

Status: Completed

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.

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.

14 Comments
Tanya_V
Active Participant

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

Tanya Visser
National Instruments
LabVIEW Group Manager
nathand
Proven Zealot

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
Member

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
Proven Zealot

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
Member

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

LabBEAN
Active Participant

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.


Certified LabVIEW Architect
TestScript: Free Python/LabVIEW Connector

One global to rule them all,
One double-click to find them,
One interface to bring them all
and in the panel bind them.
Shamloo
Member

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
Member

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
Active Participant

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
Active Participant
Status changed to: Completed

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.

Deborah Burke
NI Hardware and Drivers Product Manager
Certified LabVIEW Architect