Components

cancel
Showing results for 
Search instead for 
Did you mean: 

Current Value Table (CVT)

Hey David,

 

There is not, and that was a deliberate choice in the same way not being able to delete a tag was a deliberate choice. Because of the cacheing mechanism implemented in every single read/write function, we need to be able to ensure that the indices we are looking at are always valid. If you delete a tag every lookup in the system would have to be performed again. If you delete or modify a group, every group in the system would have to be looked up again. During development, we didn't have a good use case for changing the contents of a group (usually we form it at init time) and so we opted to discourage that--changing the members of a group--rather than trying to figure out how to force every lookup in the system to re-initialize.

 

It turned out, later on, that the FGV nature of the API actually caused an interesting condition to occur when you are using the CVT in the dev environment and re-initializing it multiple times. The FGVs are all set to clear, but the reentrant read/write VIs are not, and as a result we ended up looking up data from old indices. Its kind of a corner case (we only caught it recently after unit testing another set of code), but we implemented a reset mechanism in the standard "safe" read/write functions. Something similar could be implemented for groups.

 

Thanks,

Daniel

Message 81 of 164
(7,859 Views)

Great explanation, thanks!

0 Kudos
Message 82 of 164
(7,855 Views)

Currently I'm upgrading my development environment from 2012 to 2013 SP1. My application relies on several libraries (CVT, CCC, STM, TCE, AMC, HNE, CIE)

During the installation the it was discovered that two reference libraries has changed. CVT and AMC. For AMC I could find the old version compatible with my application, but not for the CVT

Please help me to answer the following questions so I can make the right decision about how to proceed.

1. Please provide download link for the old CVT 2.0, I cannot find it on the CVT home page

2. Have you a GUI/TCE for CVT 3.xx yet?

3. I did a initial test upgrade, but it could not find the required vi's. How API compatible are the versions? Do I need to go in and replace all CVT calls manually?

4.Can installations of CVT 2.0 and CVT 3.x coexist without cross linking.

5.CVT 3.xx is claimed that the index lookup is much faster than the CVT 2.0 index lookup. I looked at the implementations and the storage mechanism is very similar so from where does the performance improvement come from.Why do you not use inplace structures in the storage mechanism?

0 Kudos
Message 83 of 164
(7,794 Views)

Hi Petter,

 

Both CVT and AMC should be backwards compatible. For AMC, the compatibility VIs are red and should be stored here:

LabVIEW 2013\vi.lib\NI\AMC\Compatibility

For CVT, the icons match the old style icons, and should be stored here:
LabVIEW 2013\vi.lib\NI\Current Value Table\Compatibility

These compatibility VIs are in new locations. However, they are stored in VI lib so as long as you give LabVIEW a few moments to find them (you'll see a search window pop up) it should do so automatically.

 

It is worth noting though that, depending on what version you had previously, the execution settings for some of those VIs may be off. For example, one version of the CVT previously set the read and write Vis as subroutine priority. These functions are now inlined. Due to a bug in LabVIEW, you cannot add an inlined VI to a subroutine priority VI without also making the inlined subVI subroutine priority--something that doesn't really make sense and causes issues for called code. Long story short, you may need to change a few functions in CIE or CDL which expect the compatibility subVIs I provided to be subroutine priority. Most code should not care. I would argue that, since these functions access a shared resource, they should not be set to subroutine priority in the first place.

 

To your specific questions:

1. The older CVT versions were hidden because of the confusion over the various versions I mentioned above, in an attempt to encourage migration. However, the files are still cached on your machine and are on the FTP site here:

http://download.ni.com/evaluation/labview/lvtn/vipm/packages/ni_lib_reference_library_for_current_va...

The package name was changed, so the new VIs are located here:

http://download.ni.com/evaluation/labview/lvtn/vipm/packages/ni_lib_cvt/

 

2. The existing TCE should still work. It simply produces a standard file format that works across the different Cxx libraries. While the new version of the code shows preference towards a simple XML parser (easy to write, easy to read, easy to code) rather than the more custom XML generated by the TCE. However, the compatibility library still contains the old loader (CVT Load Tag List.vi) and an init function (CVT Init.vi) which is adapts the old tags to the new cluster.

 

3. As mentioned, the API calls should be identical. However, you may see some issues with priority on code which previously called CVT functions. 

 

4. No, the compatibility library makes that an issue. As such the cvt3 package excludes all of the different vip and ogp builds that were made over the years for cvt1 and cvt2. Technically if you remove the compatibility library they could coexist (CVT3 uses an lvlib for namespacing) but I'd recommend against it.

 

5. There are a few main performance boosts:

  • Since CVT3 is built on 2010 and newer, it has access to vi inlining which improves performance by removing subVI overhead.
  • Lookup of indices (ie name->I32) uses a variant attribute, which is faster than the previous linear search.
  • The "normal" api call now caches lookups. Previously the (name->data) conversion would require a linear search on every call. Now the lookup is only performed if the name changed or an error occurred.
  • The "index" api (I32->Data) is now reduced to an inlined call to the main data fgv
  • The "indices" API (I32[]->Data[]) was added in CVT3 and it allows you to fetch a group of data of the same type in a single call. This is faster for more than 2 indices then the normal index lookup. It also  has the advantage of being atomic access (one call to the FGV).
    • This can be useful in particular situations to use as a sort of fixed-size array since you can access single elements while simultaneously grabbing the full "array" as needed. This is in contrast to the full array support added in 3.3, which requires pulling the array out of CVT before indexing it.

As a final thought, it sounds like you're using a significant amount of CVT-related code. Since TCE, CIE and CDL have not yet been updated to support the new data types, you may not get any benefit out of an upgrade. CCC has been updated, but without a TCE update you can't configure it. In addition, CIE is very low on the priority list since most scan engine variables are DBL or Bool, both of which are already supported. Updating everything is certainly a goal, but for here and now you may be better off sticking with v2.

 

Thanks,

Daniel

 

 

 

Message 84 of 164
(7,783 Views)

Daniel,

 

Thanks for all information. It is exactly what I need to know. I'm phasing out the CIE, but still as you say I need TCE and CDL so I will await an update on the TCE before I migrate (I will look into the spreadsheet alternative). May I ask when you think the TCE  will be re-written?

 

Thanks

 

Petter

0 Kudos
Message 85 of 164
(7,755 Views)

Hey Petter,

 

We're trying to build out a slightly higher level architecture to solve some of the problems we see in a more complete way. Our end goal is a set of reusable components, like CIE, CCC, etc which can be used as plugins in a variety of situations, and reusable APIs for configuration of these components (ie from an editor like TCE). While this work is in progress, it may still be a long way off -- development is not our primary job.

 

That having been said, I'm curious if you have any feedback on the current architecture--anything at all. If so, please send me a PM. It sounds like you've been working with this architecture for a while and I'd like to know if you came to the same conclusions we did, or if you've noticed other things that we haven't.

 

Thanks,

Daniel

0 Kudos
Message 86 of 164
(7,740 Views)

When creating group tags in CVT3 and saving the XML file to disk, everything looks good and loads back fine. However when I read a bolean group it seems to only display n-1 tags, I have duplicated this with test groups and it only seems to happen when bolean groups are read not doubles. Any ideas?

0 Kudos
Message 87 of 164
(7,684 Views)

Hey Nasu,

 

I've made a quick test and am unable to reproduce your issue. See attached.

 

Can you attach a very small example which demonstrates the problem?

 

Thanks,

Daniel

0 Kudos
Message 88 of 164
(7,669 Views)

What I have found is 1 to 3 boleans in a group is OK but more is iffy. Attached is the code I used to test. You can see the 'Test' group has 5 tags but when they are read back it is only reading 4.

 

 

I think I found the problem, one of the tags was accidentally a double...arg.

0 Kudos
Message 89 of 164
(7,665 Views)

Ah, thats too bad. I'm glad you figured it out.

 

Is there anything we could do differently in the library which might make it easier to detect this type of error?

 

Thanks,

Daniel

0 Kudos
Message 90 of 164
(7,645 Views)