TeaCup Maximum_Feedrate units

Hi,

The fastst my Z-Axis can move is 45mm/minute. This has been determined empirically by sending

G1 Zxx fyy

style commands. Where xx is the new position for the axis and yy is the feed rate. Anything with a feed rate of 47 or higher leaeves the Axis motionless and humming to itself.
So I set the maximum feed rate in TeaCup config to "40" to be on the safe side.

#define	MAXIMUM_FEEDRATE_Z		40

Yet, when I send a command with a feed rate faster than 40, it still tries to execute that feed rate. This includes the G0 command. When I send a

G0 Zxx

My Z-Axis is only sitting there humming to itself and the axis won't move. That is at least after the initial acceleration period where it's going at speeds it can handle.

I assume that the units for maximum feed rate are different from the units given in the "G1" command, but I don't know what it is and what to set it at. Any suggestions?

ST

Hi,

git checkout f555887eb58ca1ad

and see if it behaves better, there was a bunch of work done on the ramping algorithm after that commit and I'm having some issues with it too. If that works for you, I'll reset master to that commit.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

edit "Removed incorrect information as not confuse anyone with my ramblings"

Edited 2 time(s). Last edit at 06/03/2011 05:02PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Sublime Wrote:
-------------------------------------------------------
> The firmware is set in "mm per minute" not per
> second, But you send mm per second to control it.
>
> So you need to set your firmware to 40 x 60 =
> 2400

As far as I know, all the feedrates are mm/min throughout

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> As far as I know, all the feedrates are mm/min
> throughout

Sorry you are correct the Gcode lines are in mm/m. Its Skeinforge that are in mm/s which confused me.

Edited 2 time(s). Last edit at 06/03/2011 01:35PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Triffid_Hunter Wrote:
-------------------------------------------------------
> Hi, git checkout f555887eb58ca1ad and see if it
> behaves better, there was a bunch of work done on
> the ramping algorithm after that commit and I'm
> having some issues with it too. If that works for
> you, I'll reset master to that commit.

Hi,

I just opened "git bash" on my Win7 box and entered the following:

git checkout f555887eb58ca1ad

This gave me an error:

fatal: Not a git repository (or any of the parent directories): .git

So I went to the git webpage, went to the f55.......... branch (https://github.com/triffid/Teacup_Firmware/tree/f555887eb58ca1adcd1be0354eea434e4e71f6f9) and downloaded that ZIP.

Not sure if that was the right thing to do. Anyway, I added my config.h, compiled and ran it. No change. Z-Axis still accepts speeds in excess of 40mm/min.

And I found another problem for me:

E_STARTSTOP_STEPS			10000

has absolutely no effect. Maybe I'm giving the wrong commands, but I thought that any command involving an E-move should lead to a retraction and the next E-move should then forward by the same number of steps.

Any more ideas?

ST

What values are you using for STEPS_PER_MM_Z and MICROSTEPPING_Z? If the result of STEPS_PER_MM_Z*MICROSTEPPING_Z is greater than 1000 then Teacup will ignore the max setting.

madscifi Wrote:
-------------------------------------------------------
> What values are you using for STEPS_PER_MM_Z and
> MICROSTEPPING_Z? If the result of
> STEPS_PER_MM_Z*MICROSTEPPING_Z is greater than
> 1000 then Teacup will ignore the max setting.


Aaaaaah!

It's 395.98 and 8, So we're at approx. 2400 which is certainly more than 1000!
So all that's needed is to go to microstepping of 2 and be happy with a value of below 800.

Any idea on why my extruder isn't retracting?

ST

stefanst Wrote:
-------------------------------------------------------
> Any idea on why my extruder isn't retracting?

Does your gcode contain M101 and M103 words? we use those to trigger retraction and preload.

We don't yet the differences between moves at the moment, so we can't automagically decide when to retract and when not to just yet.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> stefanst Wrote:
> --------------------------------------------------
> -----
> > Any idea on why my extruder isn't retracting?
>
> Does your gcode contain M101 and M103 words? we
> use those to trigger retraction and preload.
>
> We don't yet the differences between moves at the
> moment, so we can't automagically decide when to
> retract and when not to just yet.


A clear case of "DOH!"
Somewhere in the wiki I read that M103 and M101 have been deprecated, so I spent some time in figuring out how to remove them from my gcode generated by SF. Turning them back on should be very easy.

Too late to try much more now, but more tomorrow!

ST

stefanst Wrote:
-------------------------------------------------------
> A clear case of "DOH!"
> Somewhere in the wiki I read that M103 and M101
> have been deprecated, so I spent some time in
> figuring out how to remove them from my gcode
> generated by SF. Turning them back on should be
> very easy.

Heh yep they are deprecated in favour of E words for actually running the extruder, however they provide an excellent indication of when skeinforge is about to stop extrusion, and when it's about to start. We probably could get this from the move queue... If the next move doesn't have an e_delta or hasn't arrived by the time we finish current move, retract... if we've retracted and the next move has an E word, preload...

Good to hear that we're chewing through your issues

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:

> Good to hear that we're chewing through your
> issues

I'm very glad myself. No pain - no gain! This has been the steepest learning curve in quite a while for me. But the support in the forums is absolutely outstanding. Now if just the documentation in the wiki were 10% as good as the forum support ;-)

stefanst Wrote:
-------------------------------------------------------
> Now if just the
> documentation in the wiki were 10% as good as the
> forum support ;-)

please, feel free to close that gap! I'm too close to the code to have the slightest idea of how the wiki could be more helpful.

And as sebastian bailard (our magnificent library gnome) keeps saying, as soon as you enter this community you're a developer, act like one! ;D

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Believe it or not, I was indeed planning on helping with the wiki. But at first I actually have to know what I'm doing. The only thing worse than no advise is bad advise!

Downloading the latest version of Teacup (b39a7b8) seems to have fixed the problem with the Z-Axis exceeding the max. allowed. So one down!
In the meantime I've been busy printing some upgrades.

On the M101 and M103 issue:
M101 seems to do what is asked of it - forwarding the filament a certain number of steps, however, M103 seems to do nothing. This is only confirmed with the version that was Master on 5/14/2011. Not sure about the version-number on that one. I haven't tried yet with the current version of Teacup.

Workaround: Use the Skeinforge "replace.csv" to Replace "M103" with "G1 E-2.0 F500" and "M101" with "G1 E1.7 F500". This works. It sucks back the filament before an "empty" move and forwards it thereafter. You may notice that retraction is 2.0mm and forwarding is 1.7mm. And that leads us to the whole issue of blobs.

BLOBS! THEY ARE EVERYWHERE! RUN FOR YOUR LIFE!

OK. Maybe I've watched too many 50s scifi movies

But on the subject of blobs:
Observations:

• Even with sucking back the filament before empty moves and pushing it forward thereafter I still get some blobbing at the locations where the empty moves start and end
• The blobs at the end of empty moves can benefit from advancing the filament less than retracting, but they are not gone completely. That may be fixable by advancing even less- haven't tried that yet.
• Every corner gets a blob. (see attached image)
• The corner blobs get slightly better with lower speeds but can't be completely abated.
• nozzle temperature (varied from 170 C to 210 C) does not seem to have significant impact

An attempt at an explanation:

• Pushing the filament at a certain speed out of the 0.5mm nozzle of the extruder requires a certain pressure in the molten part inside the hot-end
• This pressure is generated by fresh filament pushed into the hot end by the extruder motor
• Stopping the forward motion on the filament does not immediately reduce this interior pressure to zero, because some parts of the system are slightly compressible
• So even when we stop the filament, we still get material oozing out of the nozzle
• This material creates a blob whenever the nozzle comes to a standstill
• In theory we now have some material missing for the next move. However, this does seem to be easily compensated for over the length of the move

Possible fixes:

• Avoid nozzle standstill (easier said than done - I know)
• retract the filament at the end of every move and forward it again at the beginning of every move, but less. I should be able to try this by manually modifying the G-Code file. Will try tonight. But I think this will be too slow.
• Run the filament at a different speed-profile than the nozzle movement. Accelerate and decelerate faster than the nozzle. See attached graph.
• ....

or maybe I am doing something incredibly stupid and there is something I am overlooking that everybody else does, that takes care of this problem!

Short description of my setup:

• Wooden Mendel
• Wade's extruder
• Home built extruder hot-end using Peek insulator and resistor block heater. The whole thing is sleeved with a Teflon sleeve. The length of molten plastic is shorter than 20mm in the hot end. (At least that's what it looks like when I pull out the filament)
• Clear PLA 4043D from Ultimachine
• Home made electronics using Pololus and Atmel 1280
• Teacup using acceleration ramping
• Slicer: Skeinforge 41

Settings:

• Max FR X: 6000
• Max FR Y: 6000
• Max FR E: 1000
• acceleration: 400 mm/s^2
• Temp: 190C
• Speed in SF: 40/40

Thanks to everybody!

ST

Edited 2 time(s). Last edit at 06/06/2011 09:58AM by stefanst.

> Does your gcode contain M101 and M103 words? we
> use those to trigger retraction and preload.

This needs to be in the comments of the code in the config file right before E_STARTSTOP_STEPS

stefanst Wrote:
-------------------------------------------------------
>
> Workaround: Use the Skeinforge "replace.csv" to
> Replace "M103" with "G1 E-2.0 F500" and "M101"
> with "G1 E1.7 F500".

I'm seeing the same thing. I think your workaround is analogous to using the retraction settings on the SF40 Dimension plugin. I get exactly the same kind of start/stop behavior that I show here: [www.youtube.com]

I have E_STARTSTOP_STEPS set at 2000 with 16x microstepping and get lots of blobs/strings.

sliptonic Wrote:
> I'm seeing the same thing. I think your
> workaround is analogous to using the retraction
> settings on the SF40 Dimension plugin. I get
> exactly the same kind of start/stop behavior that
> I show here:
> [www.youtube.com]
>
> I have E_STARTSTOP_STEPS set at 2000 with 16x
> microstepping and get lots of blobs/strings.

I think you're correct - using the SF settings should do the same thing.

Looking at your axis movement, it does not seem that you are using Teacups acceleration ramping. With acceleration ramping you get a distinct start/stop behavior on the X- and Y axis that I have not seen on yours or other YouTube videos.

But your extruder seems to move extremely fast during those retraction/advance sequences. Maybe you can dial the speed down a bit? When I had my extruder up to max speed for the retract/advance it was losing steps.

Maybe I should switch to Acceleration RepRap style and see if that changes anything.

Is anybody currently using the acceleration ramping with PLA without blobs?

As I wrote earlier: It may very well be, that I'm on the completely wrong path here and I'm screwing up something else completely.

stefanst Wrote:
-------------------------------------------------------

> Looking at your axis movement, it does not seem
> that you are using Teacups acceleration ramping.
> With acceleration ramping you get a distinct
> start/stop behavior on the X- and Y axis that I
> have not seen on yours or other YouTube videos.
>
I'm using acceleration ramping but it's pretty steep. The ACCELERATION setting is at 6000
I can't remember if that video was before or after those configuration changes though.


> But your extruder seems to move extremely fast
> during those retraction/advance sequences. Maybe
> you can dial the speed down a bit? When I had my
> extruder up to max speed for the retract/advance
> it was losing steps.

Yes, I've since capped my extruder speed much lower so it doesn't turn that fast during retraction. I was trying to show that even with obscenely fast retraction settings (in skeinforge) Teacup was still pausing too long at each retraction and causing blobs. Other comments in this forum steered me away from Skeinforge retraction in favor of Teacup's firmware approach but I haven't got that working yet.

I've got a little list of 'Things I've learned about Teacup' going that I'll be happy to dump into the wiki once I get it going right.

First off I use commit f555887eb58ca1adcd1b because I could never get the newer one to produce a good print. And I only use PLA.

Second I have always had the m101 and m103 work in both direction but it did not actually reduce my bumps because it causes a small pause where it stops to retract which causes a BLOB. (my bowden takes 400 steps just to remove the slack in the filament which takes way to long)

Third I use Ramping and get almost flawless prints, even with a bowden cable extruder.

The key to getting smooth prints currently without the much needed constant minimum speed is to have your acceleration turned up faster. I use the old commit set at 37,500 (was 500,000) and when trying the newest commit I had to have it at 5000 (was 10) to get even close to the same prints. You also need a really fast travel rate while not extruding to insure no strings or blobs. And NO reversing anywhere because the ooze during that time is to much because of my 16" bowden cable.

My quality prints are done at:
50mm/s printing
25mm/s first layer
42.5mm.s outside layer
75mm/s travel rate



P.S. If my repstrap can do it so can your machine. I have four mystery mismatched motors, pulleys and belts all attached to a machine made out of scrap with hand tools.

Edited 2 time(s). Last edit at 06/06/2011 02:48PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Sublime:

this looks extremely nice. I would certainly be happy with results of this quality. I'll return to f555887eb58ca1adcd1b and use your settings and see if it helps improve matters. I may not be able to accelerate at the same levels you are using since my X-Axis is likely much heavier than yours.

What are you using for slicing?

Sublime Wrote:
-------------------------------------------------------
> First off I use commit f555887eb58ca1adcd1b
> because I could never get the newer one to produce
> a good print.

Could you describe what kind of problem you saw with newer commits?

> Second I have always had the m101 and m103 work in
> both direction but it did not actually reduce my
> bumps because it causes a small pause where it
> stops to retract which causes a BLOB. (my bowden
> takes 400 steps just to remove the slack in the
> filament which takes way to long)

Are you saying you use firmware retraction or not?


> My quality prints are done at:
> 50mm/s printing
> 25mm/s first layer
> 42.5mm.s outside layer
> 75mm/s travel rate
>

I'm at 40mm/s printing
40*.7 for perimeter.
60 mm/s travel (I can probably go faster and will try it)

The attached picture shows a print done with Teacup (beige) compared to a makerbot cupcake with a DC extruder and NO retraction (black). The black part has not been cleaned up at all. I'm getting very close with Teacup, but those strings and bumps gotta go.

I use Ben's replicatorG with SF39 to slice. I have a .4xxx mm nozzle and extrude at a super high 225degrees to achieve the high speeds (120mm/s max with slower acceleration setting of 60,000 but more blobs).

I am attaching the my latest repG/SF39 profile for you.

But I found the only way to avoid corrupt data was to use GTKterm to send the file using Xon/Xoff.

Quote
my config speed settings

/// used for G0 rapid moves and as a cap for all other feedrates
#define MAXIMUM_FEEDRATE_X 24000 // 400mm/s
#define MAXIMUM_FEEDRATE_Y 24000
#define MAXIMUM_FEEDRATE_Z 120 // 2mm/s
#define MAXIMUM_FEEDRATE_E 24000 // 400mm/s

/// used when searching endstops and as default feedrate
#define SEARCH_FEEDRATE_X 1800 // 30mm/s
#define SEARCH_FEEDRATE_Y 1800
#define SEARCH_FEEDRATE_Z 60
// no SEARCH_FEEDRATE_E, as E can't be searched

/// this is how many steps to suck back the filament by when we stop. set to zero to disable
#define E_STARTSTOP_STEPS 0 //400 = slack in bowden

#define ACCELERATION_RAMPING

/// how fast to accelerate when using ACCELERATION_RAMPING
/// smaller values give quicker acceleration
/// valid range = 1 to 8,000,000; 500,000 is a good starting point
#define ACCELERATION_STEEPNESS 37500 I would have it set at 35000 but I lose steps (faster is better)

I should also mention I lose steps on my Z stage if I move it more than about 20mm's because of the acceleration/speed.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

sliptonic Wrote:

> Could you describe what kind of problem you saw
> with newer commits?

I couldn't run it as fast.
I would have freeze ups when trying to change temps mid build. (Xon/Xoff)
I just couldn't get as smooth of finish.

> Are you saying you use firmware retraction or not?

Sorry that was confusing of me. I was using firmware retraction until two days ago when I realized I got far better prints with it off.

> The attached picture shows a print done with
> Teacup (beige) compared to a makerbot cupcake with
> a DC extruder and NO retraction (black). The
> black part has not been cleaned up at all. I'm
> getting very close with Teacup, but those strings
> and bumps gotta go.

I get some strings but they are where the the head ends up after the move not where it leaves from so they just pop off without any trouble.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

sliptonic Wrote:
-------------------------------------------------------

> The attached picture shows a print done with
> Teacup (beige) compared to a makerbot cupcake with
> a DC extruder and NO retraction (black). The
> black part has not been cleaned up at all. I'm
> getting very close with Teacup, but those strings
> and bumps gotta go.

Do you have Comb activated?
It really helps with certain stringing.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Sublime Wrote:
-------------------------------------------------------
> sliptonic Wrote:
> --------------------------------------------------
> -----
>
> > The attached picture shows a print done with
> > Teacup (beige) compared to a makerbot cupcake
> with
> > a DC extruder and NO retraction (black). The
> > black part has not been cleaned up at all. I'm
> > getting very close with Teacup, but those
> strings
> > and bumps gotta go.
>
> Do you have Comb activated?
> It really helps with certain stringing.

Funny you mention that.

I activated it this afternoon and it made a big difference. It didn't eliminate all the stringing, but made the print quality very comparable to the makerbot.

Thanks!

with more acceleration (850mm/s^2) I do get better results. Now I'm getting to the unfortunate point where my x and y could probably take some more acceleration but my Z-Axis really can't. Since the limiting of the Z-movement in the Teacup firmware still doesn't seem to work, no matter how I set things up, this is what's limiting my quality at this point. I'll try and crank up the current - see if that helps. The Z-stepper shouldn't really get hot during normal operation since it shuts off between steps.

Triffid:
How difficult would it be to implement separate acceleration values for the different axis?

But 40mm/s seems to be the limit for my extruder. Anything faster and quality seems to suffer.

stefanst Wrote:
-------------------------------------------------------
> Triffid:
> How difficult would it be to implement separate
> acceleration values for the different axis?

the code is already in soupcup, I just need to port it across at some point. I'm planning on working out how to implement a start/stop speed too so I can put all the math in at once.

Basically the way the math works is it figures out how far along the movement vector we are when each axis finishes accelerating, picks the furthest one, and works out the proper acceleration for all other axes so they all finish accelerating at the same point. Deceleration is basically the same except we work out how far from the end rather than the start.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
...
> the code is already in soupcup, I just need to
> port it across at some point. I'm planning on
> working out how to implement a start/stop speed
> too so I can put all the math in at once.
>
> Basically the way the math works is it figures out
> how far along the movement vector we are when each
> axis finishes accelerating, picks the furthest
> one, and works out the proper acceleration for all
> other axes so they all finish accelerating at the
> same point. Deceleration is basically the same
> except we work out how far from the end rather
> than the start.


Here you go mentioning Soupcup again! That is of course wetting my appetite. Is this at a stage where we can try it out? I'm always willing to assist with troubleshooting whatever will run on my hardware.

ST

stefanst Wrote:
-------------------------------------------------------
> Here you go mentioning Soupcup again! That is of
> course wetting my appetite. Is this at a stage
> where we can try it out? I'm always willing to
> assist with troubleshooting whatever will run on
> my hardware.

It's at the stage where it accepts gcode with a fairly generic parser, performs a lot of fancy math, performs a move, then chokes on the queue and refuses to talk anymore.

However since supporting anything smaller than a 1280 isn't a design goal (although it currently still fits on my '328 without SD support), we can take up lots more space to do things properly rather than finding sneaky dodgy ways to keep the size down so I think it has more promise than teacup in terms of portability to larger chips such as ARMs. Teacup will still be available for smaller chips, and with soupcup doing big stuff I may feel better about optimising some of teacup's features away completely to neaten things up.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware