search

ahmetcemturan / SFACT

SFACT the New Skeinforge
http://reprap.org/wiki/Sfact
GNU Affero General Public License v3.0
151 stars 368 forks source link

the dwells scattered throughout - G4 P100 -400 etc... #13

Closed cakeller98 closed 12 years ago

cakeller98 commented 12 years ago

I ran a side-by-side comparison printing with the dwells, and then after commenting ALL G4's out... 88 minutes vs 69 minutes. That is a huge difference. I did notice a teensy bit more strings... very minor for the amount of speedup... it would scrifice less, I think, to just retract a little more. the dwells on a 69 minute print added up to almost 20 minutes (a 27% time increase)... and in the one test model I did, no appreciable difference.

perhaps it could be a check-box in the speed setting "use dwell for (maybe) some improved quality during retractions"

just a thought, but I'll be putting a find/replace in my find/replace.csv to remove them for now.

ahmetcemturan commented 12 years ago

I will be doing a box to make it a variable so you can set it to 0.

-----Original Message----- From: Christopher [mailto:reply@reply.github.com] Sent: Wednesday, November 23, 2011 12:21 PM To: Ahmet Cem TURAN Subject: [SFACT] the dwells scattered throughout - G4 P100 -400 etc... (#13)

I ran a side-by-side comparison printing with the dwells, and then after commenting ALL G4's out... 88 minutes vs 69 minutes. That is a huge difference. I did notice a teensy bit more strings... very minor for the amount of speedup... it would scrifice less, I think, to just retract a little more. the dwells on a 69 minute print added up to almost 20 minutes (a 27% time increase)... and in the one test model I did, no appreciable difference.

perhaps it could be a check-box in the speed setting "use dwell for (maybe) some improved quality during retractions"

just a thought, but I'll be putting a find/replace in my find/replace.csv to remove them for now.

Reply to this email directly or view it on GitHub: https://github.com/ahmetcemturan/SFACT/issues/13

ahmetcemturan commented 12 years ago

Can you mail me the gcode with the dwells?

-----Original Message----- From: Christopher [mailto:reply@reply.github.com] Sent: Wednesday, November 23, 2011 12:21 PM To: Ahmet Cem TURAN Subject: [SFACT] the dwells scattered throughout - G4 P100 -400 etc... (#13)

I ran a side-by-side comparison printing with the dwells, and then after commenting ALL G4's out... 88 minutes vs 69 minutes. That is a huge difference. I did notice a teensy bit more strings... very minor for the amount of speedup... it would scrifice less, I think, to just retract a little more. the dwells on a 69 minute print added up to almost 20 minutes (a 27% time increase)... and in the one test model I did, no appreciable difference.

perhaps it could be a check-box in the speed setting "use dwell for (maybe) some improved quality during retractions"

just a thought, but I'll be putting a find/replace in my find/replace.csv to remove them for now.

Reply to this email directly or view it on GitHub: https://github.com/ahmetcemturan/SFACT/issues/13

cakeller98 commented 12 years ago

sure - it's like every gcode... and if it's just pausing for retractions, but I have my travel after retraction set to 12mm so it shouldn't be retracting nearly as often as it is, I think - maybe it's missing what I have set to 12mm.

how can I get you the file? email?? dur... got it! :) will email you some samples shortly.

ok sent!

ahmetcemturan commented 12 years ago

The problem is that I currently have no system to add up all the moves that lie between retract and counterretract. It will just take the first move and its length/duration. So if you have comb enabled it will definitely mess up your retraction.. Also the tarvel after retaction value is only valid for fixed retraction.

cakeller98 commented 12 years ago

OK so, best solution - to regain previous speed is "use fixed retraction" until you have a solution? retraction only matters if you're leaving an island. therefore a comb that messes up the distance travelled is irrelavent, I think. In other words if the distance traveled OUT of an island, across a gap is longer than the desired distance, then retraction is needed. if you're running the head through an island there should be little to no effect from a little ooze. the ooze only matters (unless I'm wrong) is when that ooze happens LEAVING a wall... IOW crossing a wall moving from inside to outside, or vice versa. Where the ooze will show up. otherwise, I just don't think the ooze will show up too much.

Also - can you explain why there's a well needed? - as I understand it, we won't move until the retraction has completed? or is it that the retraction has completed, (at the filament drive, but you're doing this to wait for the OOZE to catch up?

either way, this solution just isn't working for me.

do you mean I should turn off comb, and use the retraction dwell you've got, and if I turn off comb, it will reduce the number of dwellings from 10000's to a few hundred?

or do you mean I should switch to fixed retraction when using comb?

or should I use a replace.csv line the remove the dwells

--- the dwells are just agonizing... just took a print that should have taken 10 minutes and dragged it out to 24 minutes+ this just isn't worth the microscopic improvement that I can't even see a difference for...

Thanks in advance for any advice you can give on how to resolve the issue I'm having with this... I don't want to have to revert to previous version, and I REALLY don't want to go back to SFORGE... :)

for what it's worth, I've been using the replace CSV to remove ALL dwells and the prints actually LOOK better? ;) go figure.

ahmetcemturan commented 12 years ago

I am working on it... Are you using relative E btw.. I(Rotorit actually) discovered a horrible bug with absolute E-distances...

cakeller98 commented 12 years ago

Im not using relative E distances. I've switched back to fixed retraction and using the replace.csv to commenet out the G4 Pxxx statements.

interesting... what's the bug?

ahmetcemturan commented 12 years ago

You shouldnt be able to use absolute e values even with fixed retract in some recent versions as it would output relative e no matter how the e distances are set. İ currently try to circumvent that problem by resetting extruder before and after retraction.

iPhone'umdan gönderildi

30 Kas 2011 tarihinde 17:18 saatinde, Christopher reply@reply.github.com şunları yazdı:

Im not using relative E distances. I've switched back to fixed retraction and using the replace.csv to commenet out the G4 Pxxx statements.

interesting... what's the bug?

Reply to this email directly or view it on GitHub: https://github.com/ahmetcemturan/SFACT/issues/13#issuecomment-2960916

cakeller98 commented 12 years ago

8^[___]

really?... Yikes, but that would explain some things... I haven't actually LOOKED at the output g-code so maybe it's all relative

So you suggest relative E ?

ahmetcemturan commented 12 years ago

Well yes, though there is a temporary fix in current daily.

iPhone'umdan gönderildi

30 Kas 2011 tarihinde 20:49 saatinde, Christopher reply@reply.github.com şunları yazdı:

8^[___]

really?... Yikes, but that would explain some things... I haven't actually LOOKED at the output g-code so maybe it's all relative

So you suggest relative E ?

Reply to this email directly or view it on GitHub: https://github.com/ahmetcemturan/SFACT/issues/13#issuecomment-2964219

cakeller98 commented 12 years ago

Wow dude!!! - latest version is (with relative E distances set, dwells to 0) - making parts that seem WAY more dimensionally accurate.

I've been having trouble with the,especially the bottom layer, being to bloomy... so parts are a bit too big - but hadn't been before. So it's not calibration settings... anyway - glad to have it seemingly much crisper now! :)