Duet 3/Rpi + toolboard on 3.2b3 - G29 fails
-
@oozeBot Please try to download and flash that file again - I just updated it once more with my other hotfix. If it remains in the "busy" state with that build, please share the debug log of DCS and I'll see what I can do.
-
@chrishamm will do it right now.. thanks
-
it stayed in a busy state. I'll capture the DCS log and upload here soon..
-
@oozeBot I could just reproduce this problem and will look into it again. To my surprise it worked nicely before with 100 points.
-
@chrishamm ok, I'll hold off on uploading a log. Please let me know if you have another update to test.
-
@oozeBot I've updated my experimental Duet 3 MB6HC binary again because I found one more potential problem in it.
@jay_s_uk The same issue will probably affect your Duet 3 Mini 5+ v0.2 as well, so here is another build for you in case you want to test it before the next release.
Duet software engineer
-
@chrishamm thanks - I'll try now and report back..
-
@chrishamm When trying to upgrade the firmware when the board is connected to an SBC, I get this error.
I also got this when I initially upgraded to 3.2beta3 and used the erase method to upgrade the firmware.
I ran the upgrade for the other build you did in standalone mode as I was doing some testing at the time. -
@jay_s_uk I guess you uploaded that file before when DWS was running as root. To fix that, connect to your Pi via SSH and run
sudo chown -R dsf.dsf /opt/dsf. Then you should be able to upload it again when DWS is running as the regular service.PS: Be aware that you need to delete the new v0.4 IAP binary and rename the v0.2 IAP binary by removing the _v02 suffix from the other filename, else the upgrade will fail on the v0.2 prototype.
Duet software engineer
-
@chrishamm first try of 169 point mesh worked! I'm going to reboot and do it again here in just a few minutes..
-
@chrishamm After rebooting, I cannot get my z-axis to home.. it is not following the macro, which is pasted below. It only touches the probe down once in the middle of the plate on line 20. It skips line 27 and immediately moves to X20 Y20. On line 29, it touches down once or twice and then goes down again without extending the probe - I have moments to pull the plug at this point or else it will crash into the bed.
This is new to the last file you uploaded after a reboot.
; == home the Z axis ================================================ M400 ; wait until idle M280 P0 S160 ; reset BL Touch if move.axes[0].homed == false M98 P"homex.g" if move.axes[1].homed == false M98 P"homey.g" G92 Z0 G1 X132.5 Y0 Z5 F24000 ; move to the front center of the build plate M400 ; wait until idle M561 ; clear any bed transforms M558 F1200 A1 G92 Z333 G30 Z-99999 ; sets z-height relative to print bed M566 Z140.00 M201 Z300.00 M558 F120 A10 M561 G30 Z-99999 G30 P0 X20 Y20 Z-99999 ; probe midway between front and rear belt on left side G30 P1 X284.80 Y20 Z-99999 S2 ; probe midway between front and rear belt on right side M566 Z300.00 M201 Z300.00 G1 X0 Y0 Z10 F24000 ; park the tool M400 ; wait until idle -
@oozeBot Okay, I'll test some more conditional G-code tomorrow. Unfortunately your macro is rather difficult to test for me because I don't have two Z motors, so it would help if you could share the debug log again.
-
@chrishamm I'll get that uploaded here in the next hour or two. FYI - here are my deployprobe.g and retractprobe.g.
deployprobe.g
M280 P0 S10retractprobe.g
M280 P0 S90 -
@oozeBot Thanks, I use the same commands on my machine with a BLTouch. I haven't seen any more problems with bed probing with the build that I shared before but I admit I haven't tried many conditional G-codes yet.
Duet software engineer
-
@chrishamm here is what I could capture before cutting power before it crashed into the build plate. Note that it actually did complete homing Z successfully the first time I tried in this log, but failed the second time. I had tried right before this and saw it fail several ways, sometimes not extending the probe, other times it seems to skip to the next probe point without completing the current probe. Also note this is the behavior in 3.2b2 that I reported which ultimately led to me rolling back to 3.2b1.
-
@chrishamm I can confirm I was able to probe a bed with 400 points.
I'll check the homing of the printer in the morning once I'm physically in front of it -
@chrishamm ok, caught a better crash while running homez.g which I posted earlier. I just let it probe with the bltouch retracted and protected the bed with a piece of cardboard..
-
@chrishamm last log file for now. This is also from homez.g which I posted earlier. This time, the first g30 completed successfully, it moved to the left side, touched the probe down once, moved to the right side, probed several times, and then moved back to the left side and started probing again, eventually probing with the probe retracted..
Also, could this be related? Note the 0 at the end of deployprobe0.g and retractprobe0.g. It's found throughout the log but only around 1/3 of the calls seem to be wrong - the rest properly reference deployprobe.g and retractprobe.g..
[debug] Macro file deployprobe0.g not found [debug] HTTP: ==> Starting code G30 Z-99999 ; sets z-height relative to print bed [debug] HTTP: Disposing macro file deployprobe0.g[debug] Macro file retractprobe0.g not found [debug] HTTP: ==> Starting code G30 Z-99999 ; sets z-height relative to print bed [debug] HTTP: Disposing macro file retractprobe0.g -
RRF allows each Z probe to have its own deploy and retract files. That's why it's looking for deployprobe0.g first before falling back to deployprobe.g.
-
@oozeBot Thanks for the logs. I'm afraid I could not reproduce any of the out-of-order replies or stack underruns that I could discover in your log - please make sure the Duet 3 firmware is 3.2-b3+2-ch and NOT 3.2-b2+1 or older (check on Settings -> Machine).
The reason for your problem is probably a combination of these issues but I was unable to provoke them on my setup with the latest firmware.
