G30 during G28 issue

fcwilt

One thing to remember is the some errors in config.g can cause the processing of config.g to be cut short.

I dealt with this by tracing the processing of config.g to make sure that it ran to completion:

At the start of config.g I have this local variable declared:

var trace = "config_trace.txt"

Then I create the first line of the file:

echo >{var.trace} "trace begun"

Then I add additional lines as seem appropriate at appropriate locations:

echo >>{var.trace} "network config"

echo >>{var.trace} "motor config"

Finally at the end of config.g I have this:

echo >>{var.trace} "trace done"

It's not much work and can save time in the long run.

Frederick

dc42

@Leonard03 did you ever test this system using RRF 3.6.0-rc.2; and if so, did that have the same issue?

I made a change to the way G30 probe coordinates are calculated between rc.2 and rc.3. It's possible that this change may have introduced a fault that is specific to Duet 2 boards.

Leonard03

@fcwilt Thank you for the extensive response. I will try to answer your ideas an questions in order so:

@fcwilt said in G30 during G28 issue:

Those G1 H2 Z# commands are not needed if you simply home Z first and leave it at a safe position for then homing X and Y.

Homez.g I tried to keep it as simple as possible. Most of the time I don't use individual homing files, and every time I home XY and after Z and if MMU is enabled W V and U in that order.
I use the H2 parameter in home X and Y only because it allow movement of Z.

@fcwilt said in G30 during G28 issue:

Now is is just my personal preference but I forgo the minor optimizations that can be done in homeALL.g by just invoking the individual homing routines:

I use this approach only for the MMU part (UV and W) The only reason I don't use this for main axis is because I like the motion of both X and Y during homing, in tandem Running both as separate M98 calls will separate that motion, that I don't like. Aesthetics, only reason :)) Ah, and I set the Z offset only during a print using G28 because the homez.g I can use it for another thing: rough leveling the bed after disassembly. After that I use the BL touch for more accurate Z0.
Before any print and before bed tramming (G32) and mesh (G29) yes, i use the sensor. for anything else, the switch is good enough (another example is NonLinear Extrusion calibration. Extruding in mid air)

@fcwilt said in G30 during G28 issue:

As to the original issue I am still stumped - something is being overlooked I imageine.

I am pretty sure that is the case..

@fcwilt said in G30 during G28 issue:

One thing to remember is the some errors in config.g can cause the processing of config.g to be cut short.

Very good point! And I have a dumb answer to this :)) Apart of the last command regarding the config-override.g.. If my config.g gets in trouble, I know it because the PanelDue will remain not connected :)) So.. if PanelDue is is not connecting, I know that I messed something up in the config

@dc42 said in G30 during G28 issue:

did you ever test this system using RRF 3.6.0-rc.2; and if so, did that have the same issue?

Thank you for your replay. I tried rc.2 now with the same result... Sadly I don't know when this behavior started. I will try with rc.1 as well and report back

fcwilt

@Leonard03

Thanks for the reply.

Since you have a Z end-stop homing Z first means you have no need to use G1 H2 commands.

Why not use the simplest code possible?

I understand it may be satisfying in some sense to optimize homing by coding homeALL.g discretely but that again makes the code more complicated. Also it means if you find a flaw in homing X or Y you have to makes changes in multiple places.

In any case it's your printer to configure as you please, just offering advice based on many years of programming experience and several years for using Duet hardware.

Now back to the original issue.

If you don't set the Z=0 Datum in the homing code, it all homes correctly?

When you set the Z=0 Datum in some separate code is the X position the same before and after executing the code?

Frederick

Leonard03

@dc42 Found when! Tried now old binaries that I have saved.
This particular issue occurred between 3.6.0-beta.2+4 (2024-12-01 18:14:39) and 3.6.0-beta.2+5 (2025-01-04 14:18:24).
In +4 version the X axis homes in the same location regardless of the G30. In the +5 version.. well.. is the present topic. I also have the .map files for them if they help you in any way

Leonard03

@fcwilt Now, back on the 3.6.0-rc.3
You pointed out some very interesting things, I admit!

@fcwilt said in G30 during G28 issue:

Since you have a Z end-stop homing Z first means you have no need to use G1 H2 commands.

Now looking at that particular macro.. I wonder the same.. Why?

@fcwilt said in G30 during G28 issue:

Why not use the simplest code possible?

For those two points, I don't have an answer, just an excuse :)) This macro most likely is the original generated by the RRF configurator for the version 3.2. So is quite old. But if it is not broken, don't fix it This is the excuse. But now I'm releasing that it makes no sense now.
This part, done. Removed the line that contained the G1 H2 command from homez.g.

@fcwilt said in G30 during G28 issue:

just offering advice based on many years of programming experience and several years for using Duet hardware.

Thank you very much for this, I really appreciate this ^_^

@fcwilt said in G30 during G28 issue:

f you don't set the Z=0 Datum in the homing code, it all homes correctly?

Let me see if I understand the question correctly:
You are referring to the G92 Z0 command, right?
I use it in both homez and homeall.

Removing it from homez.g: no change, so another line deleted
Removing it from homeall.g: no change, so another line deleted as well
The original issue is still present, sadly..
As for this

@fcwilt said in G30 during G28 issue:

When you set the Z=0 Datum in some separate code is the X position the same before and after executing the code?

I don't understand your question, I apologize. Plese give me a little more details so I can try out

fcwilt

@Leonard03 said in G30 during G28 issue:

I don't understand your question, I apologize. Plese give me a little more details so I can try out

Let's assume the current Machine Position is X=20 Y=20.

To verify this you will need to check in the Object Model as the DWC user interface shows User Position, not Machine Position.

Then execute the G30 at that position.

Then check the Machine Position to see if it has changed.

Frederick

Leonard03

@fcwilt Right, got the point!
I've made this little macro:

; printer is homed using G28 X Y Z prior to executing this macro

G90
G1 Z10 F600 ; space for the BLTouch pin to extend

echo "User " ^ move.axes[0].letter ^ " position is: ", move.axes[0].userPosition
echo "Machine " ^ move.axes[0].letter ^ " position is: ", move.axes[0].machinePosition
echo "User " ^ move.axes[1].letter ^ " position is: ", move.axes[1].userPosition
echo "Machine " ^ move.axes[1].letter ^ " position is: ", move.axes[1].machinePosition

This is the result after G28 X Y Z:

User X position is:  4.739
Machine X position is:  4.739
User Y position is:  -2.000
Machine Y position is:  -2.000

Now, moving the nozzle 100mm in X and Y, so, G1 X100 Y100 F2400

User X position is:  100.000
Machine X position is:  99.997
User Y position is:  100.000
Machine Y position is:  100.000

G30 and the result:

User X position is:  99.285
Machine X position is:  99.285
User Y position is:  100.000
Machine Y position is:  100.000

Not exactly, but they seems to be pretty close. The physical position is way bigger

fcwilt

@Leonard03

Good job.

Very strange.

I'm wondering at this point if there is a problem in the firmware.

If I was using RC firmware (which I never do) I would resort to the last stable version prior to the RC version and see if the problem goes away.

Frederick

Leonard03

@fcwilt Thank you ^_^
Digging deeper, I got something:

@Leonard03 said in G30 during G28 issue:

This particular issue occurred between 3.6.0-beta.2+4 (2024-12-01 18:14:39) and 3.6.0-beta.2+5 (2025-01-04 14:18:24).

I feel really sorry... Looking at commits on GitHub between those dates, there were many and substantial changes in RRF.. I feel sorry because only now I came across this bug (?) after so much time

fcwilt

@Leonard03 said in G30 during G28 issue:

I feel really sorry... Looking at commits on GitHub between those dates, there were many and substantial changes in RRF.. I feel sorry because only now I came across this bug (?) after so much time

There was a time when I would install beta or rc firmware - but no longer - I have things to print.

So I am still using 3.5.4.

Frederick