Posts made by Shoggoth43

@Shoggoth43 It's been a while but I seem to have resolved the problem.

First I releveled the bed and have gotten it to within .2mm across the plate so that has improved. This really didn't do anything to resolve the main problem but it is at least an improvement. I may work on that a bit more as it should be easy enough to improve, but this was done mainly to see if I could find a workaround in case I couldn't get the mesh compensation working.

Due to having to manually add/remove the probe I would manually create a bedmesh and save it. Given how warped the bed was and the bed compensation issue, it was taking way too long to try and do a full mesh with each print. Whenever I rebooted the printer I would reload the mesh with a macro that did a G29 S1 and a M376 H5 to set a height taper. I would confirm the bedmesh compensation was in use with M122.

I had glued small bits of filament on top of the Z screws to confirm that any X or Y movement using the PanelDue or other gcode commands did, in fact, use the compensation when the bedmesh was enabled using the macro. However, it would not compensate most of the time when running a job. Sometimes it would work, but most of the time the nozzle would just end up too far from the bed in places and fail, or I would have to babystep it so close it would tend to auger into the bed surface or the extruder would just skip/clog/jam instead. The bed is currently now flat enough that a .2 mm 1st layer height probably won't gouge into the bed but I will need to work on that a bit more.

The apparent fix may be one of those dumb "everyone knows this" bits but adding the G29 S1 command to the actual slicer start gcode seems to have resolved the issue. I still haven't found anything in the documentation to indicate that this should be required given that the M122 command shows that bedmesh compensation is in use, but it seems to have fixed the issue for the moment. I tried several slicers while troubleshooting but it may not be in the start code of all of them so that could have been part of the problem in tracking this down.

I still need to reset my Z offset after a nozzle change and I seem to have some under extrusion issues, but the bed compensation issue now appears to working reliably.

@shoggoth43

Hopefully this uploads them properly.

bed.g config.g

@günter-jibben I will try to post the information requested and double check your suggestions within a day or two. Work has been fairly long hours recently so I definitely can't get much done tonight.

I need some assistance on first layer printing. I have a bedmesh created and it appears to be in use. I can see it moving the Z axis slightly as the X axis travels back and forth. However the nozzle will still happily plow right into the bed as it moves along leading to permanent marks on the bed. Using a feeler gauge I can see that the distance across the bed does not seem to be consistent so it feels like the bedmesh is not being fully applied. On the left side it ends up too high to stick properly but at least prints cleanly, at least until it unsticks, but on the right side it's definitely far too low. The darker lines are where the nozzle plowed into the bed at full heat causing damage to the bed surface.

The bed is as curved as a potato chip but it's what I currently have available. It worked fine on the original prusa rambo board so it should be usable. At some point I will likely do the silicone tubing mod on the bed to try and get it a little flatter.

Mesh compensation appears to be in use.

"DMs created 83, segments created 11, maxWait 1668880ms, bed compensation in use: mesh, comp offset 0.000"

The fade height it 10mm so that should not really be a factor on the 1st layer.

The extruder extrusion is reasonably accurate with the 100mm test, just a touch of underextrusion.

I have tried creating the heightmap both cold and with the bed heated to 60C for a few minutes. It doesn't seem to make a difference in behavior. I'm using a Euclid probe that is manually added and removed as needed. The plan is to create a servo controlled dock to automate this but I need to be able to get the prints working first in order to do that.

Any ideas on what could be causing this and how I can fix it?

Any help is much appreciated.

S

heightmap.csv

@droftarts That seems to have sorted it. I would have sworn it worked before but I don't see how the wires would have changed...

Thank you all for the assistance.

@shoggoth43 Pics as requested.

@phaedrux Will try to get the wiring photos this weekend. This was only ever connected to the mini 5+. It was initially just hooked up outside the box and then was placed into the printer controller box and wired up.

@Phaedrux I have uploaded the 3.4 firmware to the PanelDue and upgraded to 3.41 on the Duet. The PanelDue was running 1.25 and the Duet had 3.40 so all the firmware should now be current release.

@dc42 I connected to the USB on the Duet, I tried connecting via 9600 baud and 57600 baud. I don't see any responses to screen. I tried sending homing commands and manually typed in a G1 X10 command using the console on the PanelDue. No response.

I don't see anything that could be shorting out anywhere. All the crimps appear solid. Not seeing any loose wiring. Anything else I can check?

@phaedrux I will try to double check later this weekend. Unfortunately I have quite a few late workdays coming up.

Not sure if my PanelDue is broken. It used to work before I moved the Duet 5 mini into a new machine, but now it just says "connecting".

I didn't move the port it was connected to, IO_0, and I have the "M575 P1 B57600 S1" line in my config.g file. I've gone and tested the same cable I was using before with a multimeter with no issues. I also confirmed it's using the 57600 Baud rate in the settings on the PanelDue itself.

I have not updated any firmware since I moved it on either the Duet 5 mini, or the paneldue.

Is there anything else I can check on this?