What is the problem?
Got some python3 scripted GPIO things here that I want to execute using octolapse. Target is to trigger a step of a StepperMotor after each layer. So after each layer I want to send a short "1" on a GPIO out (STEP) while holding another GPIO "0" (DIR) the whole time. So octolapse is configured to execute a small script after each layer that will do this output thing.
While idle this setup works perfectly. When I execute the script manually from console, everything is fine. The Motor makes one step and I am happy.
But while printing, no matter if executed by octolapse or - again - manually from the console, it does not work at all. The Motor does only occasionally step, sometimes goes back a step or - after 10 non moving consecute steps it knocks and jumps back one coilposition. When I stop the print, everything works fine again immediately, the motor steps bravely upon each manual call of the script.
I am close to insanity. I cannot figure it out why I can perfectly set GPIOs while Octo is idle, but as soon as it prints, it does not work.
What did you already try to solve it?
- tried several GPIOs, currently I am on 22 (STEP) and 27 (DIR)
- Changed the stepper driver (currently DRV8825)
- Changed the motor
- Insulated the wires between pi and DRV (interference?)
- Only thing left is to hook up an osci to prove that... well... Here is the question:
Is there any information to know about GPIOs being fragile while printing? Is octo using and hence interfering any kind of GPIO? Is there something that I am missing? For me the only reasonable idea I have left is that there is noise on the DIR pin or that the STEP impulse is timed badly due to multitasking issues (though I also tried several different timings programmatically)
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, what kind of hardware precisely, ...)
Octopi plain vanilla 0.18.0 with Octoprint 1.5.3
Pi4 4MB, wired ethernet, wifi disabled, raspi HD Cam connected and running
Printer Voxellab aquila doesnt matter, connected via USB
Thank you so much for any idea, any hint, anything that saves me from insanity 
What I would do in your situation is to reduce complexity from the setup.
Put the motor aside for a moment, write a few lines python that log the state of the GPIO pins and a timestamp. Maybe let the script you have with octolapse write a similar log. Compare, do you see differences or is it uniform?
That kind of testing shows you in which direction you should go on searching.
In fact, thanx, thats not the worst idea. Have to figure out a decent way to log that because ... I mean talking about stepping a motor and detecting noise. thats a lot of data... But yea, I give it a shot.
Meantime: Addon information: I figured the virtual printer. So I did everything perfectly the same: Same model, same GCode, same octolapse settings (including executing the post-layer-script). But it turns out: Everything works perfectly! So I can rule out the idea that octolapse or the mentioned script is doing something wrong. What I do next (besides thinking about a logging strategy) is to completely rewire everything. New GPIO wires and motorcable and USB-cable and also relocate the wiring to rule the idea of noised-interference out.
Gonna keep you updated 
Just wanted to give a short update after a little while...
To summarize: Go for a high-quality-stepstick!
As said I tried several A4988 and DVR8825 and all of them showed this weired behaviour. I did several attempts to "log" the signals with an arduino and could not prove any "noise" on the step/dir-Wires that go to the stepstick.
So my final attempt was to order a Bigtreetech TMC2208 STEP/DIR stepstick as a drop-in replacement for my existing configuration. (I did have a 2130 lying around but honestly: Dont want to go the way with SPI and stuff for this rather "stupid" little project. STEP/DIR is totally fine).
And guess what: It works "right out the box". Perfect behaviour, no stuttering, no whatsoevery. It runs quiet (StealthChop2) and smooth as melted PLA...
So for me this topic is closed. I still dont know what the heck was/is going on, I can only think of interference from the Printer-Steppers, the Printer-PSU, the Heatwires or other electromagnetic interference that might have confused the Stepsticks internal circuits... but I do have learned that TMC-Steper Drivers rock! In any sense!
Thanx and Regards and happy printing everyone!!