SOLVED - Piston Only Executing Some Commands


#1

SOLVED by @Pantheon in comment #4 (thanks, Todd).


[NOTE: I know this must be covered somewhere. I’m almost certain I’ve even asked about this before, but can’t find it. I’m also sure I’m probably just ‘doing it wrong’ lol]

1) Give a description of the problem
I created a piston to do three things, but it is only executing two of them.

2) What is the expected behaviour?
I expect it to execute all three (simple) tasks.

3) What is happening/not happening?
It’s executing the first two, but not the third.

4) Post a Green Snapshot of the pistonimage
20191026_TroubleshootingPistonTaskExecution

5) Attach logs after turning logging level to Full
I’m hoping this step won’t be necessary, but I guess I’m about to find out. :slight_smile:

REMOVE BELOW AFTER READING
done :slight_smile:


#2

BTW, just so you know that everything is working otherwise…

In order to get the third task to execute, I removed it from this piston, created a new, separate piston to just run this task (i.e. same trigger event, plus a ten second wait), and added a new third task to the present piston that calls the second piston.

Configured like that, it works just fine.
So, why won’t this one simple task fire off as expected when included in the present piston like it is above?


#3

Your second WITH changes the state of your piston (your trigger) and immediately stops execution and starts the piston again from the top. Then your trigger is false and it never gets to your third WITH.


#4

Move your second WITH to the last location and it should work as you desire.


#5

How about if you turn off TCP on each of the Withs, then they’d ignore the trigger and all fire correctly?


#6

Maybe I am old school… but I would never code like this:

IF Switch 35 turns on
    Then with Switch 35, Turn off
END IF

This basically forces the piston to run top to bottom twice each time the switch turns on.


The exception to this is if I am working with a Simulated Switch… I may return it to it’s default state on the very last command. It won’t stop the piston from firing a second time, but I structure the piston so nothing else executes on the second trigger.


I sometimes recommend a Smart button (or a virtual “Momentary Button Tile”). These go active when pushed, and then automatically return to the off state a moment later.

temp


#7

Why is it causing that with the way I have it now?

It doesn’t matter. I will do as you suggested and see how it goes, regardless, but I’m just a curiosity junkie. :slight_smile:


#8

I see that option, but which of the three would make the most sense here (i.e. I obviously don’t quite understand TCP yet…even though I just read up on it lol )?


#9

I can’t use virtual momentary buttons in this case (and explaining that wouldn’t matter here).

These are all virtual switches.

Since virtual momentaries won’t work, I have to have one virtual switch turn on, and then, do something (in this case, turn on a different virtual switch), and then turn the original virtual switch back off.

Basically, I’m using two virtual switches and a little code to simulate a simulated momentary button. lol


#10

I did what you suggested (sort of; see screenshot below), and it works just fine with just the single piston.

The reason I put them in the order I did initially was because that seemed to matter, but it really doesn’t. So, this is great! :slight_smile: I will try to remember this next time.

20191026_TroubleshootingPistonTaskExecution_2-Resolved

Thank you (and @Alwas and @WCmore) for the assist!!