BUGS! in latest RCBugFix code - important!

[playlet]

Hi!

I'm talking about the latest RCBugFix branch version available to download. Reprap discount full graphic smart controller.

1. When not printing but the nozzle is preheated, Prepare menu is blank. Only the first item ("go back to previous menu") is visible. Menu scrolls (visible on the first line) but nothing is accessible. - big problem. - fixed

2. Manual mesh bed leveling - impossible to do rendering all probeless printers useless on the latest version. Major problem for people who don't have a probe. - can't tell if it's fixed or not, I don't use MBL anymore.

3. While printing, if you change steps/mm for extruder, value is stored but the menu doesn't close. It flashes once like it wants to exit and then goes back to editing steps/mm screen. After timeout, screen goes to normal again.

4. This might not be a bug, I don't know. As time passes, after every print, I need to keep lowering the nozzle with babystepping or it would print first layer in air after a few hours. Like Z offset gets reduced somehow (bilinear bed leveling) with each print.

5. Bilinear bed leveling is higher on one side (for me, back Y) and lower on the opposite side (front Y). Higher side prints circular line (not low enough) and lower side is pressed really hard into the glass, almost to the point that it makes tiny blobs because it is too low above the glass and the flow is blocked. - This can be avoided by disabling ENABLE_LEVELING_FADE_HEIGHT option for auto bed leveling. It's still not perfect but good enough.

6. When adjusting something like Z offset (Motion menu) - value tends to avoid numbers such as: -0.30, -0.40, -0.50 and so on. It always skips even tens, example: skips from -0.29 to -0.31.

7. Vertical lines on printed parts. I tried lowering jerk values and acceleration values and it helps but not all the way. If I try to print the same file on previous RC7 release with higher jerk and accel values, there are no vertical lines on the part. - my bad. Current code uses full jerk value to start moving the axes. Just reduce your old value to half (me: 15 to 7) and you're good to go.

[l-leukert]

Hi, can confirm No.1 in RCBugFix.
Prepare -> Preheat -> Prepare : only first Line 'Main' visible
(Works in RC branch)

[FHeilmann]

I second No1 as well.

[ghost]

About #1...

I found that you can get the prepare menu back if you set the nozzle to 0 degs from the control menu/temperature.

This issue has nothing to do with the bed temp.
But, set the hotend to 1deg and poof, there goes the prepare menu.
Still looking for the issue...

Rotating the encoder while in the prepare menu will show some options but only on the first line. Even with that, the 'Move Axis menu is the only one that works. The Level Bed option... Clicking the encoder does nothing.

[ghost]

I have found that if this line (1406) in ultralcd.cpp:
HOTEND_LOOP() if (thermalManager.target_temperature[e]) { has_heat = true; break; }
is commented out, the prepare menu works just fine while the hotend has a set point higher than 0.

So.... I changed it up a bit. Now, it works like it should:

    //
    // Cooldown
    //
    bool has_heat = false;
    HOTEND_LOOP() if (thermalManager.target_temperature[e]) {
      has_heat = true;
      MENU_ITEM(function, MSG_COOLDOWN, lcd_cooldown);
    }
    else {
      #if HAS_TEMP_BED
        if (thermalManager.target_temperature_bed) has_heat = true;
      #endif
      if (has_heat) MENU_ITEM(function, MSG_COOLDOWN, lcd_cooldown);
    }

[ghost]

I had an unapproved fix for 2, if I understand that right.. (#5634)
I don't know about 3.
I don't have that issue with 4.
I don't have that issue with 5.

[playlet]

Thanks for the no. 1 fix, I can use my printer without pronterface again. Thank you, sir!!! :)

[ghost]

I put in a PR. (#5632)

[manianac]

Nothing against @Tannoo, but I didn't like the PR fix. All that was needed was removing the break statement or having it on multi-hotends only. See #5647

[manianac]

Finally got around to checking out the MBL bug, and confirmed its a recursion loop, between idle(), lcd_update(), and wait_for_homing(). #5634 by @Tannoo fixes this, although I would remove the no_reentrance line

[buzzkc]

I can confirm number 5 also, having same exact issue.

[lordjg]

I also confirm number 5. In my case the lower corner is the front left and the higher is the front right

[playlet]

I have noticed some more bugs that I'm also adding to the list in the first post.

6. When adjusting Motion - Z offset - value tends to avoid numbers such as: -0.30, -0, 40, -0,50 and so on. It always skips even number, example: skips from -0.29 to -0.31

7. Vertical lines on printed parts. I tried lowering jerk values and acceleration values and it helps but not all the way. If I try to print the same file on RC7 with higher jerk and accel values, there are no vertical lines on the part.

[playlet]

Is anyone working on the problems number 4 & 5 from the first post?

It's annoying that you have to mess with babystepping to lower the nozzle after every print, while the next is just starting. It just gets higher and higher above the print bed after every print if you don't touch anything.

Also, number 5 is pretty bad with large objects. It almost always results in a warped piece.

Please fix this. It worked great in RC7. I'd go back to RC7 but I really like linear advance these days. :)

[Roxy-3D]

Thinkyhead will be back very soon, and I suspect he will take care of this very quickly.

[playlet]

Ok, thanks for the info :)

[FATALHERMIT]

@playlet for problem number 4, try disabling leveling fade height in configuration.h , since this feature was implemented to gradually reduce leveling correction until the movement is level to the machine's X and Y plane

[dragonnn]

Is number 2 fixed? I tried Manual Bed Leveling on RCBugFix and it doesn't work, on RC8 it works fine.

[ghost]

#5634 is the "fix" I'm using for MBL until @thinkyhead gets in a proper fix.

[dragonnn]

Thanks, will try it today.

[thinkyhead]

Number 7 is interesting. We have new jerk code (from the Prusa MK2 branch), but I'm not sure if this is the main cause. @playlet — Could you post some pictures of the vertical lines so we can see what features are producing them the most?

[thinkyhead]

@playlet for problem number 4, try disabling leveling fade height in configuration.h , since this feature was implemented to gradually reduce leveling correction until the movement is level to the machine's X and Y plane

Does this help? The feature should have no effect unless Marlin gets the M420 Znn command, which sets the fade height.

[playlet]

Number 7 problem - you can disregard this. I didn't see that new code makes steppers start faster than before. I reduced my jerk value to half (15 to 7) and now it't fine. All good! :) Linear advance does the rest and all works great (k=43 for me on MK8 with 32 uStep).

As for the fade height thing, I will test this in the next few days when I get my hands on the printer again.

Thanks for taking the time to look into this.

[playlet]

Left to right and forward to back leveling seems a lot better now although not entirely consistent.

There's a bigger problem here that troubles me, and that is number 4 - after each print z axis is higher and higher above the bed. And when I leave a printer off for an hour or so and start printing again, now it is too low (scratching the bed) and then gets higher and higher again.

There is not even 1 print in a row that can be done without messing with z babystepping.

[Roxy-3D]

There's a bigger problem here that troubles me, and that is number 4 - after each print z axis is higher and higher above the bed. And when I leave a printer off for an hour or so and start printing again, now it is too low (scratching the bed) and then gets higher and higher again.

Pretty much, every print does a G28 and the position gets reset with a G28. If each print goes higher and higher above the bed, there are very limited number of things that could do that. It might make sense to make a special debug version of the code that prints out all of the constant type parameters and see which one is changing. For example, print out these types of things (if they are compiled into the code):

• pre_home_z
• bilinear_z_offset
• mbl.z_offset
• zprobe_zoffset

Something is changing... If we knew what was changing it probably would not be that hard to figure out the root cause.

[playlet]

I'm willing to test everything if someone makes the changes :)

[playlet]

I've been testing the repeatability in relation to the probe speed (z homing speed) and bed heating and have discovered a strange thing.

If the bed is cold, repeatability is in the range of 0.003-0.009. Also, if probed faster (slow speed/2), it gives less error (than let's say slow_speed/5)!

If the bed is heated, repeatability is in the range of 0.080-0.135. That is almost a whole 1 layer height. The funny thing here is that when the probe is measuring and the heater is on, error increases in relation to when it's off (in the on/off heat the bed loop).

So, I guess there might be no problem with marlin but with the probe sensing power through the bed and throwing the leveling grid off. This is really annoying. I use capacitive LJC18A3-B-Z/BX NPN NO probe, mk2b bed and 3mm regular glass over it.

Is there a way I can make probes more accurate?

[Blue-Marlin]

Could be a problem with VCC for the probe.
When the heaters are on the voltage could drop significant when the power supply is too weak.
A different temperature of the probe could be an other reason, but usually is not.

[Roxy-3D]

It sounds like you need to power the probe off of a clean source. You might be able to put a LM7805 on the +12 volts used to power the bed. And that might be able to give you a constant +5v even if the +12 v is pulsing due to the bed load.

[lrpirlet]

@playlet.. Well, I am surprised that someone tries to tram with a capacitive probe while heating the bed...

Physic tells me that heat is a good way of MODIFYING the capacitance (the dielectric becomes less insulating at higher temperature). By heating the bed you heat the air and that CHANGES the permittivity (note, beside heat, the humidity, the atmospheric pressure and maybe some other environment factor will have a direct incidence on the repeatability)... this is why I, PERSONALLY, do NOT believe that a capacitive probe is better than a good old switch taken from a broken mouse :-)

So, as you have observed, make sure to probe a bed at a very stable temperature (I would strongly suggest to probe at ambient temperature...)

[Blue-Marlin]

LJC18A3-B-Z/BX NPN NO usually needs at least 6V.
The idea with an extra regulator is not bad, but use a higher voltage type.

[playlet]

@Blue-Marlin Might be VCC, I'll test this too. I connected the probe to the rightmost connector on the ramps 1.4 12V input.

@Roxy-3D I can't use 5V as the probe is not accurate enough on such low voltage.

@lrpirlet Cold bed is not good for probing, in my opinion, as the bed warps slightly when fully heated. That's why I went with the method described below. :)

My workaround for hassle free printing is this:

In marlin, setup 4*60 z speed and 9000 probe speed, homing and probe slow_speed/2 for both. This topic (#5868) claims to have better probing accuracy on faster speed and I have confirmed that!

Procedure:

preheat the bed (me: abs 98°C, with annyer extra strong blue hair spray - part sticks even too much!),
turn off bed heating,
g28,
g29,
preheat bed again,
print.

This makes repeatability results in the range of 0.015 which is good enough in my book. Fast probe and homing speed is important here because bed looses heat fast. Results are very good indeed.

Thanks for your help

[playlet]

I just tested the probe voltage. It is 12.16V when bed is off and 12.07V when bed is heating. Is this too much for a 30A 12V LED power supply or did I connect the probe to a wrong connector (rightmost 12V power input on ramps 1.4)?

@Roxy-3D I love your double click the encoder to enter babystepping shortcut :)

[Blue-Marlin]

0.09 V difference seems to be ok.

[playlet]

More debugging done today. Today I reverted back to RC7 and tested the z offset problem. I calibrated z offset, made it perfect and started printing the cube over and over again with probe measuring at the same time bed is being heated!!

I take back what I sad about marlin not being a culprit here - IT IS! Something is wrong with rcbugfix code what makes z offset reduce after each print leaving the nozzle in next higher and higher above the bed.
RC7 does this perfectly without any problem. You can print 100 cubes one after another and z offset would always be perfect. I can't stay on RC7 as linear advance makes my prints perfect every time on latest marlin.

Current Marlin has a bug somewhere. Pleeeeeeease fix this. For a month now, I've been waiting for this to be fixed but noone is looking into it, looks like. I see less important stuff being fixed weekly and this crucial feature is not. Please fix this... :)

[Roxy-3D]

@Roxy-3D I love your double click the encoder to enter babystepping shortcut :)

Yes! I agree it is a very nice feature. And only 15 lines of code.

[playlet]

I'm so happy that this is now included in standard rcbugfix :)

@Roxy-3D Would you mind moving this option higher in the configuration_adv. This is a very useful feature and it's at the bottom of the file where people don't usually look, if they update as often as rcbugfix does :)

[ghost]

I think there should be a list options available in the configuration files that are available in the given files.
Simular to the G, M, and T codes listed in marlin_main.cpp.

[ghost]

I might compile that list and submit a PR.

[playlet]

Reporting back some observations.

Bed leveling works fine if printing inside probed area. If outside, it's not that good.
How does marlin's code determine z offset outside of probed area?

Thanks :)

[playlet]

I'm still experiencing number 4 in the latest version (tested on August 2nd). After every print, in the beginning of the next, I need to lower the nozzle about 0.125 mm more. If I reset power and then print again, no need to do that. Please look into this. Ramps 1.4 board on prusa i3 diy clone.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.