From 11:00 PM CST Friday, Feb 14th - 6:30 PM CST Saturday, Feb 15th, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CST Friday, Feb 14th - 6:30 PM CST Saturday, Feb 15th, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
10-23-2017 10:47 AM
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
10-23-2017 10:49 AM
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).
10-23-2017 10:56 AM
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!
10-23-2017 11:11 AM
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.
10-23-2017
04:15 PM
- last edited on
10-24-2017
09:19 AM
by
Christian_L
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.
10-23-2017
06:05 PM
- last edited on
10-24-2017
09:16 AM
by
Christian_L
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.
10-23-2017
06:52 PM
- last edited on
10-24-2017
09:25 AM
by
Christian_L
Please go to ni.com/dcaf to reach the DCAF community. (The link has been fixed in the previous post.)
The TEC module in GitHub is here: https://github.com/LabVIEW-DCAF/TECModule .
To download DCAF in VIPM search for DCAF core, the TEC module part of core. In VIPM it appears as UDP BroadCast Module
DCAF now has additional documentation at ni.com/dcaf. When you install DCAF Core, it adds an example to find examples.
DCAF Installation and Getting Started
Last week we added a new video that is a good introduction to DCAF.
Design, Configure, and Deploy Robust CompactRIO Systems With DCAF
Best Regards,
03-21-2019 04:01 PM
This duplicates a problem I've been having with starting the CCC Server.
DETT can be accessed on port 3364
I've tried it on two three systems and i have thre problem on all three.
1: Win 10, LabVIEW 2017
2: Win 10, LabVIEW 2017
3: Win 7, LabVIEW 2017, it used to work on this system but didn't when I tried this test program.
How to use the test program:
1: Compile the two build specifications
2: Try the following steps on the vi and both exe files
a: Start the program, either the vi or the exe
b: Click Start server, it will report on whether it suceeded
c. Click Stop server, it will report on whether it suceeded
3: Click Stop VI when you want to exit
If I run Main.vi from the the project it works fine and starting the server always works
If I run the Debugging Disabled exe it throws error 2 and the server doesn't start
If I run the Debugging Enabled exe the server starts and everything works fine
Questions:
1: What changed with my Win 7 system that is now causing it to fail?
2: Has anybody else out there encountered this and is there a workaround that allows me to leave debugging disabled?
3: Is Windows causing this and is there something I can do?