Issue with event struct reading controls

[phalanx02895]

Hello all.

I'm having issue reading my control clusters after triggering an event. Here is what I was trying to do:

1) I have a control with several booleans

2) A mouse up on the cluster triggers an event.

3) Although it's not pictured, I was using the event to queue up a state in the state machine that the cluster is wired through.

4) When I read these controls in the cluster, the data isn't getting through.

I then decided to try and read the values within the event structure. When I created the property node for the 'Speed' cluster, somehow it created as a variant. I don't understand this, but after converting the data, this works.

You'll also see in the picture a property node for the 'Carrier' cluster. This one does not work. Why does the variant work, yet the other one does not? The clusters and controls are exactly the same, save one less button.

So I tried to get the property node for the 'Carrier' cluster created as a variant, but can't figure out how.

I know that with an event structure, you're supposed to put the control in the event struct, but I can't do that in this case, and I'm reading a cluster with a cluster that is contained in the state machine.

I'm sure the answer is here somewhere. I did a couple searches, but didn't see an obvious solution right off.

Thanks,

Jim

[Cory_K]

---

phalanx02895 wrote:

Hello all.

When I created the property node for the 'Speed' cluster, somehow it created as a variant. I don't understand this, but after converting the data, this works.

You'll also see in the picture a property node for the 'Carrier' cluster. This one does not work. Why does the variant work, yet the other one does not? The clusters and controls are exactly the same, save one less button.Thanks,

Jim

---

Jim, look at the color of the wires.

The dark magenta color indicates that the "value" is of type Variant. This means you need to convert from variant to cluster, as you did.

The other wire is pink, indicating it is already a cluster. Therefor, you cannot convert it from variant, because it isnt a variant.

Message Edited by Cory K on 03-20-2009 11:20 AM

[phalanx02895]

Yes, I realize that. The issue is that the variant works, the cluster does not.

That, and I'm unsure why when I created that property node, it came up as a variant, when the other did not.

Thanks,

Jim

[nathand]

Part (maybe all) of the issue here is the mechanical action of the booleans inside your cluster.  I don't know the reason for this, but if you have a boolean with a latching mechanical action inside a cluster, a value property node for that cluster will return a variant.  I suppose it's a way of telling you that you can't really be sure of the state of that boolean at the time the property node reads it.

As for the second part of the question, why your data "isn't getting through," you'll have to be more specific - I don't understand what the problem is.  Perhaps it's also related to the boolean mechanical action.   What do you mean by "works"?  Are you trying to use the value property node to send a value from the event structure to your other loop?  Consider using a queue, notifier, or functional global; passing data around by using front panel terminals isn't ideal.

[phalanx02895]

You were correct in that the type of node was due to the mechanical action. The 'Speed' cluster was set to latch, the 'Carrier' was set to switch.

What I started out trying to do was simply use the mouse up event for the cluster to queue up the state "Write Presets" in the state machine that the cluster was connected to. The problem is that when I read the control via unbundle by name (in the state machine), it isn't firing ( a true value for the button pressed ). Is it that the event structure is resetting the value in this case, even though I didn't have the cluster control in it? This event state only contained the enqueue element vi

[nathand]

---

phalanx02895 wrote:

What I started out trying to do was simply use the mouse up event for the cluster to queue up the state "Write Presets" in the state machine that the cluster was connected to. The problem is that when I read the control via unbundle by name (in the state machine), it isn't firing ( a true value for the button pressed ). Is it that the event structure is resetting the value in this case, even though I didn't have the cluster control in it? This event state only contained the enqueue element vi

---

I see the problem now.  Your event case resets to false both clusters, but the one with the latching action "works" because the state doesn't actually change until its read in your other loop.  Conversely for your cluster with the switching action, your event structure resets the values to false, so that when the other loop reads them it reads false (as expected, since that's the value you wrote to it).  Worse, it's possible that this will work every once in a while, depending on which loop gets to the cluster first - the one that reads it, or the one that overwrites its value.  This is known as a race condition, and is a sign that your design needs to be reworked.  Why doesn't your event structure write to the state queue directly?

[phalanx02895]

I think I've caused some confusion. Originally, my event structure contained only the enqueue element telling the state machine to process the cluster. per attached picture. It was when I found that the values weren't getting passed into the state machine that I attemped to read the control from within the event structure using the property node as a workaround.

My goal would be to use the event structure to enqueue the state in which the controls would be read, as it is in the 2nd attached picture.

[nathand]

I'm sorry if I misunderstood - it's difficult when I'm only seeing fragments of the code without a good idea of how they fit together.

I am, however, still confused, maybe because I can't see enough of the code.  Your drive control front panel terminal is outside the state machine while loop, and used to initialize a shift register.  Do you update that shift register when the value of the drive control changes?  Otherwise there's your problem right there - you need to move that terminal inside the while loop.

[phalanx02895]

I saw that the control was outside the loop as I was posting the last picture. I moved it into it's own state and went back to setting up the queue with the event structure, and all is well.

Thank you for your help.