M582 in start.g to check for homed axes

TC

Sure! Here are the files:

End of config.g

; Trigger
;E2 reserved for Homing Memory!
M581 E2 S0 T2 C0

Start.g:

;Check for homed axis using Trigger (see config.g and homeall.g)
M582 T2

Homeall.g:

; homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool v2.0.3 on Thu Sep 12 2019 15:08:34 GMT+0200
G91                     ; relative positioning
G1 Z5 F6000 S2          ; lift Z relative to current position
G1 S1 X-320 Y-320 F1800 ; move quickly to X and Y axis endstops and stop there (first pass)
G1 X5 Y5 F6000          ; go back a few mm
G1 S1 X-320 Y-320 F360  ; move slowly to X and Y axis endstops once more (second pass)
G1 S1 Z-405 F1800       ; move Z down stopping at the endstop
G90                     ; absolute positioning
G92 Z0                  ; set Z to axis minimum (you may want to adjust this)

; Uncomment the following lines to lift Z after probing
G91                    ; relative positioning
G1 S2 Z5 F100          ; lift Z relative to current position
G90                    ; absolute positioning

;Trigger as Homing Memory
M581 E2 S-1 T2 C0

trigger2.g:

;Check for homed axis

M300 S300 P1000
M98 P"homeall.g"
M300 S300 P1000

Start of Gcode file:

; generated by PrusaSlicer 2.1.0+win64 on 2019-11-11 at 08:58:49 UTC

; 

; external perimeters extrusion width = 0.45mm
; perimeters extrusion width = 0.45mm
; infill extrusion width = 0.45mm
; solid infill extrusion width = 0.45mm
; top infill extrusion width = 0.40mm
; support material extrusion width = 0.40mm
; first layer extrusion width = 0.42mm

M107
;Start G-Code (Slic3r)
M83  ; extruder relative mode
;M104 S210 ; set extruder temp
M140 S60 ; set bed temp
G10 P0 S210 R210
M190 S60 ; wait for bed temp
M109 S210 ; wait for extruder temp
;G28 W ; home all without mesh bed level
G92 E0.0
G21 ; set units to millimeters
G90 ; use absolute coordinates
G1 Z0.5  F500 ; move up
G1 X0.0 Y0.0 F1000.0
G1 X60.0 E9.0 F1000.0
G1 X100.0 E12.5 F1000.0
G1 Z3.0  F500 ; move up
G1 X150.0 Y150 F2000.0
G92 E0.0
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
; Filament gcode
G1 E-0.80000 F2100.00000
G92 E0
G1 Z0.100 F4800.000
;Begin layer 0 at 0.1mm
G1 X55.472 Y190.777
G1 E0.80000 F2100.00000
G1 F600
G1 X56.928 Y190.421 E0.82483
G1 X58.395 Y190.176 E0.84948
G1 X60.775 Y190.010 E0.88901
G1 X74.540 Y190.009 E1.11708
G1 X76.303 Y190.086 E1.14632
G1 X78.042 Y190.315 E1.17538
G1 X79.754 Y190.693 E1.20444

I hope that helps

fcwilt

Hi,

Interesting but why do you wish to do this? I cannot determine what the goal is.

Thanks.

Frederick

deckingman

Hmm. It's a bit difficult to fathom out where it's going wrong. TBH, I don't use a start.g macro so I'm not best placed to help. A suggestion though is to use either M117 or M291 to pop up a message at the start of your trigger, start.g, and homing files. Maybe put a few more in other places too. Obviously use a different message in each place. The idea being that it will show the order that things are happening so might help with de-bugging.

Maybe someone else who does use start.g might have a better idea.

As an aside, I note that your slicer start code has G92 commands to zero the extruder. They do no harm but as you are using relative extrusion rather than absolute, they aren't necessary.

deckingman

@fcwilt said in M582 in start.g to check for homed axes:

Hi,

Interesting but why do you wish to do this? I cannot determine what the goal is.

Thanks.

Frederick

I could be wrong but I'm assuming the OP wants to run homeall as part of his slicer start code, but in such a way that it will only run if the axes start in a non-homed state. Otherwise, if the axes are already homed, then homeall will not run.

I guess it might save some time when running multiple repeat prints. It's not something that I would use myself though.

aidar

I dont use start.g macro as well, so just blind guessing here, but looks like actual gcode file is executed before homeall.g is finished. Maybe because start.g calls trigger2.g and then actual gcode is executed, but because trigger.g calls homeall.g, they are executed same time. How to make gcode wait until homeall.g is finished? Not sure at all, maybe try to add M400 to trigger2.g after M98 command?

TC

@fcwilt Well sometimes I allready did something with the printer and it is already homed and sometimes it is not. Additionaly it is a prove of concept

fcwilt

@TC said in M582 in start.g to check for homed axes:

@fcwilt Well sometimes I allready did something with the printer and it is already homed and sometimes it is not. Additionaly it is a prove of concept

I'm still a bit foggy on the concept.

Even if the printer is already homed the amount of time it takes to home it again is small compared to the amount of time most anything is going to take to print.

I print mostly functional parts and even the small ones take 30 minutes or more. Saving 30 seconds by skipping a redundant homing is not going to buy me much time.

Of course if you are just doing it for fun - that I can understand - fun is good.

Frederick

TC

@aidar Yes that was my assumption. I already tried a M400, not helping at all.

@deckingman I used beep sounds to debug and it definitly reaches the homing file. But it is not executed immediately. That is why I already wrote, that commands are interfering with each other and asked for someone who knows how the priority of triggered macros is handled.

A Former User

Not quite sure I get use case here.

If you want to avoid homing the printer between prints, just don't run homing sequence? (You'll need to keep the motors energized between prints to keep accurate positioning).

To avoid "unnecessary" homing at start up I did something similar. Create a trigger for each endstop, check the triggers manually and delete the triggers. trigger for each axis contain a G92 command to set the axis to zero or max travel. In having the axis set with G92 before config.g terminates will leave the printer in a homed state at power on; IF the axis triggers the limit switch at power on. However it won't be quite as accurate as just homing as the axis can move and still keep the end stop triggered, and the time savings won't be all that, I only used it for testing purposes.

deckingman

@TC You might just be better off waiting for conditional gcode which DC42 is in the process of implementing. It might be easier in the long run.

TC

Hm I am not that concerned about this homing thing. You are right the saved time is not much. But if this is not working, does it mean triggers are in General unreliable during a print?

deckingman

@TC said in M582 in start.g to check for homed axes:

Hm I am not that concerned about this homing thing. You are right the saved time is not much. But if this is not working, does it mean triggers are in General unreliable during a print?

No. They generally work very well. I use them a lot.

TC

@deckingman Can you give an example what you use them for? Just Single comands or mpre complex movements?

deckingman

@TC said in M582 in start.g to check for homed axes:

@deckingman Can you give an example what you use them for? Just Single comands or mpre complex movements?

On Duet 2 I used to use these type of commands M581 E4 S1 T0 C0. Essentially just initiate an emergency stop when a normally open switch closed. On Duet 3 I'm using these type of commands M581 P"!0.io3.in" T2 C0 and M581 P"0.io3.in" T3 C0 which run macros when a set of contact on my UPS change state. I've found them both to work reliably and consistently. But as I mentioned before, I'm not familiar with using a start.g macro and I've never tried using M581 from within a macro.

deckingman

Thinking about this some more, I suspect that the problem might be to do with running a trigger from within a macro(start.g) which in turn runs another macro. I'm not much of writer of code but I'm thinking along the lines that a macro essentially branches away from the main code, runs a series of commands, then returns back the main code. A trigger works by kind of interrupting the main code so essentially it too branches. So maybe a trigger that runs a macro from within a macro returns to the wrong point.

I'm not sure if I've explained that very well and I could be wide off the mark.

A Former User

I've never tried using M581 from within a macro

works fine, to create or clear macros. but a newly created macro will not run if the chosen input is already asserted, an additional M582 is needed for that.

deckingman

@bearer Thanks for the clarification.

dc42

I suspect the problem is that M581 triggers other then emergency stop run from their own separate GCode stream. This will execute concurrently with the original GCode streams. There is a locking mechanism to prevent two streams doing simultaneous movement.

I'm not sure there is a foolproof way of doing that you want, however you could try putting a G4 delay command after the M582 command, to give the trigger macro time to execute, or at least time to start executing.

A Former User

@dc42 said in M582 in start.g to check for homed axes:

There is a locking mechanism to prevent two streams doing simultaneous movement.

is this on a per axis basis, or a single global lock?

dc42

@bearer said in M582 in start.g to check for homed axes:

@dc42 said in M582 in start.g to check for homed axes:

There is a locking mechanism to prevent two streams doing simultaneous movement.

is this on a per axis basis, or a single global lock?

A single global lock on the movement subsystem.