@diy-o-sphere unfortunately it doesn't seem (G4 S0 has the same function) to work with the home buttons.

I eventually managed to solve my issue by working out the conditional GCode (if sensors.gpIn[In].value = 1 with the macro in the file. Just would be nice to be able to keep this information centrally in a macro.

@herve_smith Thanks for picking up my copy and paste error. Unfortunately running them manual still doesn't seem to make things any different. The best solution I've found is issuing a dwell of 5s after the trigger to give it time to run the unload command.

There may well be a simpler way however I'm trying to setup my mishmash tool changer to unload the tool before doing a Z-home. I have a trigger on the 1LC board that when triggered stores the tool with each tool head having their own trigger. The idea being that if there is a tool on the head it is parked in it's holder prior to probing. The issue I'm having is that I currently have macros for each trigger and the triggers are enable when they're needed and disabled when they're not.

The issue I have is that the trigger macros are not being run in sequence when the Home-Z button is pressed and run at the end of the probe move which means the tool remains on the head which causes a suboptimal head crash. I have tried both using pauses as well as making a separate homez macro that the homez.g refers to but it still runs in the same backward sequence. Running the macro seperately runs perfectly even before a first home.

my homez.g

m98 P"0:/macros/HomeZ"

my HomeZ macro

Setup unload before probe
M581 P11 T11 R0
M582 T11
M581 P11 T11 R-1

G4 S0

G91              ; relative positioning
G1 H2 Z5 F420   ; lift Z relative to current position
G90              ; absolute positioning
G1 X190 Y50 F6000 ; go to first probe point
G30 X150 Y150    ; home Z by probing the bed

G1 Z0

I suspect that this could be done with a conditional gcode however I can't seem to find how to check if a trigger is depressed or not.

@dc42 sorry had a moment. Definitely 2.4

@dc42 weirdly the m115 output didn't have the bootloader but i updated it to the most recent last week so it should be 2.4

@phaedrux said in No setting motor current with macro:

Update to 3.4 final.

https://github.com/Duet3D/RepRapFirmware/releases/tag/3.4.0

I have done the update and still have the issue unfortunately.

@dc42 said in No setting motor current with macro:

@nriviera said in No setting motor current with macro:

@dc42 I do get random CAN-bus unhandled inputs (2000, 3000, 2100 and sometimes others) so maybe that's it. I'll give it a go.

That's typically triggered by removing power to the tool board but keeping 5V power to the main board. Is that what you are doing?

I'm not too fussed about the warnings and errors it's having to run a separate macro every-time I print is the annoying part. Should I use a very long delay?

@dc42 yes. The 6HC 5v is always on as it triggers the 24v power which power the toolboards. I have a fairly large delay (I changed it to 10s but even 20s doesn't make any difference) to ensure the boards have enough time to boot but still get current issues intermittently.

@dc42 its been a while and the error messages never went away but I stopped having extrusion issues so I didn't pursue it. They seem to have come back intermittently this last week however. I've updated the bootloader to 2.4, running 3.4rc2 firmware. The config files are unchanged from above. Any idea?

@dc42 I do get random CAN-bus unhandled inputs (2000, 3000, 2100 and sometimes others) so maybe that's it. I'll give it a go.