Project: Teacup Firmware

Hi.
Is there are simple way to measure the actual distance traveled to endstop when command similar to G28Z is run? I'm trying to do (a kind of) pcb milling and need to probe the pcb surface to make a "height map" but stuck on determination of Z coordinate of the surface. Tried to use movestate.step_no etc. but no luck yet..

I am using recent code from git.

Do you hack the code already? The Bath group's G-code standard (other host software hackers apparently have different standards) has M117 for such operations. Implementing this would probably a good idea and allowing you to create this height map with a script sending/reading G-code.

Now, a variable holding the value of the last difference of each axis would go into machine_state in dda.h so you can read that when an M117 comes in.

The point to find the value would be line 760ff in dda.c, where and endtop stop is handled.

On finding out the current position, see update_current_position() at the end of the same file. It's move_state.x_steps/.y_steps/.z_steps.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi. Thanks for response.

Implementing M117 looks reasonable. Am I right that M117 reports current absolute coordinates in steps which are increased/decreased on each "step" timer tick (in dda_step())? If so, should I introduce 3 new uint32 variables for that or existing variables can be used? Can you please explain the meaning of z_counter and z_steps? It looks like both values are precalculated and so can't be used for measuring actual distance.

Quote

If so, should I introduce 3 new uint32 variables

Likely there's no way around this, as you have to read that value after a move, and perhaps a few another moves, have ended.

Quote

z_counter and z_steps

z_counter is the Bresenham counter. Each time it goes below zero a step is done. Not useful for your task.

move_state.z_steps is the number of remaining steps of a move. At the beginning of a move this is the same as dda->z_delta.

All you have to find the currently absolute position is dda->endpoint.Z, which is given in micrometers instead of steps. As a move has hit the endstop, you can compare the remaining steps to the remaining distance, to convert from micrometers to steps there is um_to_steps_z().

Another issue to consider is, for finding an endstop the endstop is checked twice. Once from a fast move into the endstop, once from a slow move out of the endstop. So you want to do the calculations only when moving out of the endstop. Well, except when SLOW_HOMING is set. See the code in home.c.

You can put debug messages into the interrupt to find out what's going on. Teacup's serial implementation will handle this fine, up to 64 characters per step. Watching each single step works on very slow movements only, of course.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi.

I implemented M117 command which can report current position in steps or reset these coordinates to zero. The patch is attached, it applies to commit 72185f77 without problems. I'm not 100% happy with the implementation as there are three new lines in dda_step() (though quite simple), which is somewhat time-critical.

This command indeed can be used to test repeatability of the machine. For example:

G28
M117XYZ	;reset internal coordinates

G1X100Y100F8000	;some move

G28	; go home
M117	; print coordinates
G28
M117
G28
M117

Here is a conversation:

> G28
< ok
> M117XYZ       ;reset internal coordinates
< ok X:0,Y:0,Z:0
> 
> G1X100Y100F8000       ;some move
< ok
> 
> G28   ; go home
< ok
> M117  ; print coordinates
< ok X:-10,Y:-23,Z:0
> G28
< ok
> M117
< ok X:2,Y:-1,Z:0
> G28
< ok
> M117
< ok X:0,Y:1,Z:0

Increasing ENDSTOP_STEPS improves accuracy significantly.

I have two more questions:

1. How to convert steps to micrometers to set startpoint.Z after z-probe (I should set correct z-coordinate after probing so that the following moves be correct)? I tried something like

dz_um = (dz_steps*((1000000L*100)/STEPS_PER_M_Z))/100;

Maybe there is a better way?

2. In which units MAXIMUM_FEEDRATE_* should be, mm/min? What is the purpose of the multiplication in the following code:

next_target.target.F = MAXIMUM_FEEDRATE_X * 2L;

I know that the correct feed rate will be computed later, but on my machine this causes (e.g.) G0X200Y200 to move (after short acceleration) very slowly with a strange sound. Moreover, using aforementioned M117, I can show that no step were loosed. Removing "*2L" solves the issue. I suspect, there is a overflow somewhere.

My config.h is also attached.

Thanks.

P.S. The speed issue may be related to my M117 implementation.

Edited 1 time(s). Last edit at 12/22/2011 02:49PM by Batalov Sergey.

Quote

In which units MAXIMUM_FEEDRATE_* should be, mm/min?

Yes.

Quote

move (after short acceleration) very slowly with a strange sound

Typical behaviour if you request a higher speed than the ATmega can deliver. Usual countermeasure is to reduce microstepping. Currently, Teacup can do about 15'000 steps/second on a 20MHz board.

I'm thrilled to see you have something working. I'll look into the details later, right now it's 2:30 AM here ... for now: thanks a lot.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi.

> Typical behaviour if you request a higher speed
> than the ATmega can deliver. Usual countermeasure
> is to reduce microstepping. Currently, Teacup can
> do about 15'000 steps/second on a 20MHz board.

That is possible, especially with my 16Mhz But strange thing is that G1X200Y200F9000, that is a controlled move at maximum feed rate MAXIMUM_FEEDRATE_X=MAXIMUM_FEEDRATE_X=9000, works fine, but G0X200Y200 tries to move faster than 9000 and so does not work as expected. I thought G0 in this case should move at min(MAX_FEED_X, MAX_FEED_Y)=9000, but it moves faster.. Or maybe G1F9000 moves slower? Can we be sure that G0 moves not faster than the given maximum feed rate?

Thanks.

A G1X200Y200F9000 is slower than a G0X200Y200 with maximum feedrates at 9000. Feedrate is calculated for all axes together, so you get about 9000/sqrt(2) = 6364 mm/min per axis. Maximum speed is calculated for each axis individually, so you get 9000 mm/min per axis and 12700 mm/min for both axes together.

You should do a few test moves for each axis individually, this overload limit is a pretty sharp edge. 5% more or less can make the difference.

It's also totally fine to have different limits for each axis. Teacup will handle it and always drive as fast as possible.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hey all,

any plans on implementing the look-ahead planner from the Marlin firmware into TeaCup? Or did I miss it and its allready there but I don't have the current version?

In my mind it would be a hugh enhancement and I would love to see it in TeaCup - since Marlin is, again, the Arduino IDE stuff and no real ANSI C...

Thanks,
Timo

Plans are almost as old as Teacup it's self :-)

If you want it, please do it. Everything is there, just provisions to start a move from non-zero speeds and a queue walker are needed. Instead of Marlin, I'd look into Grbl Firmware, the origins of Marlin's enhancements, instead, much nicer coding style.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Plans are almost as old as Teacup it's self :-)
>
> If you want it, please do it. Everything is there,
> just provisions to start a move from non-zero
> speeds and a queue walker are needed. Instead of
> Marlin, I'd look into Grbl Firmware, the origins
> of Marlin's enhancements, instead, much nicer
> coding style.

I know, I asked for it once before and I see your point. I was sort of hoping that you or Triffid could do the job way quicker than me, since you have the perfect overview on the code and I would have to dive into it quite thoroughly to do it right...

Anyways, my printer is printing at 130mm/s at the moment with a travel speed of 150mm/s on TeaCup. So I'm quite happy with TeaCup and I want to keep it! Just this one thing missing to make the firmware perfect

http://www.youtube.com/watch?v=HxgPlDg3WDo

Edited 1 time(s). Last edit at 12/27/2011 01:31PM by Timo Birnschein.

I updated to the latest version (as far as I can tell, GIT still manages to confuse me), and I've got a problem with the Z endstop. X and Y work fine. Instead of backing up the motor just stops and buzzes, as if it rapidly changes direction. Does anyone have an idea what to look for? I think I fixed all parts in my config.h that needed changing, like the mm to meter change.

Do slow G1 movements, like G1 Z5 F50 work? If yes, MAXIMUM_FEEDRATE_Z is too high.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks, that solved it! By the way, is it normal that X and Y homing have that slow acceleration?

Homing movements have the same acceleration as all other moves. The default acceleration is pretty low, though. I've heard of people using 1000 to 5000 mm/s²

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I think I've been able to compile the Teacup Firmware for the ATmega32U4 used in the $16/$19 [www.pjrc.com] USB development board.

I have a couple teensy boards lying around, and it looked like it would fit: 25 IO/11analog 7 PWM, USB, 32K.

There seem to be a couple significant differences with other ATmegas:

* Timer4 isn't a 16 bit & the registers are different, which complicates some PWM code
* The UART is named 1 rather than 0
* I had to add a arduino_teensy_atmega32U4.h and config.teensy-vdrf.h file

Since there is a lot of options for electronics out there, I was wondering what I could do with my junk box, and it seemed like I could breadboard a Teensy with a handful of Pololu drivers and have some USB compatible, modular, and reusable electronics for about $70.

Of course I could have tried the $24/$27 teensy++ which uses the AT90USB1286 which might already work well with Teacup and Sprinter.

Any suggestions?

Any suggestions? Has anyone breadboarded a Teensy or Teensy++ as their electronics?

Dave X Wrote:
-------------------------------------------------------
> I have a couple teensy boards lying around, and it
> looked like it would fit: 25 IO/11analog 7 PWM,
> USB, 32K.

Assuming 32k is enough for teacup and the LUFA usb<->serial library, you should be good. Beware of ram usage, we need at least a couple k unused for stack.

> There seem to be a couple significant differences
> with other ATmegas:
>
> * Timer4 isn't a 16 bit & the registers are
> different, which complicates some PWM code

remove or rewrite all the timer4 stuff, only timer1 is important

> * The UART is named 1 rather than 0

remove the uart stuff unless you plan to use dual usb/bluetooth or something like that

> Since there is a lot of options for electronics
> out there, I was wondering what I could do with my
> junk box, and it seemed like I could breadboard a
> Teensy with a handful of Pololu drivers and have
> some USB compatible, modular, and reusable
> electronics for about $70.

absolutely. I am still using my breadboarded electronics: front back.

---

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

Is there some trick for enabling the USB/LUFA serial code? It looks like the Makefile, for USB drops the serial.c code for USB-tagged architectures:

ifneq (,$(findstring usb,$(MCU_TARGET)))
LDFLAGS += -Llufa_serial
LIBS += -llufa_serial
SUBDIRS += lufa_serial
LIBDEPS += lufa_serial/liblufa_serial.a
else
SOURCES += serial.c
endif

It seems to compile and load onto the Teensy ATmega32U, but does not appear as a USB serial device on my Mac, and seems non-working.


It seems to link in the LUFA libraries, but it looks like it disables the serial communication functions I don't see how it actually enables communication over a USB serial port.

Teacup can work on a $19 Teensy ATmega32u4 over USB-serial 38400 baud:

ok FIRMWARE_NAME:Teacup FIRMWARE_URL:http%3A//github.com/triffid/Teacup_Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 TEMP_SENSOR_COUNT:2 HEATER_COUNT:2
ok 
ok X:0.763,Y:1.500,Z:2.237,E:0.000,F:50
ok X:1.000,Y:2.000,Z:3.000,E:0.000,F:50

A couple extra issues beyond those I put in a prior post:

1) One has to set the cpu speed the same in both Makefile and lufa_serial/makefile

2) In lufa_serial, use BOARD=USER and make empty Board/Joystick.h, Board/Buttons.h, and a Board/LEDs.h should be: #include "../LUFA/trunk/LUFA/Drivers/Board/TEENSY/LEDs.h"

3) 57600 seems too fast for Teensy: [pjrc.com] -- I got garbled M115 results at 57600 baud.


Now, I'll have to document what I hacked, and actually build myself some hardware.

I'm getting a hang after ~100-120 commands using Teacup, both with ReplicatorG and Pronterface. Is there a protocol change that I need to fix the host software for? The last thing it does is rewind the extruder a bit.

By the way, which acceleration option is recommended? Are all in active use, or is everyone using a specific type and others haven't been tested for a while?

With the change to steps per meter the value for E gets quite high. Do I have to worry about overflow?

And, with the current version, what is the maximum amount of micro-stepping recommended for Prusa Mendel mechanics? (In case my error is an over/underflow there)

Another thing: Would it still be worth writing a simple config tool for Teacup, or is the runtime config stuff almost finished?

Edited 4 time(s). Last edit at 01/16/2012 03:43AM by Jens_R.

Absolute E commands? Teacup stops working when this reaches 4300mm or something. Relative E commands work better.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

On a hunch I disabled Xon/Xoff, which seems to do the trick.
I'm using relative E commands already. I just remembered earlier warnings for microstepping on Z, which can cause problems generating enough interrupts. is that still a problem? Are there any checks that warn if step timings get to tight?

Quote

I just remembered earlier warnings for microstepping on Z, which can cause problems generating enough interrupts. is that still a problem?

This is gone since the move from STEPS_PER_MM to STEPS_PER_M.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
Absolute E commands? Teacup stops working when this reaches 4300mm or something. Relative E commands work better.

Most of the slicers have absolute extruder as the default now, they zero the E axis frequently. I find this actually works better during complex prints. If you have a lot of extremely tiny relative E moves, they can fall behind pretty quickly due to decimal rounding in the Gcode. If you have absolute moves, the precison of the tiny moves doesn't affect the final desired extruder position and the plastic gets extruded.

The maximum error due to relative extruder commands is 1 micrometer per move.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Am curious about why isn't E_ABSOLUTE activated by default (talking about config.h for gen7 here).

Nowadays tool chains all uses absolute extrusion by default as far as I know, and It seems it's a show stopper for people who ends up trying another firmware instead, moaning about teacup not working - I've posted a reply to a question in french spoken forum and 3 people immediately reckoned that it may have been the source of their problem and that they were going to give up on teacup because of that.

The symptom is having way too much extrusion, and especially a big blob of useless extrusion just before layer change, and it's maybe not easy for anyone to relate this with using or not absolute extrusion - myself deduced it because I have been reading a lot in the forums and this matter pop up from time to time, it just rang a bell.

---

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.

Absolute extrusion means if a requested E move is to small for the extruder stepper to take it gets added to the next move so you end up with material in the wrong place. People claim this is more accurate but it really just gives a total volume that is more accurate while placing the plastic in the wrong place. The only proper method is to use Relative which guarantees the material gets placed when and where it is needed. If you are printing tiny layer heights and short segments this can cause the extruder to not move with Relative because the requested moves are to short, but this just means you need to gear your extruder down lower (layer below 0.1mm and segments shorter than 0.1mm). I have an experimental 10.89:1 extruder just for this reason (3.3 times normal).

Edit: I wrote absolute when I meant Relative

Edited 1 time(s). Last edit at 02/11/2012 02:39AM 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

Absolute extrusion means if a requested E move is to small for the extruder stepper to take it gets added to the next move

This is true for relative E as well. The difference is just the rounding of the limited number of digits in the G-code. Also, Teacup accepts only three digits after the decimal and doesn't do rounding of the last digit, so the maximum error is 1 micrometer per move.

With this tiny error, absolute E is a bit pointless and in Teacup, absolute E overflows at about 4300 mm. When using absolute E with Teacup you have to make sure G-code resets E often enough to never reach these 4300 mm. Absolute E is one of these solutions for neglibile problems

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I'm still trying out different host software and slicers, and not too familiar with any of them yet. But I had so many problems with the ABSOLUTE_E setting being wrong for the slicer, so I implemented M82/M83 software configuration. I noticed these being generated by RepetierHost.

I think it needs a little cleanup (tabs/spaces), and it's not based directly on master, but this should cherry-pick cleanly:
M82/M83 in github

BTW - When ABSOLUTE_E is wrong, it does decidedly nasty things to the extruder. Yes, maybe it spills great blobs of goo sometimes, but other times it rewinds molten goo up into the extruder itself.

Dave X Wrote:
-------------------------------------------------------
> 3) 57600 seems too fast for Teensy:
> [pjrc.com] -- I got
> garbled M115 results at 57600 baud.

One can bypass lufa_serial and use the usb_serial_* routines from Teensy at [www.pjrc.com] and seems to get full speed USB communication. Pronterface at 250000 baud talks reliably to my modified Teacup on my Teensy's 16MHz ATMEGA32U4.

...still need to finish my hotend wiring. I'm fiddling with microstepping, steps per m, and trying to find the maximum feedrates.