Best posts made by Gamefanatic3D

This is not a problem, but more of a kudo's!
I had just recently purchased the Magnetic Filament sensor for one of my extruders and was working on calibration. I had a fairly long (12 hour) print going. During the print, the sensor kept telling me the extrusion amount was low. At first, I thought it was something I was doing. I kept checking the sensor and the machine. Finally, I ran a print where it wasn't extruding anything. It appears my extruder motor was going out slowly. Every time I looked it was working, but when I walked away it stopped.

I replaced the motor and everything was running smoothly again! So glad I purchased this, will be getting more in the future!

I just went ahead and updated to 3.0 (2020-01-03b3) and everything is working so far. Probably just a bug or bad update, because it was working before and after the 2.05.1 update.

@fcwilt

I am running v3.3, eagerly awaiting a stable 3.4 with the accelerometer.
I don't recall why I used M98, but I think it was due to an issue with calling G28 a few versions ago and never changed it back.

As I have been looking into this more, it may be related to a specific print file. I never had this problem before. However, a specific print had some GCode that specified the hot-end change temps for extruder 1 (T1) at the time of tool change. This was actually a problem as it was setting my "cooldown" temps to the active extruder, but it immediately set the working temp after. When it would pause and then I hit resume it would sometimes show the correct working temps, but other times not.
I manually went through the GCode to fix this problem rather than re-slicing and uploaded to the Duet. It ran through the entire print without a hitch. Once I get enough of the parts pushed out I will attempt to go back to the unmodified GCode and see if it actually had anything to do with the G10 codes occurring in succession or if the code was just messed up. OR look for Gremlins...

The GCode I removed throughout the file was as follows:

G10 P0 S210
G10 P0 S240

and

G10 P1 S210
G10 P1 S245

@fcwilt

Well that was a simple trick. I put a small calibration square on the bed to the right side and it quickly polled it. Definitely showing it on the correct side.

So not sure what direction to go from here. I know my probe is good, but the results of the mesh compensation isn't.

@fcwilt
I'm not sure if you saw my comment, but I have performed the procedure. I didn't drag the head across the bed, but rather my feeler gauge. The result was there was a gap at the end as I expected. Rather that was coming from the gantry or the bed height I could not tell you, but there was a variation in the height from when it started to when it finished.

I'm not sure if your goal in this was to prove there was variation in the bed or that mesh leveling had been turned off successfully. I know that my bed leveling measures at X180 Y200 and my typical measuring point is X200 Y200, and have tested the gap at both locations with and without the mesh compensation engaged. Each time I get the same result.

If it seems that I'm not providing you the feedback you are looking for, I may just be miss understanding the intended goal or I may not be describing it correctly?

@fcwilt
I think this issue is related to a failing Z-Axis motor. I heard a noise once when letting things sit idle earlier today which resulted in an obvious deviation in the Z-Level. I thought this might be due to the motors going idle and possibly the bed falling. Normally with power off, I don't get more than 0.08 of drift between the two lead screws.

However, I was printing just a moment ago and hit the pause button, but when I resumed I heard that noise again when the bed was lifting. So instead of continuing, I paused again and moved the X-Gantry to dead center between the lead screws and measured with my calipers from the top of the rails on either side with an approximately 2.3 mm deviation.

I'm really hoping this is the root cause. They are the original motors operating for over 4 years on my inexpensive starter kit!
I have to take a bit of it apart to get after them so that will have to wait until next weekend, time permitting!

@fcwilt

Going with where you are headed I did 3 heightmaps. All will use the same points and were done with the bed at 70°C.

Map1
Normal height map

 -0.050, -0.086,  0.053
  0.067,  0.007,  0.090
  0.251,  0.020, -0.019

Map2
Normal level with 0.8 feeler gauge put in after in the middle:

 -0.031, -0.124, -0.038
  0.061,  0.836, -0.013
  0.242, -0.035, -0.120

Map3
0.8 feeler gauge in place when G30 performed:

 -0.927, -0.969, -0.847
 -0.833, -0.004, -0.807
 -0.653, -0.874, -0.904

Now taking a look at just the difference between Map1 and Map2 we can see the obvious and expected difference at the middle point. I am a little plagued by the right values being nearly 0.1mm difference. I now wonder if this is my probe or my hardware.

When I run my Dial Guage out from the middle I get a negative value of ~ -0.14 after setting its Z-0 at my middle probing point. This is about what I expect based on my manual leveling.

https://youtu.be/GCf9Ta9aJSo

@fcwilt

Thank you for your help up until now. I'll continue to do some testing later this week to see if this is motor-related.

I got my Lead Screws from ZYLTech a few years ago. Never thought to look at McMaster. I suspect if there were variations I should see those in my layer lines, which I don't normally have an issue with since upgrading to these. However the anti-backlash nuts are brass and could have some play. I do my best to keep them greased.

I am thinking there may be some play in my Tool Carrier. I know that I can get flex up to 0.14mm when I put some pressure on it, but it does want to return back to 0. Today looking into this further I dove the tool into the bed and found it didn't want to return to its normal height. So I docked and undocked it and picked it up again, the tool height was back to normal. I'm suspecting that it's shifting in the kinematics and even though it's a ball bearing and has no scoring it's not able to return. This would not explain the BLTouch variation, but maybe a factor when it comes to printing.