Execute Piston, wait for execution does not work

#1

1) Give a description of the problem
Piston A includes an Execute Piston action to call Piston B. I have “Wait for execution” set to true

2) What is the expected behaviour?
Piston A should wait until Piston B is done whatever it’s doing

3) What is happening/not happening?
Piston A continues on it’s merry way without waiting

**4) Post a Green Snapshot of the piston![image|45x37]

image
image.png869×814 46.4 KB

5) Attach logs after turning logging level to Full
Very minimal, but I logged time right before, and right after the execution of Piston B. Piston B most definitely takes more than 263 milliseconds to run as it has a couple waits in it.

3/11/2020, 8:08:59 AM +151ms
+191ms	║Time before call: 8:08:59:336
+454ms	║Time after call: 8:08:59:599

Does this feature simply not work?

#2

I have never used it…

When PistonA needs to call PistonB, I do it as my very last command in PistonA. If PistonB needs to send data back to PistonA, then I add a new block to PistonA to trigger off of that new data, and then do whatever…

… Either that, or PistonB finishes, and then calls PistonC to finish up…

My code is often quite complex, so I usually choose the second option above.

#3

Are the waits longer than five seconds? If so the piston will schedule a wake up and exit and that may well be considered as the piston having finished executing. I haven’t read the code to see but the full logs should be diagnostic.

#4

Thanks. I had considered your first suggestion. It doesn’t need to send data back per se, but the remaining logic in Piston A should be executed only after B is completed. In essence I am using B as a function/procedure/method since we lack that ability otherwise. I can make it return a simple flag indicating it’s done if needed.

#5

Yes, they are, and I had the same thought. The scheduled wake up must be considered as “done”. I’ll try shortening them and seeing if it functions as I would expect

#6

I think if piston A calls piston B with wait, I think the same thread runs A, then B, then returns to A. So A ‘does not sleep’, its ‘thread’ runs B.

#7

Also keep in mind that if PistonB writes to a @global, then pt2 of PistonA may or may not see the change a second later. (depending on whether PistonA is still on it’s last iteration)

To play it safe:
If PistonA re-triggers, or stays “in limbo” for over 10 secs, then it will likely pick up the new @global.
(if it is under 10 secs, it will depend on the structure of your code whether it does or not)

#8

That is certainly what it looks like from the code.

#9

I do this with global variables because globals change after the piston is done executing.

#10

Thanks all. I’ve been playing with this this afternoon. One point of clarification, and then my findings.

First off, I am not writing to any global variables during this time. I want to avoid that for the reasons pointed out - it may or may not contain the updated value when I would potentially need it.

So in my tests, it does seem as though Piston A’s “wait for execution” only applies to a single run of B. Meaning, if the waits contained within B are enough that it schedules a wake up, then B is essentially done as far as A is concerned (even if the wake up is only a few seconds).

Unfortunately, it seems that sometimes B schedules a wake up, even with as little as a 1 second wait. And sometimes it doesn’t up to 5 seconds or more. Probably has to do with network traffic at the time, I dunno, but it’s inconsistent, and therefore unreliable.

So in reality the “wait for execution” can really only reliably be used to call another piston that has zero waits in it. Unfortunate.

#11

You could easily use the solution in post 2 above…

PistonB does it’s thing, and then sends a “PistonCompleted” alert back to PistonA.
This will give smooth and accurate timings for part 2 of PistonA.