Is DCAF still recommended for new projects as of 2022?

[UMASO]

Hello, while it seems main contributers of DCAF development have retired from NI, does NI still plan to actively maintain or develop DCAF in future?  

Is DCAF still recommended for new projects as of 2022?

I guess DCAF could have been a great differentiator for cRIO and NI RT products, if it had been better advertised.  I feel so sorry NI decided not to keep this project anymore.  

[a_clucker]

Hi UMASO,

We're here 🙂  I sit ~20 feet from one of the key R&D developers who worked on it, and I work daily with one of the main DCAF creator on various HIL projects.

Best,

Andrew

[brindle]

Why then does the github page for DCAF not have any activity on it basically since 2019?

[a_clucker]

Hi brindle,

DCAF is considered stable, released, and primary efforts are for support. NI had significant internal use and iteration on the DCAF engine before it was officially turned into a product, so while it might look like it was released and is now silent, a lot of the early churn that products go through happened while it was still internal.

If you find blocking issues, the community is here and can help debug and if it ends up being a DCAF bug it can be filed on the respective GitHub project. As mentioned here, DCAF is a community open source project and anyone can contribute, and I'm personally proud of how many non-NI-DCAF members have 🙂

Have a good weekend,

Andrew

[BeCeGa]

Hi Brindle, 

  I am the DCAF developer A-clucker mentioned. Sorry for the delay in the reply but was getting things cleared internally on where NI is currently standing on DCAF. 

 The short answer is NI is not going to accept any new pull requests or publish NI packages. I am no longer in the group that was in charge of DCAF and without getting into details there is no internal group owning it at the moment. DCAF is no longer officially supported by NI (this is a new policy from last week). No new updates or pull requests will get accepted and NI will not publish any packages. If you see movement in the repos that would probably be me or community people but we are not doing it from NI. I would be happy to have DCAF maintained by the community, and I am looking into the way to make this happen. 

 Now as Andrew Tucker mentioned we do keep using it internally, it's a solid framework, it can be used as-is and there are multiple projects that use it.  It can help create a deterministic application that requires a configurable mapping engine really fast and all is open source. There is documentation and training materials.  You can clone the repos and make updates by yourself. Also, it is a really good example of how to do RT software so even if you don't use the code as-is, it can give you an example of how to do things.  

If you have any questions let me know. 

Best Regards

[UMASO]

Hello Benjamin, thanks a lot for the clear answers.  It is a bit worrying to keep using DCAF, because it will not be maintained anymore, while LabVIEW and other functionalities such as FPGA, TDMS, HW drivers may be updated in future.  

By the way, why on earth did NI decide not to officially support DCAF anymore?  

DCAF is a great framework which makes LabVIEW a unique development environment for Real-Time system with the combination of NI's RT controllers.  Does NI plan any new framework which replaces DCAF?  

Also, does anyone have an idea to update Tag Bus with Map and Collection VIs?  

Regards,

[rhenderson]

I completely agree with this general thought regarding abandoning something good/great for projects such as DCAF.

There is a significant gap between concept and safe, functional, and best-practiced implementation without an officially supported framework such as DCAF. Recently had a conversation with NI and they basically said to build one ourselves which is a pretty poor answer for a common thing that DCAF can do so well. Having the ability to build from the ground is great, but it is a massive lift and most definitely will be built incorrectly the first time. There become other competitive solutions and products that start to look really attractive as they get better and close their gap on user-friendliness.

[Robert_Hoffman]

All,

I have been watching this thread with some interest.  I understand some of you may be looking for an alternative to DCAF that is commercially supported, so I wanted to just point out Signal.X Technologies has developed our STAX Automation Technology with a similar objective to DCAF - real-time embedded automation and control.  It is not a drop-in replacement for DCAF, and may not work for everyone.  However, it may be worth looking at - you can check out the product page here - https://signalxtech.com/software/stax/.

You can look at some of the applications, and there is a training video at the bottom of the page which walks you through the interface. Feel free to contact us through the web site or email us at info@signalxtech.com for more information.

Rob

[UMASO]

---

@rhenderson wrote:

I completely agree with this general thought regarding abandoning something good/great for projects such as DCAF.

There is a significant gap between concept and safe, functional, and best-practiced implementation without an officially supported framework such as DCAF. Recently had a conversation with NI and they basically said to build one ourselves which is a pretty poor answer for a common thing that DCAF can do so well. Having the ability to build from the ground is great, but it is a massive lift and most definitely will be built incorrectly the first time. There become other competitive solutions and products that start to look really attractive as they get better and close their gap on user-friendliness.

---

I agree with your comment and what the points about DCAF in your comment sound almost the same as the introduction of DCAF.  That means NI seems to have set lower priority to build and maintain such a framework for general LabVIEW Real-TIme users.  Rather, they seem to focus on more application-specific framework such as VeriStand, FlexLogger, etc.  

[UMASO · Accepted solution]

Last week, I have had a project finished last week for which I once considered using DCAF. 

First of all, the system ended up NOT being based on DCAF, but just based on a regular cRIO Sample Project.  The reason is that I had some problems using DCAF.  

I know DCAF is an open framework, so, I could have customized anything I want or I had troubles with, but my comments here are all based on "no custom and just use DCAF and DCAF plug-ins as-is"

Let me jot down some notes about DCAF experiences I had, so that any other users will not waste some time.  

Belows are some main application requirements

• Standalone Modbus logger (~200 discrete inputs, ~100 input registers, no control needed)
• Remote panel from host PC can be connected anytime you want through TCP.  
• Modbus items to log can be selected from the host PC remote panel.   
• Selected Modbus items are logged every 1 second, Separate log file every day by TDMS.  
• Created daily TDMS log file is moved to external USB storage.  
  • If USB is not connected, daily log files are saved to internal storage up to 15 days.  
• If Internal or external USB storage gets short in space, oldest log file is deleted.  
• Operator unplugs USB storage to move data from logger to any other PCs.  
• New logging cycle is started, when Modbus connection is (re-)established, or logger is power-cycled.  

Belows are the problems using DCAF and DCAF plug-ins as-is.  

Please forgive me that following notes are not so concrete and I do not have time to organize information and post on Github for bug fixes.  If DCAF is an active project, I would have done so.  

• Modbus plug-in access each Modbus items one-by-one; therefore, if many Mobdus items are desired to read, read API is called many times which leads a tremendous overhead.  
• default DCAF configuration editor does not work very well, if many tags and channels exist.  When the number of tags is large such as +100 and tags and connections are repeatedly being added or deleted, some tags are left unmanaged by DCAF editor.  Once this situation happens, it is required to newly create configuration file.  
• Tutotrials available on Github are not completed.  It looks like the development of tutorial is aborted in the middle.   
• TDMS logger does not work as expected as explained in its tutorials.  
• Code qualities of DCAF overall is not so good.  Especially, DCAF consists of many modules, and some modules are not well designed and implemented in my opinion.