Posts made by okercho

@dc42 said in Mesh bed Levelling with BLTouch. Am I doing something wrong?:

@okercho said in Mesh bed Levelling with BLTouch. Am I doing something wrong?:

I'm thinking about doing the difference between left/right quite obvious on purpose, to see if it actually works or not, as I think mesh is applied even if you're not printing but moving the head around...

You height map is actually very flat, so it will be difficult to see the Z axis moving due to bed compensation being active.

It's not uncommon for the height map not to match what you see when printing, which may be the case here. This happens when you use a Z probe with a large offset from the nozzle, and the print head doesn't stay in exactly the same plane as it moves over the bed. For example, some printers have an X carriage that moves on 2 smooth rods. If there is a slight twist between those rods, then the print head will rotate slightly about the X axis as it moves in X. If the Z probe is offset from the nozzle in the Y direction, that will cause the relative heights of the nozzle and the Z probe to change.

Actually that makes a lot of sense... I'm using 8mm rods for a 300mm bed, and I was thinking that maybe is just not sturdy enough...

I'm gonna see how can I replace the 8mm rods by 10mm... wish me luck!

I'll report back.

Cheers

@PaulHew I posted before :), yes, it says "mesh" in use


I'm thinking about doing the difference between left/right quite obvious on purpose, to see if it actually works or not, as I think mesh is applied even if you're not printing but moving the head around...

Regards

@mwolter said in Mesh bed Levelling with BLTouch. Am I doing something wrong?:

An easy way to check if the mesh is applied is to watch the z steppers for the first layer. They should move slightly if mesh compensation is enabled.

I did... I can see the left side still more squashed and I cannot see the motor moving (I've put a bit of tape and I´ve been observing it, and I think it didn't move at all...)

@mwolter said in Mesh bed Levelling with BLTouch. Am I doing something wrong?:

One possible issue is that you are doing g32 and g29 before the printer is up to temp. Recommend moving the g32 after the nozzle and bed heating commands.

Most likely your printer and bed dimensions are slightly changing due to probing before everything up to temp. Try to probe as close as possible to printing so things don’t change from where the printer thinks thing are to where they actually are now.

I'm not always using the heated bed. When I do, I put the bed on, wait for it, and then home Z and perform the G29, as I´ve noticed, as you said, that bed expands (and as I've several "layers", it needs more time to reach the temp on top).
Regarding the nozzle temp, as I'm using a BLTouch, the nozzle temperature is not "important", I just have it into account for the G31 command.

The problem is that, checking the raft, it doesn't seems to be applying the compensation... even though as per the heightmap, the printer is aware of it :S.

Regards

@gloomyandy said in Mesh bed Levelling with BLTouch. Am I doing something wrong?:

Is there a reason why your probe points for the lead-screws do not share the same Y values? One is 165 the other 160.

Also looking at the two meshes that you provided there is something odd going off. The first (lower resolution) mesh shows part of the bed to be "above zero" with the rest below, the second (higher resolution) mesh shows pretty much all of the mesh "below zero". That does not seem correct to me.

Regarding the different Y, the printer is a CoreXY with 2 lead-screws. When I checked for the Y position for the G32, I discovered that the motors were not perfectly aligned, and that's reflected in the bed file.

About the image, the bed is magnetic, is an aluminum heated bed, with a glass on top that has the magnets on it (Buildtak) and the steel sheet on top. I'm assuming that even though I put the sheet always the same way, the measurements changes. I'm doing always a G32 and a G29 after removing and installing the sheet, and if I repeat the G29 (without removing the sheet), results are consistent.

Regards

@OwenD said in Mesh bed Levelling with BLTouch. Am I doing something wrong?:

M290 R0 S0 ; clear baby stepping M561 ; clear any bed transform

I've changed my bed.g for this and report back, although as I'm using G32 right after starting the printer, I don't think this will apply

M290 R0 S0 ; clear baby stepping
M561 ; clear any bed transform

;G28 X ; home X
;G28 Y ; home Y
G28 Z ; home Z
G1 X5
G30 P0 X25 Y165 Z-99999 ; probe near a leadscrew, half way along Y axis
G30 P1 X290 Y160 Z-99999 S2 ; probe near a leadscrew and calibrate 2 motors
G28 Z ; home Z
G29 ; Mesh Bed Levelling

Regards

Hi all,

At least I'm not the only one so... we're all doing something weird

This is my start code, is based on the Prusa one (I'm using PrusaSlicer)

G90 ; use absolute coordinates
M83 ; extruder relative mode
;G32 ; Bed Level
{if first_layer_bed_temperature[0] > 0}
M140 S[first_layer_bed_temperature] ; set bed temp
M190 S[first_layer_bed_temperature] ; wait for bed temp
{endif}
G29 S1; mesh bed leveling
M104 S[first_layer_temperature] ; set extruder temp
M109 S[first_layer_temperature] ; wait for extruder temp
G1 X40 Y100 F5000
G1 Y0 Z0.6 F3000.0 ; go outside print area
G92 E0.0
G1 Z0.2 X30.0 E9.0 F1000.0 ; intro line
G1 X100.0 E12.5 F1000.0 ; intro line
G92 E0.0
M221 S{if layer_height<0.075}100{else}95{endif}

Regards

Hi,

Thanks, I'll try to make it more simple so I can debug it, although checking the compensation and calibration in the GUI, it seems that mesh is being used (I'm executing G29 S1 in my gcode):

Regarding the homeAll, I'm not using it... Im doing the homing "manually" (First homing X, then Y, and then Z, one by one), after that, I do the G32 and G29, and then if everything was successful, I launch the print... I got used to do it in that way when I was using a non-very-reliable probe some time ago...

Regards

I've tried with a 10x10 mesh, and yes, I'm probing the correct zone... and the results are the same, filament is less squashed in the right side of the bed

Regards

Hi all,

I've been trying to diagnose this for a long time, without success, and is creating a lot of frustration, because at this point I'm not sure if is a mechanical issue, configuration issue or any other thing.

I'm using a BLTouch (original, as per the QR code) in a 300x300 CoreXY (Hypercube Evolution+some mods), and I've also tried PINDA and DC42 IR as Probes, with same results. I'm executing a G32 and a G29 before each print, and for the G29, I've also tried with up to 42 points, and the print result is always inconsistent. When I try to print, it is clear that some parts of the first layer are not at the same heigh... For example, in this picture, the left side skirt is clearly more squashed than in the right side:

If I check the level map, the board is aware about that the left side is a bit higher than the right (slightly, but there is a difference). It doesn´t matter the amount of points that I use, and if I repeat G29, the results are consistent:

Note: First point left (same as Z Home) is 0.003, second row highest point is 0.025

I've two Z motors (left and right) and this is the config and Z config that I'm using: https://github.com/aimartin/duet3DConfig/tree/master/Hypercube

Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-RC10 (2020-04-25b3)
Duet WiFi Server Version: 1.23

In my Gcode I've a G29 S1, and I always manually execute G32 and G29 before each print....

Am I doing something wrong?

Thanks

My first print with the new firmware came out perfectly fine, but the heater was in "standby status" at 205ºC (the temperature of my print), so it didn't turn out when it finished...

My ending gcode is "G10 P0 R-273.15 S-273.15" (same as if I use "Turn Everything Off"), but it doesn't do the job. However, If I use "G10 P0 R0 S0" the status is still Active or Standby but the temp actually goes to 0 as the desired temp...

Regards

Hi, I just installed the RC2 and from the interface I'm not able to shutdown the heater, it turned on automatically (at 0ºC for active and standby temp) and if I try to "control all, turn everything off" or to switch from active to standby (from the interface) it does nothing, but I can switch from active from standby in the paneldue though.

In the console I see this "G10 P0 R-273.15 S-273.15", but nothing changes.

I think nothing changed at heater config level between 1.21 and this RC, right? (at least, I didn't see it...)

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 2.0(RTOS)RC2 (2018-05-10b1)
WiFi Server Version: 1.21
Web Interface Version: 1.21.1-RC4

Anyone else sees the same?

Regards

I've installed RC5 and printed a couple of things without any issues. Update from RC4 was OK without requiring rename of the file.

Regards

@Phaedrux:

@carlosspr:

Additionally I have some settings on Slic3r for Start-Gcode based on filament type. For example for PETG I am setting the PID parameters tuned for my PETG printing temprature and have tuned the Pressure advance to 0.3. This is my Start Gcode for PETG filament type:

That's interesting, do you notice much better temperature stability by using temp specific PID tuning?

I've kind of just targeted the middle temp range I print at and stuck there. I had done tunings at different temps in the past, but never thought to have them be filament specific like that. Good idea.

If you use the "Filaments" feature in DWC, you can just change some params (PID, retraction…) when loading the filament, although those params are just executed during load and unload, and not after a reboot :m...

Cheers

I thought the same when I watched the video XD

Installed.

Firmware Electronics: Duet WiFi 1.02 or later
Firmware Version: 1.21RC4 (2018-03-11 build 1)
WiFi Server Version: 1.21RC4(08b3)
Web Interface Version: 1.21-RC4

I can confirm that uploading "Duet2CombinedFirmware.bin" file on top of a RC3 works perfect (I didn't rename the file and the update was successful), the X/Y homing are cancelled if I try to move Z before homing it ("Error: G0/G1: insufficient axes homed" message) unless S2 is used in G1, and the G30 executed a double tap for Z homing.

I will keep using this RC and report back any issue.

Regards

@dc42:

I have changed the code so that G30 by itself can do multi tap. Only G30 S-1 and S-2 now do single tap on!y.

Great!! When is expected the next beta?

Voted!

I've updated the wifi server in my home printer from my office and it never came back, so I'm assuming the issue with my AP is still there. I can restart it (it's connected to a wifi plug) but I won't so I can check the error message in the PanelDue, but I assume is the usual "incorrect password" message.

Regards

@dc42:

Please can those of you running 1.21RC4 on a Duet WiFi try upgrading DuetWiFiServer to 1.21RC4. I need feedback on this version asap because a deadline is approaching.

I've updated the wifi server in my home printer from my office and it never came back, so I'm assuming the issue with my AP is still there. I can restart it (it's connected to a wifi plug) but I won't so I can check the error message in the PanelDue, but I assume is the usual "incorrect password" message.

Regards