Showing results for 
Search instead for 
Did you mean: 

Current Value Table (CVT)

@Mads wrote:

What do you men by fast lookups? The way the CVT works now (not 4 years ago) its lookups are super-fast because they are only used to find the index of the data. The data itself is not stored in a variant (which it was at an early stage of the CVT). AND the lookup is skipped if the value you are requesting access to is the same as on the previous call (static tag). There is an even faster mode where you hard-code that this is a fully static call (meaning the tag to be accessed will never change at run-time), but the difference is very small, its a factor of around 1,3x - not 100x (and even this mode could be changed to accept run-time changes to the table if needed without much of a penalty).

By fast lookups I mean the 'read index/indices' functions, where you perform the lookup separately from the read. This works well for simple loops like the CCC, where you look up before hand what data you want to send to the client, and you never need to use or care about the name after that point. I don't remember the exact values but yes any situation where you allow the caching to work is about the same speed, and any situation where you can read multiple items at once (read multiple indices, group reads) are significantly faster as there is only one lock on the FGV. So yes, if you are doing dynamic lookups of single values CVT doesn't provide any benefits but if you are building something that deals with a lot of values in a generic way, it can be many times faster than anything else I'm aware of.


@Mads wrote:

The changes I propose do not change any of that, it just makes the CVT a better solution for use in more dynamic applications where users might for example add or remove devices regularly, which in turn means that there are new tags to include/exclude in the CVT....So this is about making *more* people happy, not about removing/ruining anything for those (like you guys) who like the CVT (only) as it is.  

I don't think anyone is arguing that it would be nice, its just questionable if its worth the effort given the other options out there which are better suited to the need.




0 Kudos
Message 161 of 164

I was doing some benchmarks for getting higher throughput with the CVT.

My suggestion = in Double_Memory - > Read Group.

A copy of the whole content is made going into the ForLoop.


I suspect that because the data is not in a shiftregister, each iteration a new copy of the memory is even made ?


After adding a shiftregister a got a speedup of a couple %

This would also benefit all other data types.

Floris Reinders
Senior Project Engineer / CLA
0 Kudos
Message 162 of 164

Hi. I am using a CVT for managing configuration parameters on a real-time target.

During development, I noticed that once I have deployed my application to the RT target, every time I try to reconnect to my target (with an already running VI) it will display a message saying that the CVT version on the target and the one on the project do not match. The only option is then to close the running VI and thus I lose the state of the VI (particularly painful when debugging). Is there a way to avoid this message?

CVT problem.PNG

I believe there is no CVT component that needs to be installet to the RT target through MAX. 

Also, I do not explicitly include the Current Value Table.lvlib in my LV project, so it appears as a dependency within vi.lib.



0 Kudos
Message 163 of 164

Known Issue:

Connect/Disconnect to a RT target uncovers CVT library mismatch between target and host

0 Kudos
Message 164 of 164