Global variable not setting when calling another piston


#1

1) Give a description of the problem
I’m trying to assign a value to a global variable highlighted in red in the below piston image. Subsequently I attempt to call another piston. The second piston simply logs the global variables data and it never changes. The 1 second delay I added was just put there hoping that if I put a delay the value would then be seen by the piston correctly. In the second piston I simply log the value @entry_delay_active and it’s always false every single time. I then reset the variable back to false and try again and can’t get the second piston to see that the variable is true. If I log the value of @entry_delay_active in the red highlighted area of the primary piston it shows that the value has been updated.

2) What is the expected behaviour?
I set the global variable @entry_delay_active to true, call a second piston, log the value of @entry_delay_active and it should output true, but instead outputs false.

3) What is happening/not happening?
The variable is not being seen as changed in the second piston.

4) Post a Green Snapshot of the pistonimage

EDIT: Please ignore the green blocks, I removed my personal notes as they’re not needed.


#2

Anytime a piston is told to change a global variable, it will only do so once the last line of code has completed.


#3

If I set the global variable as seen in the red block, then immediately after I log the value of the global variable it seems to show that it’s been changed, but when I execute the other piston it’s not. Why does it show it’s been changed when I log it immediately after?


#4

The same piston may be showing you a post-cache (or a premonition of the future, so to speak)
IE: it is not really set until OTHER pistons can see it.

You MAY be able to cheat the system by increasing the wait to 12 seconds.
This will force the piston to schedule a wakeup, which usually updates the @global in the meantime.
(but your top logic could come into play, so I recommend setting Log Level to Full during testing)


#5

I just wanted to upload a better example showcasing what’s happening. I’ll see what I can do to get this to work I appreciate your assistance.


#6

Great “close-up”… In that case, I would expect PistonB it to always log the previous data.

My last post covers one hack, but if I do not want to tamper with PistonA, I may run it thru a third (middle piston) to create extra time for the update to go thru.

IE

PistonA

Sets @global
Executes PistonB


PistonB

Waits a few seconds (3-5 sec should be sufficient)
Executes PistonC


PistonC

Reads @global
Does whatever


#7

I tried sending myself a web request with the data as well. Please note the variable always starts off false in my tests. I’m very new to webcore but these inconsistencies make it difficult to learn.

I’m trying to create a home security system so any delay, especially that of several seconds is not feasible. I’ll try just passing an argument to the second piston and having it set the variable instead. I wanted to avoid this but this might be my best option.


#8

I can assure you, with your choice of coding, that success will be quite rare, and should not be relied upon.

TL;DR: Don’t write to a @global if you need instant feedback


Pro Tip:

If your @globals are boolean (IE true/false), might I recommend using a Simulated Switch instead of a @global? They toggle nearly instantly, and can be seen by the same piston, or other pistons, about 10ms later. (no need for any WAITS)

IE:

SimSwitch ON = TRUE
SimSwitch OFF = FALSE


#9

I might go this route actually, It didn’t occur to me to use a simulated switch but this should work just fine. Thanks for your suggestion.


#10

I am a huge fan of SimSwitches. They come in handy in so many cases


#11

Just to add to what @WCmore has been describing, when a piston starts up it caches the global variables and it works with those cached values. When it exits it will update any global variables that have changed.

When you execute a second piston there is a race on. That race is between the first position finishing execution and updating the global variables from its cached copy, and the second piston starting up and caching the global variables. You cannot depend on the result of the race being the same every time.

When pistons do a ‘wait’ for five seconds or more they will always exit and restart, so if you wait for five seconds before executing the second piston you should find the global variable is always updated. Alternatively you can put a five second wait at the start of the second piston on the assumption that the first piston will finish and exit within that time. That will only work most of the time though as sometimes weird stuff just happens.