Teaser for today - can you guess the answer?

deckingman

Just thought I'd share my latest "head scratcher". I decided that I'd take the opportunity to set my printer origin to the centre rather than the front left corner. It's mostly because the head can extend beyond the build plate for nozzle wiping so I wanted the axis min and max to suit the actual available travel, but in my slicer I also set the origin as centre but use a different min and max for the actual build plate area. That should ensure that no print move can go beyond the build plate but non-print moves such as nozzle wiping can indeed do so... at least that's my reasoning.

So homing X worked fine and after homing X, I then move to X=0 (G90 then G1 X0) which is the centre. All fine and dandy. Homing Y also worked fine and after homing I move to Y=0 which is the centre of the bed - also fine and Dandy. I did the same thing in homeall by homing X and Y before homing Z. But after homing X and Y, I used the commands G90 then G1 X0 Y0 to move to the centre before homing Z. However, the print head didn't move - it stayed in the corner. Methinks that's odd. Double checked - yes, it's definitely absolute not relative. I ran it again and the same thing happened. Ran home X - all fine. Ran homeY - all fine. Ran homeall - the print head stayed in the corner after homing X and Y. Ran homeall again and observed what happened with the axes positions in DWC. When the end stops triggered, X and Y were at their respective axis (negative) limit positions but then changed to being X0 Y0 without the print head moving.

Something in homing Z must be changing the XY origin thought I. How the hell can that be? Ran homeX then homeY then home Z - all fine and dandy - the print head gets moved to the centre prior to homing Z. Ran home all again, and the print head stayed in the corner. But home all runs much the same commands as each individual homing macro. At this point I started to doubt my sanity.

The answer was a simple mistake on my part. Can you guess what it might be? I can tell you that it isn't anything to do with G90/G91 relative/absolute, nor is it anything to do with G1 moves, nor is it anything to do with axis limits, nor is it anything to do with movement queue (I use M400).

dc42

@deckingman did you have any G92 commands in the homing files?

oliof

@deckingman anything with endstop position?

deckingman

@dc42 said in Teaser for today - can you guess the answer?:

@deckingman did you have any G92 commands in the homing files?

Nope.

deckingman

@oliof said in Teaser for today - can you guess the answer?:

@deckingman anything with endstop position?

Nope.

droftarts

@deckingman M208 in homeall.g? G1 H3 rather than G1 H1 on the last move?

Ian

deckingman

@droftarts said in Teaser for today - can you guess the answer?:

@deckingman M208 in homeall.g? G1 H3 rather than G1 H1 on the last move?

Ian

Nope

JoergS5

A command which resets homing like M584, M18, M501, tool changes?

droftarts

@deckingman Would it give it away if we saw the 'wrong' homeall.g?
I've had all my printers set to centre origin for years, just seems more 'right'. I think it was after using deltas, and then Ultimakers for a while, which were always set up like that.
Here's a wiki page that covers it, too: https://docs.duet3d.com/User_manual/Tuning/Bed_origin

Ian

deckingman

@JoergS5 said in Teaser for today - can you guess the answer?:

A command which resets homing like M584, M18, M501, tool changes?

Nope

deckingman

OK, I'll make it easy for you. Below is the offending homeall.g file with the error present.

I'd like to keep this "teaser" going for a little while longer so when you spot my mistake, reply with something like "found it in "n" seconds/minutes/hours".

Herewith the file...........

; homeall.g

T0 P0; select a tool - any one will do - don't run tool change macros

; check if tool is hot, if not start to heat it to 140 deg C

if sensors.analog[1].lastReading < 140
	M568 P0 S140
	M291 P"Hot end set to 140 deg C" R"Homing Macro" S1 T10

; Lift Z (lower bed) relative to current position

G91; relative
G1 Z5 F600 ; move bed down 5mm

;check if X or Y endstops are already triggered

if sensors.endstops[0].triggered 
	G1 X10 F3600 ; if sensor tiggererd, move away 10mm relative then......
	M400; wait for move to finish then.......
	if sensors.endstops[0].triggered; .....check again  
		abort "X endstop already triggered after moving away from end stop - aborting" ; abort if still triggered. 

if sensors.endstops[1].triggered 
	G1 Y-10 F3600 ; if sensor tiggererd, move away 10mm then......
	M400; wait for move to finish then.......
	if sensors.endstops[1].triggered; .....check again  
		abort "Y endstop already triggered after moving away from end stop - aborting" ; abort if still triggered. 

; reduce motor currents to 25% for X and Y

M400 ; wait for any moves to finish (shouldn't be any)
M913 X25 Y25

G1 Y420 X-420 H1 F4800 ; move until one or other end stops trigger

G1 Y 420 H1 F4800; course home Y 

G1 Y-10 F600; Go back a few mm

G1 Y50 F360 H1 ; fine home Y 


G1 X-420 H1 F4800; course home X (80mm/sec)

G1 X10 F600 ; Go back a few mm

G1 X-40 F360 H1 ; fine home X 


; fast move to centre
G90; set to absolute coordinates 

M400 ; wait for any moves to finish (shouldn't be any)
M913 X0 Y0; restore motor currents for fast move  
G1 X0 Y0 F5400; move to the centre of the bed


;***Now home Z****

M400 ; wait for moves to finish
G91; back to relative

; now do homing at high speed until slotted opto triggers
M98 P"0:/macros/FastJogZ.g" ; run macro which moves 80mm at high speed and repeats until trigger

; check if end stop already triggered
if sensors.endstops[2].triggered ; if it is triggered..... 
	G1 Z10 F300;... then move down 10mm.......
	M400; wait for move to finish, then ......
	if sensors.endstops[2].triggered ; ........check again if it is triggered..... 
		abort "Z endstop already triggered after moving away from stop - aborting"; ........and abort if it still is

; reduce motor currents to 50% for Z 
M400 ; wait for any moves to finish (shouldn't be any)
M913 Z50 

; check agin if tool is still at or above 140 deg C, if not heat it
if sensors.analog[1].lastReading < 140
	M568 P0 S140
	M291 P"Hot end below 140, so set to 140 deg C" R"Z Homing Macro" S1 T10

; now wait for temp to get to 140 or above

while sensors.analog[1].lastReading < 140
	M291 P"Waiting for hot end to heat" R"Z Homing Macro" S1 T4
	G4 S4

; FAST home Z 
G1 Z-120 F300 H1 ; should be within about 80mm so 120mm more than enough
M400 ; wait for moves to finish

G1 Z5 F300 ; lower bed again

; SLOW home Z
G1 Z-10 F60 H1

; set offset 
G91 ; relative
G1 Z{global.z_offset} ;slightly lower
G4 P100; .1 sec delay
G92 Z0 ; set new zero

; lower bed again
G90 ;absolute
G1 Z5 F300

M400 ; wait for moves to finish then restore motor currents to 100% for Z
M913 Z100; restore Z motor current 

M568 P0 S0; set hot end temp back to zero

jay_s_uk

@deckingman found it (assuming my DM was correct) as I scrolled down the homeall

o_lampe

@deckingman #MeToo
There were some gcodes I'm not familiar with and had to read up

droftarts

@deckingman #methree ah yes, saw it pretty quickly once you’d posted the homeall.g.

Ian

deckingman

In case anyone is still scratching their head, if one restores the motor current to zero instead of 100% ( M913 X0 Y0 instead of M913 X100 Y100 ), then any following G1 move will result in no physical movement of the motors. But the firmware doesn't "know" this and so reports the motor positions as being their latest commanded position -in this case 0,0 which is the centre of the bed although the print head remained in the left rear corner.

In my defence, the reason it took my about 10 minutes to find my error was that I changed the printer origin at the same time as I started to change my homing files from a CoreXYUV machine to a simple CoreXY. So "origin" was at the forefront of my limited mental capacity. That's my feeble excuse and I'm sticking to it.

SJI

@deckingman would that then constitute as a bug

deckingman

@SJI said in Teaser for today - can you guess the answer?:

@deckingman would that then constitute as a bug

Only in the sense that the firmware isn't idiot proof - but then what is? I suppose one could make the case that the firmware shouldn't allow users to set zero motor current - maybe default to a pre-determined minimum. But who decides what that minimum should be and is there a minimum that would suit every machine? - probably not. There are other commands that would give zero motor current (e.g. M906) and yet more that would likely result in no motor movement when a G1 is sent, such as zero maximum speed (M203), zero acceleration (M201) etc. And one could also make a similar case for things like fans where setting the maximum speed to zero (M106 Pn X0) would result in the fan not turning when commanded to do so. So I'd say that once you start looking at making things idiot proof whilst allowing users to make changes to their configurations, you end up going down an infinitely deep and infinitely complex rabbit hole.

o_lampe

@deckingman IMHO M913 X0 should flag the axis as not homed, just like M84 X (disable motors) does.
But the examples you gave wouldn't risk loosing position. They only disable motion, like M92 X0.

deckingman

@o_lampe said in Teaser for today - can you guess the answer?:

@deckingman IMHO M913 X0 should flag the axis as not homed, just like M84 X (disable motors) does...............................

What about M913 X1? It's unlikely that 1% motor current would be sufficient to drive a motor (depending on a number of factors) so should that also flag any axes as not homed? If so then what about 2% current, or 3 or 4? You'd also need to apply the same criteria to M906 and probably M917. I think you can see where I'm going with this but I have more important things to think about right now.

oliof

@SJI no, its open loop control after all.