search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.21k stars 19.22k forks source link

M48 and UBL G29 UBL issue with Bugfix 1.1.x #13269

Closed VFRoderick closed 5 years ago

VFRoderick commented 5 years ago

Description

When conducting a G29 P1 my z-probe never reaches the bed in the corner region of (X=max bed size, Y=0) this occurs for 12 adjacent points in this region (box region of 3 points in X direction and 4 points in Y direction). What is occurring is the bed just continues to fall instead of rising up to reach the probe. I conducted a M48 X279 Y21 on one of these points and the issue was the same. My z-probe is a mechanical switch in which the nozzle itself is acts as the z-probe.

  1. Attempted latest 1.1Bugfix but causes my G28 Z to do nothing. Using 1.1Bugfix from 4 months ago.
  2. Followed UBL guide
  3. When noticing this issue occurring during G29 P1 I've pressed on XY-carriage which can actuate the probe, but this doesn't seem to have any effect on correcting the issue other than causing the probe to move onto the next point.
  4. Repeated this phenomenon in which the bad region stays relatively the same (sometimes grows or shrinks), and the amount of deviation may change.
  5. Conducted M48 in bad region and results are same.

Expected behavior: Bed should rise up to nozzle as it does for the good region.

Actual behavior: Nozzle never reaches bed. When this occurs after a successful point capture the bed just falls 5mm, but if the previous point capture was invalid it falls another 5mm or 10mm. This in return compounds the effect resulting in large deviations (40mm at some points).

Videos of Behavior: M48 issue - https://youtu.be/DI_Wpm_sLvg G29 P1 U T issue- https://youtu.be/zUEnEMFrVMI

final image of bed topology (G29 P1 U T command without heating bed or nozzle, and not conducting attempting Step 3 above):

image

Additional Information

I have the marlin leveling debugging feature defined in Marlin, but don't know how to utilize it in this case.

Configuration_adv.zip

boelle commented 5 years ago

and the problem is there also with latest bugfix 2.0?

VFRoderick commented 5 years ago

I haven't tried bugfix 2.0 as I just have an 8-bit Ramps board. I did attempt the latest 1.1bugfix but as noted earlier I wasn't able to get G28 Z to work so I went back with the previous working firmware for me.

AnHardt commented 5 years ago

This could be noise on the probe lines. A bit of default software denoising was removed between 1.1.8 and 1.1.9. If 1.1.8 is working for you try 1.1.9 or one of the bigfix branches with activated ENDSTOP_NOISE_FILTER. If that helps try to reduce the noise in hardware. Maybe you can reduce it enough to kick ENDSTOP_NOISE_FILTER out again.

boelle commented 5 years ago

Also 2.0 is both 8 bit and 32 bit

VFRoderick commented 5 years ago

Did not know 2.0 is 8bit and I will give it a try. I activated the END_NOISE_FILTER and gave it a test with the M48 in the same location but results were the same.

VFRoderick commented 5 years ago

Also, what I meant by previous version of firmware was 1.1BugFix but from 4 months ago.

VFRoderick commented 5 years ago

Just attempted 2.0 but get the same issue I have with trying the latest release of 1.1BugFix. Attached are my 2.0 config and config_adv files. Configuration_adv.zip

Roxy-3D commented 5 years ago

Are you using an inductive probe? If so... It seems the probe is 'seeing' stuff under the bed...

VFRoderick commented 5 years ago

Hello Roxy, I'm not but I think I found the reasoning behind my issue. I'm using a mechanical switch for the z-probe. What I've found is I've moved the gantry to the troubled area when it wasn't under power and tried to physically actuate the switch. Turns out it is much tougher to do this in this region. Which explains the trick I was applying a little in the videos. I guess my trick wasn't activating the switch but was deactivating it. Being a CoreXY printer I believe this issue resides in either unequal tension of the belts or not properly squared Y-axis rods.

What I've done is release the pressure on the mechanical switch (uses a lever arm with screw to adjust tension) so its giving good readings now, though my X-rods flex a little when probing.

I apologize for bringing this up as a bug issue when its entirely on me, but thank you all for your inputs and help.

Here is a new printout: image

Roxy-3D commented 5 years ago

I apologize for bringing this up as a bug issue when its entirely on me, but thank you all for your inputs and help.

Not a problem... I'm glad you have a direction to get things resolved!

github-actions[bot] commented 4 years ago

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.