For the lazy people and those (e.g. me) that weren't able to search well for it:
M376: Set bed compensation taper
Best posts made by Ted
-
RE: Gradually reduce grid compensation when printing
-
RE: Gradually reduce grid compensation when printing
That is a good point @Edgars-Batna!
That would also give us the possibility for another special usecase: Knowing the height oft the first few raft layers you could have the actual model printed without any distortion. Only the raft is used for compensation.
Latest posts made by Ted
-
RE: Weird outline that is not existing in GCode – Hardware problem?
@phaedrux @dc42
I uploaded the files here (an xyz cube, a *.3MF file for it from Cura 4.1.0 and the GCode, all for 40mm/s at lowest temperature possible with 0.2 mm layer height using a 0.3 mm nozzle).The prints all are made with line width of 0.3 mm (was recommended default setting from Cura for 0.3 mm nozzle).
The print is printed walls before infill (I was wrong at this!) and with inner walls first.I printed the same cube again at 5 mm/s (~1.5h to that level) and at 40 mm/s (< 10 min to that level) as it can be seen in the following image (click to see details).
That the problem is present the same at the picture independent to the print speed indicates that the low speed is not the problem here.- list item"External perimeters" first will cause bad overhangs (had that before), but I will definitely test it in the next run again.
- I can't go lower with print temperature as the nozzle will clog even at 1mm/s extrusion without part cooling fan on.
- The cooling was my initial idea. I've tried it with an air pressure gun from my painting compressor at first, blowing into a flexible tube fixed to my main part cooling fan. While it was fun testing, my wife wasn't impressed by the noise, the print wasn't either. No visible difference except increased stringing and an angry wife.
So far, thank you very much for your support!
-
RE: Weird outline that is not existing in GCode – Hardware problem?
I've found another problem that I want to solve first as it more pronounced, easier reproducible and might even have the same cause:
Looking at the following image (A standard XYZ test cube) the printer "lays its sausage" for the three perimeter walls counter-clock-wise around the already printed infill, starting at the most inner perimeter line and stopping at the most outer.
On the image I have drawn red and blue arrows for the movement. The red arrows indicate the problem area: Instead of doing a 90° corner the printer cuts the corner starting about 1 mm bevor it in a much smaller angle.
This was printed with PLA (same settings as above) at 20mm/s using Cura 4.1.0.
While it does look very small on the image, it is very noticeable and ugly holding the print in the hand. Every 90°-to-the-left corner does have a phase of 1 mm. Text printed on top of things is hardly readable.
Curious about it is also that when looking at previous prints made before switching to Duet Maestro and to Cura with the same setup no such round corners are visible. They all are crisp!At the moment I think this is some hardware configuration problem as the problem is invisible looking at the gcode:
I don't know what causes this. I have no clue. Hopefully you have one!
-
RE: Weird outline that is not existing in GCode – Hardware problem?
@phaedrux That's the post I found them in. Will try out your values as a starting point. Thanks! At the moment the printer is much slower than usual with the settings from the post. It looks so ridiculous! It looks drunk.
I am looking forward to your tuning guide – Great that you are doing this! -
RE: Weird outline that is not existing in GCode – Hardware problem?
@veti @dc42 I actually thought I bought semitecs. Oops! I will than try to replace the thermistors with semitecs (or others?) then and for the moment try to find somewhat suitable settings for my NTC 3950 100K until switched. Thanks for pointing out!
@dc42 You misread my post: I'm excluding missed steps as a cause for my problem because the print recovers on higher layers. I now rather think that wrong Acc/Jerk/Speed settings are the problem. And hope someone can recommend a good way/process to figure out what the best settings are.
-
RE: Weird outline that is not existing in GCode – Hardware problem?
@phaedrux Thx for the clearification! I will try to find more information about SC and typical SC settings. Right now it is hard to find beginner friendly information.
I switched to an 24V/320W PSU for my Cetus.@Veti Thanks for your help! I thought about an error increasing with temperature as well but had no clue about thermistors. Since you are supporting that conclusion I'm trying to find out what the correct values are. I'm not using the Cetus thermistors any more. I switched to those to have the same everywhere.
Right now I still can only find sources (only forum entries out in the internet) that point me to those values:
@ted said in Weird outline that is not existing in GCode – Hardware problem?:M305 P0 B4725 C7.06e-8 H30 L0 M305 P1 B4725 C7.06e-8 H30 L0
I think the error when setting the heater to 170°C is only about -10°C as when setting the temperature to 167°C it already starts to block the nozzle.
For the main problem I tried to figure out how max speed, acc and jerk will influence the print quality. I tried out very sluggish settings with XYZ-Cube that turned out much better for corner sharpness. It also introduces the same bad extrusion (suppose the problem is located there!) to the cube where it wasn't that much present before. I could think of just bad jerk, acc, max-speed settings for extruder that introduced that initial problem. At least I now know why my corners were that round.
M201 X200.00 Y200.00 Z100.00 E250.00 ; Set accelerations (mm/s^2) M566 X230.00 Y230.00 Z90.00 E120.00 ; Set maximum instantaneous speed changes (mm/min) M203 X28000.00 Y28000.00 Z15000.00 E10000.00 ; Set maximum speeds (mm/min)
I will need to find better settings – The printer now accelerates so slow that I always have to laugh watching it.
Can someone of you recommend any process to find those settings? -
RE: Weird outline that is not existing in GCode – Hardware problem?
@dc42 Thanks for your help! I thought about a wrong thermistor value as well, but for the bed where the same thermistor is used it is working perfectly. I could check with an optical thermometer, but only up to 60°C as my heatbed doesn't want to get higher. Are my thermistors defined right for that type?
M305 P0 B4725 C7.06e-8 H30 L0 M305 P1 B4725 C7.06e-8 H30 L0
Anyways, also wrong temperature shouldn't cause that movement failure. The most curious thing is that the print seems to recover on upper layers. That means that missing steps (hardware) cannot be the problem as the absolute positioning origin is the same for those layers.
Could it be that the steps are too big or so and more/less microsteps are needed?
Some thing that I set up wrong with the Trinamic drivers usingM569
command?
(I'm just pointing randomly on things that I don't feel that I completely understood. ) -
RE: Weird outline that is not existing in GCode – Hardware problem?
@phaedrux I set my speed to 50 mm/s in Cura. Either Cura resets the max speed itself or it just does feel that fast for me. It clearly moves faster than 20 mm/s when printing. With the Trinamic drivers I should not move very fast or I skip steps, I thought?
Anyway, having low speed should not result in my problem, should it?
-
RE: Weird outline that is not existing in GCode – Hardware problem?
@phaedrux Thanks for your help! Nope, inner layers first. Also tried with an "Extra infill perimeter" that aims to make the infill not influencing the skin. I also tried with better part cooling and lower temperatures (though 170 °C is already very low and there is clearly a movement problem). Thanks for your hint, though.
Are my microsteps, currents, max speed changes and acceleration values ok for a that setup? Really not sure about that.
-
Weird outline that is not existing in GCode – Hardware problem?
While being very happy with the switch to the Duet Maestro on my Cetus MK1 with E3D Titan Aero, I'm fighting with a very weird outline problem. Currently I'm not sure if this is a slicing problem or just a configuration problem (acceleration, speed, jerk, micro steps, whatever). Maybe you can shine some light on it.
It looks like this:
While it should look like this:
Any idea? Is this a slicer problem or a hardware / hardware configuration problem?
PLA printed at 170°C at around 50 mm/s using Cura 4.1.0 and 4.0.0. GCode file is too big for upload here. Hope this link works for a while: http://www.filedropper.com/rtkbody2
My config:
; --- SECTION: GENERAL PREFERENCES --- M555 P2 ; Set output to look like Marlin G21 ; Work in millimetres G90 ; Send absolute coordinates... M83 ; ...but relative extruder moves ; --- SECTION: Z-PROBE & MESH COMPENSATION (Z PROBE SECTION) --- M558 P9 H5 F100 T2000 ; Set up z probe to be blt2 G31 X44 Y30 Z1.55 P25 ; Set blt2 offset to nozzle (Z is "triggert height") M557 X0:170 Y0:170 S9 ; Set bed mesh grid M280 P64 S90 ; Pull in blt (not necessary but for safety) M280 P64 S160 ; Reset blt ; --- SECTION: DRIVES (MOVEMENT SECTION) & ENDSTOPS --- M667 S0 ; set corexy off M669 S0 ; cartesian M569 P0 V100 S1 M569 P1 V100 S0 M569 P2 V100 S0 M569 P3 V100 S1 M569 P4 V100 S1 M569 P5 V100 S0 M569 P6 V100 S0 M350 X16 Y16 Z16 E16:16 I1 M92 X80 Y80 Z80 E842.487 ; Steps per mm M906 X500 Y500 Z500 E1000 I60 ; Set motor currents (mA) and increase idle current to 60% M201 X1200 Y1200 Z1000 E1000 ; Accelerations (mm/s^2) M203 X1200 Y1200 Z1000 E1000 ; Maximum speeds (mm/min) M566 X1200 Y1200 Z1200 E1200 ; Maximum instant speed changes mm/minute ; Axis Limits M208 X0 Y0 Z0 S1 ; Set axis minima M208 X180 Y180 Z180 S0 ; Set axis maxima ; Endstops M574 X2 Y1 Z2 S1 ; Set active high endstops ; --- SECTION: HEATERS (HEATER & THERMISTOR SECTION) --- M302 P1 ; Allow Cold extrudes ; Thermistors M305 P0 B4725 C7.06e-8 H30 L0 M305 P1 B4725 C7.06e-8 H30 L0 M570 S180 ; allow it 180 seconds before giving a heating warning and test hotends wont be tuned. ; Tool definitions M563 P0 D0 H1 ; Define tool 0 G10 P0 S0 R0 ; Set tool 0 operating and standby temperatures ;M563 P1 D1 H2 ; Define tool 1 ;G10 P1 S0 R0 ; Set tool 1 operating and standby temperatures ; --- SECTION: FANS ( ) --- ; Disable Fan 1 thermostatic mode M106 P1 H-1 ; --- SECTION: TOOLS (TOOL DEFINITION SECTION) --- ; --- SECTION: NETWORKS (PROLOGUE & COMMUNCATIONS SECTION) --- ; Network M550 3D-Printer ; Set machine name M552 P192.168.118.19 S1 ; Enable network and set IP address M553 P255.255.255.0 ; Set netmask M554 P192.168.118.254 ; Set gateway M586 P0 S1 ; Enable HTTP ; --- SECTION: MISCELLANEOUS --- G4 S2 G92 X100 Y100 Z100 E100 G90 G28 ; Home all axes ;G29 ; Mesh probing ;G1 X0 Y0 Z200 S1 M280 P64 S90 ; Pull in blt (not necessary but for safety) M140 S60 ; Heatbed start heating to 60C
Thanks in advance for any hint!
-
RE: Z homing Gcode bloody for beginners
@aidar Thanks, that solves the problem for me!
@phaedrux I set the dive height to 50 mm. It gives me a lot of failure tolerance. It is working fine for me. So far no problems and much safer than just the 5 mm default. The mentioned error while probing (which I now avoid with a higher dive height) was due to mechanical tolerances in my extruder / laser mount.
It is working fine for single probes using
G30
. Wasn't aware that this would affect the dive height ofG29
, too. Haven't triedG29
in a while now as I still don't know if it resets z=0 when called AFTERG30
.
I got the problem that wheneverG29
afterG30
the printer prints with different z=0 heights. It is always a way too high and it is different every sequence! Trigger height of BLTouch probe is wonderful stable with < 0.01 mm tolerance, which is amazing! Also checked if I have missing steps and lowered max z speed to 1 mm/s. It's fine. Still looking for the error and still thinking about my question above: WhenG29
is not setting z=0 than this could cause the changing z=0 height. Need to investigate here.BTW: When having dive height at 50 mm and then
G30
down and get the probe triggered already after 1 mm it is not driving back 1 mm but driving back whole 50 mm. So it ends at 50 mm over the trigger point while started at 1 mm over the trigger point. Not sure if this is not a bug. When first setting the dive height to 180 mm (my build volume) I got the problem that it rises even over the endpoint switch. SinceG29
seems to use that dive height also it is not a good idea to do so anyway (unless I have too much time).