topic CVT vs Shared Variable Engine in Components

Current Value Table (CVT)

Doug_S — Tue, 03 Jan 2017 20:20:06 GMT

Post your questions or feedback on the Current Value Table (CVT) component here.

Installation minimum OS mismatch

Imaginatics — Mon, 05 Nov 2007 17:09:41 GMT

Tried to install to a Windows 2000 SP4 system with LabVIEW 8.2.1 and received message:

"This computer does not meet the minimum operating system requirements for this product. Consult the documentation for operating system requirements."

The readme_CVT.rtf file states that that there are None under System Requiremtns and under Supported Targets it lists LabVIEW 8.2.1 for Windows Vista/XP/2000. What gives?

Thanks!

Re: Installation minimum OS mismatch

Christian_L — Thu, 08 Nov 2007 20:09:49 GMT

An updated installer for the CVT component has been posted on DevZone in the CVT example document. The updated installer includes support for installation on Windows 2000.

Re: Current Value Table (CVT)

Gryphon — Fri, 04 Jul 2008 12:30:54 GMT

Hi All,

Let me start by saying that I love the idea of the CVT and it is just the sort of structure I was going to code myself before starting on a compact fieldpoint project. It really looked really good and I jumped into its use with both feet. Here's what I found. Not sure if anyone is going to read this as it seems to be a pretty quiet thread but what the heck...

1. I am using lv 8.5 and I found that the tag editor executable actually did not save the tags correctly. I tested this on both windows and on the cfp and in both cased when the tag file was read back, it was actually corrupted. This was only really clear when you looked at the data structure carefully. Not all fields were corrupted but the label field which I was using for storing the address of IO points on the cfp backplane was corrupted. I ended up having to write my own editor.

2. The biggest problem I have had is that the CVT read and write of doubles which looks perfectly sound, does not work when built into an executable. It works fine when run from the host but when put into an exe, it does not work. I have provided code to NI here in Australia and demonstrated the problem and they are trying to get a resolution. It has been 1.5 weeks and its not looking promising. Meanwhile my whole application which works beautifully when run from the development machine on the CFP does not work when built into an exe. If I am forced to take out the CVT, it will be VERY painful. I am sure it will build character.

3. An interesting thing happened when I went to NI to demonstrate the problem on their hardware. With an old CFP2000 controller, a really simple app using the CVT completely filled up the memory to the point that the app could not run.

My conclusion at present is sadly that

1. The CVT is a great idea, looks well written and is an elegant solution.

2. At present there are bugs which may have more to do with the compilation of the exe for real time than with the actual CVT component. I am using it with no problems on a windows project but avoid it if you are targetting real time.

Oh, I forgot to mention my favourite part of the bug with real time exe and the CVT. If the exe is built with debugging enabled and you connect to it via remote front panel, you will see that the doubles in the CVT dont fnxn (the booleans do). If you then try and perform online debugging, labview downloads a swag of vis to the target to allow the host to see the target in debug mode and then walah! the CVTs function perfectly. If you then exit the debug session and reconnect via a remote front panel, the system continues to look to be working perfectly until you cycle power when of course the system boots up with the freaky exe again.

I love labview but I got to say that everytime I build a real time exe, I feel like I'm about to walk the plank... maybe its just me.

have a good weekend all,

Peter

Re: Current Value Table (CVT)

Christian_L — Wed, 09 Jul 2008 16:57:25 GMT

Peter,

Thank you for your detailed feedback. I'd like to help you out with some of the problems you are facing with building the CVT into an executable. Please send me a message at systemseng at ni dot com with your example code.

1. I am using lv 8.5 and I found that the tag editor executable actually did not save the tags correctly. I tested this on both windows and on the cfp and in both cased when the tag file was read back, it was actually corrupted. This was only really clear when you looked at the data structure carefully. Not all fields were corrupted but the label field which I was using for storing the address of IO points on the cfp backplane was corrupted. I ended up having to write my own editor.

The label field is used for a different purpose in conjunction with the HMI portion of the machine control acrchitecture and therefore the contents will look slightly different than what you may expect. In short the label is designed to be used as a label for front panel controls and indicators and supports up to five different languages. These are stored in the label field and are parsed automatically in another set of functions on the HMI. For your purpose the Address field is more appropriate, but unfortunately in the current version is can only be edited using the provided dialog based on the Protocol chosen. We are planning on providing an updated version of the TCE including source code which will allow you to make changes to the editor and configuration file. It will also provide a simple method to add support for other protocol or interface configuration such as FP.

Re: Current Value Table (CVT)

Christian_L — Thu, 10 Jul 2008 22:44:10 GMT

Gryphon wrote:

2. The biggest problem I have had is that the CVT read and write of doubles which looks perfectly sound, does not work when built into an executable. It works fine when run from the host but when put into an exe, it does not work. I have provided code to NI here in Australia and demonstrated the problem and they are trying to get a resolution. It has been 1.5 weeks and its not looking promising. Meanwhile my whole application which works beautifully when run from the development machine on the CFP does not work when built into an exe. If I am forced to take out the CVT, it will be VERY painful. I am sure it will build character.

Peter,

I debugged your code and the problem was not with the CVT. It works fine in an executable. The problem was that you used a front panel control property node in one of your subVIs. Property nodes are not supported and do not work in RT executables. (They do work in RT VIs run from the development environment, which is an unfortuante inconsistency.) Because the property node returned no data (empty string array) the FP Read VI was never being called correctly and no data was passed to the CVT. By removing the property node and rewriting the code around it, your example works as expected in an executable.

Re: Current Value Table (CVT)

Gryphon — Fri, 11 Jul 2008 10:37:49 GMT

Christian!!

Man, you are a star. Thanks very much for your support with this problem. I received the modified subvi you sent to support here in australia and support in Australia tested the fix on their hardware and it works. Woohoo!!

I must say that I did not initially suspect the CVT because it is written in straight labview code and there is nothing mysterious in the implementation but everyone I spoke to at NI said it must be the CVT and I guess I got sucked in a little. Apologies for casting aspersions on a great little piece of work.

I attached my code in the zip file and your modifications to the read input vi so others can see the way I implemented stuff and how you fixed it up as well. Comments are more than welcome. I am really glad that your fix worked as it means I can at least move forward.

Now that I have gushed, I do have a few questions.

1. The use of property nodes. I found that with cRIO that it was absolutely suicidal to try and use property nodes and as such stayed away from them in the compact field point as well. Unfortunately the problem I had 1st manifested itself as a chart not updating with any value other than 0. Support over here told me that I should be using property nodes because on RT targets, local variables would modify values on the block diagram and property nodes had to be written to for the front panel to be updated as well. I was shown a very convincing knowledge base artilce that stated this. I can't find it at the moment but I will post a link as soon as I can find it. The other reason that I felt safe in using property nodes is because the implementation of the data logger on compact field point (anothe excellent piece of NI example code which I really like) has quite a bit of it in use. This project is found at

http://zone.ni.com/devzone/cda/epd/p/id/3221

It has property nodes used and builds into a real time executable and appears to work just fine.

2. The way that I was experiencing failures was that only values from analog cards could not be read and written to using the CVT. It worked perfectly when communicating with digital input and output cards. Falling through to defaul cases would not have explained this either. What do you think could have caused this? Also, while you removed the use of a property node in the read inputs sub vi, the updating of the chart was being done by passing a sub vi a reference to a chart which then updated the value of the chart using a property node. That still works fine as well.

3. I have to ask. How did you debug the problem? When I tried debugging my exe, it was meaningless because everything started working perfectly when I tried to connect to it and labview did its download of support vis to the target. Also lots of property nodes (as described above) were working fine and this made me think that the use of property nodes may have been more acceptable of cfp compared to crio.

4. One of the cooles things about all the real time targets is the ability to serve remote front panels over web browsers. If you had an application (as I do) with more than a 100 I/O points which you need to display on the front panel over sets of tabs (like is done with the data logger example) how would you go about writing to the display elements. The vi would take up a heck of a lot of real estate if updates of the front panel was not being done in sub vis. Have I completely missed out some way of doing this without references and property nodes from these references? What is your recomendation.

I think I'll leave it here for now but I am really keen to understand how to use this stuff well and any insights you can provide into the design intent would be greatly appreciated.

Once again thanks for your help and for going over my code. If anyone has questions about the code, please post here and I'll do my best to explain what I was trying to do. Feel free to laugh out loud at my code.

cheers

Peter

Re: Current Value Table (CVT)

Christian_L — Fri, 11 Jul 2008 15:17:10 GMT

Gryphon wrote:

1. The use of property nodes. I found that with cRIO that it was absolutely suicidal to try and use property nodes and as such stayed away from them in the compact field point as well. Unfortunately the problem I had 1st manifested itself as a chart not updating with any value other than 0. Support over here told me that I should be using property nodes because on RT targets, local variables would modify values on the block diagram and property nodes had to be written to for the front panel to be updated as well. I was shown a very convincing knowledge base artilce that stated this. I can't find it at the moment but I will post a link as soon as I can find it. The other reason that I felt safe in using property nodes is because the implementation of the data logger on compact field point (anothe excellent piece of NI example code which I really like) has quite a bit of it in use. This project is found at

http://zone.ni.com/devzone/cda/epd/p/id/3221

It has property nodes used and builds into a real time executable and appears to work just fine.

I need to modify my earlier statement. Some property nodes do not work in RT executables. Unfortunately I do not know of a list that tells us which work and which don't. Basically if you want to use property nodes you need to verify yourself that the ones you want to use will work in RT executables. Doing some simple testing I noticed that the Strings[] property node works for Rings, but not Enums. There are some underlying reasons why certain property nodes work and some don't. It is not that NI decided to only implement some. i.e. the property nodes that work do so because they need to work for other reasons.

Re: Current Value Table (CVT)

Christian_L — Fri, 11 Jul 2008 16:01:47 GMT

Gryphon wrote:

2. The way that I was experiencing failures was that only values from analog cards could not be read and written to using the CVT. It worked perfectly when communicating with digital input and output cards. Falling through to defaul cases would not have explained this either. What do you think could have caused this? Also, while you removed the use of a property node in the read inputs sub vi, the updating of the chart was being done by passing a sub vi a reference to a chart which then updated the value of the chart using a property node. That still works fine as well.

3. I have to ask. How did you debug the problem? When I tried debugging my exe, it was meaningless because everything started working perfectly when I tried to connect to it and labview did its download of support vis to the target. Also lots of property nodes (as described above) were working fine and this made me think that the use of property nodes may have been more acceptable of cfp compared to crio.

When the property node returned an emtpy string array your logic did not fall through to the default case but the 'cFP-2120' case instead. This case performs the digital I/O so those worked in the executable.

In the example you sent the chart was updated directly. But as I mentioned in my previous post it turns out some of the property nodes will work in executables, but I can't tell you easily which ones.

Debugging: lots of changes to the VI and a lot of Build/Deploy/Reboot/Connect Remote Front Panel. In the end I added a lot of indicators to the subVI and pulled them out to the front panel of the main VI, so that I could see what was going on inside of the subVI while running as an executable.

Another idea for debugging in the subVI would be to open a TCP or UDP connection to an external system and send debugging strings to the remote system for display. I put together a set of Syslog VIs that would be perfect for this purpose. I guess I need to post them somewhere online.

Message Edited by Christian L on 07-11-2008 11:01 AM

Re: Current Value Table (CVT)

Christian_L — Fri, 11 Jul 2008 16:35:47 GMT

Gryphon wrote:

3. I have to ask. How did you debug the problem? When I tried debugging my exe, it was meaningless because everything started working perfectly when I tried to connect to it and labview did its download of support vis to the target. Also lots of property nodes (as described above) were working fine and this made me think that the use of property nodes may have been more acceptable of cfp compared to crio.

4. One of the cooles things about all the real time targets is the ability to serve remote front panels over web browsers. If you had an application (as I do) with more than a 100 I/O points which you need to display on the front panel over sets of tabs (like is done with the data logger example) how would you go about writing to the display elements. The vi would take up a heck of a lot of real estate if updates of the front panel was not being done in sub vis. Have I completely missed out some way of doing this without references and property nodes from these references? What is your recomendation.

I forgot to mention in my previous post, from a LV RT perspective cRIO (9002/9004) and cFP are virtually identical. Except for the I/O the controllers are very similar and how the SW behaves will be very similar. The newer cRIO controllers (9012/9014/9072/9074) use a different RTOS underneath so there may be slightly more differences, but if you are programming in pure G most things will still be the same. Some DLL/shared library dependent drivers/functions/toolkits may behave differently.

Back to the property nodes, I think most of the Value property nodes for front panel indicators will work with control references in subVIs. I just tested the Chart and it works. Of course you will want to verify any other indiciators that you may be using in your application.

Another idea is to use a Case structure in your main diagram that matches the different tabs in your tab control. In each case you only update the indicators on the specific tab being shown. Of course for charts you will want to update them all the time to keep the continuous trace going.

Re: Current Value Table (CVT)

Gryphon — Sat, 12 Jul 2008 07:05:28 GMT

Hi Christian,

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

Re: Current Value Table (CVT)

Gryphon — Sat, 12 Jul 2008 07:33:40 GMT

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.

Peter

Re: Current Value Table (CVT)

wireman — Wed, 10 Feb 2010 19:21:58 GMT

I think when I install the cvt200_installer.zip I am missing the <user.lib>\CVT\_compatibility\CVT Enum Read.vi. However, it seems to be included in cvt200_zip.zip. Is there a reason the installer installs a different set of VIs? Or did I miss something?

-Nate

Re: Current Value Table (CVT) missing VIs

wireman — Wed, 10 Feb 2010 19:27:20 GMT

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

-Nate

Re: Current Value Table (CVT) missing VIs

Christian_L — Thu, 11 Feb 2010 17:46:27 GMT

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.

Re: Current Value Table (CVT) Save Tag List

wireman — Fri, 12 Feb 2010 21:06:41 GMT

Thanks very much!

Is it possible we could have a CVT Save Tag List.vi that is analogous to the CVT Load Tag list.vi?

Listing the Benefits of CVT will be Useful

AustinManinTown — Fri, 29 Oct 2010 14:11:41 GMT

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.

Re: Current Value Table (CVT)

rwunderl — Fri, 01 Apr 2011 20:42:02 GMT

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!

-Richard

Re: Current Value Table (CVT)

Gryphon — Mon, 04 Apr 2011 01:24:45 GMT

Hi Richard,

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

Peter

CVT Core

Mads — Tue, 24 May 2011 10:46:51 GMT

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.)