Suggestions for SF42

Some random stuff..

- Cool slows down travel, I think it'd be nicer if it didn't. There's a thread around here somewhere about this where somebody modified it to (not) do this..

- Support feed/flow should obey Object First Layer modifiers on the platform. Currently, if support starts on the platform, it seems to print at normal object feed rate and support modified flow rate, which makes it very hard to get adhesion - it usually rips off

- It'd be nice if support density was split from interface density.

- The current nightly build eats my end.gcode commands to move up and away from the build. SF41 doesn't.

- A min travel distance before reversal kicks in would be nice. I think this might be in the nightly build but it either does not work (I still see retractions on <1mm moves when I set it to 3mm) or doesn't do what I think it should.

- If retraction isn't enabled, Dimension still includes 6 or so lines of gcode that have no effect - it should skip the extra gcode, if possible

- If Dimension\Absolute Distance is set, it'd be nicer to not reset E, which would avoid a frequent non-buffered G92 E0.

- Skirt is quite nice but I still don't always get a nice & primed extrusion.. Having multiple shells on skirt might be cool

That's it!

Dear Dave,
- Cool slows down travel,>> might be a good option.to disable that.

- Support feed/flow should obey Object First Layer modifiers: in SFACT you can give a direct Feedrate and set flow seperately

- It'd be nice if support density was split from interface density. : Does anyone use interface? what is it good for?

- A min travel distance before reversal kicks in would be nice. FACT has that

- Skirt is quite nice but I still don't always get a nice & primed extrusion.. Having multiple shells on skirt might be cool: Why not making it wider...

---

[github.com]

Cool slows down indeed, allowing to set a minimal time to be spent per layer, this seems to do a good job when printing small parts. What would be the the reason to want to suppress this feature?

Lanthan Wrote:
-------------------------------------------------------
> Cool slows down indeed, allowing to set a minimal
> time to be spent per layer, this seems to do a
> good job when printing small parts. What would be
> the the reason to want to suppress this feature?

Especially since you can choose to 1) use orbit instead of slow down or even 2) disable cool

Quote
ahmetcemturan
- Support feed/flow should obey Object First Layer modifiers: in SFACT you can give a direct Feedrate and set flow seperately

I'll have to check that out.. I've been avoiding yet another slicer but have been hearing nice things about sfact..

Quote
ahmetcemturan
- It'd be nice if support density was split from interface density. : Does anyone use interface? what is it good for?

When I do use a raft, not very often, I do also use interface..

Quote
ahmetcemturan
- A min travel distance before reversal kicks in would be nice. FACT has that

I think that may be coming in SF42, too. Maybe. Hope so..

Quote
ahmetcemturan
- Skirt is quite nice but I still don't always get a nice & primed extrusion.. Having multiple shells on skirt might be cool: Why not making it wider...

Wider would be fine, too.. And/or slower.

Lanthan Wrote:
-------------------------------------------------------
> Cool slows down indeed, allowing to set a minimal
> time to be spent per layer, this seems to do a
> good job when printing small parts. What would be
> the the reason to want to suppress this feature?

I was just saying that it shouldn't slow down travel moves.

I had a look at SFACT yesterday, some good clarifications all around, some yet to be done. Increases overall usability IMHO. Good job, Ahmetcemturan!
But several still-useful plugins dropped, for example unpause. Kindly request is to keep it in future SF42... (and SFACT)

Lanthan: I am open to suggestions.. when do you need unpause.. I never used/needed it?

And I have added a minimum feedrate even when slowing down so it does not print at 2 mm/sec spoiling the print...

---

[github.com]

@ahmetcenturan: Unpause, from what I understand, does some preventive acceleration when doing arcs.

This is supposed to keep hole diameters near their intended size. Acceleration is very visible.

From the code:

"The unpause script is based on the Shane Hathaway's patch to speed up a line segment to compensate for the delay of the microprocessor"
...
def getUnpausedMovement(self, distance, line, splitLine):
"Get an unpaused movement."
if distance <= 0.0:
return line
resultantReciprocal = 1.0 - self.delaySecond / distance * self.feedRateMinute / 60.0
resultantReciprocal = max(self.minimumSpeedUpReciprocal, resultantReciprocal)
return self.distanceFeedRate.getLineWithFeedRate(self.feedRateMinute / resultantReciprocal, line, splitLine)
...

I have it set at the default maximum speed of 1.3 base speed.

No I haven't scientifically tested by printing the same piece with/without unpause (yet).
But holes come pretty close of the intended sizes. Of course under 4 mm diameter like everybody I need to start non-linearly enlarging hole sizes to get them right.

Hi Dave,
I ahve included a minimum settable feedrate for times when cool is active...
That should do it. (It is momentariliy in the experimental branch only...)
Also ı revised the skin plugin. see pictures..:
[www.flickr.com] is faster and better IMHO

---

[github.com]

@Ahmetcemturan:

OK here's some fresh data on the unpause plugin. I printed two pieces with M3 holes, same SF42 settings, one with unpause enabled, the other with unpause disabled.
--------------
configuration.scad m3_diameter = 4 mm
measured hole diameter, unpause enabled = 3.92 - 4.02 mm
measured hole diameter, unpause disabled = 3.72 mm
-------

However, the shells around the hole look "better" without unpause (less sparse).

I'll try printing without it. Setting m3_diameter to 3.8 BTW.

There is the stretch plugin for that now.
As the problem that unpause is trying to solve is actually Firmware based I dont want to have that handled in gcode..

---

[github.com]

It seems to me that the problem is microcontroller, so it should be done in Skeinforge. The segment pause that unpause is trying to fix is due to the fact that the Arduino is not fast enough for our purpose. It cannot interpret G-code fast enough to keep the head moving without pausing when the segments get too short at high enough feed rates. But it seems that unpause was created before stepper motors were used on the extruder. Thus, it compensated for the Arduino by increasing the feed rate without changing the flow rate. But doesn't this still lead to segment pause? It only speeds up the head in between the pauses. I think that the correct way to deal with it is to slow down the feed rate, so that the time to move the head for the segment is equal to the minimum time that the Arduino takes to process the g-code. At the same time, the flow rate need to be slowed down proportionately.

On a related note, it also seems to me that acceleration is better done in Skeinforge instead of in the Arduino firmware. This way, the Arduino can use all it's processing power in interpreting the g-code, stepping the motors and controlling all the heaters. It just doesn't seem that the Arduino has the needed processing power to do acceleration calculations.

Edited 1 time(s). Last edit at 09/03/2011 07:14AM by brnrd.

Marlin Firmware does a gret job in accelerating, buffering commands, evaluating and "thinking ahead". If your extruder can handle it and you are satisfied with a bit less quality you could print with speeds up to 300mm/s. (with appropriate acceleration settings..)

---

[github.com]

How large is the buffer in Marlin? I think this would only work if the buffer size is larger than the number of short segments that's in the g-code. And there has to be enough long segments for the microcontroller to catch up. It would be nice if this can be implemented in Sprinter or Teacup.

At any rate, it would still be nice for Unpause to be corrected to slow down both feed and flow rates to eliminate segment pause when going around circles and arcs.

brnrd: I am going to look into that.. As I said: I never used unpause... And I only can get experience other than mine by contributions like yours...
If I find it useful I will add it back to SFACT: (does unpause have any settings that need to be tweaked or that should work differently..in the sense of SFACT.. asking to get a head start...)

---

[github.com]

I just tried unpause in SF 41 after reading this tread. I tested it by extruding a series of circles at 10, 20, 30, 40 and 50 mm diameter at different speeds. It didn't remove blobs due to segment pause as expected.

I looked into unpause.py and I figured out where to change it to slow down the feedrate so that the time to draw the segment is longer than the time the microcontroller takes to process a gcode line: the unpause Delay parameter. Here's the change:

	def getUnpausedMovement(self, distance, line, splitLine):
		"Get an unpaused movement."
		if distance <= 0.0:
			return line
		resultantReciprocal = 1.0 - self.delaySecond / distance * self.feedRateMinute / 60.0
		resultantReciprocal = max(self.minimumSpeedUpReciprocal, resultantReciprocal)
		return self.distanceFeedRate.getLineWithFeedRate(self.feedRateMinute / resultantReciprocal, line, splitLine)

to

	def getUnpausedMovement(self, distance, line, splitLine):
		"Get an unpaused movement."
		if distance <= 0.0:
			return line
		resultantReciprocal = self.delaySecond / distance * self.feedRateMinute / 60.0
		resultantReciprocal = max(1.0, resultantReciprocal)
		return self.distanceFeedRate.getLineWithFeedRate(self.feedRateMinute / resultantReciprocal, line, splitLine)

Note that the feed rate will be decreased if the time for the move is less than the unpause Delay parameter. I think this should do it. I'll try it today and report back.

This didn't work very well with large circles (10-50mm). For some reason, the circles are comprise of alternating short and long segments so the feed rate was changing too much. This resulted in more blobs at high feed rates.

Edited 2 time(s). Last edit at 09/07/2011 05:58PM by brnrd.

I will be updating on git daily now (working or not)

[github.com]

features:
14.9.2011

Main changes:
DIMENSION:Retraction handled differently.
Now the only variable is the Oozerate. SFACt automatically does retraction based on the duration of the move that it will do in

retracted state.
SPEED and INSET
Bridging:
Bridge settings are calculated automatically so that your extrusion xsection equals the nozzle-orifice x-section..
As it will not change the layer height it will alter the extrusion width to achieve that.
The default bridge feedrate is now referencing the perimeter feedrate.
Also the settings for bridge spacing in INSET is now calculated according to the newly calculated extrusion width of the bridge extrusion.
You can experiment with values from 1-2 for the spacing that should all give decent results. ı personally prefer closer to 2 and have set default accordingly.
RAFT:
Raft feed and flowrates are working now.
First layer travel feedrate now controls all travel moves..
EXPORT:
The export archiving commands have moved to the top menu. (>Analyze>Synopsis)
There is also an option for Gen3 users to have small gcode with their Z-commands on a seperate line (for faster Z moves)
If you get memory errors during skein disable skeiniso. (enabled by default)
For being able to open a preview lateron you should enable exporting penultimate gcode.
CARVE:Extra decimals range is now 2-6 with 4 as default. (needed for the finer printing possibilities..)
COOL: You can now specify a minimum feedrate so you dont end up having the printhead move at 2mm/s and ruining your top layer.
SKIN: Is calculating the flow correctly now. But a bug prevents the inner ring from being extruded when the extra perimeters
option in Fill is set to 1. (0 or more than one works without problems..)
Also I found that the option to prefer loops in INSET produces better result hence is set as default.

GENERAL:I also changed most of the broken links that were in the top menu.

Edited 1 time(s). Last edit at 09/14/2011 03:45PM by ahmetcemturan.

---

[github.com]

Is there any hope to see implementation of 2, 3 or more heads - extrudors?

I'm working on multiple extrudors design (wel I will in couple of weeks) an want to print colored parts with 3 extrudors.....
And yes - i know the limitations of STL files not containing color signature (at least not in most cases) - but 3 materials - one support and two for different parst done at once... can be done...

Regards
Bogdan

There ia already a way to use 2 extruders. That is what the (start/end support) gcode files are for.

That is NOT what the start/end gcode files are for and won't help with using dual extruders.
Dual extruders means using BOTH heads during the build NOT deciding which extruder to use BEFORE the print - that is a single extruder!

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

If one of the extruders is for putting down support material, there are support_start/support_end files that get included every time SF starts (and ends) a support section. I think these are probably what Andrew was referring to.

If the extra extruders are for different colors, that's a different story. People have done it but it involves slicing each color separately then merging the gcode files (adding toolhead change codes as necessary) afterwards, outside SF..

Ahhh... Thanks for the clarification!

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

Yes, that is what i was referring to.

I personally feel using dual extruders for support/build materials is more important than for colors. You may feel differently.

From a purely technical perspective, there are a lot of software/mechanical bugs that have yet to be discovered (which will be most easily remedied if we start with something simple like support material)





Dave Durant Wrote:
-------------------------------------------------------
> If one of the extruders is for putting down
> support material, there are
> support_start/support_end files that get included
> every time SF starts (and ends) a support section.
> I think these are probably what Andrew was
> referring to.
>
> If the extra extruders are for different colors,
> that's a different story. People have done it but
> it involves slicing each color separately then
> merging the gcode files (adding toolhead change
> codes as necessary) afterwards, outside SF..

> I personally feel using dual extruders for support/build materials is more important than for colors. You may feel differently.

I do indeed feel differently! That's ok, though - I respect your right to be wrong.

I've had good luck with SF and doing support structures with the print material but at lower density. It's be nice if the first layer of it was better, like I wished for up in the OP, but it does work..

Dave, what does up different on the first layer?

---

[github.com]

ahmetcemturan Wrote:
-------------------------------------------------------
> Dave, what does up different on the first layer?

For support structures? Basically it prints at the normal support settings, which can be hard to get stuck onto the platform.

What would be nicer is if support also factored in the Object First Layer settings into the support feed/flow or, even better, just ignored the support settings (on the first layer only!) and used normal 1st-layer perimeter settings for support structures.

Even on non-support structures, getting the first layer to stick properly can be tricky.. With support structures and their lower-than-normal-flow-at-the-same-feed, it's extra tricky. This, I think, would help.