Marlin 1.1 config for TAZ6?

mrvanes,

The reason LIN_ADVANCE is disabled is that our R&D department tested it a while back and found it produced subpar results. This was before I came on board, so I do not know the details or reasoning behind that. It is also possible that it has been improved since then.

It’s possibly something that I could consider re-enabling if it is giving good results now. I do not know much about LIN_ADVANCE or what is it is used for. Is there a particular test print where it does particularly well?

– Marcio

Probe structuraly fails at second washer, i.e. it touches the washer but disregards the probe and starts wipe, returns to second washer, touches it (correctly) and bails out.

mrvanes,

What GCODE are you using to probe? In order to reduce EMI and allow us to pass FCC emissions tests, our FW grounds the probe lines and only activates them during a G28, G29 and M119. In order for the probe to succeed, the nozzle needs to be grounded (as it is in the standard toolhead) and you must use one of the GCODEs that I have listed. G30 currently would not work (perhaps I should fix that, just in case someone wants to use that).

– Marcio

The nozzle is clean. I have no problems probing the second washer with 1.1.0.11. Also, I can see it detects the washer, because the nozzle is not bending the bed down before it fails. It clearly fails on “succes”.

I mean M206 Z-1. I need this, because the e3d nozzle is 1mm longer than original nozzle, so Z_MAX_POS is 158 instead of 159 without the need for recompiling.
1.1.0.11 shows this when I do a M501, 1.1.4.37 doesn’t. That doesn’t mean it’s not used, I just can’t check it with M501 anymore.

Ordinary G29.
This is my start GCODE:

G26							; clear potential 'probe fail' condition
G21							; metric values
G90							; absolute positioning
M82							; set extruder to absolute mode
M107						; start with the fan off
G92 E0						; set extruder position to 0
M140 S[bed_temperature]			; get bed heating up
M204 T300					; set travel accel for homing
G28							; home all
M109 R170					; set to cleaning temp and wait
G1 Z150 E-30 F75				; suck up XXmm of filament
G28 X0 Y0						; home x and y
M204 T300					; set travel accel for probing
G29							; Probe



I do not know much about LIN_ADVANCE or what is it is used for. Is there a particular test print where it does particularly well?

I have never printed anything using LIN_ADVANCE (obviously, because it wasn’t supported in the firmware) it’s just one of the hiped features in recent Marlin releases that everybody speaks about: http://marlinfw.org/docs/features/lin_advance.html

Is there an easier way to download from this site? I’m only able to do it one file at a time.

Use a 25x25x2 test cube to print and use a k value of 0 and then a k value of 60 and then a k value of 120 as a rough comparison, here’s more info about the feature: http://marlinfw.org/docs/features/lin_advance.html

tl;dr
It’s basically a pressure relief feature that also adjusts acceleration at sharp corners.to provide straighter edges, more consistent and smooth infill, with less retraction, etc. The default value should really be 0 as each type of filament requires a different k value and if you’re using multiple processes with variable layer heights, widths, and/or extrusion multipliers than you K value won’t work properly and should be disabled by being set to 0.

I gave you the “browse” link, here’s the overview with git clone links:
https://code.alephobjects.com/diffusion/MARLIN/repository/devel/

Here’s the detailed output of a G29 V4, failing on LULZBOT_ABL_PROBE_PT_2

Send: G29 V4
Recv: G29 Auto Bed Leveling
Recv: Bed X: 0.000 Y: -6.000 Z: -3.371
Recv: Rewiping
Recv: PROBE FAIL CLEAN NOZZLE
Recv: Error:Printer stopped due to errors. Fix the error and use M999 to restart. (Temperature is reset. Set it after restarting)
Recv: Bed X: 164.000 Y: -6.000 Z: 0.000
Recv: ok

The Z: 0.000 seems suspicious to say the least.
I assure the probe is a clean, no bed push probe.

update: Aha!

#define LULZBOT_BED_PROBE_MIN   -3
#define LULZBOT_BED_PROBE_FAIL  -2

So, the -2 limit is a bit too conservative or my Mini is extremely out of spec. Which is weird, because my nozzle sticks out 1 full extra millimeter compared to the original? Also, the -3.371 seems to belong to PROBE_PT_1 which didn’t fail but is out of limits nonetheless?

update2: WHAAT!!?

#define LULZBOT_NO_WORKSPACE_OFFSETS

This trickles down to M206 completely disabled? Why!?

If I managed to compile the firmware using Arduino, would I have to flash Marlin.ino.mega.hex or Marlin.ino.with_bootloader.mega.hex?

Update3: Went the build-lulzbot-firmware.sh route but had to modify Marlin/Makefile to accomodate for new gcc-avr (4.9.2) behaviour regarding linking of eeprom functions. After some reading up on this forum post it turned out I needed to supply -l$(MCU) to LD_SUFFIX:

LD_SUFFIX=-lm -lgcc -lc -lgcc -l$(MCU)

update4: Setting

#define LULZBOT_BED_PROBE_FAIL -3

Combined with a G92 Z158 after G28 solves my problem. I used to be able to imply this by setting M206 Z-1 in eeprom and although commenting out LULZBOT_NO_WORKSPACE_OFFSETS does recover M206 functionality, it makes G29 fail at second probe again, even with LULZBOT_BED_PROBE_FAIL -3.

update5: After changing the “G1 X5 Y15 Z10 F5000 ; get out the way” standard start-gcode line to

G1 X15 Y15 Z10 F5000          ; get out the way

I was able to get a reliable probe sequence (the X5 caused an X trigger that interfered with Z from that point forwards). And after that a successful first print! Now, let’s restore M206 again and then try LIN_ADVANCE :slight_smile:

How I solved M206 and fixed failing probes
After meticulous measuring and probing it turns out that my nozzle is at Z:161, even with the E3D replacement nozzle sticking out 1mm lower than the original? Which made the Z error (with original M206 Z-1) a total of 3mm! So, either my Mini is completely out of spec, or the LULZBOT_STANDARD_Z_MAX_POS 159 is way off to start with? This 3mm offset explains why the probe failed with M206 Z-1.

Using M206 Z2 fixes the probe, but leaves the internal z-position 2mm too high (0=-2) after probe and applying z-probe-offset. I’m glad I didn’t try a print using that firmware!!

It turns out run_z_probe() needs correction for home-offset, not only when DELTA is enabled, but also when HAS_HOME_OFFSET is true:

diff --git a/Marlin/Marlin_main.cpp b/Marlin/Marlin_main.cpp
index a58bb33c..38a66618 100644
--- a/Marlin/Marlin_main.cpp
+++ b/Marlin/Marlin_main.cpp
@@ -2264,7 +2264,7 @@ static void clean_up_after_endstop_or_probe_move() {
       float z = LOGICAL_Z_POSITION(Z_CLEARANCE_BETWEEN_PROBES);
       if (zprobe_zoffset < 0) z -= zprobe_zoffset;
 
-      #if ENABLED(DELTA)
+      #if HAS_HOME_OFFSET || ENABLED(DELTA)
         z -= home_offset[Z_AXIS]; // Account for delta height adjustment
       #endif
 
@@ -2292,7 +2292,7 @@ static void clean_up_after_endstop_or_probe_move() {
       }
     #endif
     return RAW_CURRENT_POSITION(Z) + zprobe_zoffset
-      #if ENABLED(DELTA)
+      #if HAS_HOME_OFFSET || ENABLED(DELTA)
         + home_offset[Z_AXIS] // Account for delta height adjustment
       #endif
     ;

After this fix and applying M206 Z2, G28 correctly(?) sets my nozzle at z:161, G29 probes correctly within the original LULZBOT_BED_PROBE_FAIL -2 limit and now prints it’s first LIN_ADVANCE (k=0) test print.

update: This doesn’t make G29 fail when I hold a paper between nozzle and washer, although Z was -2.430 for all 3 probes? Back to the drawing board.

update2: The above problem comes from do_probe_move(), translating LULZBOT_BED_PROBE_MIN (-3) to -1 because z is transformed via LOGICAL_Z_POSITION, which is nonsense because z is already corrected for home_offset by virtue of M206 or G92?
So, when replacing the do_blocking_move_to_z line with

do_blocking_move_to_z(z, MMM_TO_MMS(fr_mm_m));

And setting the lower limits of LULZBOT_PROBE_Z_WITH_REWIPE to

#define LULZBOT_BED_PROBE_MIN   -2 // Limit on pushing into the bed
#define LULZBOT_BED_PROBE_FAIL  -1 // At what point is a failure detected

Which should be plenty of headroom for a carefully calibrated Mini. G29 now succesfully probes on a clean nozzle and fails on no contact, but only budges the bed 2mm, which is more than enough in my humble opinion.

The reason for this is that the WORKSPACE_OFFSET feature modifies the behavior of “G92”. Try this. Manually move the nozzle to the top of one of the bed washers and type “G92 Z1”. What this would do in past firmwares is set the Z position to 1 so that now the bed itself was roughly at 0. However, in Marlin 1.1.4 with WORKSPACE_OFFSETS, if you do this, the G92 will adjust the travel limits so that the nozzle will move no lower than Z=1 and will no longer reach the bed. This change was causing problems with the start GCODE for a toolhead we are developing, so I had to enable NO_WORKSPACE_OFFSETS in order to allow G92 to behave as before. M206 no longer working was collateral damage.

See my post to the Marlin team: https://github.com/MarlinFirmware/Marlin/issues/7323

– Marcio

You’re right, and as I’m stuborn I tried to mimick the behaviour with the new enabled M206 in my version, but that exhibits exactly the same behaviour. This is really a shame, because on stock fw, I’d now had to modify any start gcode I’d be using (G92) and have to redo it after every Cura update.

So, what’s AO’s stance on maintaining custom patches on Marlin_main.cpp? I could look into “fixing” endstop behaviour with WORKSPACE_OFFSETS?

My problem is not restoring old G92 behaviour and I don’t have a problem with HAS_POSITION_SHIFT in my configuration.
I do think M206 is a better (more userfriendly) way to compensate for different extruder dimensions because it’s storable in EEPROM and thus behaves independant from default start gcode. That means I wouldn’t have to restore G92 custom(ized) start gcode everytime the start gcode is overwritten (e.g. when new Cura update is installed).

That’s why I’m so vocal about M206 restoration, for the sake of future firmware updates.

I’ve made the fix I described above standard in FW 1.1.5.3 which will be released shortly. Workspace offsets are now enabled again, but G92 retains the old behavior in Marlin 1.0. So you will not need to re-compile firmware to adjust your printer height using G92.

There are other reasons to upgrade to 1.1.5.3. I restored the MIN_TEMP error when the toolhead is disconnected and also enabled the internal controller fan so the electronics do not overheat. If you are using “devel” firmware, I strongly advise you to upgrade to 1.1.5.3 for these fixes.

You may consider bringing this up in the Marlin forums. I do not think M206 is intended for the purpose you are using it for, so I do not think the Marlin developers would be willing to restore the old behavior, but perhaps they could add an additional LCD and EEPROM setting for adjusting the Z_MAX, if you bring it up as a suggestion.

Until that happens, all I can suggest to you is to use G92 in your start GCODE to compensate for the offset, or for you to compile custom firmware with LULZBOT_TOOLHEAD_Z_MAX_ADJ adjusted for your custom print head. The source code is provided so that you can make such modifications.

– Marcio

Hmm… in my experience M206 perfectly fits the Z_MAX adjust purpose? It consistently adds an offset to Z after it was homed using G28, automatically from EEPROM. I’m stumped!?

But, you’re right, your latest fw 1.1.5.3, without my patches from this post leaves Z exactly home_offset too close to the bed after probing because it doesn’t take the M206/home_offset into account while probing. With M206 Z2, G1 Z2 exactly touches the bed, G1 Z0 would probably crash the PEI sheet (which it will, because it isn’t soft endstopped!)

So, for those who used M206 like me, this version is quite dangerous!

But the good news is, so much has changed since 1.1.4 that the only change to make M206 work like I expect in 1.1.5 is this:

diff --git a/Marlin/Marlin_main.cpp b/Marlin/Marlin_main.cpp
index 1fcd8a661..02f490108 100644
--- a/Marlin/Marlin_main.cpp
+++ b/Marlin/Marlin_main.cpp
@@ -2352,7 +2352,7 @@ static void clean_up_after_endstop_or_probe_move() {
     #endif
 
     return RAW_CURRENT_POSITION(Z) + zprobe_zoffset
-      #if ENABLED(DELTA)
+      #if HAS_HOME_OFFSET || ENABLED(DELTA)
         + home_offset[Z_AXIS] // Account for delta height adjustment
       #endif
     ;

Which makes perfect sense, because DELTA isn’t the only setting that can adjust home_offset[Z_AXIS]

I just tried firmware version 1.1.5.3

After flashing the firmware I entered the factory calibrated figures.
Esteps/mm: 0846.0
zoffset : -1.361
Then save settings in eeprom of printer (love the new audio feedback)

Is the bed end stop treated as a probe point now?
My taz6 only probed 3 points:
build plate endstop–>wipe–>front left–>front right–>rear right–>**not rear left–>heat up nozzle position.

Model was positioned in the rear right of build plate. Print head moved to print position but crashes into the build plate b4 it reaches correct start position. I quickly shut power off.

I know I saved the zoffset because I heard the new audio beep confirming your saved settings to epprom. Which I didn’t notice in old firmware.

I’m trying new firmware because I’d hoped the firmware executed filament change procedure is better then old firmware but I didnt get that far.

Yes, that is the new probe sequence. I was surprised to see it too, but looking at the code it’s “by design”. And it’s enough to describe a plane anyway.

http://marlinfw.org/docs/gcode/M206.html

I now finally understand why M206 isn’t doing what I expected: it offsets the coordinate space as a whole, that’s why G1 Z2 was bed level after M206 Z2!

Ok, will rethink my sins and the future use of M206 now.

Yes. We switched to a three point probe. What brought about the change is that Marlin 1.1.4 probed the corners in a different order and this was causing the head to run all over the place. It was quite ugly. The three point probe gave control over the order of the points, so it looked better and was considerable faster, which everyone seemed to really appreciate. There was quite a bit of discussion about whether a 4 point probe was better than a 3 point probe, by virtue of having one extra point of measurement, but ultimately we concluded that since 3 points perfectly describe a plane, if a forth point disagreed with the three previous points, a fifth point would be needed to break the tie. A fourth point alone simply would not add additional meaningful information. Our experimentation confirmed that prints looked just as good, so we went with it.

So that’s the long story. We now do a 3 point probe – and it’s way faster :slight_smile:

– Marcio

Could you try “Restore failsafe” from the menu? Then adjust your Z-Offsteps and E-Steps and save.

I’m curious whether that makes a difference with the issue you encountered.

– Marcio

Ok I will try restoring failsafe 1st. But I noticed newer version firmware 1.1.53 -->> 1.1.54
Which to try?