shared variable clusters not working as intended

[johnnyt]

Hi All,

I've been using shared variables to communicate between a host computer and a crio real time target.  This works well as simple variables.  I configured a cluster of shared variables to try and clean up the code a bit.

I have a couple of problems.  If I write to a single element, using bundle, the other elements in the cluster that I do not want to write to are overwritten with some unknown default value.   Second, when the host computer program is stopped, the cluster on the RT host writes what appears to be default values to all the variables in the cluster on the RT.  The idea is to keep the RT program running in it's current state until the host computer recovers.  Of course this is impossible, if it resets all the data to default.

It appears that I can only write to a cluster on one side and read on the other side.  I cannot read/write to the same cluster at different points on the host and target machines.  With a single shared variable, I can read/write to my hearts content on any process.  I haven't been able to find a way to solve this.

I will post the code, but you will need a cRIO to run it.  If anyone is using clusters in shared variables, I'd be curious to see how you are doing it.

Thanks,
John

[Rob_F1]

I have used clusters of data and write/read them to a shared variable and it worked OK.

If the code you posted is the actual code you are using you will need to enforce execution control. Use the error wire for this, without execution control you have no control over when the shared & local variable is being read to or written to. What is the Local variable doing there anyway? 

If you write then immediately read the same variableyou may not get the update and will need to use a time delay so the shared variable engine can update. Nominally I believe the SV engine has an update rate of about 100ms but I have tested it down to about 30ms. Of course this is dependent on your system.

The single element shared variable will respond faster than a cluster of data.

The shared variables being written to also have a coercion dot, you should look into that if it's the same on your system. It could just be because I don't have the project or type def linked here.

[johnnyt]

Hi Robert,

Thanks for your fast response, to be perfectly honest, I didn't expect any replies!  Anyway,  throw out those examples, I've attached a new example that I feel captures what I'm trying to do.  I have two buttons, one is controlled by the host the other by the target.  As you can see from the examples, if I keep the buttons out of the cluster, they behave in the way I expect.  In the cluster, it appears they are trying to overwrite each other and the behavior is unexpected.  I'm using 8.6.1.  Thank you much for looking.

John

[Rob_F1 · Accepted solution]

That makes some sense, what I can think of is you are writing to the same cluster in two different places. Each place updates both values so if the host writes B1=False and B2=True then the Rio Writes B1=False and B2=False then the variable will have the latest value of both being false.It's a loop condition.

Even though you are only setting one value in the bundle by name the other value is coming from the cluster input to the bundle by name.

To handle this you will need remove the input cluster to the bundle by name and replace with the shared variable read. This is where you may need a delay to ensure the variable has the most recent updated value.

Also you still have the coercion dots. For the shared variable try linking it to the custom control instead of a undefined cluster (Next choice below in the SV setup)

[johnnyt]

Wow!  Thanks Robert!  That was the solution and rather simple too.  I never did notice the coercion dots and it never occured to me to use the share as the input to the bundle.  Thank soo much for your help on this.  I was getting ready to give up on the idea.  Have a great day!

[johnnyt]

Here is the your fix, the coercion dots are now gone.  Thank You.

[Rob_F1]

Better, You still need some kind of execution control and or Timing to prevent loop conditions. I would recommend also you make two clusters one that only gets values written in the RIO and one that only gets written to by the host. That way you are only writing in one place and if you happen to miss an update it won't be so critical.

Good luck