preheat bugs #1818
Comments
|
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: End gcode: |
|
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: 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. |
|
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 ... 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 G21 ; set units to millimeters ... 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. |
|
Really, starting from wrong assumptions is a very bad way to solve problems, get help from other people and achieve goals. @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: And that's also in the FAQ: https://github.com/alexrj/Slic3r/wiki/FAQ |
|
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. |
|
@RenaeMacLeod I'm using Marlin: |
|
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 |
|
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. :) |
|
@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. ;-) |
|
Where we are indeed. :) Thanks for the warning about EEPROM settings carrying across firmware updates. I will make sure to reset whenever I flash. |
|
Whether the behavior is intentional or not, is besides the point. The Setting the bed temperature in on printer profile means the software Works as designed is not a response to a bug report. Does not "work" as is. So the question is, why does the software look at the custom code AT ALL? Nothing in the fine print prepares the unwary for tuning the temperature Now, as to what the software should do by default, Now, there are two ways to disable temperature handling, but there is no The current design requires the custom code to do EVERYTHING, if it does So, if the intended design is to allow the user to shoot themselves in peace,
On 3/2/2014 7:12 PM, Alessandro Ranellucci wrote:
|
|
Bill - I am trying to read your note - I am confused.
Note: I had similar confusion as yourself when I went from my MakerBot, RepG, Skeinforge to Marlin, Pronterface, Slic3r. Why? MakerBot had already custom <start.gcode> & <end.gcode> 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. 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. 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. |
|
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.... ;-) |
|
@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 |
|
@RenaeMacLeod 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. |
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.
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'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.
Alexrj already answered this and you are ignoring the answer .. |
|
@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... My filament settings (used for temperature control commands)... My start GCode... GCode file made by Slic3r... 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. |
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.
The text was updated successfully, but these errors were encountered: