Problem with 2 State Toggle

Archived Topics
1

I’ve noticed a problem with the 2 State Toggle control when it is linked to a SQLTag point: when you press the button to change state from 0 to 1, the ‘Control Value’ field actually goes 0-1-0-1. Similarly when it changes from 1 to 0 it goes 1-0-1-0.

I noticed this when trying to trigger off the Control Value when the point was changed from 0 to 1- the script was triggering both when the point was set and when it was reset. (I got round this by triggering off the Indicator Value which does seem to work as advertised.)

2

This is a timing issue with the write, not with the toggle component. It sounds like you just need to increase your fallback delay on the button’s Control Value tag binding.

3

Changing the fallback delay has no effect - I’m currently using the control to set a DB tag, if that makes a difference. This ‘double toggle’ happens within half a second.

4

Yeah, I’ve reproduced this. We’re looking into it.

5

Thanks for pointing that out, it turned out to be a pretty subtle issue with SQLTags that shouldn’t cause any problems, but was a slight performance drain. The fix will be in 3.2.2.

FYI, you’ll still get more property changes than you might expect - your control value will get 2 updates for the new value; that is it will go 1-0-0. The first zero is from clicking on the button, the second is from the tag value being read back from SQLTags after the write has taken place. Normally duplicate property changes get filtered out, but the 2-state button is designed to let them through for a boring technical issue. Just thought you’d like to know…

6

Im having a hard time falling asleep..... please explain

7

Okay, its not really that complex.

So, when you click the 2-state button, it looks at the current state (0/1), and then sets the control value to either state1Value or state2Value, appropriately.

If you click the button again, before the new state is read from the binding (this can take up to a few seconds on a slow SQLTag scan class, so its not that unlikely), we want another SQLTag write to be issued. That will only happen if the controlValue’s property change event is fired again, so thats why it fires the event regardless of whether or not the property actually changed or not.