Current Value Table (CVT)

[Doug_S]

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

[Imaginatics]

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!

[Christian_L]

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.

[Gryphon]

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

[Christian_L]

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.

[Christian_L]

---

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.

[Gryphon]

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

[Christian_L]

---

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.

[Christian_L]

---

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

[Christian_L]

---

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.