Best Practices for Discrete Action Commands in DCAF System

[KeenanJohnson]

I have a DCAF system that has a remote GUI that communicates via the UDP module.

The UDP command module works great for what I'll call "continous" command actions. Things like "open this relay". The operator clicks the button, which asserts the GUI tag high, the UDP module mirrors that over to the remote CRIO, which then asserts it's local channel high until the user commands it to be off again.

However, there are some types of commands that the "continous" system doesn't work well for. Things like "start executing this sequence". I really want to just issue this command once. It's possible to work around this by creating some sort of UI channel that is mirrored to the CRIO. The sequencing logic then only checks for the rising edge of that channel before running the sequence. However, this means that the UI must then contain logic to reset the control once the sequence has ended or the operator must remember to toggle the request channel off before re-asserting it.

Is there any plan to support any sort of "discrete" event command or some obvious workaround that I am missing?

[Burt_S]

There is no simple workaround for this unfortunately. DCAF as a whole (not just the UI and UDP modules) was designed specifically to help with cyclic 'continuous' updates and doesn't currently offer many tools to help with messages or commands.

That said, it would probably make sense to have a feature request to add boolean 'latch' functionality to the UI module which would automatically reset a value to False once the module has read a True.

If that existed, you could then map that value over UDP and see the toggle occur all the way down in the engine on the other target. However for that to truly work reliably, you would need to use a reliable communication mechanism (say TCP instead of UDP), and would need handshaking between engines to ensure there is no data loss.

Technically all of the above is possible, but the simplest path to a solution is probably to choose your own favorite messaging protocol (Network Streams, TCP, STM, AMC, etc.) and implement code in your UI and execution logic that handles this communication outside of the context of DCAF. In other words, send the messages directly between modules and don't use the Tag Bus to store the values (unless the message is to modify a value on the bus of course).

[MarkCG]

I'm digging into the DCAF now and noticed this. I'm going to need to implement it for my project. I am thinking of creating a module that will sit and act as TCP listener (using the simple messaging protocol library) and dispatch commands on the cRIO to the relevant user processes using an AMC queue (or possibly RTFIFO if necessary). Does anyone see any major problems or caveats with this? 

[Burt_S]

Creating a module to act as a TCP listener is perfectly fine. Just make sure that it doesn't run inline in a way that blocks the execution of the engine. In my mind, the question is less about will it work and more about whether it would be worth it over implementing the listener outside of DCAF.

Is the listener something that you could reuse across projects?

Does it need to interact with values on the tag bus in the engine?

Are there parameters for the listener that would benefit from being configurable?

Will the listener take advantage of the engine's error handling capabilities?

If the answer isn't 'yes' to one or more of the questions above, then I'd be curious to learn more about the benefits that you see in wrapping the listener up in a module.

If you do build it as a module, be careful to consider whether or not multiple instances should be allowed to run on a target simultaneously. I've also found that wrapping up the native TCP calls for sending messages to the listener in an API, often with a VI for every message that is supported, can make the code much cleaner.

[MarkCG]

Hi Burt thank you for your feedback. I was indeed thinking of reuse. I was also thinking that I have made message dispatchers that took command messages from a network stream and automatically forwarded the message to the correct module's command queue. So a "set temperature" command gets forwarded to the temperature control loop, a "start test sequence" message gets forwarded to the sequencer module. That sort of thing. I was thinking of possibly making something like that configurable- you configure the message and target module through a configurator GUI. This is probably more that I want to tackle right this second though.

[MarkCG]

Could you just piggyback ontop of the DCAF message service? I know it uses UDP so you MIGHT miss a command but that's okay- you can just send it again