@droftarts Thank you, I'll look into this. Might be the right solution. Alternatively I had planed to just setup a hardware thermistor, but it would be nice to just control things from the tool change macros. I had thought also going after the firmaware and changing the value, but seems like that might be more work overall.
I'll likely use the Duet3 for my larger format system in the future, but already have this one wired up. Yeah its more wires, but its working.
Posts made by Gamefanatic3D
-
RE: More than 12 fans
-
RE: More than 12 fans
@stuartofmt I am not familiar with what you are referring? Do you have a link?
-
More than 12 fans
I'm on a Duet2/Duex5 and plan to have 4-5 tools on my system, but wanting to use 3 fans per tool (tool fan, part tool and a cooler for the extruder). I probably don't have enough ports to connect them all up to be controlled, but even if I could I can't define more than 12 (0-11). Is it possible to have more on a Duet3 platform possibly with tool boards?
-
RE: Magnetic Filament Monitor noDataReceived
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
-
Magnetic Filament Monitor noDataReceived
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.
-
RE: Mesh compensation results backwards
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.
-
RE: Mesh compensation results backwards
@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 screwsM350 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?
-
RE: Mesh compensation results backwards
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.
-
RE: Mesh compensation results backwards
@fcwilt said in Mesh compensation results backwards:
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. -
RE: Mesh compensation results backwards
@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.
-
RE: Mesh compensation results backwards
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
-
RE: Where use bed compensation
@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.
-
RE: Mesh compensation results backwards
@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. -
RE: Mesh compensation results backwards
@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! -
RE: Mesh compensation results backwards
I use this macro when just probing a single point on the bed during the previous tests:
Bed_Height_Test
G1 Z5 F6000 G30 S-1 G1 Z5 F6000 echo (sensors.probes[0].lastStopHeight - sensors.probes[0].triggerHeight)
-
RE: Mesh compensation results backwards
@fcwilt said in Mesh compensation results backwards:
@gamefanatic3d said in Mesh compensation results backwards:
My goal is to verify that the Z probe Z Trigger Height setting is correct and that the Z Offset settings of the tools are correct.So I repeated the steps above which are essentially how I get my G10 settings so that I can ensure I've performed as you noted.
Step 1 - Pre environment:
- Bed Temp: 70
- T0 Temp: 230°C
- T1 Temp: 230°C
- Click Home All in WebGUI
- Click Disable Mesh Compensation in WebGUI
Step 2 - Probe Height:
- G1 X168.25 Y234.4 Z6
- G30 S-1
Result:
8/22/2021, 12:47:32 PM M98 P"0:/macros/Homing/Bed/Bed_Height_Test" Stopped at height 0.871 mm -0.029
Step 3 - T0 Height:
- Click Tool-0 in WebGUI
- G1 X200 Y200 Z6
- Using PanelDue move Z-5 (Z=1.0)
- Using Z-0.05 movements, after 3 adjustments I'm at Z0.85, and the feeler gauge is now just barely getting a tap when I wiggle it under the tip.
- Using PanelDue Z+5
Step 4 - T1 Height:
- Click Tool-1 in WebGUI
- G1 X200 Y200 Z6
- Using PanelDue move Z-5 (Z=1.0)
- Using Z-0.05 movements, after 3 adjustments I'm at Z0.85, and the feeler gauge is now just barely getting a tap when I wiggle it under the tip.
- Using PanelDue Z+5
- Click Tool-1 in WebGUI to dock.
Blow on fingers and look for ice and a band-aide...
-
RE: Mesh compensation results backwards
@fcwilt said in Mesh compensation results backwards:
What happens if you do this:
- disable mesh compensation
- set the Z=0 datum at a XY point on the bed where the height map suggests it is quite flat
- move tool 0 to that XY point
- move tool 0 to Z=0
- does the nozzle is just touch the bed?
- move tool 1 to that XY point
- move tool 1 to Z=0
- does the nozzle is just touch the bed?
So to respond to this request:
I used an area near the edge of the bed to ensure the feeler gauge isn't being supported by another higher area. My probe is offset from my Nozzles: X= 31.75, Y= -34.4
So when I move to a location I want to test both the probe and the nozzle at the same location I use the above to offset the Duets coordinates for the probe. There is no offset for the Nozzle as those are set by the associated G10 commands and will move to the spot shown by the Duet.
I perform a homing of Z. The process disables mesh compensation, performs the homing, and when done enables mesh compensation.
Step-1 - Prepare Environment
- Heat Bed: 70°C
- T0: 230°C
- T1: 230°C
Step 2 - Probe Height:
- Disable mesh compensation using Duet WebGUI
- G1 X338.25 Y54.4 Z6
- G30 S-1
Result:
8/22/2021, 12:15:34 PM M98 P"0:/macros/Homing/Bed/Bed_Height_Test" Stopped at height 0.949 mm 0.049
Step 3 - T0 Height
- T0 (Selected from GUI)
- G1 X370 Y20 Z6
- Using PanelDue Z-5 to achieve Z1.0 height.
- Using Z-0.05 movements after 4 adjustments I'm at Z0.8 and the feeler gauge is now just barely getting a tap when I wiggle it under the tip.
- Using PanelDue Z+5
Step 4 - T1 Height
- T1 (Selected from GUI, system knows to put the T0 back and grab T1)
- G1 X370 Y20 Z6 (Entered it again, but is redundant at this point as my Tools will automatically move to the last point on the bed.)
- Using PanelDue Z-5 to achieve Z1.0 height.
- Using Z-0.05 movements after 5 adjustments I'm at Z0.75 and the feeler gauge is now just barely getting a tap when I wiggle it under the tip.
- Using PanelDue Z+5
It's probably worth noting that my Probe Trigger height is 0.9. So the result noted in Step 2 was the difference from the point measured and my trigger height thus 0.049.
-
RE: Mesh compensation results backwards
@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?
-
RE: Mesh compensation results backwards
@fcwilt
I ran a similar test to what you were asking, I think.I turned off mesh compensation and measured at my typical 0 (X200, Y200) location with a feeler gauge (0.8mm) and then moved to a spot that was lower and found that I needed to move the head down. The results were very different from what was recorded either by my manual mesh macro attempts or the systems.
I believe the deviation the probe is finding is accurate, but for some reason is not being applied properly when the tool is engaged and thus having a larger than a normal gap. Not sure about this quite yet.
-
RE: Mesh compensation results backwards
I hadn't been taking pictures of the results but set up a simple single-lined box to test a run of making the first layer and not waste too much filament.
Calibration-Bed-Level-Single-Extrusion-Boxes.stl
With one of the heightmaps that were generated by the system. You will notice is the image below a lot of areas where the single extrusion lines are missing. This is a result of not getting close enough from what I can tell and as I watched it extrude it would just gather on the nozzle in most cases. Even better, when it actually got something to stick, the slicer thought it best to go back over that line, and low and behold the nozzle would scoop it back up again due to it not barely touching. Here is the result of one such test:
Even after running through my own macro to get the deviations in the bed, I had problems. Now I'm in the process of doing the following:
- Warm the bed and Nozzle to operating temps (Bed: 70°C, Nozzle: 230°C).
- Run G28
- Disable mesh compensation
- Using a feeler gauge manually measure the height of T0 to the bed at my typical 0 location (X200 Y200).
- Move the nozzle to the point on the bed that would normally be measured by the probe and lower it until it just barely touches my feeler gauge.
- Write down the difference in the coordinate on my custom heightmap (feeler gauge is 0.8mm) <feeler gauge height> - <Duet reported Z> = <heightmap value>
Maybe I should have done a smaller height map, but I didn't. It was 3 am and wasn't thinking clearly. I got through the first 3 furthest most Y-Axis rows. I uploaded my slightly modified map and enabled mesh compensation and measured both tools to the feeler gauge at both X200 Y200 and at least one of the points on the map and got approximately a 0 gap. So the method appears to be working, but have a ways to go.
In this image, you can see the right side (bottom of the picture) has a greatly improved first layer. This was using the heightmap I generated using my macro as the basis.
Going forward I need to find my Z-probe tool to make this an easier task and less burning of skin!