Run triggered scripts exclusively
-
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). -
@bludin I'm fairly sure that the homing macro and trigger macro don't run as parallel threads (but I could be wrong). If that were the case then there would for sure be conflicts if say the homing macro called for a negative X move but the trigger macro called for a positive one. Nothing similar to that has ever been reported to the best of my knowledge.
Maybe @DC42 will jump in here and explain how the code works. Meanwhile, it might be an idea if you post your homing file and trigger macros as well as an elaboration of what you mean by leading to "undesired results".
-
@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.
-
@bludin Difficult to say without a bit more info like the homing file and trigger scripts. If the trigger script "stalls" on the first G1 move, then that may be because the axis hasn't been homed so you need to have an "H2" parameter or some such. But I'm only making guessing with the limited information to hand.
-
@bludin I have faced that problem 2 weeks ago and also tried to find held in the forum. Unfortunately it seams not a lot of people are trying to use triggers that way and even the developers couldn't really help. In the end I found a messy but functional work around by adding a number of M400 right after the M582. I needed one M400 for each G1 command in the trigger script to make sure the main code is paused long enough. But I am not sure if that is a general rule
I hope that solves your problem.Ps: Am I right you need one trigger per tool? That might be possible with just 4 tools but since I am setting up a tool changer with 8 I simply use one switch on the carriage which causes a message for the user to remove the tool. Maybe that is also an easier solution for you
-
What are you trying to get the script to wait for? If it's heaters, you can use M116. Otherwise for moves, try M400, or if you know how long it will take for the macro to finish, a set time with G4.
You may also find that manually putting in M120 (Push) and M121 (Pop) forces the macro to complete. It should happen automatically when a macro is called, though. I haven't tried this myself, but have seen other people's macros that do it.
Ian
TronXY X5S with Duet 3 MB6HC and Roto toolboard : Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : Polargraph with Duet 2 WiFi
-
@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.
-
@droftarts I tried a G4 as well. It also paused the execution of the trigger Script, so unfortunately not a solution.
-
@bludin @TC Sorry, my macro writing (and programming) experience is pretty limited! I'm just surprised that macros run concurrently. Can you post your homing/tool change macros?
@bludin said in Run triggered scripts exclusively:
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.
Maybe @dc42 has a view on this? Also, conditional gcode is set to come in RRF 3.
Ian
-
The real solution to this is conditional gcode, coming soon in RRF3. 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. So in your homeall.g or other startup script, you may be able to do something like this, before doing any other motion:
M581 to set up the trigger for tool 0 microswitch
M582 to poll tool 0 switch
short G4 delay to give the trigger macro time to start
M400 to wait for the trigger macro to finish, if it ran
Repeat for the other 3 tools -
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?
