"synchronization" with an already running system

[MarkCG]

Frequently one of the things that I have seen in machine control applications is the need to connect to a running target application that is not in its default state. For example the machine may be running independently doing some task, have certain things turned on and off etc. 

What I see using the Tag Engine Communication module is that connecting to running target causes the target to immediately take the state of the variables in the UI application. So for example you have a valve open on the machine, commanded by the UI.  Then for whatever reason the UI program has to close (operator error, programmer bug, windows problems). You start up the UI program again, it connects to the target, and that valve is immediately shut due to the startup state of the UI program defaults that valve as closed.

In the past I had handled this problem by first using a command based architecture where no action was taken to change the target until the operator hit hte button on the UI, and by doing a "synchronization" with the target upon connection, where the UI programs reads the state of the target and sets the front panel control programmatically. 

I'm thinking of good ways to do this within the DCAF framework. Possibly by doing the synchronization before even starting the DCAF engine in the UI program, or possibly by making the TEC module one-way (target to host) and making all host to target comms command based. 

Any ideas? 

[BeCeGa · Accepted solution]

Hi MarkCG,

  You are correct the TEC module will map the values when the engine starts, and they might be out of sync or not be valid. 

I agree with you probably want to build a custom module to manage your communication. 

IN the situation you are describing there are 2 issues. One is the starting value of the cRIO and the second is how to validate the communication. For example, lets say you have a tag that is the "Setpoint" and this value comes from the host normally. But in this case the cRIO started before the host is ready. To figure out which one is the correct initial value, you could do several things: 

  1) Have a good default value for the TAG. You can define this in the configuration, and you could update this in your host and send this file for when the cRIO start.

  2) The module that would normally be writing to the TAG, in this case it would be your communication module, could read the values from a different file, and you could just send this file from the host, and have the module load the value at startup.  

  3) Modify the main VI on the target so it wont start until host. This can be complex, and it won’t be good if you need the cRIO to be running even if the Host is down.

Now for knowing that there was a change in commands as you mention the TEC module is just tag communication, it has no acknowledge, it will read the command multiple times and can loose communication. But you can replace this for a module that gives you more control over this, again the implementation of this module will depend on what you need.

   A simple option is just having some message-based communication, I have seen some Systems using DCAF that have a JSON RPC (web methods) to receive commands, and this information is then converted to tags in the cRIO. This could be also a be a custom TCP or any other protocol.

 The other option depending on how often you send commands is still use tags, use one tag to identify the update and add some logic in the cRIO to act on it. For example, if you send the update 25, and the cRIO already process it it will ignore it until update 26 arrives.

In here it will depend on the application you have what is the best option. But you will need to create a module to handle the new message-based communication, or a module to handle the logic when sending the values using a tag based communication.

Best Regards

[MarkCG]

Hi Benjamin,

thank for you thoughts on this, and apologies for my much belated response. I've learned some more about how dynamic modules work by creating one for my project ( which does exponential averaging on floating point tags) so now I feel pretty comfortable taking on creating a command based module. JSON - RPC does sound like something that would make sense for this. The communication module will handle these scenarios ---

1. cRIO started before UI

cRIO sends a "sync" update containing all current tag values, essentially. UI program sets all front panel controls to reflect current state of the cRIO

scenarios where this can happen: UI program is restarted for whatever reason during operation, due to user error, windows crash, inadvertent unplugging and the like. 

2. cRIO was reset, after the UI is up and running

same sync message from cRIO to UI computer is sent, containing default values of tags. 

scenarios where this can happen - machine containing cRIO is power-cycled, for whatever reason. You do not want motion or anything else actuating when the power switch is thrown.