Print speed, hot end air flow direction, unstopped bed heating

Hi,

new user of a 3D printer, I've been discovering my Ormerod for two weeks and got interesting results, but also some issues.

Environment : Linux
Firmware : 0.65e
Slic3r : 1.0.1, with the basic configuration found in the Ormerod-master directory from Github.

Print speed : using Pronterface, whenever I load a G-code file I can read in the output log a pessimist estimation of the print duration. The actual duration is always much longer than the estimation by a factor from 2 to 5 (20mn in place of 11mn, 2h45 in place of 45mn, ...). I've tried changing the speeds in Slic3r and regenerating the G-code file from the STL file, the speed is always the same. What can I do to change the printing speed ?

Hot end air flow direction : which direction should the air flow ? toward the hot end (blowing) or away from the hot end (aspiring) ? Mine is aspiring, I find it strange as I've often read about the importance of hot end cooling and blowing seems to me more efficient. I've checked a few times the wiring, it seems ok. Of course I can try to wire it reversed but I'd prefer an advice before changing it.

Bed heating : the post-printing commands automatically added by Slic3r to the G-code file (G1... for parking, M1 for halting) seems there to stop the hot end and bed heaters. My hot end actually stops heating, but not the bed. Is this normal ? probably not ;-) I've tried with different post-commands (M104 S0 and M140 S0), same issue no matter the order of the commands (M104 then M140 or M140 then M104).

Thanks
Patrice

Quote
paflviet
Print speed : using Pronterface, whenever I load a G-code file I can read in the output log a pessimist estimation of the print duration. The actual duration is always much longer than the estimation by a factor from 2 to 5 (20mn in place of 11mn, 2h45 in place of 45mn, ...). I've tried changing the speeds in Slic3r and regenerating the G-code file from the STL file, the speed is always the same. What can I do to change the printing speed ?

I don't know what's happening there because I use the web interface to control the printer instead. The web interface provides 3 different estimates of print end time, or 4 if you use my variant of the firmware and web interface. The last one (based on filament consumption) is usually quite accurate.

Quote
paflviet
Hot end air flow direction : which direction should the air flow ? toward the hot end (blowing) or away from the hot end (aspiring) ? Mine is aspiring, I find it strange as I've often read about the importance of hot end cooling and blowing seems to me more efficient. I've checked a few times the wiring, it seems ok. Of course I can try to wire it reversed but I'd prefer an advice before changing it.

There is a lot of backwash from the fan unless you fit an inlet duct, so it is easy to think the fan is blowing the wrong way. If you search this forum, you will find a number of designs for fan inlet ducts. The one I use is here [github.com]. It's designed for screw fixing, so you need a couple of long (50mm AFAIR) M3 countersunk screws to fit it.

Quote
paflviet
Bed heating : the post-printing commands automatically added by Slic3r to the G-code file (G1... for parking, M1 for halting) seems there to stop the hot end and bed heaters. My hot end actually stops heating, but not the bed. Is this normal ? probably not ;-) I've tried with different post-commands (M104 S0 and M140 S0), same issue no matter the order of the commands (M104 then M140 or M140 then M104).

That's probably because you (or slic3r) are using the M190 command somewhere to set the bed temperature, and there is a bug in the firmware. A workaround is to put M190 S0 before the M1 command.

Edited 2 time(s). Last edit at 06/14/2014 04:39PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42
I don't know what's happening there because I use the web interface to control the printer instead. The web interface provides 3 different estimates of print end time, or 4 if you use my variant of the firmware and web interface. The last one (based on filament consumption) is usually quite accurate.

My real concern is about changing the printing speed : as long as I understand the print time is directly related to the speed for print moves, and the speed influences the print quality as a side effect.
Slic3r has a print tab with a speed sub-tab, I've tried to modify the settings one after another to check carefully (and learn) which parameter had which effect, nothing changed. I also read quite all the topics from this forum, every topic about speed directed me to this Print/Speed tab.
I did a diff on different versions of the generated G-code file (same STL source file, only one parameter changed at a time, ...), they seem to incorporate various speed settings but the print time remains constant no matter the change I test.

Quote
dc42
There is a lot of backwash from the fan unless you fit an inlet duct, so it is easy to think the fan is blowing the wrong way. If you search this forum, you will find a number of designs for fan inlet ducts. The one I use is here [github.com]. It's designed for screw fixing, so you need a couple of long (50mm AFAIR) M3 countersunk screws to fit it.

For the moment, I'm learning how my printer works before beginning to modify it, I keep your suggestion for the fan inlet duct replacement somewhere in my mind.
I've also seen your modified IR Z probe, I'll certainly re-contact you later for an order. Today I'm setting Z manually before every print, it's fine as long as I'm learning, but for sure it will become annoying for an actual usage ;-)

Quote
dc42
That's probably because you (or slic3r) are using the M190 command somewhere to set the bed temperature, and there is a bug in the firmware. A workaround is to put M190 S0 before the M1 command.

Ok, I've found the M190 command, it's the bed temperature setting at the very beginning of the G-code file generated by Slic3r. I'll try with your M190 S0 command.

Thanks
Patrice

Hi Patrice,
Welcome to the forum and don't worry - we've all been on the journey you are on and it will come right My advice would be to try and get some basic prints working (like snowman and coathook) using standard settings before adjusting too much - that can come later. In case it is useful to you, I have attached my standard Slic3r setting which you can just import (one each for printer, print and filament - these are based on all the good advice I got when I started and give me rock-solid results every time - I go back to these whenever I get in a tangle and I know for certain that they work fine with @DC's firmware and web interface. They will give you a baseline that you can rely on the for the slicing, allowing you to concentrate on what the printer itself is doing- good luck and stick with it

Regarding the fan, there is always one correct direction for it to rotate. The blades are slightly curved, and the "inside" of that curve is always in the direction of the airflow. Some fans have an arrow on the housing pointing in the airflow direction as well (and sometimes also one showing the direction of rotation).
If it is turning the other way it is probably wired wrong, and having like that will make it significantly less efficient in moving air. There are aerodynamical reasons for having the blades curved like that, and having them go the other way is rather counterproductive.

Once you have the fan turning the correct direction, you then decide the airflow by which way you mount the fan. The cooling for the hotend is designed to have the fan blowing towards the heatsink and then down onto the printed plastic.

Quote
paflviet

Quote
dc42
That's probably because you (or slic3r) are using the M190 command somewhere to set the bed temperature, and there is a bug in the firmware. A workaround is to put M190 S0 before the M1 command.

Ok, I've found the M190 command, it's the bed temperature setting at the very beginning of the G-code file generated by Slic3r. I'll try with your M190 S0 command.

Btw that bug is now fixed in my latest firmware, 0.65g-dc42 described in another thread.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
paflviet
My real concern is about changing the printing speed : as long as I understand the print time is directly related to the speed for print moves, and the speed influences the print quality as a side effect.
Slic3r has a print tab with a speed sub-tab, I've tried to modify the settings one after another to check carefully (and learn) which parameter had which effect, nothing changed. I also read quite all the topics from this forum, every topic about speed directed me to this Print/Speed tab.
I did a diff on different versions of the generated G-code file (same STL source file, only one parameter changed at a time, ...), they seem to incorporate various speed settings but the print time remains constant no matter the change I test.

You are possibly running up against the quite low default max speed. Use the M203 command to change (see below).
I print with 65mm/s for print moves and 100mm/s non-printing moves (which could probably be increased if I also increase the max s[peed setting). At higher print speeds you will run up against the maximum extrusion limit - the extruder cannot push plastic through the nozzle fast enough and so the extruder motor starts skipping. You should however also increase the stepper currents in your config file otherwise you will get steppers skipping prematurely. Increasing to 1000mA is safe enough.

My config.g file (on the SD card) has the following:

M203 X6000 Y6000 Z500 E6000 ;set max feedrates - divide by 60 for mm/s
M201 X1500 Y1500 Z30 E500 ;set accels
M906 X1000 Y1000 Z1000 E1250 ;set currents

The time estimation calculated by the slicing program will be calculating based on the set speeds rather than the speed the machine actually prints at if it is limited by the max speed, and in addition may well not take into account either acceleration or extruder retraction delays, and so will tend to be overly optimistic. For short moves (such as infilling narrow areas) the print speed is constrained by the acceleration to be a *lot* slower than the speed set.

Dave
(#106)

Edited 1 time(s). Last edit at 06/16/2014 09:31AM by dmould.

Thanks to all for your help. I'll try to answer to everyone.

Quote
dc42
That's probably because you (or slic3r) are using the M190 command somewhere to set the bed temperature, and there is a bug in the firmware. A workaround is to put M190 S0 before the M1 command.

You were right, inserting a M190 S0 before M1 solved my issue.

Quote
MrCrispi
Welcome to the forum and don't worry - we've all been on the journey you are on and it will come right. My advice would be to try and get some basic prints working (like snowman and coathook) using standard settings before adjusting too much - that can come later. In case it is useful to you, I have attached my standard Slic3r setting which you can just import (one each for printer, print and filament - these are based on all the good advice I got when I started and give me rock-solid results every time - I go back to these whenever I get in a tangle and I know for certain that they work fine with @DC's firmware and web interface. They will give you a baseline that you can rely on the for the slicing, allowing you to concentrate on what the printer itself is doing- good luck and stick with it

Actually I'm a Unix system engineer and used to these procedures, changing things slowly and one after another
Thanks for your files, they give me an operational reference for my tests, they help me a lot for testing and learning.

Quote
jstck
Regarding the fan, there is always one correct direction for it to rotate. The blades are slightly curved, and the "inside" of that curve is always in the direction of the airflow. Some fans have an arrow on the housing pointing in the airflow direction as well (and sometimes also one showing the direction of rotation).
If it is turning the other way it is probably wired wrong, and having like that will make it significantly less efficient in moving air. There are aerodynamical reasons for having the blades curved like that, and having them go the other way is rather counterproductive.

I checked once again my wiring and it seemed right. As I always tested the air flow with the feelings on my hand , I remembered a simple test I forgot to perform, with a small piece of paper held in the flow in front of the fan : the paper was aspired by the fan. The conclusions are easy : the fan is operating well, and I was wrong with the air feeling on my hand due to the importance of the air flow. Shame on me.
Anyhow, I learned something regarding the blades conception, thanks.

Quote
dc42

Quote
paflviet
Ok, I've found the M190 command, it's the bed temperature setting at the very beginning of the G-code file generated by Slic3r. I'll try with your M190 S0 command.

Btw that bug is now fixed in my latest firmware, 0.65g-dc42 described in another thread.

I checked your 0.65g-dc42 firmware and posted a message in that other thread after a lot of tests. Bad news, I found some issues. Or I've totally missed something, do not hesitate to show me where I'm wrong.

Quote
dmould
You are possibly running up against the quite low default max speed. Use the M203 command to change

Thanks for your commands. I tried them, the printer seemed to move faster but the overall time remained quite the same. I understand that moving faster can generate quality issues, that's not a problem for the moment, I want to check for the limits. Later on I'll certainly use at least two configurations : one for rapid prototyping where quality is not mandatory but speed is, a second one for the definitive printings.
As I spent some time testing dc42 latest firmwares I didn't performed all the tests I intented to do with your configuration but I'll study it more thoroughly later.

Once again, thanks to all.
Patrice

Quote
paflviet

Quote
dmould
You are possibly running up against the quite low default max speed. Use the M203 command to change

Thanks for your commands. I tried them, the printer seemed to move faster but the overall time remained quite the same. I understand that moving faster can generate quality issues, that's not a problem for the moment, I want to check for the limits. Later on I'll certainly use at least two configurations : one for rapid prototyping where quality is not mandatory but speed is, a second one for the definitive printings.
As I spent some time testing dc42 latest firmwares I didn't performed all the tests I intented to do with your configuration but I'll study it more thoroughly later.

Once again, thanks to all.
Patrice

You can set the outer perimeter to print at a slower speed and the rest at a faster speed. That way the finished quality will be good but the print will complete a lot faster. Also set the bridging speed lower. As said, if you have a lot of narrow areas to fill the speed is constrained by the acceleration so the average print speed will be lower than what is set. To improve that you need to increase the acceleration - but setting it too high will result in missed steps which ruins the print. You can make the non-printing move speeds pretty much as high as you like and it will not affect print quality at all. There is not much improvement I can see in the quality of prints when the outer perimeters are printed slower than about 40mm/s, but you should experiment and find the limit yourself. Above 40mm/s I start seeing more distortion and blobbing on corners, though 65mm/s gives me perfectly satisfactory quality.

Dave
(#106)

Thank to everybody, now I'm able to print at a speed which seems correct : my reference part (a small octopus) which took 2h45 is now printed with a better quality in 55mn
I use :
- the basic configuration found in the Github. Thanks again MrCrispi, your files helped me to understand all those parameters.
- dc42's 65h firmware. With this one the heat bed stops heating after a print, I can now send a print at night before going to bed knowing my Ormerod won't heat the whole night. I'm not able to go for a second printing without rebooting the printer, but as it seems more a firmware or G-code issue, I'll continue this discussion in dc42's 65g (and now h) thread.
- dc42's HTTP interface, and much less Pronterface.
- a personal Z compensation procedure to run by hand (let me know if somebody is interested in it). It's not revolutionary but it's simple, easy to run and to reproduce, and needs approximately 2mn. I didn't want to automate it before some weeks for the heat bed to stabilize itself on the printer base, now that it seems ok I'm beginning to use a setbed.g file with just an initial head positionning.

Patrice

Quote
dmould

Quote
paflviet
My real concern is about changing the printing speed : as long as I understand the print time is directly related to the speed for print moves, and the speed influences the print quality as a side effect.
Slic3r has a print tab with a speed sub-tab, I've tried to modify the settings one after another to check carefully (and learn) which parameter had which effect, nothing changed. I also read quite all the topics from this forum, every topic about speed directed me to this Print/Speed tab.
I did a diff on different versions of the generated G-code file (same STL source file, only one parameter changed at a time, ...), they seem to incorporate various speed settings but the print time remains constant no matter the change I test.

You are possibly running up against the quite low default max speed. Use the M203 command to change (see below).
I print with 65mm/s for print moves and 100mm/s non-printing moves (which could probably be increased if I also increase the max s[peed setting). At higher print speeds you will run up against the maximum extrusion limit - the extruder cannot push plastic through the nozzle fast enough and so the extruder motor starts skipping. You should however also increase the stepper currents in your config file otherwise you will get steppers skipping prematurely. Increasing to 1000mA is safe enough.

My config.g file (on the SD card) has the following:

M203 X6000 Y6000 Z500 E6000 ;set max feedrates - divide by 60 for mm/s
M201 X1500 Y1500 Z30 E500 ;set accels
M906 X1000 Y1000 Z1000 E1250 ;set currents

The time estimation calculated by the slicing program will be calculating based on the set speeds rather than the speed the machine actually prints at if it is limited by the max speed, and in addition may well not take into account either acceleration or extruder retraction delays, and so will tend to be overly optimistic. For short moves (such as infilling narrow areas) the print speed is constrained by the acceleration to be a *lot* slower than the speed set.

Dave
(#106)

I´ve also sometimes skipping in the y and x axis. The belt-tension is ok - no beltslipping. And it is especially on my try to print the t-800 Terminator head from Thingiverse.

I wanted to Print by 50 Perimeter Speed, 35 infill, all other Speed - Settings are the Default Settings.

Other prints, mostly without so much curves in the layers, gone right good with this Settings.

So i think it is maybe also the acceleration of the lot small movements in this prints. And want to try this Settings.


or am I wrong?

Muggi, what motor currents are you using? Many of us have increased some of them to 1000mA to avoid missing steps. This is especially important for the y axis.

You can adjust the accelerations using the M201 command.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi

i use actually the Default Settings:


M906 X800 Y800 Z800 E800 ; Motor currents (mA)