Project: Teacup Firmware

I do not want to hijack this thread but I have a question that it sounds like people here might be able to answer. I have put a direct drive extruder on my prusa with Sanguinololu running teacup and with the after setting a small amount of steps per meter of extrusion the stepper motor runs in large steps, very jittery, to the point of creating small bulges on the exterior of my parts. I have been running teacup for a long time with a geared extruder and the motor must have been running at a high enough RPM that it was never an issue. I have found when I lower any of my axis steppers to the same RPM as my extruder stepper they also become jittery.

Is this a code issue? I would like to run the direct drive extruder, but currently it is not producing good surface finish. Any input would be helpful.
Thanks
Dave

How much exactly is this "low steps per meter" setting?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

As I looked up the steps per meter number for the extruder I realized that it is very close to the number steps per of the x and y axis. The number that I am using for the extruded is 181486. I am not sure that this is the issue any longer.

I am using:
200 steps per revolution motor
1/32 stepper driver
10.35mm diameter drive pulley
1.75mm ABS (I add half the diameter of the filament to the drive pulley diameter in my calculation)

It seems very strange to me to have smooth motion on the x and y axis and jittery motion on the extruder when both are approximately the same number of steps.

I recently bought the 1/32 nd stepper driver to try to reduce the jitter feed from the original 1/16 stepper driver but the results are basically the same.

I attached a link to a video. It is not very clear but you can hear the motor oscillate on and off. I am starting to wonder if the sangunio chip does not have the processing power. (By the way I believe I am using a 644p chip)

[www.youtube.com]

If its processing power, you can reduce the processing power required by using less microstepping or reducing the feed rates or max feed rates.

A 100mm X0.4x0.6mm strand would need ~5.7mm of filament, so if all your axes are about 181486 steps/m, then a diagonal 100mm deposition would need about 26700 steps. With a max of 15kSteps/s (per [forums.reprap.org] ) -- you might run into max feed rate issues around 50\\xx mm/sec.

(I was curious about how the other firmware step rates compare to the 15kStep/sec. I noticed that Marlin has a MAX_STEP_RATE config of 40000 and handles that rate by limiting to 10000 interrupts/sec and doing 1, 2, or 4 steps per interrupt.)

edit: The Bresenham algorithm does its timing work based on the axis with the most steps, so although 26700 steps are needed on the combined x,y,e axes above, the lead x (or y) axis would only need 12832 steps while the x (or y) and e steps would piggyback on the lead axis. So max feed rate issues might kick in around 75-85mm/sec (4500-5000 mm/min)

Edited 1 time(s). Last edit at 03/02/2013 12:58AM by DaveX.

I was afraid that the processor was the problem but it raises a question.

Why do the x and y axis always run smoothly when they have the same number of steps per meter and are running at relatively the same rpm?

Thanks again

The only difference between the X and the E axis is feedrate calculation. The F keyword applies to X, Y and Z, but not to E. Is the issue still there when you move E and X at the same time? How does the extruder behave when you insert it into the X axis connector and do movements there?

On CPU exhaustion, step rate will suddenly go to a crawl and stay there, like 1 or 2 steps per second. Not like what's visible in the video.

Also, is it possible your stepper driver overheats? Overheats typically result in repeated half-second dropouts. On setting motor current, see [reprap.org]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Finally I found the time to move Cyberwizzards lookahead into Teacups main repository, Gen7 branch. It's turned off by default, but can be enabled by just uncommenting the feature in config.h. In case you have an older config.h already, you have to copy a number of #defines in the ACCELERATION section from one of the templates.

Two parts not moved (so far):

- Implementation of M141/M142/M143 (turn it on/off at runtime): IIRC, the G-code standard has a different code already, G64. G64 tells the controller about geometric tolerance when trying to maintain speed, which is pretty exactly what MAX_JERK is. G64 P0 would turn lookahead off. Have to look up this further.

- This implementation which does an emergency stop if one of the endstops is hit. For one, an emergency stop perhaps isn't the best way to handle the situation. More importatnly, though, endstops aren't as reliable as one might wish. Single triggers happen sometimes and some people would never finish a print with this behaviour. Third point is, endstop handling is already implemented for homing, even with debouncing, so this implementation should be used.

My testing showed me a clear improvement. Hard corners are moved by decelerating to zero as before, smooth corners maintain speed. What I'm not so sure about is, wether decelerating partially works, too. My suspicion is, corners are either moved full speed or full stop. Tried this with (very low) ACCELERATION = 10, but this apparently caused overflows; movements go to a crawl. Also, I can't see a difference between JERK = 10 and JERK = 1.

Does this look like a lot of ranting? U-oh, Traumflug, what are you writing?

The truth is, this patch is absolutely great! Did a number of dry runs and the printer runs a lot smoother, faster and just as glitchless as before. Congratulations, Cyberwizzard, great work!

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Cheers!

And the parts you left out were for my benefit only: the first few attempts caused skips and ran the axis into their ends so I needed a method to make sure the printer stopped at that point and the G-codes were picked randomly.

I've just pushed a commit to the Gen7 branch which moves endstop handling from the step interrupt to the clock based interrupt. As endstops are checked now "only" 500 times a second, the measured step rate[1] was raised by some 10% to 16600 steps/second (20 MHz electronics). That's 780 mm/min / 13 mm/s on a M8 rod driven axis at 1/8 microstepping or 24960 mm/min / 416 mm/s on a typical belt driven axis (40 steps/mm).

Also, the axis decelerates now properly and physically sane after an endstop stop. This means, the endstop is overshot by the deceleration distance (which is always the same distance). As the secondary, precision search of the endstops is done at very low speed, the difference to the previous behaviour shouldn't be more than a step or two. Might be even more precise, because debouncing takes now not 8 steps, but always 16 ms time. At 50 mm/min, 16 ms equal 0.013 mm, previously it was 8 steps = typically 0.2 mm.


[1] My standard test is setting maximum speed in config.h very high, then moving a single axis back and forth, 100 mm each time. This movement translates to 128'000 steps here, acceleration is 50 mm/s². Then, G1 feedrate is rised until step rate dropouts happen audibly (typically at the first steps of deceleration).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I like that test.

On Mar 28, 2013, at 12:48 PM, Traumflug wrote:

Quote

BTW., I think most other RepRap firmwares set an divider of 8 for the step interrupt, so timing is not entirely as accurate as with Teacup, but the 32 bit extension can be avoided. They then get maximum delays of (1 / F_CPU) * 65535 * 8 = 0.026 s = 26 ms. Translates to a minimum feedrate of 38 steps/second or 288 mm/min on a half-stepping, belt driven axis. With Teacup, I've done successful movements at F0.1 (for EDM) already.

So Teacup's step-timing capabilities are 1/F_CPU * 2^32 = 268s by 1/F_CPU=0.625us. That would translate to a comparable minimum feedrate of 0.0037 steps/sec, and with a 0.126mm/step machine: 0.00047 mm/sec or 0.028mm/min.

On the maximum rate side, I guess the 1/F_CPU = 0.625uS timer resolution translates into accuracy of the computation-limited step frequency. With the 32 bit timer, it is possible to do the ~15000 steps/second moves with 0.1% frequency accuracy, while the /8 divider would limit the frequency accuracy to 0.8%.

(cross-posted on [github.com])

I've been sloppily porting Teacup to a Teensy 3.0 (ARM, Cortex-4, mk20dx128, 48MHz or 96MHz) and have it compiling, blinking, and communicating, but I haven't yet connected it to hardware. The repository at [github.com] uses the compiler chain that PJRC packaged for Arduino, and the code there would likely have compilation issues on someone else's computer.

The Teensy 3.0's mk20dx128 (http://www.pjrc.com/teensy/datasheets.html) has 4 32 bit count-down timers, and 2 16 bit timers comparable to the &OCRxc timers. I used one of the countdown (periodic interrupt timers , PIT) timers for the clock interrupt, and one of the comparison timers (flexible timing module FTM) for the step timer. Maybe using another of the countdown timers would be better for the step timer, but, since I wasn't sure of how much setTimer needs to reset the clock, the FTM seemed more similar to Teacup's usage.

Edited 2 time(s). Last edit at 03/29/2013 11:02AM by DaveX.

ACCELERATION_CLOCK

The idea is to accelerate not on every single step, but "only" 500 times a second. Accordingly, acceleration maths is not only closer to your highschool physics text book, you should also have some 10 to 20 times more CPU cycles to do this math without bringing the ATmega to its knees. While all RepRap firmwares I'm aware of accelerate per step, the well known EMC/EMC2 does use clock based movement control, too.

You can find an implementation in Teacups accel_clock branch. To get it going, comment out ACCELERATION_RAMPING in config.h and add a ACCELERATION_CLOCK instead. Acceleration works fine, as well as constant speed movement. Deceleration is simply not yet done, because ...

... well, look at the description of the most recent commit of this branch: [github.com] For some reason I can't find, performance is below expectations. The only thing I'm pretty sure about is, it's not due to slow calculations in the interrupts.

Perhaps you have an idea? Debug code illustrating what happens is already in place.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Is the Teacup now under [github.com] instead of github [github.com]?

Quote

Is the Teacup now under [github.com] instead of github [github.com]?

Yes, as of today. Teacup changed ownership, unfortunately Github doesn't allow to keep the original URL in this process. I hope I can update all the references in the wiki soon.

To deal with this change, either throw the old repo away and clone a new one or edit .git/config and replace "triffid" with "Traumflug". There should be only one occurence.

Let me take this opportunity to say a big THANK YOU to Triffid Hunter and all the early hackers of Teacup Firmware. Somehow they managed to achieve code of excellent quality and quite a number of detail designs, for example the unlimited number of possible heaters, start to show their real value today.

- - -

That said, I just updated the accel_clock branch. It works now as a proof of concept. Timing calculations are still a bit inaccurate, so the end of deceleration doesn't always hit the geometrical end of the movement. You'll see a lot of "overshoot" and "undershoot" messages. Geometry should be accurate, though.

The advantage of this? Well, the possible step rate was raised. Formerly about 16'600 steps/second, now -- please try to hold your seat -- not 30'000 steps/s, not 40'000 steps/s, but a measured maximum step rate of no less than

48'000 steps per second! on an ATmega based electronics (Gen7, 20 MHz)

On a typical belt driven axis, this is more than 1200 mm/s. Even on an M8 rod driven axis you can achive now more than 18 mm/s, and that with 1/16 microstepping. Other firmwares can do 2 or 3 mm/s here. Yikes!

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Sounds cool.

Following Github's procedure, revising the your repository's 'origin' to point at the new URL would be:

git remote set-url origin [github.com] # 'origin'
git fetch origin

To add a local branch tracking the accel_clock branch:

git branch accel_clock origin/accel_clock

Thanks for the hard work... with acceleration it makes the choice harder for justifying the hardware for marlin, especially with having 328's just lying around...

Will that be the same for an arduino mega2560 with 16Mhz?

48k steps/sec sounds like really alot! if thats correct that its a great speed

this will be interesting to see what it does with my tb6560 drivers, whats the new pulse width if it had changed?

---

-=( blog )=- -=( thingiverse )=- -=( 3Dindustries )=- -=( Aluhotend - mostly metal hotend)=--=( Facebook )=-

Quote

Will that be the same for an arduino mega2560 with 16Mhz?

On 16 MHz these 48 kHz become 48 / 20 * 16 = 38'400 steps/second.

Quote

whats the new pulse width if it had changed?

You should get the same puls width over the entire move now, not longer ones during ac- or deceleration and shorter ones during the constant speed part. A rough guess is something like 10 microseconds per puls.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

sweet, i found with marlin the pulese were too short, so with some help i've now got a delay function in there and i can adjust the pulse width, it might say 30usec in the datahseets but in reality anything over 8usec is very usable , interestingly enough after i did that to marlin, the reapeatable resonance issue dissapeared is almost impossible to reproduce with the longer pulse width

---

-=( blog )=- -=( thingiverse )=- -=( 3Dindustries )=- -=( Aluhotend - mostly metal hotend)=--=( Facebook )=-

What about comport connection speed bottleneck? For currect firmwares it's not higher 250000baud. Thar's too slow for "high density" gcode and some of us are forced to print from sdcards for better prints.

karabas Wrote:
-------------------------------------------------------
> What about comport connection speed bottleneck?
> For currect firmwares it's not higher 250000baud.
> Thar's too slow for "high density" gcode and some
> of us are forced to print from sdcards for better
> prints.

I think that bottleneck is in the electronics rather than the firmware. Doesn't hardware with built-in USB chips, like the atmega32u4 on the Teensy 2.0 (and perhaps the at90usb1286 on the printrboard) ignore the baud rate and communicate at up to the full speed USB of 12Mbit/sec? With pronterface or pronsole, I can connect at "9600" to my Teensy2.0 and communicate with visually undetectable latency.

I simulated a PinkPantherWoman run in 47 minutes: Slic3r-ed at 0.4mm, 1000mm/sec into 155441 lines; with Teacup/accel_clock branch (but w/o ACCELERATION_CLOCK) on a 16MHz Teensy 2.0 configured with 10000mm/sec^2 acceleration, LOOKAHEAD, max feed rates of (X,Y,Z,E)=(152740, 152740, 5184, 12925) mm/min, (90% of 38400 steps/sec with my steps/meter); with Pronterface at "9600" baud though my USB.

I see lots of warnings that lookahead didn't have time to join the moves per [github.com] Maybe we should downgrade the error message to "//Warning: lookahead not fast enough\r\n".

Edited 1 time(s). Last edit at 04/02/2013 08:43PM by DaveX.

Quote
karabas
What about comport connection speed bottleneck? For currect firmwares it's not higher 250000baud. Thar's too slow for "high density" gcode and some of us are forced to print from sdcards for better prints.

I use 19200 baud and have to detectable latency due to the communication channel unless there are many, many very short moves. This is because it takes much longer for the printer to carry out the command than it does to send it.

Quote
DaveX
I think that bottleneck is in the electronics rather than the firmware. Doesn't hardware with built-in USB chips, like the atmega32u4 on the Teensy 2.0 (and perhaps the at90usb1286 on the printrboard) ignore the baud rate and communicate at up to the full speed USB of 12Mbit/sec? With pronterface or pronsole, I can connect at "9600" to my Teensy2.0 and communicate with visually undetectable latency.

Yes and No, the physical transmission occurs over USB but we are accessing this USB using a Virtual COM port so the software such as a terminal program, RepRap Host software actually uses the Windows API for serial communication.

---

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

Quote

With pronterface or pronsole, I can connect at "9600" to my Teensy2.0 and communicate with visually undetectable latency.

Visually undetectable means less that about 100ms, which is huge latency at 250KB.

---

[www.hydraraptor.blogspot.com]

nophead Wrote:
-------------------------------------------------------
> With pronterface or pronsole, I can connect at
> "9600" to my Teensy2.0 and communicate with
> visually undetectable latency.
>
> Visually undetectable means less that about 100ms,
> which is huge latency at 250KB.

Yep, my visual timing measurement is poor. Measured latency between successive no-op gcodes was less than 1ms/line.

A better test of the communication bottlenecks might be 1,000,000 blank lines:

   2,770 bytes/sec  Parsed by Teacup/Gen7 on a 16MHz Teensy 2.0
  72,674 bytes/sec  Parsed by a simple Arduino sketch that read and discarded single bytes out of the USB buffer 
 500,000 bytes/sec  Parsed by a simple Arduino sketch that flushes the USB buffer after receiving it.

For 1MB as 50K lines filled with 19 spaces and a newline, it is:

   23,809 bytes/sec  Parsed by Teacup/Gen7 on a 16MHz Teensy 2.0
   76,923 bytes/sec  Parsed by a simple Arduino sketch that read and discarded single bytes out of the USB buffer 
  500,000 bytes/sec  Parsed by a simple Arduino sketch that flushes the USB buffer after receiving it.

For 1MB as 50K lines filled with "G00X0", 14 spaces and a newline, it is:

   21,739 bytes/sec  Parsed by Teacup/Gen7 on a 16MHz Teensy 2.0
   76,923 bytes/sec  Parsed by a simple Arduino sketch that read and discarded single bytes out of the USB buffer 
  500,000 bytes/sec  Parsed by a simple Arduino sketch that flushes the USB buffer after receiving it.

USB seems to be capable of pushing 5,000,000 baud into this chip, but that is throttled to 384,000 baud as it is copied byte-wise from the USB buffer, and further throttled to 217,000 baud by parsing and processing no-op G-codes. It isn't the comms connection speed that is the bottleneck.


These tests were all using a Mac laptop with 'CoolTerm' as a sender.

Edited 2 time(s). Last edit at 04/03/2013 05:08PM by DaveX.

So it's all for Teensy boards. What about arduinos already in use? In my arduino 2560 - USB-to-serial mega8u feeds main chip via serial lines. F.e. with marlin I cannot go faster 250000. Is it possible to use teacap at all?

Quote

Is it possible to use teacap at all?

Huh? Of course Teacup works. It should even work with 250'000 baud, if you set that in config.h.

Regarding USB speed: at least V-USB is known to almost exhaust the CPU at 12 MHz, so you have still not much room at 16 or 20 MHz. Not sure how much of this work is done in hardware on the USB-equipped ATmegas.

The above tests (thank you for them) show, actually parsing the line slows down communications by just 10%. Not exactly much.

The USB protocol has quite some overhead. Unlike serial comms, just reading bytes isn't sufficient. The difference between Arduino and Teacup might be in the USB protocol implementation. The current one appears to be compact, but is it also fast?

Teacup reads characters in the main loop (from a buffer filled by an interrupt). Only a few lines of code, it should be simple to comment out gcode_parse_char() and clock().

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Is it possible to use teacap at all?
>
> Huh? Of course Teacup works. It should even work
> with 250'000 baud, if you set that in config.h.
>
>
> Regarding USB speed: at least V-USB is known to
> almost exhaust the CPU at 12 MHz, so you have
> still not much room at 16 or 20 MHz. Not sure how
> much of this work is done in hardware on the
> USB-equipped ATmegas.
>
> The above tests (thank you for them) show,
> actually parsing the line slows down
> communications by just 10%. Not exactly much.
>
> The USB protocol has quite some overhead. Unlike
> serial comms, just reading bytes isn't sufficient.
> The difference between Arduino and Teacup might be
> in the USB protocol implementation. The current
> one appears to be compact, but is it also fast?
>
> Teacup reads characters in the main loop (from a
> buffer filled by an interrupt). Only a few lines
> of code, it should be simple to comment out
> gcode_parse_char() and clock().

I think it's pretty fast. V-USB is working that hard for low-speed 1.5Mbit/sec USB. The difference in Arduino's FTDI vs an atmega32u4 or at90usb1286 is that the USB protocol is handled in either the FTDI chip hardware and bits are clocked into the AVR at AVR clock speeds, or handled within the usb-capable AVR chips with bytes are clocked out of the USB buffers at AVR clock speeds. Either way should be faster/more efficient than V-USB, but the hardware USB within the AVR should be capable of an additional speed up over FDTI.

Teacup's USB is based on the usb_serial stuff from [www.pjrc.com] stuff, which seems to benchmark at 800-1000kBytes/sec (or about 8,000,000 to 10,000,000 baud) out of the AVR and into the computer. That bnchmark depends on an (unused by Teacup) optimized usb_serial_write(char *, size) as in [github.com] There are some pointers to speeding up the transfer in the PC->AVR direction by writing a corresponding buffer-based usb_serial_read(char*, size) function in [forum.pjrc.com] -- Hooking a routine like that into Teacup's normal ring buffer should be fast, and probably overkill. If it would be symmetric, the comms bottlleneck could be widened to maybe 8,000,000 baud, far beyond the 217,000 baud I saw with the degenerate G-code.

I should try it again with longer and more complicated G-code, and with the parsing and clock handling commented out.

Hello everyone.
Could you point me to a firmware or modifications to be done in order to
make the gen7tm from maket city work?
I have enable on the drivers but step znd dir are not reacting to commands in pronterface.

I guess you have to ask the guy who designed this board and/or create a config template on your own. "Gen7TM" is different form Gen7, so I can't help much. Patches against the Gen7 or master branch of Teacup are welcome, of course.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks for the reply.
Of course I am communicating with the developer of the GEN7TM.
I finally moved the axis yesterday night, there is something in the driver circuit that I have to debug.
After I will make it work properly, maybe together with the actual developer of the board we will make a branch,
and post some information on the wiki...after I read how I should do this.

This is really a very easy DIY solution, and the drivers with TB6560 are cheaper at least for me to build and source.
I use a gen7 config file with minor modifications conform to what the maket-city said about inverting the enable line,
using only one enable line for all steppers and that is basically it.
Will be back with more progress soon.