Project: Teacup Firmware

A little coding session with schmelly not only fixed Teacup for electronics featuring a PSU pin as well as a common stepper enable pin, it also brought a bunch of other cleanups:

[github.com]

Most commits have multi line commit messages to explain the Why. Please test and cherry-pick them to master, if appropriate.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I've been working on some new MCode commands and I wanted to get some feedback on the ideas before submitting the changes on github.

Background: The new volumetric E control produced by Skienforge works really well. However, it requires that the GCODE be regenerated if you want to use a different filament that is a different diameter or that is a little harder or softer than that used when originally generated (this was also true before the volumetric functionality was added, but it is still not an ideal situation).

Proposal: Two new M codes.

M210 - E distance compensation
Parameter S - Sets the requested distance of a test extrusion.
Parameter P - Sets the actual distance of a test extrusion.

Setting S and P to the same value disables the compensation.

This is an attempt to move adjustments to the standard approach to computing the firmware steps/mm for the extruder out of the firmware compilation and into a user adjustable setting. An initial reasonable value must be set in the firmware when it is compiled, but modifications required to adjust for similar filaments can be made by the user without recompiling the firmware.

To determine the correct values for S and P for a particular filament (at a particular temp), disable E volume compensation (see below), disable E distance compensation, and run a test extrusion of a reasonably long distance (50-100mm). Then, measure the actual movement of the filament. Assuming the test extrusion is 50mm and the actual distance traveled is 40mm, send the command M210 S50 P40. The firmware will then scale all E axis movements by computing E(adjusted) = E(requested)*S/P, which should result in actual filament movement equaling requested filament movement. The setting remain in effect until an different M210 command is issued (or the firmware reset).

M211 - E volume compensation
Parameter S - Sets the diameter of the filament that was specified in Skienforge when the GCode was generated.
Parameter P - Sets the actual diameter of the filament as measured by the user.

Setting S and P to the same value disables volume compensation.

This compensation will scale all E distance requests such that the volume implied by the the requested distance will be delivered based on the change in radius of the filament. The calculation used is: E(adjusted) = (S/2)^2 * E(requested) / (P/2)^2. This adjustment is computed before the adjust made by M210.

---
Is this something that interests anyone? Any suggested changes to the behavior?

madscfi, glad there's something happening in this area.

However, Sprinter has a solution to this problem already: [reprap.org] . I like the Sprinter approach, as it keeps calculations on the PC. Your proposal should work, but it'll get confusing if the user doesn't get it right on the first attempt.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

M92 is really addressing a different problem, I think. While M92 could be used to make any/all needed adjustments for different filaments, it could also be used to adjust for GCODE that was generated in inches, but I don't think anyone would suggest using M92 in place of G20. I realize the comparison is not exact, but I do think the issues are strongly related.

I do agree, however, that the issue of needing to "get it correct the first time" is something of a problem, and part of the reason I posted the proposal before submitting a pull request. Maybe M210 should multiply the current adjust with the newly provided S and P parameters (rather than setting the adjustment) and a separate M command to clear the adjustment completely? To really simplify the process maybe there should be an M command that does a test extrusion, bypassing the M211 compensation automatically.

On the other hand if no one else is interested in the functionality then it is of no consequence anyway. Maybe a separate utility on the PC to help compute the adjustments, or inclusion in some of the client programs?

I see this as part of tweaking skeinforge/sfact settings. if the slicer is spitting out wrong values, the slicer needs to be adjusted. Adjusting in firmware just separates the problem from its actual source and gives mere symptomatic relief, like taking pseudoephedrine to reduce mucus production when you have a cold. I much prefer to tackle problems at their source, rather than giving the option to kludge downstream.

Having said that, the firmware does need a correct E_STEPS_PER_MM to a surprising degree of precision for good prints, and since that's actually a bona fide firmware setting implementing M92 would definitely help with tuning that properly.

---

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

I see the source of the problem a little differently. I view the E compensation functions much like the tool radius compensation codes (G41,G42,G43) of standard GCODE. The differences between filaments can be viewed as a parallel to the differences between worn tool bits. Skeinforge generates a plan specifying the placement of specific volumes of plastic (expressed as a length). The E compensation functions allow one to achieve the desired results given the available filament.

It also allows one to easily change to a different filament part way through a print using values that are directly associated with the problem at hand. My plan is to always run Skeinforge using a standardized filament diameter and then to always set the E compensation for the specific filament. Much faster and easier than running Skeinforge again, at least for me.

The utility of open source - at least I have the option of making the changes to a copy of the source.

Anyway, thanks to both of you for the feedback. It has helped clarify how I think the feature should work, even if no one else is interested in the feature.

I like the idea of not having to spend 45 minutes re-slicing a model if I want to print it with a different filament. And I have the habit of slicing a few hours a head of time then when it's time to print the filament is not always the same diameter as it was before using a few meters off the roll. So all and all I could see myself using it.

With that said it seems like we need Skeinforge to output a "V" value for volume and let the firmware do the conversion based on the diameter set via an Mcode. Instead of letting skeinforge convert the volume to distance.

---

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

Volume of a cylinder is: pi * h * r^2, so simply tell Skeinforge that the diameter of the filament is 2*(1/sqrt(pi)) (approximately 1.128379) and the values that Skeinforge outputs are volumes. Hopefully I've not messed up the algebra.

Actually, asking Skeinforge to output the diameter of the filament on which the distances are based as a M Code might be a good way to address the issue. It would also be backwards compatible with firmwares that don't have the ability to use volume based values.

Since the major Teacup programmers are not really interested in this feature any additional discussions do not really belong on this thread. Consequently, I've created a top level thread for any additional discussions of the feature.

Edited 2 time(s). Last edit at 08/07/2011 10:05PM by madscifi.

I was hoping you'd come up with situations where it would be useful

Varying plastics mid-print seems to be on the cards, and kliment's prusa M12 has a dual extruder carriage, and now that we're getting pretty good with extruders I think dual heads will start becoming more common.

Embedding plastic properties into a gcode file would help enormously with getting those to work, especially if you get skeinforge to deliver a pure volume.

Having said that, both these gcodes seem to operate on E, can we combine or rename them? I still think E_steps_per_mm should be either fixed (current head) or completely adjustable (M92), does that make your M210 redundant?

Perhaps we could change M211 to be called something more descriptive, since in a properly calibrated setup it's not a compensation at all, it's a conversion factor (from volume to distance).

I'll accept a pull request once we've sorted this out

---

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

Quote

And I have the habit of slicing a few hours a head of time then when it's time to print the filament is not always the same diameter as it was before using a few meters off the roll. So all and all I could see myself using it.

That's fine. Just stuff the right STEPS_PER_MM_E into the firmware before starting the print.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> And I have the habit of slicing a few hours a head
> of time then when it's time to print the filament
> is not always the same diameter as it was before
> using a few meters off the roll. So all and all I
> could see myself using it.
>
> That's fine. Just stuff the right STEPS_PER_MM_E
> into the firmware before starting the print.

It is set correct. It is set to move ten mm of filament when asked to move ten mm of filament. Because we are using Skeinforge 40 and newer we are talking about the volume of plastic ten mm is equal to. And that changes based on the assumed diameter of plastic which needs to be set during slicing right now. What we are proposing is to do that final conversion in the firmware. This would even allow you to use the same gcode for 1.75mm filament as used for 3mm and make the gcode more transferable between people the same way we share stl's.

---

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:
-------------------------------------------------------
> This would
> even allow you to use the same gcode for 1.75mm
> filament as used for 3mm and make the gcode more
> transferable between people the same way we share
> stl's.

If only it weren't for that pesky layer height...

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> If only it weren't for that pesky layer height...
>

Even then it's still plausible. I have noticed the norm was .4mm and now most people have moved down to either .33 or .25 which would allow some exchange to happen. Tip size would have to be within range for the layer height and w/t but as long as you can print at the layer height the file was sliced at you could use someone else's gcode file.

---

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

Hey Triffid

I'm trying to use an arduino mega1280 but I am getting this error:

dda.c: In function 'dda_start':
dda.c:412: error: 'AI012_WPORT' undeclared (first use in this function)
dda.c:412: error: (Each undeclared identifier is reported only once
dda.c:412: error: for each function it appears in.)
dda.c:412: error: 'AI012_PIN' undeclared (first use in this function)
dda.c: In function 'dda_step':
dda.c:464: error: 'DI07_WPORT' undeclared (first use in this function)
dda.c:464: error: 'DI07_PIN' undeclared (first use in this function) etc ..........

Can you help? It works on a few select pins but I need it on other pins.

Logan

lstu012 Wrote:
-------------------------------------------------------
> I'm trying to use an arduino mega1280 but I am
> getting this error:
>
> dda.c: In function 'dda_start':
> dda.c:412: error: 'AI012_WPORT' undeclared (first
> use in this function)

you need to use a font in which O (letter oh) and 0 (digit zero) look different. I do, and I could see your problem within a second of viewing your post!

A font in which 1Il| all look different is important too, and any other visually similar combinations.

---

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

Thanks Triffid, My Bad

Downloaded the latest version today after problems with an earlier. Unfortunately the problems are worse. Basically a G0 move can result the motors moving to nearly reach the destination and then virtually stopping. The pulse it too infrequent to show up on my scope (it's not a good one) but you can here the motor ticking and feel the motor very slowly pulsing. I have eliminated hardware problems by removing the motor drives and just looking at the pulses. This can also happen when backing off in the home command. But the point is that it doesn't always happen.
I have had to replace the
delay((uint32_t) (60.0 * 1000000.0 / STEPS_PER_MM_X / ((float) MAXIMUM_FEEDRATE_X)));
with a delay(150) which is what it evaluates to as having the formula in just produced a very high pitch noise.

I have ACCELERATION_RAMPING defined and also #define ACCELERATION 60.0

Also the M114 report position is wrong, it reports X=8.988 after I tell it to move to X=10. The Z is always zero no matter where I move it to.

I am using Gen 7 electronics with a 664

Any ideas?

Acceleration values should at least a few thousand, not 60

M114 has never worked properly for some reason.

Quote

Acceleration values should at least a few thousand, not 60

Works fine with 10 here.

Quote

I have had to replace the
delay((uint32_t) (60.0 * 1000000.0 / STEPS_PER_MM_X / ((float) MAXIMUM_FEEDRATE_X)));
with a delay(150) which is what it evaluates to as having the formula in just produced a very high pitch noise.

This is code from home.c, isn't it? This code is neither used for G0/G1 movements, nor does it acceleration. Even more, all the numbers are constant, so they're calculated once and forever at compile time. You've apparently "fixed" the firmware by some side effect.

What is your STEPS_PER_MM defined to? It's currently limited to about 500 due to calculation accuracy limitations (see UM_PER_STEP macro).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

A big thank you to modmaker, who provided a whole bunch of enhancements for Teacup. We couldn't agree on all of them (yet), still his name is dominant amoung the currently active committers: [github.com]

The most noteworthy of the enhancements is support for RAMPS v1.3 and (almost) it's ATmega 1280 chip.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I would like to start using Teacup (been using official fived) for my Gen3 vanilla setup (mb12 +ec22). Mostly because i would like to try the acceleration stuff.

Atm all seems to work allright, accelerations, managing both extruder and bed, etc. Havent printed anything yet, but probably will do so tomorrow. I tried the sdcard branch (although ofc sd doesnt work atm).

Fan doesnt work (wasnt really using it tho), and it seems i cant get my head to figure proper definitions in both extruder and master firmwares. Also maybe there is something with the M106/M107 parser, and i think it should also be able to pwm different voltages on the output although cant find that exact spec of g-code in the wiki.

The extruder seems a little faster now. I was using fived+pronterface, and now with teacup+pronterface with same settings seems like it is moving much faster in terms of speed although the pronterface speed button set is the same.
Edit: just realized it accelerates it.

Also i am just curious if the multi-extruder setup is actually working? Because it sounds tempting enough for me to try for a next machine.

Should i use another branch, like master or stable? Also any further tips? And btw, TY for this firmware

Edited 2 time(s). Last edit at 09/05/2011 04:04PM by NoobMan.

Quote

Fan doesnt work [...] and i think it should also be able to pwm different voltages on the output although cant find that exact spec of g-code in the wiki.

One way to get an adjustable fan is to define it as a heater with the just recently introduced TEMP_NONE dummy-sensor. Then you can run your fan with M104 S1 ... M104 S255 and turn it off with M104 S0. TEMP_NONE isn't reliable with M109 yet, I'll have to investigate that further.

Quote

Also i am just curious if the multi-extruder setup is actually working? Because it sounds tempting enough for me to try for a next machine.

There are no known issues, define as many extruders ( = heater/sensor pairs) as you want.

Quote

Should i use another branch, like master or stable?

The Gen7 branch has a few improvements regarding switching the power supply and using one common stepper enable pin. This will probably move to master, soon.

Quote

And btw, TY for this firmware

Thanks.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> One way to get an adjustable fan is to define it
> as a heater with the just recently introduced
> TEMP_NONE dummy-sensor. Then you can run your fan
> with M104 S1 ... M104 S255 and turn it off with
> M104 S0. TEMP_NONE isn't reliable with M109 yet,
> I'll have to investigate that further.

Teacup will happily accept a heater with no associated sensor, not sure if that's what TEMP_NONE does. May take some trickery with the changes to the config file that we've been making to "simplify" writing your config.

Then you can control it with M135 (heater set raw PWM). This won't work for regular heaters, because the temperature sensor loop will quickly overwrite the value you specify.

---

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

Hey guys,

my printer is sort of working now (thanks to Triffid for his great firmware). All axis are running, the end stops work (at least in my test program but they are not recognised by TeaCup) and the extruder works fine as well. At least during manual control - and here is the problem:
1. For some reason changing SEARCH_FEEDRATE_XX doesn't change anything. During printing neither MAXIMUM_FEEDRATE_XX nor SEARCH_FEEDRATE_XX seems to be used for speed control.
2. I can extrude ABS in good quality out of the nozzle in manual mode using the button in pronterface.py in the lower left - I can also change the mm/min and mm using the GUI for that. So extruder works. But when I run a GCode file the extruder only(!!) does E_STARTSTOP_STEPS but is not extruding anything!

I didn't wait until the end of a print, but I let it print thin air for a couple of minutes and there wasn't even an attempt to extrude anything out of the nozzle

Do you have any idea what might go wrong?


Thanks for reading!

Timo

ps. sorry for dubble post in your comment section. Just found this forum

If you are using Skeinforge to generate the gcode make sure you have Dimension turned on!

---

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

rhmorrison Wrote:
-------------------------------------------------------
> If you are using Skeinforge to generate the gcode
> make sure you have Dimension turned on!


In case its not default its definately turned off. I didn't dive into Skeinforge yet, I'll check that property as soon as I get home tomorrow!

Quote

During printing neither MAXIMUM_FEEDRATE_XX nor SEARCH_FEEDRATE_XX seems to be used for speed control.

It's designed that way. SEARCH_FEEDRATE is used for homing only. MAXIMUM_FEEDRATE is, well, the maximum feedrate allowed and also used for G0. If you have a max. feedrate of 2000 and send a F3000 command, axes will still travel with 2000 mm/min only.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks for your help guys!

After turning the Dimensions in Skeinforge on it is actually extruding now!
But about 1000% to much - and my STEPS_PER_MM_E is already at 1.2, and its also extruding additional tons of material while printing the base layers - while non of the three axis are moving - I hope its just a setting in Skeinforge, because I don't see any reason why my modified Teacup should behave like this.

Anyways, it seems I'll dive into Skeinforge tonight, make a little video of the stuff and post it. That makes it way easier to describe the remaining problems.

Edited 1 time(s). Last edit at 09/20/2011 08:01AM by Timo Birnschein.

Using Dimension, steps_per_mm should be for mm of filament entering the extruder, not extrudate leaving the extruder. Feed and flow rates in Skeinforge should be set to the same value.

I believe I found a bug with teacup.

While the Z (and possibly x and y) axis is homing, the extruder does not regulate temperature and leaves the heater in whatever state it was at when homing began. If homing is interrupted (like by disabling the steppers) the extruder can overheat.

If somebody has fixed this in the last month I apologize for bringing it up.