From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
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.
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?
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 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.
Did this discussion make any broader progress? I just spent a lot of time trying to debug some shared variable references which broke without error when running on a RT target. I'm assuming it is related to the problem in this discussion, but haven't found any direct references to it. My program ran fine when executed from my development machine (which shows a front panel on the VI) but always failed when running headless on the target.
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.