TAZ 6 Single Extruder V62 G29 V4 fails

I updated my TAZ 6 Single Extruder to V62 to test endstops. While the endstop tests were successful. A G28 followed by a G29 V4 failed. I loaded LulzBot’s Universal firmware 2.0.9.0.13, Selected the Single Extruder tool head, and verified that the printer hardware is functioning as expected.

V58 works, V59 fails. I assume that V60 and V61 will also fail.

At some point in the past, I had a development environment setup. With some help I’m willing to get it working again if that aids in troubleshooting.

Hi Brad,

I do not have a printer to test this, so I need as much details as possible. Can you be more specific as to how it fails, whether it prints a message either on the LCD or the serial port, and how what part of the probing it fails? It would be helpful if you could post a video demonstrating a close up of the behavior.

I suspect that the recent changes in Marlin changed the longstanding behavior of endstops. AFAIK, in the old Marlin, endstops behaved like this:

1 - If a max endstop was triggered, the stepper for that particular axis would stop stepping, but the printer would continue along other axis and proceed as normal.
2 - The value of the [XYZ]_MAX for the axis that was triggered would be loaded into the current position.

It would be useful to confirm this behavior in older firmware and determine exactly how the new firmware operates. LulzBot printers would often reach the MAX endstops during probing and for full compatibility with older LulzBot printers, we might need to persuade Marlin developers to emulate the old behavior as closely as possible.

For reference, here are the pull requests that have caused the issues:

  1. Connect to printer with OctoPi / OctoPrint
  2. Flash firmware, Marlin_Oliveoil_TAZ6_Tilapia_SingleExtruder_bugfix-2.1.x.1_d8ec9938fc_62.hex
  3. Send G28
  4. Send G29

Terminal output from the G28, G29:

[...]
Send: G28
[...]
Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
[...]
Recv: X:-19.00 Y:258.00 Z:16.00 E:0.00 Count X:-1900 Y:25800 Z:0
Recv: ok P13 B4
Send: M113 S2
Recv: ok P13 B4
[...]
Send: G29
[...]
Recv: X:-10.00 Y:-9.00 Z:2.00 E:0.00 Count X:-1000 Y:-900 Z:3197
Recv: //action:prompt_end
Recv: //action:prompt_begin G29 Retrying
Recv: //action:prompt_button Dismiss
Recv: //action:prompt_show
Recv: //action:probe_rewipe
[...]
Recv: X:-17.00 Y:25.00 Z:1.00 E:0.00 Count X:-1700 Y:2500 Z:1600
[...]
Recv: X:-10.00 Y:-9.00 Z:2.06 E:0.00 Count X:-1000 Y:-900 Z:3290
Recv: //action:prompt_end
Recv: //action:prompt_begin G29 Retrying
Recv: //action:prompt_button Dismiss
Recv: //action:prompt_show
Recv: //action:probe_rewipe
[...]
Recv: X:-17.00 Y:25.00 Z:1.00 E:0.00 Count X:-1700 Y:2500 Z:1600
[...]
Recv: X:-10.00 Y:-9.00 Z:2.05 E:0.00 Count X:-1000 Y:-900 Z:3280
Recv: //action:probe_failed
[...]
Recv: //action:cancel
Cancelling on request of the printer...
Recv: echo:Probing Failed
Recv: Error:Printer halted. kill() called!
Changing monitoring state from "Operational" to "Error"
Send: M112
Send: N2 M112*35
Send: N3 M104 T0 S0*34
Send: N4 M140 S0*97
Changing monitoring state from "Error" to "Offline after error"
Connection closed, closing down monitor

My first attempt at capturing a video failed, I’ll get to that later today or tonight. When the G29 is issued, the nozzle is positions over the left front (0,0) washer, lowers to touch the washer, and immediately moves up and then starts a wipe sequence. After the wipe, it moves over the washer and tries again. There are some messages on the LCD in addition to the output over the USB connection. I’ll try and capture a video of those as well.

I’ll also load V58 and video a successful sequence when I get my camera(s) sorted out.

Here is a link to the video file on Mediafire:
V62_G29

Here is a link to the video file on YouTube (in case the above doesn’t work):
V62_G29

The YouTube video is probably lower resolution. This file was edited from a 4K video which I have if you need better resolution.

I have a video on my phone of the LCD display. Let me know if you need it.

Here’s the terminal output from V58. I added the temperature command as the V62 firmware wanted the nozzle heated up. Video link below.

Send: M109 S160
[...]
Printer seems to support the busy protocol, will adjust timeouts and set busy interval accordingly
[...]
Recv: ok P15 B4
Send: M113 S2
Recv: ok P15 B4
[...]
Send: G28
[...]
Recv: X:-19.00 Y:258.00 Z:16.00 E:0.00 Count X:-1900 Y:25800 Z:0
Recv: ok P13 B4
[...]
Send: G29
[...]
Recv: Bilinear Leveling Grid:
Recv:       0      1
Recv:  0 +2.282 +2.201
Recv:  1 +2.043 +2.095
Recv: 
Recv: X:-10.00 Y:292.50 Z:5.95 E:0.00 Count X:-1000 Y:29250 Z:10848
Recv: //action:prompt_end
Recv: ok P15 B4

V58_G28_G29

I have Visual Studio with Auto Build Marlin installed along with a clone of Drunken-Octopus-Marlin on my system.

I’m not sure what to edit so that the Auto Build will select the TAZ 6 Single Extruder. Clicking the Configure button is less than satisfying :grin:. Also clicking the Build button fails to build the selected Mini firmware so I’ve probably got something else that needs to be setup.

I ran into the same thing with v61. I found that if you do G29 P1 it will probe all the points. A simple G29 no longer works. Marlin changes? Not sure.

Send: G29 V4 P1
Recv: Default storage slot 0 selected.
Recv: Mesh invalidated. Probing mesh.
Recv: Probing around (105.69,189.69).
Recv: 
Recv: Probing mesh point 1/25.
[...]
Recv: Bed X: 77.85 Y: 203.55 Z: 0.10
Recv: Probing mesh point 2/25.
[...]
Recv: Bed X: 77.85 Y: 140.70 Z: 0.03
Recv: Probing mesh point 3/25.
[...]
Recv: Bed X: 140.70 Y: 140.70 Z: 0.00
Recv: Probing mesh point 4/25.
[...]
Recv: Bed X: 140.70 Y: 203.55 Z: 0.07
Recv: Probing mesh point 5/25.

I should say, mine is using the BLtouch probe now.

My TAZ 6 has the Rambo controller it came with and does not have a BLTouch so I’m still using the four corner washers for bed leveling. Adding a P1 to the G29 (or G29 V4) makes no difference.

When BLTouch is enabled, I use UBL, which modifies G29 by quite a bit (see Bed Leveling (Unified) | Marlin Firmware)

Thank you for sharing that. Now that I see the video, I don’t think it is necessarily an issue with the changes to the endstop behavior. Something else might be happening, but I’m not sure exactly what. Does the nozzle push down on the washer or does it lift as soon as it touches it? If it is pushing it down, it may indicate it is unable to detect that it has touched the washers.

If this is the case, do you have a multimeter? Could you check whether there is a voltage present between the bed washer and the nozzle while it is probing? It should have a few volts of difference.

The other test you can do is run M119 and see if Z Probe is untriggered. Then use a wire or aligator clips to short the nozzle to the bed washers and rerun M119 and see if that changes.

It does not push the washer down, it lifts as soon as it touches.

I have verified that M119 sees Z Probe triggered when shorted with an alligator clip (and untriggered without). I did not test with a multimeter but I don’t think that is necessary since the M119 is working.

Okay, thanks for for checking this. This is quite puzzling. I do not know what might be causing it. Can you check whether any of the endstops are being triggered while this is happening?

I’m not sure how I would check. I can’t do M119 while the G29 is in progress. The Z endstops are definitely out of the picture and I would think that if the X or Y endstops were being triggered it would happen while the nozzle was being positioned over the first washer and not while Z was being lowered at that position.

Since V58 works and V59 does not, is there a way to get a comparison between these two versions?

Generally I just listen carefully for the endstop clicks.

Comparing V58 and V59 is easy, here, in fact, is the link on github that does just that.

The trouble is that over 729 files changed between those two releases!

The only way to narrow this down is for me to build and for you to test intermediate firmware between the known working firmware from March 19th to the not working firmware from April 20th. We may have to test several dozen builds.

If you are up for it, here is some firmware from the Marlin code as of April 6th:

https://github.com/drunken-octopus/drunken-octopus-marlin/releases/download/v2.1.x-rc59/TEST_Apr_6_2023_5b1f087c.zip

I’m happy to try as many builds as it takes…

Apr_6 works.

How easy is it for you to do a binary search, i.e. build one in the middle and we can see which half has the failure. Then build one in the middle of the failing half, etc.

If that’s hard to do, then I’m happy with the one day at a time approach.

I’m already started a binary search. April 6th was half way between March 19th and April 20th :slight_smile:

Here is April 13th:

https://github.com/drunken-octopus/drunken-octopus-marlin/releases/download/v2.1.x-rc59/TEST_Apr_13_c3921bbf.zip

Glad we are doing a binary search…

Apr_13 fails.

Here is April 10th:

https://github.com/drunken-octopus/drunken-octopus-marlin/releases/download/v2.1.x-rc59/TEST_Apr_10_182497fc.zip

The April 10th version is working correctly.