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

[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.