preheat bugs

[mrbi11]

Bug 1) If user has a preheat command for bed in custom commands, the software will not generate any heat command for hot end Bug 2) If user has a preheat command for hot end in custom commands, the software generates no heat command for heated bed Bug 3) If user gives no preheat commands in custom code, the software generates out of order preheat commands. Specifically, it generates a preheat with wait on bed, then generates a preheat without wait on hot end, then generates a preheat with wait on hot end. Net effect is it heats one, then heats the other, instead of heating both at same time. So takes up to twice as long for no reason. Bug 4) The software should generate a preheat command (WITHOUT WAIT) for both hot end and bed. Then it should generate a heat with wait in either order for same heaters. This will heat in minimum time no matter which heater is faster. (independent of custom commands) Bug 5) Although implied in 1 and 2, the software should not get more specific, it should not look at custom commands at all. Reason, the user already has a method to ignore either heater by setting its temperature to zero. It is not necessarily true the user means to permanently change temperature just because it has a temperature command. It may be adjusting the hot end to be cooler till the heater bed reaches working temperature for example. Why? to avoid burning the ABS or PLA by cooking it too hot for too long without extruding. That is one example. Since the software already has a way to allow the user to control whether or not to set heaters, it is counter productive to try and read the users mind, effectively defeating his true purpose, and generally introducing the above sequence of bugs by over constraining the controls.

[bstott]

Hi - Which gcodes are you using? You are using the wait and/or no wait commands? I am at a loss for what you are actually referring. I use my own start and stop gcode as do most others that print. The Custom-gcode? That is an example - you must change to your use. If you read the gcodes in the reprap wiki you will find that some have a wait until temp is reached others do not. Most of us use both to good effect as you can see in my functioning code at the end of this post.

The manner in which you write about your functions indicates that you are talking about a gui printer interface rather than Slic3r. Slic3r is a gcode generator for turning stl files into commands for a 3D printer. It is not a printer interface. Are you using Pronterface? I do. The preheat commands for the bed and hot end work concurrently not waiting for either.

IMO - Your indicated bugs are directed at the use of a printer gui not Slic3r. The example Custom-Gcode for start and end is simply that. Find another's gcodes (Mine are simple and are below for reference.). Or generate your own start and end gcodes for your respective printer. If you bought your printer from a vendor or manufacturer then they can give you a start with operating the printer. Searching forums is fruitful also.

Do you use the stock start and end gcodes within Slic3r? I do not remember what they are so do not know their actions - You would be better off to read the Mcode and Gcode commands (http://reprap.org/wiki/G-code) to setup your machine to run as you would like it. My machine gcode starts the bed first to 80°C and waits. When the bed is 80°C the gcode then increases the bed to 110° C without waiting and initiates the hot end to 224°C with a wait. During this my bed gets to 110° C while the hot end temperature reaches 224°C. When the hot end is at temperature so is the bed and the printing begins.

Your Bug 5) I disagree completely. You need to write your own code for your use and insert it into the Custom-Gcode. Our whole existence is ALL experimental/new machines, materials, processes all the time. The purpose of the software is to use the new and developing machines, materials and environments to our best advantage. What you suggest would not work for us!

Here are my start and end gcode for Slic3r. They do work as intended. I hope they can help.

Best Regards,

Brian.

Start gcode: M190 S80 ; Start bed heating. Wait for temp. M140 S110 ; Set bed temp, no wait. M104 S220 ; Set hotend temp, no wait. G28 ; Home all axes. M106 S127; Begin Fan to cool entry tube and stop swell & jamming. G1 Y 25 Z5 F5000 ; Place nozzle within 5mm of bed. M114 ; Output position to serial. M140 S110 ; Set bed temp, no wait. M109 S224 ; Set hotend temp, wait. M106 S255 ; Turn on Fan.

End gcode: G92 E0 ; Reset Extruder to 0. G1 E-5 F1800 ; Retract filament 5mm @30mm/s. G92 E0 ; Reset Extruder to 0. M140 S0; Set temperature to 0. Turns bed off. M104 S0; Set temperature to 0. Turns hot end off. G28 ; Home all axes. M18 ; Disable motors. M300 S659 P125 ; Play Beep on Completion. Fur Elise M300 S622 P125 M300 S659 P125 M300 S622 P125 M300 S659 P125 M300 S494 P125 M300 S587 P125 M300 S523 P125 M300 S440 P500 M1 ; Shut heat and motors off. M107 ; Turn Fan off.

[alranel]

You used the word "bug" 6 times without even considering whether such behavior is intentional or not. The behavior you're describing is both intentional and documented.

Please, read the tooltip documentation for the Start G-code setting: This start procedure is inserted at the beginning of the output file, right after the temperature control commands for extruder and bed. If Slic3r detects M104 or M190 in your custom codes, such commands will not be prepended automatically.

If there's some special configuration Slic3r doesn't allow you to do, please describe your needs. But don't start by saying "bug" "bug" "bug" "Slic3r should do this" "Slic3r should do that". Let's start with an analysis of the actual problem before moving onto solutions. Thank you.

[RenaeMacLeod]

I can confirm at least part of his findings (item 3 and 4) in 1.00rc3. I found this because I was about to add an item for the order of heating and custom commands.

In Slic3r x64 (Windows compiled version running on Windows 8.1 fully updated) I have 3 custom commands...

start_gcode = M301 P63.84 I5.57 D183.05\n; MOVE THE FOLLOWING BELOW LAST HEATER COMMAND\nG1 E10 ; Extrude 10mm\nG28 ; Home all axes

... and I have different temps for different filament. Here are the temperature settings for one I am running with currently...

bed_temperature = 60 first_layer_bed_temperature = 60 first_layer_temperature = 200 temperature = 180

... However, I have to manually move the extrude and home parts one line down because the GCode file generated has the wait for extruder temp after my start GCode. Here is a copy from the very start of the GCode file, unedited, partially into the print cycle...

; generated by Slic3r 1.0.0RC3 on 2014-03-01 at 22:37:15

; layer_height = 0.3 ; perimeters = 3 ; top_solid_layers = 3 ; bottom_solid_layers = 3 ; fill_density = 0.5 ; perimeter_speed = 60 ; infill_speed = 120 ; travel_speed = 260 ; nozzle_diameter = 0.35 ; filament_diameter = 1.655 ; extrusion_multiplier = 0.96 ; perimeters extrusion width = 0.35mm ; infill extrusion width = 0.37mm ; solid infill extrusion width = 0.37mm ; top infill extrusion width = 0.37mm

G21 ; set units to millimeters M107 ; disable fan M190 S60 ; wait for bed temperature to be reached M104 S200 ; set temperature M301 P63.84 I5.57 D183.05 G1 E5 ; Extrude 5mm G28 ; Home all axes M109 S200 ; wait for temperature to be reached G90 ; use absolute coordinates G92 E0 ; reset extrusion distance M82 ; use absolute distances for extrusion G1 F1800.000 E-1.00000 ; retract G92 E0 ; reset extrusion distance G1 Z0.300 F15600.000 ; move to next layer (0) G1 X33.170 Y30.899 F15600.000 ; move to first skirt point G1 E1.00000 F1800.000 ; compensate retraction G1 X34.030 Y30.109 E1.05472 F600 ; skirt G1 X35.070 Y29.599 E1.10899 ; skirt G1 X36.210 Y29.409 E1.16315 ; skirt G1 X78.210 Y28.409 E3.13170 ; skirt G1 X123.680 Y28.409 E5.26229 ; skirt G1 X142.890 Y29.419 E6.16366 ; skirt G1 X144.010 Y29.629 E6.21705 ; skirt G1 X145.020 Y30.149 E6.27028 ; skirt G1 X145.850 Y30.929 E6.32365 ; skirt G1 X146.420 Y31.909 E6.37677 ; skirt

... I suspect that the 'M104 S200' command should be before, rather than after, the 'M190 S60' command. And the reason I'm here is that the 'M109 S200' command is after my start GCode.

@bstott Thanks for your start GCode. Very interesting use of the bed and extruder temp commands. I may experiment with them and save custom printer configs to heat the bed and extruder efficiently for different filament types.

[alranel]

Really, starting from wrong assumptions is a very bad way to solve problems, get help from other people and achieve goals. In the original report, @mrbi11 states that heated bed and extruder are heated separately for no reason. That's a bit rude. I recommend putting a question mark next time, because, you know, there's always a reason behind design choices. In this case, it's pretty obvious: heated bed takes much more time to heat and nobody wants to have plastic burning in the hot-end for several minutes while heatbed gets to temperature.

@RenaeMacLeod, if you want to do something and you don't know how to do it, just ask it. For example: Hi! How can I run a custom G-code command after heating is complete?

Magically, someone would have answered with a solution for you:

M301 P63.84 I5.57 D183.05
M109 S[first_layer_temperature]
G1 E10 ; Extrude 10mm
G28 ; Home all axes

And that's also in the FAQ: https://github.com/alexrj/Slic3r/wiki/FAQ

[RenaeMacLeod]

I didn't think I was making assumptions. The tool tip (which you pasted above) and your website clearly says that start GCode commands are inserted AFTER the temperature control commands. However, there is a temperature control command still being inserted after my custom GCodes.

While I do agree that the initial issue verbiage was a bit rude (in fact, item 1 and 2 are feature requests as he wrote them), I only wanted to make sure that I added my findings since it seemed to me that it wasn't acting as it was described. I only care that the final extruder heat command is not before my custom commands. I agree that you shouldn't have the extruder sitting at a high temp while the bed is heating up. This is why I thanked bstott for his listing of bed and extruder temp heating commands which seemed pretty well thought out. In addition, I've actually spent considerable time finding a good holding temperature for my filament so I can have the extruder close to ready (no drips) while the build platform heats up.

Lastly, I personally don't believe in using an issue tracking system for asking questions. If you are referring to another place to ask questions, I'll happily add it to my bookmarks. I have briefly looked in the past for a Slic3r forum but I have not found anything specific to Slic3r. To be honest the software is designed very well and I haven't had much of a need for questions to be answered. Any Google search usually results in the answer that I need.

With all that being said, I'm sorry I didn't know about the temperature variable system that was designed. I will definitely experiment with it when I have some time but I'll add the command you listed above to work around the issue that brought me here. If it's by design (which it seems it is judging by your response) that an additional heating command is placed after custom GCodes, then the bug is that the tool tip and various other locations that state otherwise are incorrect.

[bstott]

@RenaeMacLeod Quick questions to you - Why do you put the M301 PID into your gcode? Do you reconfigure your machine with different tool heads?

I'm using Marlin: Once most machine operators run the M303 (Auto Tune PID) sequence to get the initial tuned PID and/or fine tune one manually they program the PID into the firmware or save into EEPROM.

[RenaeMacLeod]

I don't update my firmware every day, that's a recent PID. I will be putting it into firmware but it's there as a reminder and I'm not 100% certain if it's saved when my machine is powered down. I have RAMPS 1.4 and an Arduino Mega 2560. Can you tell me for certain it is and/or that putting it in here until I update my firmware is a bad thing? I will put it elsewhere if either of those is true.

Thanks

[RenaeMacLeod]

Well, I found the settings. EEPROM will be enabled after my next flash. My long list of low-priority things to do when I have a spare minute is now one item shorter.

Thanks for the gentle nudge. :)

[bstott]

@RenaeMacLeod Thanks for the insights. My machine is, like yours, RAMPS 1.4 (w/Marlin, Slic3r & Pronterface/Printrun). I've all the software tools for printing on the laptop connected to my machines so, two minutes or less to edit the configuration.h and update the firmware.

As to EEPROM - since you enabled that you saw that you will be able to save your configurations so they will reinitialize on the machine each time you start it. [Nice!] Be careful - I'd read and already been caught - when you make additional changes to the firmware later you will need to save to EEPROM otherwise the EEPROM will overwrite what you change in firmware. How to avoid this? Turn the EEPROM feature off in the firmware when you are experimenting or making adjustments and multiple re-flashing of the firmware. You know the routine of try and re-try until you get it right. Once you have the correct settings - like your PID - then turn EEPROM back on with the included firmware configuration changes. OR get to know how to manually write the new configurations into the EEPROM using the Mcodes. I am not there. I see the order and ease of the Mcode commands. I currently lack the practiced confidence and the understanding/proof that it works. Tedious? Normal, IF learning and developing. Ha, ha, right where we are. ;-)

[RenaeMacLeod]

Where we are indeed. :)

Thanks for the warning about EEPROM settings carrying across firmware updates. I will make sure to reset whenever I flash.

[mrbi11]

Whether the behavior is intentional or not, is besides the point. The behavior can damage machines, filament etc.

Setting the bed temperature in on printer profile means the software will leave the extruder heater OFF, so grinding filament for 10 hours while the user is expecting printing to be happening. That is a bug. If you intended that, the intention is still a bug.

Works as designed is not a response to a bug report. "works" is a response.

Does not "work" as is.

So the question is, why does the software look at the custom code AT ALL? It serves no purpose. It accomplishes nothing that cannot be accomplished by a simpler set of rules which does not surprise the user with ruined prints. It is straight forward for the user to disable either heater, and documented on the actual human interface. The "other" documentation does not appear on the human interface. Bug. Presence of documentation on a topic, implies absence of documentation on the same topic means there is nothing else to document.

Nothing in the fine print prepares the unwary for tuning the temperature on on heater to turn off the other heater. That is, the unwary who has read the human interface.

Now, as to what the software should do by default, It should set both all layer temperatures, without waiting, then wait for each one. This works on all machines, and preheats the machine in minimal amount of time. The current system preheats the bed first, waits for the bed to preheat, then initiates heat on the hot end. This takes as much as twice as long as necessary for no purpose. It is a BUG when a print takes 20 extra minutes to start, for no reason. If it is working as designed, then the bug is in the design.

Now, there are two ways to disable temperature handling, but there is no reason for there to be two ways. One is plenty. If the design were "fixed" to ignore the temperature commands in the custom code, absolutely nothing is lost. If the intent of the user is to disable the extruder heater, then the user can certainly do that. No limit on what can be done.

The current design requires the custom code to do EVERYTHING, if it does ANYTHING, but no check is in place to say, excuse me sir, but since you set the bed temperature i also turned off your extruder heater, which by the way is entirely pointless, since you did not also set the extruder temperature. Instead it produces an easily detectible, guaranteed failure.

So, if the intended design is to allow the user to shoot themselves in the foot, well i guess you have a correct design after all.

peace, *Bill Kelley

• 512 266 1896

On 3/2/2014 7:12 PM, Alessandro Ranellucci wrote:

You used the word "bug" 6 times without even considering whether such behavior is intentional or not. The behavior you're describing is both intentional and documented.

Please, read the tooltip documentation for the /Start G-code/ setting: /This start procedure is inserted at the beginning of the output file, right after the temperature control commands for extruder and bed. If Slic3r detects M104 or M190 in your custom codes, such commands will not be prepended automatically./

If there's some special configuration Slic3r doesn't allow you to do, please describe your needs. But don't start by saying "bug" "bug" "bug" "Slic3r should do this" "Slic3r should do that". Let's start with an analysis of the actual problem before moving onto solutions. Thank you.

— Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/1818#issuecomment-36474675.

[bstott]

Bill - I am trying to read your note - I am confused.

• I have no problems setting both heaters to on at the same time.
• I have no problems setting one to heat and the other to heat and wait for the temperature to get to target.
• I would want my custom code to have priority since I went to the trouble to make a demand/command to the machine

Note: I had similar confusion as yourself when I went from my MakerBot, RepG, Skeinforge to Marlin, Pronterface, Slic3r. Why? MakerBot had already custom & for my specific machine and I never had to deal with these files other than making a few minor changes. This left me with no understanding that the 'slicer' application slices and generate simply the gcode to move the machine. It does not setup for a file nor does it complete activities after a print is run. This is the skill we have to learn as operators. Once you learn and setup your machine you will see there are no bugs ---- You are a machine operator --- The programmers here have many machines with which they have their software to work with. The industry hasn't gotten to the point to have individual machines with individual software to dummy us down yet. So, we have to be smart. The same situation was with early machinists. They manually setup and ran their machines and knew them. The modern machinist in many production houses is mostly a sit down button pusher. The engineering programmer, machine manufacturer and the design engineer have done the work. The many modern machinists load raw material, a program and push the button. Then sit down to read for the next three hours collecting their high wages.

Sorry - I am too tired to read your back and forth about documentation and not documentation and custom code not to be looked at all and the funny thing why you can not heat the bed and the hot end to temperature at the same or concurrently to two temperatures. We all run our machines and do this. It is how it works. The is OPEN SOURCE = So, if there is no documentation you join the groups and forums and read, read, read, read. Then you ask nice questions. If the lack of documentation really is your want then you help out and make some, video, CAD, animation, photos, kids, cats, wife, etc.... Then post it for others to get help from you.

Here is my start gcode. I have just taken others and reading the gcode on reprap.org and firmware github docs and again from others ---- Read the code ---- Add it to the beginning your sliced gcode file.

M190 S80 ; Start bed heating. Wait for temp. M140 S110 ; Set bed temp, no wait. M104 S220 ; Set hotend temp, no wait. G28 ; Home all axes. M106 S127; Begin Fan at 50% to cool entry tube and stop swell & jamming. G1 Y 25 Z5 F5000 ; Place nozzle within 5mm of bed. M114 ; Output position to serial. M140 S110 ; Set bed temp, no wait. M109 S224 ; Set hotend temp, wait. M106 S255 ; Turn Fan to 100% on.

The above is inserted somewhere within your slicing application. It will aknowledge it as the start gcode and prepend it to your gcode. You make your own shutdown end gcode script and insert it into your slicer and this will be appended to your gcode by the application.

Awe ---- here is my end gcode script. It places a tune after the printing and the heating is turned off.

G92 E0 ; Reset Extruder to 0. G1 E-5 F1800 ; Retract filament 5mm @30mm/s. G92 E0 ; Reset Extruder to 0. M140 S0; Set bed temperature to 0. M104 S0; Set hotend temperature to 0. G28 ; Home all axes. M18 ; Disable motors. M300 S659 P125 ; Play Beep on Completion. Fur Elise M300 S622 P125 M300 S659 P125 M300 S622 P125 M300 S659 P125 M300 S494 P125 M300 S587 P125 M300 S523 P125 M300 S440 P500 M1 ; Shut heat and motors off.

Oh - Bill ---- "All machines..." in NO WAY can be used anywhere regarding Open Source 3D printers. Unless you say All 3D printers are meant to print in 3D. Otherwise we do not all make the same machines. We all do not have machines that work the same. None of us do anything exactly like the other and many of our machines do not work. So ---- until our machines are made by one manufacturer and use only one firmware/software and all use only one material and are all the same machine with brain dead push button instructions - or better yet are wirelessly attached to our brain so we don't have to move and it is flawlessly able to interpret our randomness to make all the same YOU CAN NOT SAY ALL MACHINES...!!!! READ!!! Read more forums!

There is not one of us Yahoo's that can see anyone's machine and say we want that and then make it exactly the same. We are Geeky Dorks and we are so twisted to customization or making it our way that there will not be any ---- All Machines ---- Oh, Look at - All Those Machines!!! ;-) Be happy that your light switch works.

Oh, use the start and end gcode to your best effort and if I got this all wrong. All in good spirit.

[bstott]

One last thing ---- If you post pictures of your machine there will be someone here that can help through buying or selling it.

P.S. Don't get too frustrated --- Breath and count.... ;-)

[RenaeMacLeod]

@mrbi11 AFAIK if you put 0 in your filament temp settings it doesn't put any heating commands in your GCode. If setting it to 0 is the problem you are having then set your filament temps to what you want. I hope that is helpful.

@bstott Can you confirm if it is intended to have a heating command after your start GCode or if the tool tip is correct and all heating commands are supposed to be before your start GCode.

Thanks

[bstott]

@RenaeMacLeod Are you referring to manually pre-heating the machine prior to starting a print?

I do not pre-heat other than pre-stage the printer within the start gcode.

I have not made inter-print temperature changes or required them after the start gcode other than for the use of a different first layer temperature over the other layers of a print - See Slic3r --> 'Filament Settings',

The heating commands are within your GCode in the start gcode section. Any temperature changes after the start gcode are from the above noted 'Filament Settings', if using Pronterface. Any heating prior to printing is your manually manipulating the machine.

If you use Marlin firmware and are concerned with temperature runaway on the hot end (extruder, tool tip, tool head, etc...) then you can configure your hot end and the firmware for two thermistors which will be compared. If they get out of sync the machine can be configured to shut-down. (I did have my lab filled with smoke streaming from my molten hot end last week. The thermistor slipped out and the temperature was over 650° F (345°C).)

Within the Slic3 application under the tab 'Printer Settings' > 'Custom G-Code' is where you place your start and end gcodes. I do use the temperature variability for the first print layer over the rest of the print under the 'Filament Settings'. I print ABS & modified PLA at 220° with different heated bed temperatures. But, I do not have any experience with having purposeful temperature changes during a print. We usually try to keep temperatures stable during printing. So, we will put barriers around our printers, at times, to stop drafts and also adjust the machine print speeds to not exceed our extruders being able to adjust for the amount of filament being melted as the print proceeds. Go to reprap.org forums - search: 3D printer forum. Good learning and discussions.

[ledvinap]

@mrbi11

Setting the bed temperature in on printer profile means the software will leave the extruder heater OFF, so grinding filament for 10 hours while the user is expecting printing to be happening. That is a bug. If you intended that, the intention is still a bug.

You are wrong. The idea is simple: either let slic3r do the temperature management (in most basic way) and do not touch temperatures in start G-Code OR handle it all yourself. In my opinion this is clean and documented behavior.

So the question is, why does the software look at the custom code AT ALL? It serves no purpose. It accomplishes nothing that cannot be accomplished by a simpler set of rules which does not surprise the user with ruined prints.

Well, then state the simpler rules!

She software checks gcode to see which of the two cases to use. There could be a checkbox to turn implicit temperature handling on and off, but it will be redundant.

It is straight forward for the user to disable either heater, and documented on the actual human interface.

It's not about disabling heaters. It's mostly about sequencing temperatures during initialization phase. For example my mendel90 starts heating bed and preheating extruder concurrently with homing, but extruder temperature is raised to first layer temp only after nozzle is touching bed to prevent ooze.

It should set both all layer temperatures, without waiting, then wait for each one. This works on all machines, and preheats the machine in minimal amount of time.

Alexrj already answered this and you are ignoring the answer .. Alexrj: In this case, it's pretty obvious: heated bed takes much more time to heat and nobody wants to have plastic burning in the hot-end for several minutes while heatbed gets to temperature.

[RenaeMacLeod]

@bstott Thanks for the useful info, I appreciate it. I am only trying to find out if there is a bug with the last heat command (from filament settings) being inserted after start GCode or if the tool tip and the website is wrong in stating that all heat commands (inserted by Slic3r and NOT in the Start GCode sectoin) are placed before your start GCode. I hope you understand my question. Here is additional relevant info...

Slic3r tool tip & documentation... "This start procedure is inserted at the beginning of the output file, RIGHT AFTER the temperature control commands for extruder and bed."

My filament settings (used for temperature control commands)... bed_temperature = 60 first_layer_bed_temperature = 60 first_layer_temperature = 200 temperature = 180

My start GCode... start_gcode = G28 ; Home all axes

GCode file made by Slic3r... M190 S60 ; wait for bed temperature to be reached <<<--------- Right before start GCode M104 S200 ; set temperature <<<--------- Right before start GCode G28 ; Home all axes <<<---------* Start GCode * M109 S200 ; wait for temperature to be reached <<<--------- NOT right before start GCode

See my post above (4 days ago) for this same information in full detail. I am trying to point out that not all temperature control commands generated by Slic3r are inserted before the start GCode as the documentation says. I personally agree with the documentation in that it should be kept together before the start GCode.

I fully understand that it is possible to bypass what Slic3r is doing with your own GCode but that is not my point. I hope you understand I am simply either pointing out a bug in the implementation or the documentation.