@dc42 thanks. that might be a viable workaround in many situations. I don't know yet how tight the off-timing needs to be to have all extruded material cured (at least to the point where it becomes dimensionally stable) while making sure that the curing does not propagate into the nozzle.

@owend thanks, also for making me aware of M571. I will consider moving to hardware-based solutions of I can't find one in software

@phaedrux Thanks for the hint, I will give it a try.
Would it be possible to have G10/G11 call a retract/unretract macro?

I've built a nice syringe extruder tool for our E3D Toolchanger. Controlling the extrusion should be simple enough as it is largely analogous to filament extrusion. But I also need to control some UV LEDs to cure the extruded photopolymer and for practical reasons, I would like to (ab)use the hotend heater power for this (I'm open to proposals though). Basically, the LEDs should turn on as soon as extrusion starts and continue for an adjustable period (0.5-5") after extrusion stops. Would anybody know if and how this can be achieved?
TIA, Beat

Thanks a lot for stepping in @dc42!

@dc42 said in Run triggered scripts exclusively:

The real solution to this is conditional gcode, coming soon in RRF3.

I agree 100%. That will make things like this a lot easier, safer, and more transparent. I look very much forward to it.

@dc42 said in Run triggered scripts exclusively:

Meanwhile, it is a feature of macros that once a macro has moved an axis, that macro has exclusive access to the move system until the macro completes, with a few exceptions.

Could it be that the C-axis of the ToolChanger is one of these exceptions because it is not considered part of the move system? That would explain why the triggered parking script, which only accesses the X- and Y-axes fails to block the C-homing script which only access the C-axis.
If so, could I have the triggered parking script access the C-axis in the very beginning in order to "claim" it?

@droftarts What I actually want is for all script execution to pause until the triggered script has finished what it needs to do and exits. That's the simplest way of putting it and akin if standard interrupt programming. Putting in M400s or G4 delays (the latter probably would work, because it will also delay the G1's in the triggered script) in the other scripts would be really bad and unsafe programming.

@deckingman I have M118 messages in both scripts and they come up interleaved. So some sort of threading seems to be going on. What is true, however, is that the triggered script seems to stall at the first G1, so maybe there is some protective lock mechanism, but it works very much the opposite way that I would want it to.

Thanks. Yes, I have. But I can't find anything there, that pertains to my question. Am I overlooking something?
To be more specific, I have an E3D Toolchanger. Currently, it is unaware (e.g. after a reset) of whether a tool is mounted on the carriage. When homing the C-axis (<-the coupler) or Z-axis with a tool mounted, the tool will just fall off or ram the bed. Therefore I have equipped the tools with microswitches that can be polled when homing, so if a tool is present, it will first be parked in the correct slot. The problem is that the parking scripts is correctly triggered by a M581/M582 sequence in the homing script, but from then on the homing and the parking run as parallel threads which leads to undesired results. I need the homing script to be paused until the parking script has finished.
(I know I can solve this by setting up an additional trigger for when the first tool is NOT mounted invoking a second trigger when the second tool is not mounted and so on, but this is very inelegant and obscure, to say the least).

when running a triggered script (e.g. invoked by M581/582 for instance), how can I make sure, all other scripts remain paused until the triggered script finishes?