CVT Client Communication (CCC)

BeCeGa · ‎10-23-2017

Hi xl600, we are not doing any active development on CCC, but we can add the bugfixes. In general for new developments we recommend using DCAF.

In Order for us to add the changes you need to submit a pull request from your branch.

Best Regards

Benjamin C
Principal Systems Engineer // CLA // CLED

xl600 · ‎10-23-2017

I don't handle that situation (I have a small closed test system so if the network cable gets disconnected, everything is lost and has to be restarted).

xl600 · ‎10-23-2017

I started this project a few years ago (Before DCAF) and it would take a lot of effort ($$) to migrate. CCC/CVT has been working pretty well. I didn't know to create the pull request myself so I just took care of that. Thanks!

Dave_Thomson · ‎10-23-2017

I'm glad to hear that bug fixes will continue to be posted. Disappointed that CVT is no longer active. As xI600 said, CVT is a great tool and has been working well. I haven't had time to learn and transition to DCAF, and I'm not sure (from what little I know) that it really hits all the same use cases. It's a bit frustrating to try to keep up with all the latest tools, and when I finally adopt one that works really well, just be told that a different one is currently recommended.

-------------------------------------------------------------
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
Certified Embedded Systems Developer
-------------------------------------------------------------
There are 10 kinds of people: those who understand binary, and those who don't.

BeCeGa · ‎10-23-2017

Hi Dave_Thomson,

CVT is a good tool, also it’s at a mature stage that is why we mostly just fix bugs to it. CVT is part of the Machine Control Reference Application. We used that architecture in System Engineering in multiple applications and it works fine.

Still it has some limits and problems, and the root if it is in CVT. CVT is a global resource and you can’t define scope for it, it will always be global. This has the advantage of making it easy to use but we pay with potential race conditions, name space collisions and in some cases limited code reuse.

In DCAF the backbone is the TagBus that is basically CVT on the wire, this allows us to scope tags names to modules or engines, allowing you to reuse the code. In the engine, we restrict the tag access to single writer which prevents race conditions. Also, every module can have a tag call reset for example and they won’t collide with each other.
Still with all this we still consider CVT to be useful and because of this DCAF has a CVT module. This allows code that works with CVT to interact with DCAF. Using it like this you can keep your normal code using CVT and use the DCAF modules.

With CCC and CVT your application code must include the CCC Vis for starting and publishing the variables inside the rest of your code

If you are using DCAF you can remove the the CCC Vis, and just put the DCAF engine in parallel to this code.
Also for example in the case of temporary disconnects is not an issue with the TEC (Tagbus Engine Communication Module) as it is using UDP considering that what we have is tags, it covers most cases. In the future we are considering to add a pure TCP module but haven't worked on it.

But here is where you start getting more with DCAF, if in a future you decide to use for example Modbus for communication between the host and the Client you just switch it in the DCAF configuration, run the includes Script, and you don’t need to change the rest of your code in LabVIEW.

In summary more than depracating CVT in itsef is the support libraries to it, like CCC or CDL that are no longer in active development and are lower priority. This is because they can be replaced with DCAF using modules like the TEC (UDP) module, or the TDMS module. Also its importat to clarify DCAF does not need to be the main architecture of your application but suplement it. You can keep all your code with CVT and just add DCAF instead of the CCC.
You can find more information about it in www.ni.com/dcaf .

Now regardless of which library you decide to use we have moved both to Github, and they are open source. This allows the community to continue developing on them and making bug fixes. For example, with the bug fix xl600 did. He forked the code and made his fix. The only thing missing is for him to submit a pull-request from his repo. After this we will look into it and if everything is good we will integrate it into the main branch and update the tools network with it.

To make this process even better we have been adding more infrastructure, especially on all the DCAF packages, adding unit tests, and validation tests. This allows us to have a better turn around for integrating changes coming from the community. The continues integration service we have is using Jenkins to check when changes occur or pull request, run unit tests and make a build we can use to verify the code. This code is also available in the DCAF Repo.

Benjamin C
Principal Systems Engineer // CLA // CLED

Noriker · ‎10-23-2017

Thanks for the insight. By the way, the link www.ni.com/dcaf does not exist and cannot find TEC module. The problem is lack of documentation, that makes adopting new thing hard.