Opinions on the CVT Client Communication (CCC) Reference Library?

[drjdpowell]

I'm helping a new client that has existing code that heavily uses the Current Value Table (CVT) library and the network extension CVT Client Communication (CCC) Reference Library.  Does anyone use these libraries and what are peoples opinions on them?  I would particularly like to know if it scales well to large numbers of CVT values.  The authors of these packages seem to have moved on to DCAF, which makes me worry that there are issues in using CVT-CCC.  

[Tim_S]

I used the NI CVT as a reference. There was nothing wrong with the CVT itself, but I needed something that worked with objects in packed libraries (plugins) which don't seem to share the same memory space.I didn't use the CCC with my inter-application communication.

Not used DCAF before... just getting back to looking at it now because of your question. Looking at a demo video of DCAF, it's not an equivalent to CVT. CVT only stores values for read/write where DCAF can interface with hardware, run PID loops, etc., where storing values is a subset of what it does. This video goes through how the DCAF engine works. CVT is meant for asynchronous accesses from a central repository; DCAF appears to iterate through each, object that is configured/loaded in the system using strict by-value data transfer.

[smithd]

Actually the memory space issue was the original original reason we moved to dataflow for what eventually became DCAF. Early concepts for that library involved sharing CVT tags between plugins, which got replaced with the calling process being responsible for sharing the values via dataflow. The other big issue is that if you use a global variable, like the CVT, you run into the problem that reads and writes are not coherent for sets of values...that is, if you wish to write the cluster {value=1, time=blah, accurate=true} that would be 2 or 3 separate write actions and a consumer wouldn't necessarily know that all values were from the same 'sample' if they were read out. Having the DCAF engine orchestrate plugin calls and act as the synch point for large data sets was also a driving factor. The implementation doesn't really preclude use of the CVT (I don't know that its ever been used, but I made a CVT-based engine at one point), its just that when you have a single labview process passing data around it makes more sense to use dataflow.

As to performance, all the accesses are simple subroutine-priority FGV accesses so an individual read is pretty quick. If you knew what values you want to use up front you'll definitely get more better performance from a set of DVRs of clusters -- the locking is equivalent, but you solve the coherency issue above, you can create as many separate and distinct locks are you might wish, and with 2017 you can do parallel reads. The CVT is geared towards more dynamic situations. The slow part of the CVT implementation is the lookup (name->index). Theres a variety of 'advanced' functions to let you look up the index of each value early in the run of your application which brings performance back to just a few checks and then the FGV read operation which is quite fast. In general, the number of 1000 was always kept in mind as an intended number of tags. It can of course go much higher, but I think trying to keep 1000 individually named global variables in your head is hard enough, let alone more than that. Because it is a FGV-per-data-type, you will by definition eventually run into contention issues but thats going to be dependent upon your application.

The alternative implementation I've seen is using queues (https://lavag.org/topic/14446-viregister/?page=1) or notifiers. If CCC is your main interest, something more standard like OPC UA might be a better fit.

 

[drjdpowell]

Thanks, both of you.  Sounds like the only major issue with the CVT is the non-atomic update of sets of values, which presumably can be managed by clusters of related info.

[drjdpowell]

Follow-on question: Why does the CVT NOT have a Variant type?!?   I was going to suggest to my client that they could both significantly simplify their code and guard against race conditions by grouping data in cohesive clusters, but that doesn't seem possible due to the lack of a variant type in the CVT.   Why is it missing?

[Taylorh140]

Is it just me or is NI really bad at actually describing what their products do? I had no Idea that DCAF even fell in the same realm of function as CVT. I thought it was some kind of generic configuration distribution tool thing. I have mixed guess about the variant support, on one hand its nice to know the specific type (of course you could query this with variants), they use variant attributes for the back end so i don't see any reason they the couldn't have included them.

[JKSH]

3 hours ago, Taylorh140 said:

Is it just me or is NI really bad at actually describing what their products do?

To be fair, I think DCAF is quite well-described at http://www.ni.com/white-paper/54370/en/ and http://sine.ni.com/nips/cds/view/p/lang/en/nid/213988

 

3 hours ago, Taylorh140 said:

I had no Idea that DCAF even fell in the same realm of function as CVT. I thought it was some kind of generic configuration distribution tool thing.

(Image from http://sine.ni.com/nips/cds/view/p/lang/en/nid/213988)

The configuration aspect just one part of DCAF, and CVT fits inside the another part: The "Data Exchange". So, I'd say that DCAF can contain CVT functionality, but CVT doesn't do most of what DCAF can do.

Edited March 16, 2018 by JKSH

[Taylorh140]

I just installed DCAF through the VIPM. Interestingly enough it uses the NI Current Value Table as a dependency. So maybe there is no worries after all to your initial post.

 

[smithd]

The DCAF CVT module copies data from the inside of the engine (where data exists on the wire) to the CVT -- so while the core components do not depend on the CVT, that particular package serves as a bridge.

As for why the CVT doesn't have a variant type...it was proposed often enough, but somehow never happened I guess. I honestly dont remember why. The CVT includes a set of template functions and a generator for any types you might want, so that would be the solution. If you did a pull request on github I would imagine they'd be happy to accept the change.

Edited March 17, 2018 by smithd