[not yet solved] Tevo Little Monster DuetWifi errors
-
@giostark said in [help] Tevo Little Monster + DuetWiFi + DuetTouch7" errors:
Right now , I facing the issue that after the print is finished the head fall in the bed (glass!). After the home G28 in the ending script I have to put something that dont disable completely the motors ?
-
Make sure you don't have M18 or M84 in your end print GCode script in your slicer, or in file stop.g.
-
If necessary, increase the idle current by adding e.g. I60 (that's uppercase-letter-i followed by 60) to your M906 command in config.g. That tells the firmware to maintain 60% of normal motor current when the motors are idle. The default is 30%.
-
-
Print and install these, then you can disable all motors after printing
-
This is weird , I added G28 in the stop.g and cancel.g .
Before they were empty.
BUT still the head fall down at the speed light crashing on the bed. O_O
I changed the I30 to I60 but nothing seem even slow a little.
-
@giostark What do you have in your slicer end code?
-
@phaedrux
just this :
M104 S0 ; turn off temperature
G28 ; home -
If 60% is still too low for an idle hold current try leaving it at 100% so the motors stay powered.
-
@phaedrux
I noticed Matter Control (usb connected) send in the terminal when I stop the printer via "cancel" in MC panel those gcode : N5 M84*26.
Instead If I press the stop or emergency stop in WC (so no usb cable) , I see the popup of M112 and M999 and the head fly down.
I tried to print via file.gcode and there is no M84 inside.
And the only one way to stop the printer via WC is the stop emergency button. (there is not a cancel button)
When The printer is finished, after some second, the head crash in the bed. Of course is just matter of time before Ill break the glass. In the last print the head melted the plastic falling directly on the printed part
-
Does it crash down on to the bed immediately the print finishes, or 30 seconds later? If it's immediate then there must be a M18 or M84 or similar command at the end of the GCode file.
-
Was after 30s , so I found in the section drivers in config.g this "M84 S30 ; Set idle timeout" and I now excluded it. I have settled at 60% the motor, lets see if if enough
-
@giostark If you removed M84 S30, it will never drop to 60% idle current.
-
Have sense...ok ,
now I launched a print . It will take near 6h lets see what happen. -
Some progress...
1- I discovered that the problem of crash in the bed depend by MatterControl. It look like after the finished printing it send some Gcode independently by the printing data.
If I generate the file.gcode , now that I have commented the M84 , the head stay in home position like expected . So i have to discover where to put attention in MatterControl for resolve this.
EDIT-2 ! And here how to solve this ! https://github.com/MarlinFirmware/Marlin/issues/1485It suggest where to look: C:\Program Files (x86)\MatterControl\StaticData\SliceSettings\Properties.json
Look for this line:
"DefaultValue": "M104 S0 ; turn off temperature\nG28 X0 ; home X axis\nM84 ; disable motors"
And remove the M84 ! Or just put in front the ";".
For configure the delta printer LM there is not a pre-built profile so you must choose "other" so You have also to change the "Other.printer" profile in the folder C:\Program Files (x86)\MatterControl\StaticData\Profiles. Looking always for the M84 and remove or comment it.
The printer configurated come located here: C:\Users{user}\AppData\Local\MatterControl\Profiles\guest . So if you have already reconfigured the printer here you can change the M84 value.
in linux is here : ~/.local/share/MatterControl
Fine.2- Some printing issue:
I discovered that for small printing object base the glass is perfect , BUT for big object base I cant let the corners stay on the glass , ending to ruin the print.
So for big printing I used one thermal adhesive pad and hell the print stay down and the problem is to remove the printed part from it. Any way I'll see what to do.
Now suggestion about those print?
This is the 1st layer, and what you see is what is against the bed.
Here ,the lines are not lines !!! This is incredible...look ! seems like a patchwork !
I used the infill 100% and could be this the issue? In the preview of MatterControll those that are broken and discontinuous lines instead appear regular lines.
The motors need to be cooled? I settled the 1700mA of current because the motors need 1.7A so should be fine right? Or should I sett less of the target specification?
Here, always the first layer, look melted. I should use some fan percentage? I read ABS didnt like cooling (but I experienced that for small print it is necessary)
The last picture show How ugly the finish looks. In some places is perfect and in other is horrible.
-
That looks to me like a first layer that just isn't sticking very well.
The flow rate needs to be correct, and the first layer height needs to be accurate. That should give the right amount of flow and squish. If it's too close or extruding too much, the plastic can squish out and curl up.
Then temperature needs to be high enough that the plastic stays molten long enough to bond. This is why a high bed temp is needed for the first layer.
It also helps to print the first layer very slow.
How fast are you trying to print?
What layer height are you using?
What is your extrusion width?
-
@phaedrux said in [help] Tevo Little Monster + DuetWiFi + DuetTouch7" errors:
That looks to me like a first layer that just isn't sticking very well.
The flow rate needs to be correct, and the first layer height needs to be accurate. That should give the right amount of flow and squish. If it's too close or extruding too much, the plastic can squish out and curl up.
Then temperature needs to be high enough that the plastic stays molten long enough to bond. This is why a high bed temp is needed for the first layer.
It also helps to print the first layer very slow.
How fast are you trying to print?
What layer height are you using?
What is your extrusion width?
I settled 45mm/s and 30% for 1st layer and 100% width for 1st layer and perimeters. The fist 2 pictures where about the contact with bed , the last is the top face.
Can you tell me something about the fist picture? Especially in the center the lines are not lines. They seems interrupted and the filled again...it is really weird. -
@giostark said in [help] Tevo Little Monster + DuetWiFi + DuetTouch7" errors:
They seems interrupted and the filled again...it is really weird.
That's exactly what I was talking about. I think you are over extruding, and the plastic is getting pushed up and then smoothed back down when it comes back the other direction. That's why the lines look woven.
Your top layer looks like it's over extruded in some areas. Especially the left side. But then it looks like you're under extruding on the right side.
Have you calibrated your E steps?
13.5mm/s sounds ok for first layer speed.
I'm not familiar with MatterControl as a slicer, so I'm not sure how it behaves.
-
Yep , I have calibrate the E step , BUT is arriving the Bondetech BMG and I'll put on it the 0.9 motor , so I should gain some better extrusion.
Maybe is worthy to wait that I have installed it before losing time looking for a configuration that must be replaced.
Thanks you for your time and attention. I'll try to investigate your points and I'll write back.
-
Hi folks !
I'm facing this issue: the calibration report an absurd bed leveling. (see the picture)
I installed the new motor (changing the microstep to 160 in config.g) that look more accurate but after this the mesh bed compensation become more strange.
When I try to print large object one side of the printing is just few attached the other is strongly attached.
If I send the calibration before the print and with the M122 I can verify the mesh compensation is loaded but the result is as above described.
Im using the last firmware (but this is not relevant maybe)
Re-calibrate the Z-probe have not produced improvement. -
-
Some post above there is a calibration that look like very different
-
I presume you ran auto calibration before you generated that height map. Did you run auto calibration (G32) before generating the height map (G29)? Assuming that you did, what was the reported calibration deviation; and are you using the same bed.g file that you published in your earlier post in this thread dated 21 September?
