thanks for your response and explainations. I guess the bottom line is to be really cautious with the use of property nodes and do early builds into executables to test their functionlaity. The easy trap is to design and develop the application with tests being done from the host computer (without building exes). I have in the past been told by NI that what works when run from the host should just work when run as an exe but this is clearly only true for a subset of stuff.
I still have a niggling doubt about why the digital IO worked. From the code subset that you saw, the only digital IO was on the processor but in the actual application, all the digital IO worked and this included 2 DO-401
whoops, premature post. Continued from above. There was also a DI module. All the digital inputs and outputs were being read and written to correctly and this was really puzzling. I am not sure I understand how getting an empty string from the value property node would have given me the proper handling of the digital IO which were spread across different positions on the backplane.
I understand that it will need to be a case of testing for the behaviour of the property nodes but it is pretty spooky to get confusing behaviour as I observed.
Bottom line though is that I can move forward at present and that is really great. Thanks again for your help.
Actually, now I seem to missing
<user.lib>\CVT\CVT String GetLabel.vi
<user.lib>\CVT\CVT Double GetLabel.vi
<user.lib>\CVT\CVT I32 GetLabel.vi
<user.lib>\CVT\CVT Bool GetLabel.vi
Any idea where to get these? These are linked from the
C:\Program Files\National Instruments\LabVIEW 2009\user.lib\TAE\Display\TAE Format Alarm History Display.vi
The GetLabel VIs were renamed to GetDescription to be more accurate in their purpose. This change was noted in the Readme file which is included in the CVT installer, but unfortunately is not included in the ZIP distribution.
To correct the error (missing VIs) in the TAE, please replace the GetLabel VIs with the corresponding GetDescription VIs for each of the four data types.
For the Enum datatype you do not need to make this replacement as the Enum CVT was removed from the public API and moved to the Compatibility directory. It includes the older GetLabel VI.
I can see how CVT's can be applied in a number of applications, both Windows and RT based. From a learning perspective it would be useful to list the benefits of using CVT's, compared to other methods (local/global variables is a prime candidate). This information would be very useful for developers wishing to understand why they should go to the trouble of implementing CVT's in place of 'simpler' data strategies.
I know I am almost 3 years too late with this comment, but I feel I should throw this out there anyway so that it may help someone.
The problem Gryphon described of having an RT VI work in development but not in the compilation has been, at least in my experience, solely due to timing issues. Running the VIs in development or in debug mode slows them down to the point of working properly; however, when they are compiled, the speed is too much and the RT processor gets jammed up.
This problem is inevitably solved by being sure to always including some amount of delay in any loop that is not extremely tight. (Yes, this includes For loops too!) Without inserting the delays, the (otherwise untimed) loop runs at full speed, starving the processor and disrupting normal operations. Of course, this does not apply to timed loops since they already have a delay built in.
My only problems related to property nodes have been using too many of them! Property nodes can be an extremely slow way to update things like charts, and removing charts from compiled RT programs (since you can't see them anyway) is always a good thing for the best performance. I usually have some charts in my RT apps for debug purposes (monitoring loops times for abnormal spikes, for example), but when final compile time comes I always either disable the chart updates or remove the chart altogether.
Hope this helps someone out there!
Thanks for trying to help with this point. I do have to say though that your point was not completely accurate.
There are SOME property nodes that are not supported and / or do not function in the expected way in real time targets. The documentation these days is a lot better at spelling this out but I will give one simple example and try and explain it as best as I can.
For the example consider the common case of trying to offer the user a list of configuration files in a ring control. The application reads a directory to see what files are available and lists them on the ring control.
The real time targets do not have a REAL front panel and so while it is possible to pull up a front panel for all the controls that are in the vi, the wya in which your interaction with this front panel behaves is not exactly the same. Again it is important to bear in mind that what we are talking about here is connecting a remote front panel in a browser to a deployed executable running on a real time target. This is not the same as clicking run on a vi which is open in labview when connected to a real time target (crio, cfp etc).
Simple example is you can pull up a remote front pane which has a ring control on it. If you power up you device and programatically assign text items to the ring control, this will execute without any errors. If however you now (after the device has executed this code assiginig text to the ring control) fire up a browser and view the ring control, the ring control will be empty. I am not talking about items that were put in in edit mode in the vi in labview. I am talking about assigning text items using the property node of the ring control.
If you have code that tries to read the selected item in the ring control and then tries to use the string item that is associated with the selection, the code will come back with an empty string because the front panel came into existence AFTER the coder that assigned the text values executed on the PHANTOM front panel. This phantom front panel allows code that tries to read and write property nodes to work with out throwing errors but the actual behaviour is very dependent on whether a front panel was open at the time.
So back to our empty ring control. If you have a button that causes the execution of the code that assigns text values to the ring control again, you will see the ring control values updated as expected. This happens because the browser front panel instance takes on the phantom front panel and starts to behave a little more like you expect. You will now be able to use the enumerated selection and use the string value to execute code as you expect.
If you now close the browser window and fire up a remote front panel on another machine, the ring control will be empty again. What happened? The previous instance of the remote front panel data was lost when the browser session was closed. The PHANTOM front panel became again the only front panel and it does not store data in the way you expect (for some properties). The new front panel is again empty until you click the button to repopulate the ring programatically.
OK, lots of words but I hope it helps reinforce the point. When you use remote front panels or are running on real time targets, be very careful to test the functionality that depends on property nodes. Check the documentation and DO NOT assume that things that work on a PC or in debug mode will automatically work when run as embedded executables. It is still a fantastic enabling technology but do take the time to test before deploying (or doing important demos).
Peace to all
Would it not be better to sort the tag list and perform a binary (getindex) search? The way the table is built now, frequent access to the table will be much slower than it could have been. In many cases it is even quicker to do a sort, and then a binary search - than it is to run the current sequential search.
People will adopt this component very quickly (because it is a great concept) so it should be as optimized as possible, otherwise people might get into trouble late in the development cycle due to the performance with large tables.
(Using variant attribues to store the values could be an alternative as these already have such optimized search functionality in-built...- And you could support alternative data types with variants as well, but that brings in other overhead.)