DCAF cDAQ examples?

[BowenM]

So, I was recommended by one of the applications engineers to look into DCAF. After watching the videos, going through some of the documentation, and playing with it - the framework looks promising!  I do have a couple of questions before I dive in headfirst that I haven't readily found answers to.

1.  I see with the standard configuration editor that I can add a cDAQ target but configuring it for I/O isn't intuitive.  Is there any documentation or examples on this I've missed?

2. Does the cDAQ engine use single point on demand for value requests?  This greatly limits how fast the engine loop will run (and is the reason that VeriStand doesn't work well with cDAQ!)

3.  Is there a default API or interface to get / set all of my hardware values aside from the GUI device?  Again I don't seem able to find one playing or in the documentation.

Thanks,

-M

[MattP]

Hello!

DCAF was designed and built for CompactRIO targets, but it can work on cDAQ targets as well.  The primary means DCAF uses to interface to local IO is via the cRIO Scan Engine, which is not available on cDAQ.  To talk to IO on a cDAQ, a DAQ plugin for DCAF would need to be created.  This is a large gap, and is mainly due to our small team's focus on CompactRIO applications.  If you'd like to make a DAQ plugin, let's talk!

The DCAF engine is designed to be a single point engine, and is not intended for waveform acquisition or processing, rather for closed-loop control and automation applications.  We can achieve very efficient loop rates on our targets - what speed are you looking for?

The configuration editor GUI is designed to instantiate plugins and define mappings between plugins.  To get to the IO, you'd need a plugin that knows how to get to the IO (in your case, a DAQ plugin).  

[BowenM]

Matt thank you for the quick response.  To answer a few...

"To talk to IO on a cDAQ, a DAQ plugin for DCAF would need to be created."

This surprises me since the editor allows me to add a cDAQ target.  Did you just add that option for future development with a #todo? 🙂

"If you'd like to make a DAQ plugin, let's talk!"

I would love to (assuming I can find the time). I have a much larger application that I am looking to integrate DCAF into.  At the moment it relies on VeriStand as the HAL and I'm itching to replace it.  I will need to do a bit more research and playing with the DCAF framework first before I make the leap.

"We can achieve very efficient loop rates on our targets - what speed are you looking for?"

Well... you can achieve very efficient loop rates on targets with FPGAs that can run the timing.  cDAQ targets with slow cards on the other hand that are forced to use their own clocks for single point - not so much.  As for rate, I need to close loop at around 200 Hz minimum and 500 preferable.

"To get to the IO, you'd need a plugin that knows how to get to the IO (in your case, a DAQ plugin)."

I thought this might be the case - though it seems to me that filling this gap would be useful.  Your GUI method is great for 1:1 mappings, but if there needs to be some logic or extra "stuff" happen it seems to fall short. The ability to update a command without tying it directly to a control is almost mandatory to me.

Thanks again for your response.

-M

[MattP]

The DCAF engine and almost all modules will run on a cDAQ, so we didn't want to preclude the possibility of using it on those targets.  Keep in mind that DCAF can run alongside other LabVIEW code on the target, so you might have DCAF handling protocol gateway duties while taking vibration measurements with parallel LabVIEW code.  

With regard to how well DCAF would fit for your application needs, we'd be happy to chat with you about it.  We're pretty open as to what works well, what DCAF can't do well, and what we'd like to extend it to do in the future.

As to loop rates, on the cheapest Linux RT target, we can hit 1 KHz rates in a realistic application, with significantly higher rates on the better targets.

We do expect that almost all DCAF applications would need some application-specific processing or logic modules to do anything interesting (this is why we invested in the project templates for static and dynamic channel modules - we can script out most of the new module for you).  Our primary goal with the existing plugins was to take care of the 80% of application code that would be common from system to system to let you focus efforts on the part that is actually specific to your application.   We've got some plugins in the pipeline that should start to cover the processing needs also, but those are a ways out.