LabVIEW Real-Time Idea Exchange

About LabVIEW Real-Time Idea Exchange

Have a LabVIEW Real-Time Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW Real-Time Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW Real-Time Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW Real-Time!
Top Authors
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.

13 Comments
nathand
Proven Zealot

If the proposed solution is to run VI Analyzer, perhaps there could be an option in the build specification to run VI analyzer prior to building an application?

MichaelWestwood
Member

I found this out the hard way since I regularly use an Enum typdef and the strings property node to return the strings in the enum thus retaining integrity when the typedef is modified.  I find it bizzare that such a propery of an object would be removed in the deployed realtime bin files, but work fine in the dev environment. WTF?  Since one cant access And to have not so much as a warning when placing the property node on the diagram or compiling? This is not acceptable. The code just breaks in a really insiduous way. I would feel better if there was a way of referencing a block diagram constant properties, but I am not aware of one.

 

 

I confidently deployed a "working"" system in front of the customer and looked like a total fool when thier expensive all singing all dancing CVS 1458  sat there like a doorstop...and I had to run to catch my flight home from Ohio to South Africa.

 

I am less than impressed.This is so unlike NI. 

 

 

Mike

MichaelWestwood
Member

Hi,

 

I Have fallen foul of this nasty little "feature" before and I'm now working on adapting some mature software that runs on windows to run on a realtime CVS1458. I want to still be able to run in on Windows or RT so I'm using Conditional Disable structures. I'm using LV2015, so I have the  realtime VI analyser tools, however property nodes are listed as faults even is they are disabled and since it only lists 5 faults per vi, I have no easy way of finding the rest. 

 

Any advice?

 

Mike