[3.6.0.Beta.2+4] G30 Z motion max accel not enforced

Notepad

@dc42 THe last version I was running was Beta2+1
At the time I wasnt aware of a +2 +3 or available. If you have the Drop box link, I can load each one up and see which version started the behaviour

dc42

@Notepad thanks. Beta 2+3 is at https://www.dropbox.com/scl/fo/pasag1g18orahwvn49qp2/ABWgw6D-TyKWxxurTmGwiUE?rlkey=r9h3rjyw1l4wh7xbr8yho37gw&dl=0 however it has an issue with CoreXY kinematics that cause the first X or Y movement to be diagonal. You should be able to work around that by commanding very short X and Y movement before homing. I didn't publisg the beta2+2 builds.

Please can you also try the following with beta2+4:

After homing for the first time, send M201, M203 and M906 to check that the Z acceleration, speed and motor current are as expected.
Try removing the two M201 commands from QuickHomeXL.g and use M201.1 instead to set lower acceleration when homing.
If it is safe to do so, try removing the two M906 commands from Quick HomeXL.g.

These tests may tell us whether the problem really is that Z acceleration or speed is too high, or motor current is too low.

Notepad

@dc42
Will do. I had to step out the factory for today so I will get these tested tomorrow.

Notepad

@dc42 Just to keep you updated. I will have the testing results tomorrow

dc42

@Notepad we've found a more general issue with beta4 performing moves at incorrect speeds and I am working on a fix. Although the symptoms we have reproduced are different from yours, I suspect it is the same fault.

Notepad

@dc42 Thats good to know. is there any additional testing you would like me to undertake with this new identified behaviour?

Notepad

@dc42 Is it possible to get a binary made for the duet 2. last thing I need to test is if its hardware specific.

Notepad

@dc42

I have results so far!

For firmware updates with no gcode changes
Beta 2+1 behaves as expected
Beta 2+3 Produces the artefact (does not move in a diagonal at first move command)
Beta 2+4 Produces the artefact

Using Beta 2+4 the Quick Home XL macro has been edited with debug steps
Quick Home XL.txt

Which has produced the following

Whilst the order of the debug outputs are out of sync with the requests. once the values have been shifted around, the requested changes do appear to be happening.
This does not rule out if the printer is processing command moves with incorrect values, but it is more likely that the print to DWC service might have a delay.
Both behaviours however do not explain the sudden rise in the Z accelerations.

Replacing M201 in the macro with M201.1 in the config.g

Important to note the M201 in the macro only commands the X & Y motors, the Z acceleration is commanded in the config.g already (set to z500).

the Config.g was updated to include M201.1 Z300

This did no change to the behaviour

M906 was removed from the macro, which did noticeably increase the distance the bed could move before stalling. This definitely highlighted that the bed was accelerating very aggressively.

To guarantee that this behaviour is repeatable, I have tested this on a separate machine. This machine does not have a roto toolboard, and is instead using a D3-mini WITHOUT sbc.
The firmware version is 3.6.0.beta2+4
config.g Quick Home XL.txt

The behaviour of the motor stalling from excessive accelerations is also present on this machine.

This currently concludes my available testing. It appears that the use of M201, M201.1 M906 do not affect the behaviour of the printers, and the z motion on consecutive homing moves appears to stay broken.

Homing the printer through the homeall button does appear to be working, The first use after using the macro does produce the same error, but subsequent uses of the homeall.g appears to be working normally.
The single error appeared when a G30 line was used in the middle of the homing sequence

What is very interesting is after using a mixture of homeall.g and quickhome.g the printer does not seem to be doing the incorrect behaviour any more. What did show up a single time before this behaviour change (but after the machine has been moving multiple times) is the print head on a homeY.g move, moved backwards in a 15 degree angle. After this the z movement stayed consistantly working normally.

My current gut feeling is the issue may be directly linked to the diagonal moving identified in Beta2+3

I hope this is helpful @dc42, if there is any way to gather more advanced debug logs that would be helpful. feel free to use me in any way needed,

T3P3Tony

@Notepad please could you test if this is resolved in 3.6beta3. test builds are available here:

https://www.dropbox.com/scl/fo/22qkmz3oqxo2jb97l7716/AMVS8V_burccxcC5HWIfwEk?rlkey=v5vi2k9q1qjqviq97otkjqn1g&dl=0. Please try them on your machine(s) if you can.

Release notes are at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-360-beta3-in-preparation.

T3P3Tony

@Notepad please use the official release files:

https://forum.duet3d.com/topic/37289/software-version-3-6-0-beta-3-now-available