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.

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

I'm running 3.4 firmware and recently started having problems when changing tools. For the moment it appears when switching to a specific tool (T1) and it completes the TPost1.g the print pauses and I receive an error "Filament error on extruder 1: noDataReceived". When I resume the print all is fine, and monitoring continues.

As part of my Pause.g I have it report the data from the filament monitors and it never has an issue providing the data. I assume this means it's communicating with the MFM when it receives the error, showing it's communicating.

TPre1.g

; tpre1.g
; called before tool 1 is selected
;
; Check if we have another tool selected
; Is this even necessary with our tool detection script in play?

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Validate axes have been homed before picking up tool
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Home Y
if !move.axes[1].homed
  M98 P"/sys/homey.g"

; Home X
if !move.axes[0].homed
  M98 P"/sys/homex.g"

; Home Z
if !move.axes[2].homed
  M98 P"/sys/homez.g"

; Home C
if !move.axes[3].homed
  M98 P"/sys/homec.g"

G60 S0               ; Save this position as the reference point from which to later apply new tool offsets.


;;;;;;;;;;;;;;;;;;;;;
;; FILAMENT SENSOR ;;
;;;;;;;;;;;;;;;;;;;;;
; Dumb switch
;M591 D1 P2 c"e1_stop" S1			; Enable Extruder 1, Simple Sensor (High signal), Connected to E1 input
; Duet Magnetic Filament Monitor
; Duet3D rotating magnet sensor extruder drive 1 is connected to E1, enabled, sensitivity 24.8mm.rev, 70% to 130% tolerance, 3mm detection length 'agc' of 50 to 105
M591 D1 P3 c"e1_stop" S1 R10:190 L25.0 E3.0


;;;;;;;;;;;;;;;;;;;;;;
;;  Tool Variables  ;;
;;;;;;;;;;;;;;;;;;;;;;
; Set tool specific variables.
set global.currentTool_fan = 2


;;;;;;;;;;;;;;;;;;;;;;
;;    Load Tool     ;;
;;;;;;;;;;;;;;;;;;;;;;
; Turn on heater
if tools[1].active[0] > 0
  M568 P1 A2
elif tools[1].standby[0] > 0
  M568 P1 A1

; Set tool wiper height
G1 A56.4 F750         ; Typical V6 Tool height (just misses fan on brush)
; Save wiper height to file.
M28 "/sys/TriggerA.g"
G92 A56.4
M29

; Wait for set temperatures to be reached
M116 P1

if move.axes[2].machinePosition < abs(tools[1].offsets[2])
  G1 Z{(abs(tools[1].offsets[2])+5)}

; Load T1 Configuration
M98 P"/sys/tconfig1.g"

TConfig1.g

M207 P1 S0.50	; Retraction

;G10 P1 X-6.8 Y35.15 Z-1.85 A1.7           ; Set tool 0 axis offsets (-1.67)
G10 P1 X-6.8 Y35.05 Z-1.8 A1.65           ; Set tool 0 axis offsets (-1.8)

TPost1.g

; tpost1.g
; called after tool 1 has been selected
;
M703		; Load filament config

; Squeeze Filament Out
M98 P"/sys/prime.g"

; Pickup Tool
M98 P"/macros/Tools/T1-Pickup"


; Perform any wipe commands if nozzle is above extrusion temps.
if sensors.analog[2].lastReading > heat.coldExtrudeTemperature
;  M98 P"/macros/Tools/Tool-Wipe" ; Wipe nozzle

; restore print cooling fan speed
;M106 P2 R2
M106 P2 S{state.restorePoints[2].fanPwm}

G0 R2 X0 Y0 F6000
G1 R2 Z0                     ; Restore prior Z position before tool change was initiated.
                             ; Note: tool tip position is automatically saved to slot 2 upon the start of a tool change.
                             ; Restore Z first so we don't crash the tool on retraction.
G1 E{tools[{state.currentTool}].retraction.length} ; Prime Nozzle.

@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.

@fcwilt
So I'm not exactly sure how to move a single step, but mechanically this is how I am setup:
Dual 1.8° steppers w/ TR8*2 lead screws

M350 X16 Y16 Z16 E16:16 I1                ; Configure microstepping with interpolation
M92 X201.2499 Y201.2499 Z1601.584008 C100 E421.1332199:690    ; T8x2 1-Start Lead Screw

When I perform a single rotation of the Z motor my Dial Gauge reads 2mm at bed center, which is expected. It reads the same when moved to the lead screws and moved one full rotation.

Maybe I need to perform some tests for repeatability?

@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 said in Mesh compensation results backwards:

@gamefanatic3d

In your MyMeshCompStep1 file you have

if var.probezOne - var.probezTwo <= 0.005

Ignoring any floating point errors:

if var.probezOne = 1.006 and var.probeTwo = 1.000 then var.probezOne - var.probezTwo = 0.006 and the test fails.

if var.probezOne = 1.000 and var.probeTwo = 1.006 then var.probezOne - var.probezTwo = -0.006 and the test succeeds.

In both cases the difference is 0.006.

I don't understand what you are testing for.

---

Also the number returned by G30 S-1 does not have a fixed relationship to the probe Z Trigger Height setting.

Thanks.

Frederick

I'm attempting to get a height value from the BLTouch that represents the difference from Z-0 which I am interpreting to be in direct relation to when I run my G30.
In this case, I'm interested in the return values so I can better understand what is happening and see the variations. I'm not so sure how much it matters on the macro as it's not what's actually coming up with the heightmap values, I'm just using it to test my theory and why I can manually set my values in the heightmap vs using the BLTouch and the G29.

@phaedrux said in Mesh compensation results backwards:

@gamefanatic3d said in Mesh compensation results backwards:
Have you tried a homez.g without the conditional gcode?

I started off without the conditional code and only added it due to a recommendation by @fcwilt.

@gamefanatic3d

Okay I'm back and after much testing over the past week, I'm convinced there is nothing wrong with my Z-Motors, even though the issue I experienced was real. I believe the Duet may have just been having a moment as I was getting a homing error with negative values when performed the first homez.g after startup. Any future homing would be successful. This appears to have cleared itself up as easily as it came with me doing nothing to the system other than turning it off and back on a few times...

Moving back to the issue at hand here I have mounted a Dial Indicator tool to my system and validated my original statement that the Z-Probing being done and recorded is in fact opposite of what I would expect.

Note: I made the mount for the Dial Indicator such that I could probe with the BLTouch while having the Dial Indicator tool attached. I realize there is a tension that is created as the Dial Indicator gets closer to the end of its measuring.

Probing at a point with the BLTouch will return a positive value to the homing file when it should in fact be a negative value.

My BLTouch trigger value is 0.9.

I validated this by performing the following procedure:

Step 1: Setup

• G28
• Disable Mesh Compensation
• Attach Dial Indicator tool. (Manual process for now)
• G1 X180 Y227 Z6 (Move the BLTouch to a center point on bed)
• G30
• G1 X206.8 Y143.4 Z15 (Move Dial Indicator to same point on the bed with specific height/trigger point)
• Set the Dial Indicator to 0.000

Now I go to a spot on the bed shown on the heightmap that I know to be a low spot (further away from tools)

Step 2: Probing Low

• G1 X328.23 Y224.37 Z6
• M98 P"/macros/Homing/Bed/MyMeshCompStep1"
• G1 X355.03 Y140.77 Z15

The result of BLTouch

8/28/2021, 2:37:40 PM	G1 X355.03 Y140.77 Z15
8/28/2021, 2:37:29 PM	Stopped at height 0.987 mm
-0.085
8/28/2021, 2:37:28 PM	M98 P"/macros/Homing/Bed/MyMeshCompStep1"
Stopped at height 0.983 mm
8/28/2021, 2:36:46 PM	G1 X328.23 Y224.37 Z6
8/28/2021, 2:36:14 PM	G1 X206.8 Y143.4 Z15
8/28/2021, 2:36:03 PM	G30

Dial Indicator: -0.08

I repeat this procedure 3 times in the same spot to validate any potential mechanical issues. Keeping in mind the dial indicator is not as accurate as of the BLTouch and validate the numbers are still roughly the same.

The heightmap.g in this area is showing a positive value in this area. I believe this is due to the BLTouch returning a positive number when subtracting the two probing values which are greater than my trigger (Z-0) value.
IE)
Probe1 returns: 0.918
Probe2 returns: 0.923
The resulting value would be acceptable as it's within 0.005
The value returned should be:

-0.0205 = 0.9 - ((0.918+0.923)/2)

But what is recorded in the heightmap is 0.0205

This is my assumption of what is happening based on the heightmaps I am obtaining. I could be missing something here still...

MyMeshCompStep1

var probezHeight = 6
var TravelSpeed = 6000

var probezOne = 0
var probezTwo = 0

	while true
		if iterations = 5
			abort "Too many auto calibration attempts"

		G1 Z{var.probezHeight} F{var.TravelSpeed}
		G30 S-1
		set var.probezOne = sensors.probes[0].lastStopHeight
		G1 Z{var.probezHeight} F{var.TravelSpeed}
		G1 Z{var.probezHeight} F{var.TravelSpeed}
		G30 S-1
		set var.probezTwo = sensors.probes[0].lastStopHeight
		G1 Z{var.probezHeight} F{var.TravelSpeed}
		if var.probezOne - var.probezTwo <= 0.005
			echo sensors.probes[0].triggerHeight-((var.probezOne + var.probezTwo)/2)
			break

@peirof
Main thing is to not load your heightmap.csv it until you have set your Z-Height (G30).

Where from there is up to you.

I recommend applying in the homez.g as one of the very last steps.

I am not a fan of putting anything in the slicers personally as I use to many and all have their own quirks.

When validating your tool height be sure you disable mesh compensation.

@fcwilt said in Mesh compensation results backwards:

@gamefanatic3d said in Mesh compensation results backwards:

G1 X168.25 Y234.4 Z6

Where does those X and Y values come from?

That is technically where the Probe - probes when I do my startup. The X/Y noted in the G1 command are where 0 would be at the time, in my case, it's the front of my tool plate (not including the shaft).
The offset of my probe from that location is X31.75 Y-34.4.
When I perform a G1 X200 Y200 the probe is actually probing at X168.25 Y234.4.