G29 fails on Duet3 with toolboard
-
Hi,
I am scratching my head here. Mesh compensation keeps failing after about 6 or 7 probes on the bed. When it does I receive the following error:
1/21/2021, 2:17:33 PM G29
Error: M280: Response timeout: CAN addr 20, req type 4012, RID=75
Error: M280: Response timeout: CAN addr 20, req type 4012, RID=77
Error: Failed to enable Z probe
1/21/2021, 2:17:32 PM Error: Response timeout: CAN addr 20, req type 6037, RID=76I am runnning on 3.2.0-rc2
Below is the M122 for the toolboard and main board. I cannot seem to find an answer online for this issue. Please help.
M122 b20
Diagnostics for board 20:
Duet TOOL1LC firmware version 3.2-RC2 (2020-12-24)
Bootloader ID: not available
Never used RAM 4032, free system stack 82 words
HEAT 90 CanAsync 89 CanRecv 83 TMC 54 MAIN 208 AIN 64
Last reset 00:05:12 ago, cause: power up
Last software reset data not available
Driver 0: position 0, 409.0 steps/mm, standstill, SG min/max 0/0, read errors 0, write errors 0, ifcnt 12, reads 25095, writes 12, timeouts 0, DMA errors 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0
No step interrupt scheduled
VIN: 24.0V
MCU temperature: min 50.5C, current 50.5C, max 54.1C
Ticks since heat task active 144, ADC conversions started 311294, completed 311293, timed out 0
Last sensors broadcast 0x00000002 found 1 148 ticks ago, loop time 0
CAN messages queued 3622, send timeouts 10, received 2721, lost 0, free buffers 36M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2-RC2 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
Board ID: 08DJM-956L2-G43S4-6J9DJ-3SN6P-9S62G
Used output buffers: 1 of 40 (40 max)
=== RTOS ===
Static ram: 149788
Dynamic ram: 62800 of which 136 recycled
Never used RAM 146108, free system stack 126 words
Tasks: Linux(ready,81) HEAT(blocked,296) CanReceiv(blocked,830) CanSender(blocked,352) CanClock(blocked,352) TMC(blocked,19) MAIN(running,715) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:08:06 ago, cause: power up
Last software reset at 2021-01-13 13:44, reason: User, none spinning, available RAM 145928, slot 2
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task Linu Freestk 0 n/a
Error status: 0x04
Aux0 errors 7,7,7
Aux1 errors 0,0,0
MCU temperature: min 25.1, current 30.5, max 30.9
Supply voltage: min 23.8, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
Driver 0: position 32864, standstill, reads 43799, writes 18 timeouts 0, SG min/max 0/499
Driver 1: position 15200, standstill, reads 43799, writes 18 timeouts 0, SG min/max 0/791
Driver 2: position 3912, standstill, reads 43799, writes 18 timeouts 0, SG min/max 0/992
Driver 3: position 0, standstill, reads 43799, writes 18 timeouts 0, SG min/max 0/1023
Driver 4: position 0, standstill, reads 43800, writes 18 timeouts 0, SG min/max 0/799
Driver 5: position 0, standstill, reads 43800, writes 18 timeouts 0, SG min/max 0/408
Date/time: 2021-01-21 14:22:33
Slowest loop: 1172.85ms; fastest: 0.04ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 32261ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 46, completed moves 46, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 1967, send timeouts 0, received 5698, lost 0, longest wait 3ms for reply type 6024, free buffers 48
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 1ms ago
RX/TX seq numbers: 16376/16376
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x2c8a8
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0-rc2
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 31.48
Maximum length of RX/TX data transfers: 3004/780 -
Please upgrade both boards to 3.2 final and re-test.
-
Thanks DC42,
I upgraded to 3.2.0 an now the bltouch will deploy but not retract. M401 and 402 commands work after a full power reboot and before a G32 or G29. During a G32 it will work fine for 2 points, on the 3rd it did not retract. I did another power cycle tested with m401 and 402 at least 6 times cycles without issues. Did another G32 and this time it did not deploy on the 4th probing move. I already replaced the bltouch.
-
@jdumoulin
check the wiring. the cables that come with the bltouch often the cause for problems. -
Can you post your config,g?
Is the BLtouch connected to the tool board?
Can you verify that the firmware update was applied to the mainboard and tool board by sending M122 and M122 B1?
-
Please post your config.g and deployprobe.g files.
It may help to add a short delay between deployment and probing, either by using the M558 R parameter or by adding a G4 delay command at the end of deployprobe.g.
-
I'm not 100% but seeing as you are on RRF3
Should you not be using the following commands ?
M280 P0 S10 ; Deploy Probe PinM280 P0 S90 ; Retract Probe PinInstead of the M401/M402 commands
I think those are more suited to the newer firmware
And you can also re-set the probe using M280 P0 S160
-
@JayJay said in G29 fails on Duet3 with toolboard:
Instead of the M401/M402 commands
those commands execute the retract and deployprobe scripts.
-
@Veti said in G29 fails on Duet3 with toolboard:
@JayJay said in G29 fails on Duet3 with toolboard:
Instead of the M401/M402 commands
those commands execute the retract and deployprobe scripts.
Yes I know that, but if you read some info on setting up a BL-Touch it says that using M401/M402 is depriciated and that you should use M280 (with switches) instead.
-
@JayJay said in G29 fails on Duet3 with toolboard:
but if you read some info on setting up a BL-Touch it says that using M401/M402 is depriciated
can you point to the duet documentation where it says that?
-
@JayJay said in G29 fails on Duet3 with toolboard:
@Veti said in G29 fails on Duet3 with toolboard:
@JayJay said in G29 fails on Duet3 with toolboard:
Instead of the M401/M402 commands
those commands execute the retract and deployprobe scripts.
Yes I know that, but if you read some info on setting up a BL-Touch it says that using M401/M402 is depriciated and that you should use M280 (with switches) instead.
It's not deprecated, it's just that when using BLTouch you should not explicitly use M401 and M402, except to test the deploy and retract macros. Whereas when using other types of probe that need to be deployed, it makes sense to use M401 at the start of mesh probing or calibration, and M402 at the end.
-
@Veti said in G29 fails on Duet3 with toolboard:
@JayJay said in G29 fails on Duet3 with toolboard:
but if you read some info on setting up a BL-Touch it says that using M401/M402 is depreciated
can you point to the duet documentation where it says that?
in future can I kindly request that you do not edit/quote me with only a part of what Isaid, as your change does not reflect the full context of what I said, you need the whole context of what I posted.
And possibly my choice of word "deprecated" was not the best choice.
The documentation has changed, there used to be specific wording noting that there was a change from using M401/M402 to use M280
And as pointed out by by DC42 highlights another instance where the documentation is lacking context, the documentation says to use M280 and goes so far as specifically telling you to place those commands in your deploy/retract files in the root of the sys folder.
Now common sense would dictate that if the documentation is listing M280 and NOT M401/402 and that documentation had previously advised to now use M280 instead of M401/M402 that would technically mean M401/402 is no longer really used (or mentioned) so it would be logical to assume the word "depreciated" would come into effect.
And now further confusion with @dc42 stating that:
it makes sense to use M401 at the start of mesh probing or calibration, and M402 at the end.
There is NO specific mention of using M401/M402 in the documentation Mesh Compensation
And no specific example (as is usually the case) given for carrying out any probing using M401/M402.
So I am Sorry but the documentation really needs to be majorly overhauled as it is, things are littered all over the place and that leaves many users unsure about what to follow because of so many inconsistencies, conflicting info and ambiguity.
Commissioning & Testing (RepRapFirmware 3)
To test the setup with the nozzle maybe a 100mm up from the bed you can check if the trigger signal is reaching the Duet by attempting to extend the pin by using the following command:M280 P0 S10
If all is well the web interface should report a value of ”0” or "N/A" in the Z probe column when the pin is extended. You can then lightly touch the extended probe pin to check that the value in the Z probe Column changes to “1000”
You can retract the pin again with
M280 P0 S90
the above two commands are also what should be in /sys/deployprobe.g and /sys/retractprobe.g, respectively.
-
@JayJay said in G29 fails on Duet3 with toolboard:
And now further confusion with @dc42 stating that:
it makes sense to use M401 at the start of mesh probing or calibration, and M402 at the end.dc42 said that with
Whereas when using other types of probe that need to be deployedit is documented in those that need it e.g
https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe#Section_Touch_Mi -
@Veti said in G29 fails on Duet3 with toolboard:
@JayJay said in G29 fails on Duet3 with toolboard:
And now further confusion with @dc42 stating that:
it makes sense to use M401 at the start of mesh probing or calibration, and M402 at the end.dc42 said that with
Whereas when using other types of probe that need to be deployedit is documented in those that need it e.g
https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe#Section_Touch_MiYes But the OP is operating a BL-Touch NOT something else, therfore it would be reasonable to assume that the OP wouldnt be following a guide for something else, and the OP wrote that he had used M401/M402 hence my reason for mentioning it.
And as @dc42 has stated above you shouldnt explicitly use M401/M402 with a BL touch and the fact that the BL touch documentation doesnt mention using M401/M402 it would be resonable to assume that the as the OP was using them might be having an effect on what is happening to the OP's machine.
And bringing other non relevant documentation into the mix can only lead to further confusion.
Anyway back to trying to help the OP's overcome his issue.
I had a spurious issue with my toolboard acting up which was cured by making sure the firmware between board and toolboard matched. I ended up having to manually tell everything to update using the M997 command for the mainboard and M997 B switch to update the toolboard. that cured my issues.
if that doesnt work then we need to see full copies of the following files
config.g
homeall.g
bed.g
deployprobe.g
retractprobe.g -
@JayJay Just for the sake of clarity.
M280 commands are servo control commands. The BLTouch uses a servo to deploy and retract the pin. For the BLTouch you put the M280 commands in deployprobe.g and retractprobe.g
M401 and M402 call the deploy and retract macros. That's all they do. When using a BLTouch (probe type P9) G30 will call M401 and M402 automatically.
In the days before the P9 probe type specifically for the BLTouch, you had to manually deploy and retract the probe before sending G30. Using the base M280 servo commands was common, however M401 and M402 were added so that the firmware could actually keep track of the state of the probe as being deployed or not.
So yes, using M401 and M402 in your homing files when using a BLTouch isn't needed anymore because probe type P9 takes care of deployment and retract automatically. But behind the scenes it's still just using M401 and M402, which is just calling deployprobe.g and retractprobe.g which just contains the M280 servo commands.
I hope that gives some historical context and explanation on why things are the way they are.
