1HCL probing problem with ***video***

[dc42]

@highfreq thanks for confirming the workaround. That tells me what is going wrong. Now I need to work out why it goes wrong on your system but not on my bench setup.

[HighFreq]

@dc42 not meaning to push you but do you have any idea how long it'll take to have a fix?

Maybe multiple motors on z axis or big motors are more exposed to this problem?

[dc42]

@highfreq please send M115 from the console, to confirm that you really are running firmware 3.4.2 on the main board. You are running in SBC mode, and I have known the SBC to downgrade RRF in the past.

The problem is that the main board firmware isn't tracking the motor steps during the probing move. This behaviour was a known bug in some earlier firmware versions. I'm reviewing the source code and I don't yet see how it could happen in 3.4.2. The flag that causes the main board to track motor steps even when there are no local drives involved is the same one that causes the move to end when the prove triggers.

[HighFreq]

@dc42

22/9/2022, 17:15:11 m115
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6XD FIRMWARE_VERSION: 3.4.2 ELECTRONICS: Duet 3 MB6XD v1.0 or later FIRMWARE_DATE: 2022-09-13 15:19:26

To rule any installation problem out we did the installation from scratch already twice.

Maybe has something to do with the relatively new 6XD?

[dc42]

@highfreq thanks for confirming the version.

Please run the following test:

• Connect a PC running a terminal emulator (e.g. YAT) t the USB port
• Set up the machine so that you are ready to send the G30 command that goes wrong
• Send M111 S1 P4 and then M111 S1 P6
• Send G30. This should produce some output in the terminal emulator screen.
• When the move completes, copy the output from the terminal emulator screen and paste it into a message here.

[HighFreq]

@dc42 Do i need to do this with or without the fake axis workaround?

[HighFreq]

@dc42

This was the output of the terminal, the test was made WITHOUT workaround.

Connection to SBC established!
Executing config.g… Done!
RepRapFirmware for Duet 3 MB6XD is up and running.
Forward transformed 0 200000 0 to 0.00 1000.00 0.00
Forward transformed 0 200000 0 to 0.00 1000.00 0.00
Forward transformed 0 200000 -1600 to 0.00 1000.00 -5.00
Forward transformed 0 200000 -1600 to 0.00 1000.00 -5.00
Forward transformed 0 200000 0 to 0.00 1000.00 0.00
Transformed 0.00 1000.00 -5.00 to 0 200000 -1600
pr 1 ts=215104413 DDA: s=1.5050e+3 vec=[0.000000 0.000000 -1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000]
a=4.4444e-10 d=4.4444e-10 reqv=1.1111e-5 startv=0.0000e+0 topv=1.1111e-5 endv=0.0000e+0 cks=135474990 fp=4294967295 fl=0c00
U d=1.3889e-1 t=25000.0 b=0.0000e+0 c=4.5000e+9
U d=1.5047e+3 t=135424992.0 c=9.0000e+4
U d=1.3892e-1 t=25000.0 b=2.5000e+4 c=-4.5000e+9
DMZ: dir=B steps=481600 next=1 rev=481601 interval=3749 ssl=45 A=0.0000e+0 B=0.0000e+0 C=1.4062e+7 dsf=1.3889e-1 tsf=25000.0
Forward transformed 0 200000 480000 to 0.00 1000.00 1500.00
Transformed 0.00 1000.00 5.00 to 0 200000 1600
Transformed 0.00 1000.00 5.00 to 0 200000 1600
Transformed 0.00 1000.00 15.00 to 0 200000 4800
pr 1 ts=232476041 DDA: start=[0.000000 1000.000000 5.000000] end=[0.000000 1000.000000 15.000000] s=1.0000e+1 vec=[0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000]
a=3.5556e-10 d=3.5556e-10 reqv=4.4444e-5 startv=0.0000e+0 topv=4.4444e-5 endv=0.0000e+0 cks=350000 fp=4294967295 fl=0401
U d=2.7778e+0 t=125000.0 b=0.0000e+0 c=5.6250e+9
U d=4.4444e+0 t=100000.0 c=2.2500e+4
U d=2.7778e+0 t=125000.0 b=1.2500e+5 c=-5.6250e+9

[dc42]

@highfreq thanks, I did want the results of testing without the workaround.

[HighFreq]

@dc42 is it the log you were looking for?

[dc42]

@highfreq yes, thanks!

I believe I have found the reason for this behaviour, and I expect to have a new firmware build for you to test later this morning. You were right, it is specific to the 6XD board.

[HighFreq]

@dc42 thank you very much, looking forward to it.

[dc42]

@highfreq please try this build. In my tests, it fixes the problem.
Duet3Firmware_MB6XD.bin

[HighFreq]

@dc42 will test asap and let you know.

Do i have to turn off any of the logging i switched on yesterday?

thanks

[HighFreq]

@dc42 So far everything works as expeced.

Thank you and great customer service!!!!!!

[dc42]

@highfreq I'm sorry it took so long. As it only happened in closed loop node, I assumed it was an issue with the EXP1HC firmware, so I was looking in the wrong place. In fact it was caused by the step generation code on the 6XD being different from other Duets because of the different hardware (the 6XD uses a timer to generate the step pulse so that the CPU doesn't have to hang around until it finishes).

[HighFreq]

@dc42 Thank you very much!!!

[HighFreq]

If a mod could change title to SOLVED would be greatly ppreciated.

[HighFreq]

@dc42 Still working fine. Don't know if it could be related but the 1HCL didn't show any brake issue after we installed the probe patch on the 6XD.
1HCL are running on latest stable release.

[dc42]

@highfreq I'm glad to hear it. I would not expect to see any brake issues when a driver is enabled (assuming you set the current first), but a delay between de-energising the brake solenoid (to turn the brake on again) and disabling the driver is likely to be needed. I'll make that delay configurable in RRF 3.5.

[HighFreq]

@dc42 ok, great

thank you.