Teacup supported on Sanguinololu?

Is Teacup supported on Sanguinololu boards (1.3a)? I haven't seen any confirmation one way or another and it doesn't include a config.sanguinololu.h file. I ask because Sprinter has a bug that requires you to turn down the perimeter speed (http://forums.reprap.org/read.php?147,99606), and Marlin has bugs, period.

Pointedstick Wrote:
-------------------------------------------------------
> Is Teacup supported on Sanguinololu boards (1.3a)?
> I haven't seen any confirmation one way or another
> and it doesn't include a config.sanguinololu.h
> file. I ask because Sprinter has a bug that
> requires you to turn down the perimeter speed
> (http://forums.reprap.org/read.php?147,99606), and
> Marlin has bugs, period.


I have a Config for Sanguinololu for Teacup and use it on my Prusa. But it has the exact same results. Thats why I know about the other firmwares and their issues.

I will add the Config in a few minutes for you to download.

---

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

Thanks! If it has the same issues though, I'll just stick with Sprinter and wait for either the issue to be fixed, or Marlin to stabilize and mature.

Well I have to say I prefer Teacup hands down over Sprinter for many reasons.

Sanguinololu 1.1 config [forums.reprap.org]

Sanguinololu 1.2 config [forums.reprap.org]

You may need to change some pins for 1.3a. To use them just rename them to config.h and open it in Adruino IDE

The default acceleration is set waaaaay to low at 10. Raise it to 1000 or 1500 for great prints.

---

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

Quote

Well I have to say I prefer Teacup hands down over Sprinter for many reasons.

Sanguinololu 1.1 config
Sanguinololu 1.2 config

Thanks for the contribution, Sublime. I picked them up into Teacup's Github repository. Currently in the Gen7 branch, because there is support for a common stepper enable pin already.

... and I'd like to hear what you prefer on Teacup over Sprinter. Always thought Sprinter is a lot more in fashion.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Why I prefer Teacup.....

1) The config file. Its so clear and straight forward. (I'm not a programmer so sprinter is like looking at a foreign language)

2) Having the ability to have Zero in the Center. I know it seems inconsequential, but its really important to me.

3) Because zero is in the center I can use the software end stops and never bottom out any of the axis. ( No physical endstops )

4) The ability to change Microstepping easily.

5) Has Xon/Xoff which has given me 6 months of flawless communications through a terminal window. ( Only completed 1 out of every 20 builds using other methods )

6) The end user never has to make changes in any file other than the Config.

7) Default PID not Bang Bang

8) Maximum speed limits that are obeyed.

Reason why it not popular:

1) Every time the developers are asked if its ready they say NO. (but its more complete than Sprinter was when it was released as Carukip)

2) The default acceleration Value and recommended values. (they are far to low unless being used for milling)

Quote

Should say
usable value for milling is 10 - 100
usable value for RepRap is 500 - 2000
And set the default value 1000 (same as sprinter)

This would let people start with it working and they would not give up so fast.

3) Its not in a folder that Arduino can open without being re-named. (so confusing for a noob)

4) All the stuff in the folder that is not used when you upload it via the arduino environment SCARES people.

5) Most importantly is that people are scared of new stuff. ( nothing you/I/anyone can do about that one )

It doesn't hurt that I have been using Teacup since before Carukip was released.

---

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

As for the Branch the Sanguinololu are in.

I am using it with the master branch.

1.2 has Z enable on its own line and I have comments saying to only un-comment one of the axis enable pins because its common to all three axis.

1.1 is also commented similarly. ( I have a 1.1 with the Z enable re-routed )

Any reason why I should use the gen7 branch with combined enable pins?

---

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

Well, I tried and failed to Teacup working on my Sanguinololu. Let me list the things that were problematic:

1. the STEPS_PER_MM_ values for Z and E were totally wrong. Z was simply waaaay off and E assumed I was using 1/4 microstepping for the Extruder motor. ???
2. The MAXIMUM_FEEDRATE values are expressed in mm/min rather than mm/sec and are absurdly low for mm/min. For example, the default value of 200 for the X and Y axes translate to a maximum speed of 3.3 mm/sec.
3. One of the pin assignments in the config file checked into git was wrong; As per the Sanguinololu spec, Y_MIN_PIN should actually actually DIO19, not DIO16.
4. I couldn't figure out how to invert an axis for the purpose of homing. INVERT_DIR inverted my Y-axis for the purpose of movement, but it always homed in the same direction regardless of whether or not I inverted it in firmware.
5. Whenever I tried to Home X or Z, instead of moving the axis, all of my motors would turn on full power and screech until I cut the power.

I've gone back to the warm, safe comfort of Sprinter.

Pointedstick Wrote:
-------------------------------------------------------
> Well, I tried and failed to Teacup working on my
> Sanguinololu. Let me list the things that were
> problematic:
>
> 1. the STEPS_PER_MM_ values for Z and E were
> totally wrong. Z was simply waaaay off and E
> assumed I was using 1/4 microstepping for the
> Extruder motor. ???

You do have to configure it to your system!

> 2. The MAXIMUM_FEEDRATE values are expressed in
> mm/min rather than mm/sec and are absurdly low for
> mm/min. For example, the default value of 200 for
> the X and Y axes translate to a maximum speed of
> 3.3 mm/sec.

I agree that the defaults are way to low.
All RepRap firmwares I have seen are in mm/m

> 3. One of the pin assignments in the config file
> checked into git was wrong; As per the
> Sanguinololu spec, Y_MIN_PIN should actually
> actually DIO19, not DIO16.

My bad. @ Traumflug please update.

> 4. I couldn't figure out how to invert an axis for
> the purpose of homing. INVERT_DIR inverted my
> Y-axis for the purpose of movement, but it always
> homed in the same direction regardless of whether
> or not I inverted it in firmware.

> 5. Whenever I tried to Home X or Z, instead of
> moving the axis, all of my motors would turn on
> full power and screech until I cut the power.
>
> I've gone back to the warm, safe comfort of
> Sprinter.

This is because you were using G28 which is actually a command to go to home x0 y0 z0. (but most firmwares use it incorrectly)

G161 Find min endstop (home)
G162 Find max endstop (home)

These are the correct Gcodes to find home. (I don't even use endstops because Teacups software endstops work so well)

Edited 2 time(s). Last edit at 10/04/2011 12:22AM 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

Quote

Y_MIN_PIN should actually
> actually DIO19, not DIO16.

My bad. @ Traumflug please update.

Updated.

Quote

Any reason why I should use the gen7 branch with combined enable pins?

Because it's implemented properly there (I hope). I mean, the idea to #define just X_ENABLE_PIN and not the other ones isn't that bad. What does not work is to #define all Enable pins to the same pin.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

I mean, the idea to #define just X_ENABLE_PIN and not the other ones isn't that bad.

That said, I reviewed the code and ... this won't work for homing a non-X axis.

This probably changes when somebody (me?) finds the time to test queued homing implemented by bgamari.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> I mean, the idea to #define just X_ENABLE_PIN and
> not the other ones isn't that bad.
>
> That said, I reviewed the code and ... this won't
> work for homing a non-X axis.
>
> This probably changes when somebody (me?) finds
> the time to test queued homing implemented by
> bgamari.

Good to know. As I said before I do not use endstops so this has not come up yet. But I do have them installed on my recently finished Prusa and may want to use them eventually. When that time comes I will switch over to the gen7 branch.

---

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

Quote

2) The default acceleration Value and recommended values.

Done. See [github.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> 2) The default acceleration Value and recommended
> values.
>
> Done. See
> [github.com]
> 6e3860b8e609ed203f19191a1311020e98d8a6b9

That should help people get started.

And if you are updating things you may want to address "Pointedsticks" concern

Quote

> 2. The MAXIMUM_FEEDRATE values are
> absurdly low for mm/min. For example, the default
> value of 200 for the X and Y axes translate to a
> maximum speed of 3.3 mm/sec.

This is another one of those things that make people run back to their comfortable old firmware.

Edited 2 time(s). Last edit at 10/04/2011 02:41PM 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

What are safe values for belt driven axes? IMHO, rod driven axes are reasonably safe at 500 mm/min and can do something like 1200 mm/min.

The current estimate is, Teacup can do 25'000 steps/second, which translates to 625 mm/s or 37'500 mm/min with 1/16 microstepping on X & Y. Shall we set the default values there, so people never ever again complain Teacup is slow?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Good question?

I have run as high as 400mm/s, but never go above 200mm/s anymore. (limit set to 24,000)

Sprinters default feedrate seems high. Homing seems alright. (people rely on the gcode to limit the speed)

Quote
Sprinters defaults
float max_feedrate[] = {200000, 200000, 240, 500000};
float homing_feedrate[] = {1500,1500,120};

I would think 24,000 mm/m for X,Y would be a good starting value. It allows those who want to go fast to do so but still prevents excessive damage.

For Z I have mine at 90 mm/m but most people use the skeinforge limit plugin instead of the firmware limit.

And because E's max is used for the internal reversal it needs to be an actual max. Maybe 6000 mm/m

I personally use the limits and think more people should. So I would set some basic limits. But people are used to Sprinters defaults and it may make sense to set it to Teacups limit and let people use the Gcode to set the limits.

You may also want to put a large note mentioning the fact the default is relative extrusion in contrast to most other firmwares.

Edited 1 time(s). Last edit at 10/05/2011 06:04AM 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

All axes have to be real limits, as these values are used for G0 (rapid move). This reluctance of people to tune their firmware is ridiculous, 200'000 mm/min corresponds to 5'000 RPM of the motor, which none of the usual steppers can achieve even remotely.

I fear there is no sane solution until we have some PC-side setup application which allows KlickiBunti users to calibrate their thing.


Anyways, I've just moved all the enhancements from the Gen7 branch to master, so both branches are equal today. I'll continue development in the Gen7 branch.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> All axes have to be real limits, as these values
> are used for G0 (rapid move). This reluctance of
> people to tune their firmware is ridiculous.

This is something that very few people run into. Skeinforge does not create G0 moves, it creates G1 moves with a high feedrate in place of G0's. I myself have never seen a G0 in any code i've created.

---

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

It is more than 6 months since the last post, but hopefully someone is still following this thread.

I have a Sanguinololu 1.3a that basically works with current Sprinter and Proterface, but only sometimes prints anything (lots of 'Line number not equal last line +1', and 'Sumcheck Errors')

I downloaded the latest (05/04/12) Teacup_Firmware.zip, and work on the config.h (see attached). It compiled and loaded OK, also I can connect.

Heater temperature control works, but I cannot move or home any of the X, Y, or Z axis. Any ideas what is wrong?

I can't find an obvious error in your config.h. If you send M114 before and after sending a movement, does the reported position change? If yes, the stepping logic works.

Do you have a voltage meter handy? If so, please check wether the ENABLE pin on the Pololus (the leftmost in the bottom row) goes from 5V to 0V when a movement starts. You can also check the DIR pin (rightmost pin in the same row) wether it changes voltage on movement direction changes. The STEP pin is a bit more difficult, as it changes too fast for a voltage meter, still it should go above 0V when moving and go back to 0V after the movement is done. "movement" doesn't imply here your motors are actually turning, sending movement commands to the Sanguinololu is sufficient.

How about the E (extruder) axis? Does this one work? Without filament in the nozzle you can test this with an cold extruder, too.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Motion Problem solved. Bad solder joint on ATmage644P pin 20.

Is there some way to turn on automatic temperature updating for the Hotend and Bed when they are on?

Thanks for your tips. They got me looking in the right direction

Quote

Is there some way to turn on automatic temperature updating for the Hotend and Bed when they are on?

The usual procedure is to have a host which sends M105 repeatedly. If you want Teacup to send something on it's own, see line 42ff in clock.c. Any code in ifclock(clock_flag_1s) { } is executed once a second. temp_print(0) sends a temperature report, see also line 482ff in gcode_process.c (where M105 is handled).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I built a prusa and made the sanguinololu and put teacup on it. The sanguinololu seems very touchy when using replicator g. Is there a better interface?

I have had troubles with numerous things in the control panel
No bed thermostat reading (it has a good connection to called out pin)
Extruder stepper turns only in one direction regardless of direction chosen
Occasional large delay from command to action

Is it just not made to use replicator G?

What should I use as a g code creator? And what goes code commands the extruder to move?

I really want to make this work!

Thanks

Quote

I have had troubles with numerous things in the control panel
No bed thermostat reading (it has a good connection to called out pin)

What does a M105 send back? It should give you something like T: 23.0 B: 23.0. If one of both is zero, likely the wrong pin is configured.

Quote

Extruder stepper turns only in one direction regardless of direction chosen

By default, the extruder is configured to accept relative commands. So, to move it back, you have to send something like G1 E-5. There's M82/M83 to change that at runtime and E_ABSOULTE in config.h to change the default. Also, Skeinforge and slic3r have flags to produce either relative or absolute extruder commands. I have no stron opinion on which to prefer.

Quote

What should I use as a g code creator?

I think currently the best results are seen with Pronterface and slic3r.

Quote

And what goes code commands the extruder to move?

The extruder is the E axis, which works just like the other 3 axes.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY