Found the problem! Your reminder for what the the g-code does is not commented out in the final gcode. You need to put the semicolons in for the start/end/extruderchange alteration boxes otherwise you comments get sent to the firmware and cause issues.
(**** beginning of start.gcode ****)
(This is being used lol?)
(This file is for TOM with 1.75mm ABS in a MK7 Extruder)
;(**** beginning of start.gcode ****)
; (This is being used lol?)
; (**** end of start.gcode ****)
You can set the speed for 3 different regions: Perimeter (I set this fairly slow), Solid Infill (I set this medium), and Sparse Infill (I set this fast). Loops actually interpolate (non-linear, though) between the perimeter speed and the solid speed.
I don't control the acceleration profile at all, partly because BfB printers don't support that...does RepRap? I sort of assumed the firmware is set to accelerate at the highest non-skipping acceleration possible.
Thanks for continuing to play with KISSlicer, and thanks Andrew for helping out. Since I know so little about the RepRap world I really appreciate everyone's patience!
While some of the firmwares allow on the fly acceleration changes, they were never really meant to be adjusted automatically withing a print. The intention was to be able to easily calibrate the machine's max acceleration without having to constantly re-upload the firmware if an acceleration proved too extreme.
In my experience, the highest acceleration your machine can handle reliably is always the best. When the printer is accelerating, the flow rate does not perfectly follow the head velocity. Therefore, the longer (lower value) the acceleration, the more severe the flow rate discrepancy becomes.
Also, most machines are running accelerations many times faster than you posted. (I run 2500mm/s^2, many other Prusa's are running in the 1200 range) and the acceleration is a very small percentage of overall print times in the majority of cases.
What is your particular machine setup which requires such low accelerations?
Do you really run at 2.5 meters per second squared? my TOM will vibrate to the point of self destruction if I set acceleration that high!
Mainly I am looking to have a smooth acceleration somewhere from ~10mm/s to 90mm/s, which is my TOM's max feed speed it can handle until extruder stepper motor starts to skip.
I'm still tweaking to reduce running noise and vibrations of my TOM, as many already have posted it creates a loud-almost-musical noises while running and also makes unfriendly -dunk- noises at every fast corners.
"the longer (lower value) the acceleration, the more severe the flow rate discrepancy becomes."
I'm not quite sure about that statement, figuring out what flowspeed is required to have constant extrusion material per distance would be trivial calculation based on acceleration curve generated, no?
It still puzzles me that people are still doing guess and check with feedspeed and flowrate while much simpler way of calculating exists, granted absorbed moisture in ABS introduces error but it won't be far off.
Edit: sorry I'm tired and grumpy right now and means absolutely no offense to anyone, I'm just thinking out loud
Edit : ps. sort checkbox on KISSlicer 184.108.40.206 does not work, all it did for me is arrange everything from Z-A
Edited 1 time(s). Last edit at 02/21/2012 09:57PM by zsunsun.
I'm attaching truncated gcode file generated using KISSlicer
I was looking through gcode and found a few weird floating spot.
First, first layer of the print has different supporting pattern compared to the rest of the print making next layer of support material impossible to have strong adhesion, making them detach in the middle of the print. Also, this makes bottom look ugly
Another problem is when support material color is going from green to grey (in the Kisslicer layer view) I can see that my grey support layer is just laying in the thin air creating mess in the middle of the print if not knocking over other printed side.
Also, 90 degree rotating support makes it very difficult for removal, I would like to have support stacked neatly in one thin feature. After all, support material should be easier to remove there is no reason to give it a structural support by interlinking them.
Finally, it seems like what I put in 'advanced setting' window is halved or in fraction of in the gcode generated. I tried changing maximum extruder speed and minimum print time, dragging slider all the way left and right, etc, but didn't seem to affect actual feedrate. Am I doing something wrong here?
Overall I really like the gcode generated by KISSlicer. Path generated makes sense when I look at them, most of the times , and its fast slicing time is a big plus as I prefer rapid iteration of tweak and test. The whole steps flow quite nicely, Cadding -> slicing -> printing -> tweak -> Cad and or slicing -> print -> tweak . . . etc etc.
It's getting late and I'm not sure I'm making any sense at this point, and thanks for reading I really hope your software to be good as it can get.
Whisper quiet at 2.5m/s^2. Can run up to 6m/s^2 but short fills hit a resonance causing skips.
Anyway, 20 and 300mm/s^2 of acceleration take 5mm and 10mm to come up to speed for 20 and 80mm/s printing, which is a lot.
The old Tom's were never really meant to take 80mm/s, and to be honest the fill quality suffers on my machine at that speed. I'd try and keep things 20/40mm/s if not a little slower, and just keep pushing the acceleration as high as you can.
"the longer (lower value) the acceleration, the more severe the flow rate discrepancy becomes."
While the calculations tracking flow rate to extrusion rate are perfect and easy, the actual extrusion rate does not immediately match what the stepper is doing. The filament is essentially a plastic 'spring.' Even though the extruder stepper may slow down as feed rate decelerates, the plastic will continue at the previous rate for a bit leading to extra material at the end of threads. Things may behave a little differently than i'm used to at such slow accelerations, but I'm pretty sure the same effects are there.
I think the support material is getting an minor overhaul soon? I agree with the first support layer should be aligned with the others, though. I haven't done much with the support yet myself.
As for the adjusting the speed slider, your firmware may be limiting your speed, or your may RPM may be set low and that is capping the feed rate?
Sun, Andrew had a great idea about the 1st support layer changing directions, so I'll try to have that in by the next release. Yep, some support does float (if I'm understanding correctly), especially when the supported area is very small relative to the support density...the only fix for that right now is to choose a support style that is more fine / dense. And regarding the speed issue, I'm not sure what's happening there. Let me see if any of my beta testers have a TOM and if they could provide a working baseline INI file collection.
Breakdown of estimated extrusion time by extruder and path type (in G-code)
Can optionally extrude loops from inside to outside
1st layer temperature only happens after the raft if the material is different from the raft
Changed the name "Wipe Pillar" to "Prime Pillar"
Changed the name "Bed Flatness" to "Bed Roughness".
Changed the math for solid infill
to remove overlap with loops
to account for material in short connecting pieces
NOTE: you will probably need to change your "Flow Tweak" in material settings (close to 1.0)
Allows a 0mm wipe (will still trigger destring on 5D firmware)
Added a "Scale by X" right-click menu option to each object tab
Added an "All Models Menu" (to scale, revert, or delete)
Added an option to *NOT* rotate the model on load or packing
Fixed grid raft thickness bug
On Drag-n-Drop to 3D pane, can now handle filenames with spaces in them under Linux & Mac (was changing space to %20)
The combined changelog is on the downloads pages, and is too big to list here, but some highlights are:
* Support reworked, including gap, inflate, and some finer settings, interface support on internal support if needed, etc.
* Raft has inflation as well (to control oversize), and has a "Skirt" mode
* 5D firmware updates
--- don't output Z if unchanged
--- Added minimum jump length...no destring if the jump < threshold
--- Destring feedrate setting
--- Filenames are not truncated to 8 characters
--- Optional extruder axis (E A B C) for Mach3 controllers
* better Mac integration
* Bulk Key in case people want to use a bunch in a lab
* Path Color Key
Considering there are free alternatives you may consider lowering your costing, you would actually get more pro users this way. I personally use Slic3r, Cura, SFACT, and SF41 in that order to generate my g-code. If I didn't like the first g-code I would use one of the other generating programs.
I understand that you want to make money, (seems like everyone in 3D printing is trying to atleast) but at the same time you are competing against free open-source and very mature programs that have a strong foothold in the community.
Thanks for posting. As you point out, there are a lot of slicers out there, and most are Open Source, and since most of them sit on skeinforge in some way, that makes sense, Slic3r is the exception and is a _very_ cool initiative...I am glad that it is gaining followers. skeinforge can do anything (just not quickly) and is a good mature codebase. The other main slicer I see (which isn't free) is netfabb.
Regarding KISSlicer, the pricing model was based a lot on my philosophy and guesswork. [8^) When I first wrote KISSlicer it was because I had some very complex models and skeinforge (via Axon) was taking forever. When my slicer actually seemed to work pretty well (as a command line interface), I released it for free, and started planning on making a PRO version.
The very first step was deciding what feature set belonged in the PRO category, and I settled on this mantra: "The hobby user should have everything they need for free". This meant no slowing down the FREE version, no cutting features you would need for a great print, no time-limited trials to hook someone and then force them to pay, and no restriction on size of prints or on the commercial use of KISSlicer (since many hobby users make huge prints, and may want to sell them).
Then I needed a working definition of "hobby user", and I settled on "someone with a single-head printer". That way I figured I could support almost the entire RepRap community and most of the kit-BfB printer users for free. (Note that the free version of KISSlicer also lets you use any single head of your multi-head machine.) So, it's not open source (to protect the PRO portion of KISSlicer), but it IS free if you don't need multiple heads.
Pricing was tough...I had a bunch of data points at 0, and netfabb hanging out in the $200-800 range. So, when searching for the answer without knowing the question, I naturally turned to Douglas Adams, and thus the price was $42 [8^) It also was not too high (if you just bought a 2- or 3-head printer you paid what...$2k-4k?), and hopefully not so low that it looked worthless. That, plus the fact that most users don't need the PRO features is a combination that I hope will keep KISSlicer from being wildly pirated (though 'KISSlicer' just turned up as a search term on SerialBay... [8^/
Anyway, all that to say, I really hope that the free version of KISSlicer works for most users. I don't want to suck money from hobbiests. If a commercial user finds that KISSlicer PRO helps, great! Schools or bulk uers get a serious discount. I'm also thinking of trying to make a few mini-contests where I give licenses as prizes, but I don't have any good contest ideas yet. (Does anyone have some ideas?)
Thanks for listening to my manifesto! [8^)
I think your pricing is spot on. As the number of printers grow so does the number of people willing to pay for their tools. I don't think you need to use a gimmick like a contest to raise awareness. I think you have the best slicing quality at the moment and I think the only thing holding it back from more adoption are its BFB roots which are confusing to people used to a Reprap style slicer setup.
Good point about the BfB roots..that is quite true. The other two things I feel are holding back adoption are a lack of good settings for a broad variety of common printers / firmwares, and some pretty complex settings (at least for the new user). I just released KISSlicer version 1.0.9 so the next big push is to solve these issues, and return to the KISS principle as much as possible.