Project: Teacup Firmware

I think this should be posted here, too. For the Github issue, see [github.com]

This extensive jerk calculation algorithm was and is a bit a thorn in my eye since I had a first look at GRBL and I thought a lot about getting this simplified. Here's the result of these considerations:

Foundation

There is no need for extensive trigonometry, because we can handle each axis individually. On Mendel-like printers even more than on traditional concepts, because moving the mass of the X axis doesn't influence moving the mass of the Y axis at all.

What we want to compute is actually not some complex corner angle <-> speed relationship, but the difference of speeds of each axis between two moves. Like:

vx1 = 400 mm/min, vx2 = 420 mm/min  ==> continue full speed
vx1 = 50 mm/min, vx2 = 600 mm/min ==> too much jerk ==> slow down

Math

What we want is (for each axis):

|v1 - v2| < max_jerk

In case this isn't satisfied, we can slow down by some factor x until the equitation is satisfied:

x * |v1 - v2| < max_jerk

Now computation is pretty straightforward:

     max_jerk
x = -----------
     |v1 - v2|

if x > 1: continue full speed
if x < 1: v = v_max * x

(Pseudo-)Code

max_speed_factor = 2 << 8;
for (i = 0; i < AXIS_NUM; i++) {
  factor = (max_jerk(i) / abs(v1(i) - v2(i))) << 8
  if (factor < max_speed_factor)
    max_speed_factor = factor;
}
if (max_speed_factor >= (1 << 8))
  f_corner = f_max;
else
  f_corner = (f_max * max_speed_factor) >> 8

What do you think? Will this work? Does this reflect physics?

The only issue I can find so far is, computing speeds of both moves for each individual axis requires no less than eight 32-bit divisions.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Teacups' experimental/development branch is no actually named "experimental". It was renamed from "Gen7".

To adjust your local repo before pulling:

git rename -m Gen7 experimental

To adjust after pulling, you can simply delete the Gen7 branch, but have to cherry-pick eventual local commits on top of this to the experimental branch, first.

Just introduced: support for the Sanguish electronics.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Another weekend of Teacup improvements.

The code in the accel_clock branch was very fast, but even with a lot of trying, I couldn't get it to work reliably. The approach was to calculate acceleration/deceleration ramps solely on the time passed. Worked for acceleration just fine, but the start of the deceleration ramps was often missed by several steps, sometimes causing the move to end with tens of steps at minimum speed or dropping half of the deceleration ramp. Our primitive maths is simply not accurate enough to predict the 500.000th step precisely to the microsecond.

Now there's yet another branch, accel_clock_step. Like accel_clock, it does speed calculations at regular time intervals, but not based on time, but based on the current position. The inv_int_sqrt() based acceleration maths contributed by @zuzuf helped a lot to do so. Works beautifully and thanks, @zuzuf.

Achieved speeds are around 42.500 steps/second! I guess Teacup is back on the throne of being the fastest firmware for ATmega-based electronics. Without dirty tricks, acceleration is still smooth, linear and matches physics.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Teacups' experimental/development branch is no
> actually named "experimental". It was renamed from
> "Gen7".
>
> To adjust your local repo before pulling:
> git rename -m Gen7 experimental

Git doesn't have a 'git rename' command. I think you mean this command:

git branch -m Gen7 experimental

Or something like that. It should be possible to train Git to switch over cleanly, but it's probably more cmdline noise than is worth posting here, plus it might not translate well to everyone's environment. If anyone needs help there, let me know.

Edited 1 time(s). Last edit at 10/22/2013 10:34AM by phord.

tl;dr - I merged the LOOKAHEAD code a few weeks ago and OMFG it was awesome! But slow homing is broken. So I merged again with this week's changes, but I wasn't not sure which branch to merge with. Wound up rebasing my changes onto one of the current tips, and printing went to sh!t because of accel/jerk issues. Dang. Looking forward to getting it working again. I still have my old branch(es) to fall back on and they are buttery smooth except for the homing issue.

Thanks to everyone for improving this beautiful functional firmware so far. And +1 for mainstreaming the LOOKAHEAD feature. I'm willing and able (sporadically) to help out on this code, so feel free to point me to an active lookahead branch if you want to collaborate. I'm really interested in reviving the simulator code. I heard someone had some PC-side code to test with recently. Maybe we can make that a full-fledged _thing_ again.

---

I got quite busy for the past year and I've let my printer get dusty. It was suffering multiple problems at once and I didn't have time to sort them all out.

Now things are twice as busy in my life at work as they were 10 months ago, and so I turn to my printer as a hobby/respite from the insanity. Strange how that works out.

I'm surprised to find most of my "problems" have gone away. Bravely Recklessly I merged the latest tip from Teacup in with my myriad little config changes. I hazarded the 'make upload' process. It worked! But things are out of tune again, for no apparent reason. So I re-tuned X, Y, Z and E -- to surprisingly different settings than they had before. Printed a calibration cube. Looks perfect. Experimenting with different slicers gives wildly different (and different than before) results. :-\ Slic3r gave me crap at first and crashed on my first few STL tests, but after some tuning is starting to look like the jewel everyone else thinks it is.

When I pulled in the LOOKAHEAD changes, something magical happened. My Prusa started making those musical noises like everyone else's printers do on the videos. It was truly a thing of beauty. >< I am used to my printer producing self-annihilating machine noises as it ramps up and down for every G-code. I tolerate it because it works reliably; but it's noisy, curiously fast and slow, depending on the activity, and doesn't tolerate slicer changes well.

My optical endstop tabs have never been aimed perfectly. Slamming into the endstops due to misalignment finished off 2 of my endstop mounts last month, so I disabled homing altogether and went back to manual startup. I finally replaced the endstop mounts and used mechanical endstop switches instead, since I needed to rebuild them anyway and I am disillusioned with optical tabs. When I turned the endstop-pins back on in the firmware, X and Y homing didn't work. After much fiddling about with settings and code tracing, I figured out that slow-homing is broken in the code I merged. Non-slow homing works, but is brutal since it accelerates into the endstops and then begins decelerating, far too late. Yikes! How is "slow" homing not the only acceptable version of homing?

I'm going to try working on this again for the next few weeks. Ping me if you think of something I can help with or if you have any suggestions; feel free to ignore me if you don't.

Phil ~ Prusa i1 w/ Gen7 1.3.1 electronics

Hi Phil, glad to see you chiming in.

Regarding look-ahead, there are currently three efforts:

- LOOKAHEAD on the experimental branch, done by Cyberwizzard.

- A rework of this on the "roland" branch, done by zuzuf. It measures start/stop speeds not in mm/min, but in motor steps. It also introduces some additional, very useful maths (zuzuf is apparently a math genius).

- A rework of both on the accel_clock_step branch (only half-done, by me). This moves acceleration calculations away from the step interrupt into a time based interrupt (every 2 milliseconds), making the step interrupt substantially smaller, allowing much higher step rates. The higher step rates work excellently already, but no connection to the look-ahead code, yet.

The unfortunate thing is, look-ahead doesn't work for myself so far. Maybe because I have very high steps/mm values (1280 on X, Y and Z). I hope I can get into this in the next few days.

Quote

Non-slow homing works, but is brutal since it accelerates into the endstops and then begins decelerating, far too late. Yikes! How is "slow" homing not the only acceptable version of homing?

Well, for obvious reasons you can't start decelerating before hitting the endstop. Accordingly you either have to stop brute force (which is what most firmwares do and causes a spike of high mechanical stress) or trust there's enough room to allow proper deceleration after hitting the stops.

Fast homing exists, because not everybody is as patient as you :-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Can i use Teacup on a atmega328 to drive a uln2003 darlington array and a unipolar stepper with normal step signals and not dir/step/enable?
with 2 or 4 wire control like this [arduinodiy.wordpress.com]

Thanks

Quote

Can i use Teacup on a atmega328 to drive a uln2003 darlington array and a unipolar stepper with normal step signals and not dir/step/enable?

An effort to run this exists, see graycode.c. Not sure about the status, but surely, Teacups' movement algorithms have proper abstraction. Abstraction on the preprocessor level, so it doesn't hurt performance.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Had a look at the file, but it does not make much sense for me, sadly :-( Any help?
Will try again when i get my uln2003 setup put together.

Today I couldn't resist and hacked a new corner/crossing speed algorithm for look-ahead in. Cyberwizzard and me developed the theory for it over the last few weeks: [github.com] The idea is, there is no XY-jerk, but jerk on the X axis and jerk on the Y axis. Matches physics closer than some complex trigonometric maths.

To test, simply pull/download the cross branch: [github.com] At line 155ff of dda_lookahead.c you'll see a number of new #defines. There's some debugging code in, which shows the relevant numbers. Also another test case with straight moves (see testcases folder). The nice thing is, you can now define individual jerk for each axis. If you want a full stop on each Z axis movement, simply define MAX_JERK_Z to 0. If you want to allow speed bumps of just 30 mm/min on the X axis, define MAX_JERK_X 30. If you define MAX_JERK the same as MAXIMUM_FEEDRATE, you'll never see a slowdown at corners.

config.h is so far unchanged, just #define LOOKAHEAD like before. To my delight, the code works very well.

Keen to read your results, please give it a ride.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi everyone.

I am using teacup on my gen 6 electronics to run a CNC mill but I am wanting to use the z output to drive a second motor on the y axis. Does anyone know I'd this can be done? Thanks

Quote

I am wanting to use the z output to drive a second motor on the y axis.

Likely you simply want to put both steppers onto the same stepper driver, like all the Prusa-Mendel printers do for the Z axis.

Another way to achieve this is to rewire the board and to connect both stepper driver signals to the same ATmega pin.

A software solution should be to add a z_step() to all occurrences of y_step() in dda.c. Similar for y_enable()/z_enable() if Gen6 happens to have separate enable signals for each stepper. That's not 100% accurate, but close enough.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote

I am wanting to use the z output to drive a second motor on the y axis.

Likely you simply want to put both steppers onto the same stepper driver, like all the Prusa-Mendel printers do for the Z axis.

Another way to achieve this is to rewire the board and to connect both stepper driver signals to the same ATmega pin.

A software solution should be to add a z_step() to all occurrences of y_step() in dda.c. Similar for y_enable()/z_enable() if Gen6 happens to have separate enable signals for each stepper. That's not 100% accurate, but close enough.

Thanks for that.

The only reason I wish to run the steppers on there own pins is because I the Y axis has a substantial amount of weight to it and with it being a CNC mill I could do with all of the power I can get.

I will give the software solution a go.

Wiring two stepper drivers to the same source pin should not cause any reduction in power. Driving two motors from one stepper driver would, though.

Quote
Traumflug

Quote

I am wanting to use the z output to drive a second motor on the y axis.

Likely you simply want to put both steppers onto the same stepper driver, like all the Prusa-Mendel printers do for the Z axis.

Another way to achieve this is to rewire the board and to connect both stepper driver signals to the same ATmega pin.

A software solution should be to add a z_step() to all occurrences of y_step() in dda.c. Similar for y_enable()/z_enable() if Gen6 happens to have separate enable signals for each stepper. That's not 100% accurate, but close enough.

I have tried doing this but the motor does nothing? Any idea what I have missed? Also, I am actually changing the E output, not Z.

I have changed the 2 instances of e_step() and the 1 instance of e_enable()

In addition to the above, would I need to change any of the pin settings, below is what they are at the moment....

/*
this is the official GEN6 reprap motherboard pinout
*/

#define X_STEP_PIN DIO15
#define X_DIR_PIN DIO18
#define X_MIN_PIN DIO20
//#define X_MAX_PIN xxxx
#define X_ENABLE_PIN DIO19
//#define X_INVERT_DIR
//#define X_INVERT_MIN
//#define X_INVERT_MAX
#define X_INVERT_ENABLE

#define Y_STEP_PIN DIO23
#define Y_DIR_PIN DIO22
#define Y_MIN_PIN DIO25
//#define Y_MAX_PIN xxxx
#define Y_ENABLE_PIN DIO24
//#define Y_INVERT_DIR
//#define Y_INVERT_MIN
//#define Y_INVERT_MAX
#define Y_INVERT_ENABLE

#define Z_STEP_PIN DIO27
#define Z_DIR_PIN DIO28
#define Z_MIN_PIN DIO30
//#define Z_MAX_PIN xxxx
#define Z_ENABLE_PIN DIO29
//#define Z_INVERT_DIR
//#define Z_INVERT_MIN
//#define Z_INVERT_MAX
#define Z_INVERT_ENABLE

#define E_STEP_PIN DIO4
#define E_DIR_PIN DIO2
#define E_ENABLE_PIN DIO3
//#define E_INVERT_DIR
#define E_INVERT_ENABLE

//#define PS_ON_PIN xxxx
//#define STEPPER_ENABLE_PIN xxxx
//#define STEPPER_INVERT_ENABLE


Thanks again

And my final development for the night...

I have got the stepper motor to work! However, it will only go one way? I.e. both motors take the Y axis back together, but when I press forward the stepper under E goes the wrong way?

Quote

it will only go one way

You have to do the same for the Dir pin. {x|y|z|e}_direction() in dda_start().

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug

Quote

it will only go one way

You have to do the same for the Dir pin. {x|y|z|e}_direction() in dda_start().

I have changed the following but with the same results?

/
void dda_start(DDA *dda) {
// called from interrupt context: keep it simple!
if ( ! dda->nullmove) {
// get ready to go
psu_timeout = 0;
if (dda->z_delta)
z_enable();
if (dda->endstop_check)
endstops_on();

// set direction outputs
x_direction(dda->x_direction);
y_direction(dda->y_direction); e_direction(dda->e_direction);
z_direction(dda->z_direction);

Quote

z_direction(dda->z_direction);

z_direction(dda->y_direction);

Notice the y? You want to move your Y axis, after all.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

With a few weeks of wrestling, I finally managed to get Teacup running in a simulator. Nice stuff, now you can attach a debugger, communicate as with real hardware and even get clock accurate traces of signals. For example, to verify new look-ahead algorithms.



This is the beginning of a G1 X20 Y10 F400. First two rows X axis, second two rows Y axis. Upper is the Step signal, lower the Dir signal.

You see step by step what happens. Like X accelerates and how Y follows. Excellent.

Instructions in the wiki, of course: [reprap.org]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks for the info, this is excellent.

I am trying it now. Installation of simulavr is straight forward and flawless by just following the wiki.

Now getting into trying the debugger section, I got this:
(gdb) load
Loading section .text, size 0x47fa lma 0x0
Loading section .data, size 0x3c lma 0x47fa
Loading section .eeprom, size 0x20 lma 0x8101000
Loading section .simimfo, size 0x28 lma 0x900000
WARNING: file cmd/gdbserver.cpp: line 961: Invalid memory address: 0x900000
Load failed

I am using Teacup simavr branch and have done any change at all other making the config.h and Thermistor.h from the existing template.
FInding it out what is the problem….

Quote

WARNING: file cmd/gdbserver.cpp: line 961: Invalid memory address: 0x900000

"Address 0x900000" sounds familiar? It's probably the one you asked the linker to put this SIMINFO stuff into. A warning you can safely ignore. Also the "Load failed" behind it. So far I couldn't find a way to tell gdb to ignore the SIMINFO section.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Paper chase (Schnitzeljagd) to find the best way of accurately displaying firmware doings: view every single step, timed precisely to the nanosecond. Two guys want to be the best, one by running Teacup right on the host (Teacup compiles on i386 just fine), the other one by running the original binary in a simulator. Now we can actually see what's exactly happening, guessing based on print results is a thing of the past:







To follow this chase: [github.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hey guys, Im sorry if this is the wrong place but as you can see, Im new here.

Ive been building a machine over the last year and have only recently learned about the Bucaneer 3D printer.

My machine uses a similar XY table config in order to use two steppers simultaneously on one belt. I thought that this would increase the max speed of XY since both steppers carry the load vs just one per one as in an gantry system.

The teacup firmware appeals to me since it is super small and appears to work really fast.

QUESTION: How can I go about configuring the firmware to work with the above mentioned XY setup? Im not really a strong programmer but do have some very limited experience. Any help will be very much appreciated!

Quote

How can I go about configuring the firmware to work with the above mentioned XY setup?

Please read 10 posts above: [forums.reprap.org]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Well, how to show how excellent Teacups' lookahead works now? Record a video of a running printer? How about technical details, the area where Teacup really shines? This is the same G-code shown in the picture a few posts above, now working precisely how university textbooks describe it:



Teacup runs like a swiss clockwork now, without or with lookahead. Enjoy!

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks for making this. Now I am trying Teacup and playing with the simulation.

When compiling the simulation on my mac book, the compiler complain about this kind of line: TARGET startpoint __attribute__ ((__section__ (".bss")))
It says that it needs comma separated, so then I change this line and others similar to something:
#ifdef SIMULATOR
#ifdef __MACH__
TARGET startpoint __attribute__ ((__section__ ("__DATA,.bss")));
#else
TARGET startpoint __attribute__ ((__section__ (".bss")));
#endif
#else
TARGET startpoint __attribute__ ((__section__ (".bss")));
#endif

Second thing, it does not accept on exit on the simulator/data_recorder.c, so I change this to:
#ifdef __MACH__
atexit((void *)recorder_close);
#else
on_exit(recorder_close, NULL);
#endif

Another issue is mac os does not recognize clock_gettime (in simulator/timer_ext.c). So after some googling I found a suggestion and add this:
+#ifdef __MACH__
+#include
+#define CLOCK_REALTIME 0
+#define CLOCK_MONOTONIC 0
+int clock_gettime(int clk_id, struct timespec *t){
+ mach_timebase_info_data_t timebase;
+ mach_timebase_info(&timebase);
+ uint64_t time;
+ time = mach_absolute_time();
+ double nseconds = ((double)time * (double)timebase.numer)/((double)timebase.denom);
+ double seconds = ((double)time * (double)timebase.numer)/((double)timebase.denom * 1e9);
+ t->tv_sec = seconds;
+ t->tv_nsec = nseconds;
+ return 0;
+}
+#else
#include
+#endif

Now the simulator is working fine. Last one I found is that the simulator seems to work with config.default.h config. When I used config for gen7 1.4, I just get flat line. I have not seen further … so not sure which one to change.

Another one though, on the real running firmware I am stuck with M116 as could never get the 'Temp achieved' after heating the extruder to a target temp and wait for it. I configure Teacup with both using extruder and heat bed. And apparently M116 expects both extruder and bed temp to be set to return 'Temp achieved' whereas I just only want to heat the extruder and leave the bed cool. Is this on purpose that we have to set both temp if configured to use both?

Quote
zungmann
When compiling the simulation on my mac book, the compiler complain about this kind of line: TARGET startpoint __attribute__ ((__section__ (".bss")))
It says that it needs comma separated, so then I change this line and others similar to something:

...

Quote
zungmann
Now the simulator is working fine.

Thanks for the patch. I think I have embodied all your fixes in this patch:

[github.com]

Also in the mac-simulator branch.

Can you try it and let me know if it works ok for you?

Quote
zungmann
Last one I found is that the simulator seems to work with config.default.h config. When I used config for gen7 1.4, I just get flat line. I have not seen further … so not sure which one to change.

The PIN settings in the configs should be ignored for the simulator (mostly) but I have not tested them all thoroughly. Can you explain a little more? I do not get a just a flat line when I tried it here just now.