Suggestions for SF42:)

Re: Suggestions for SF42:)

Dave Durant — Wed, 21 Sep 2011 09:28:06 -0400

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.

Re: Suggestions for SF42:)

ahmetcemturan — Wed, 21 Sep 2011 00:51:22 -0400

Dave, what does up different on the first layer?

Re: Suggestions for SF42:)

Dave Durant — Tue, 20 Sep 2011 23:52:20 -0400

> 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..

Re: Suggestions for SF42:)

Andrew Diehl — Tue, 20 Sep 2011 20:22:11 -0400

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..

Re: Suggestions for SF42:)

rhmorrison — Mon, 19 Sep 2011 13:48:51 -0400

Ahhh... Thanks for the clarification!

Re: Suggestions for SF42:)

Dave Durant — Mon, 19 Sep 2011 12:39:44 -0400

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..

Re: Suggestions for SF42:)

rhmorrison — Mon, 19 Sep 2011 05:05:33 -0400

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!

Re: Suggestions for SF42:)

Andrew Diehl — Sun, 18 Sep 2011 23:37:52 -0400

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

Re: Suggestions for SF42:)

BogyX — Fri, 16 Sep 2011 03:56:25 -0400

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

Re: Suggestions for SF42:)

ahmetcemturan — Wed, 14 Sep 2011 15:44:57 -0400

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.

Re: Suggestions for SF42:)

brnrd — Wed, 07 Sep 2011 10:04:46 -0400

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)

	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.

Re: Suggestions for SF42:)

ahmetcemturan — Wed, 07 Sep 2011 04:25:42 -0400

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...)

Re: Suggestions for SF42:)

brnrd — Tue, 06 Sep 2011 18:46:33 -0400

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.

Re: Suggestions for SF42:)

ahmetcemturan — Sat, 03 Sep 2011 16:14:27 -0400

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..)

Re: Suggestions for SF42:)

brnrd — Sat, 03 Sep 2011 07:13:04 -0400

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.

Re: Suggestions for SF42:)

ahmetcemturan — Mon, 29 Aug 2011 19:37:01 -0400

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..

Re: Suggestions for SF42:)

Lanthan — Fri, 26 Aug 2011 14:27:58 -0400

@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.

Re: Suggestions for SF42:)

ahmetcemturan — Thu, 25 Aug 2011 19:18:05 -0400

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

Re: Suggestions for SF42:)

Lanthan — Wed, 24 Aug 2011 05:13:32 -0400

@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.

Re: Suggestions for SF42:)

ahmetcemturan — Tue, 23 Aug 2011 04:09:42 -0400

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...

Re: Suggestions for SF42:)

Lanthan — Tue, 23 Aug 2011 02:44:24 -0400

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)

Re: Suggestions for SF42:)

Dave Durant — Sun, 21 Aug 2011 18:26:45 -0400

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.

Re: Suggestions for SF42:)

Dave Durant — Sun, 21 Aug 2011 18:23:48 -0400

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.

Re: Suggestions for SF42:)

DeuxVis — Sun, 21 Aug 2011 16:22:33 -0400

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

Re: Suggestions for SF42:)

Lanthan — Sun, 21 Aug 2011 16:13:05 -0400

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?

Re: Suggestions for SF42:)

ahmetcemturan — Thu, 18 Aug 2011 08:57:35 -0400

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. :SFACT 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...

Suggestions for SF42:)

Dave Durant — Tue, 16 Aug 2011 18:55:38 -0400

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! :)