Re: Project: Teacup Firmware
September 20, 2011 10:56PM
Andrew Diehl Wrote:
-------------------------------------------------------
> 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.

That would also be fixed by hooking homing into the DDA instead of the crude code we have now.

Perhaps, since noisy endstops seem to be a thing of the past, we can simply enable endstops all the time.

Traumflug, any comments on this, since you seem to be the lead teacup developer at the moment?


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: Project: Teacup Firmware
September 21, 2011 05:59AM
bgamari has done a pretty good patch to do that:

[github.com]

This implements queued home moves as well as debounced endstop checks during normal moves.

The only thing I'm wondering is, wether we need the endstop_check flag(s) in the queue. The idea to always check endstops isn't that bad, even if there is no disaster recovery in place. Also depends on how much this slows down the maximum feedrate, of course.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
September 21, 2011 08:06AM
I like the way sprinter handles endstops. It keeps track of actual position, so when the endstop condition is cleared we don't need to rehome, and the print can continue without interruption.

I've had wires come out of my electronics, or break, far more often than actually hitting an endstop during a print


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: Project: Teacup Firmware
September 21, 2011 04:05PM
Unless we ramp down when hitting an endstop, I'd expect to loose a few steps when stopping suddenly. The same when picking up full speed instantly as the condition is cleared.

Step loss aside, the following change should help:
if ((move_state.x_steps) && !endstop_stop) {
  move_state.x_counter -= dda->x_delta;
  if (move_state.x_counter < 0) {
    x_step();
to
if (move_state.x_steps) {
  move_state.x_counter -= dda->x_delta;
  if (move_state.x_counter < 0) {
    if ( ! endstop_stop)
      x_step();

I.e., run all counters as normal, but step outside the endstops only.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
September 21, 2011 06:06PM
Traumflug Wrote:
-------------------------------------------------------

> I.e., run all counters as normal, but step outside
> the endstops only.


Wouldn't that result in a lock situation where the printer is not able to get away from the endstop ever again during a print?
Re: Project: Teacup Firmware
September 21, 2011 11:15PM
we would of course tie the endstop condition flag to the direction the axis is moving in!


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: Project: Teacup Firmware
September 24, 2011 04:16PM
I have a configuration question / feature request:

I noticed that each vector starts and stops with a ramp. So when I print something like a belt pully I always print very short vectors and therefore at very slow speeds without any positive effect.
What I would expect is that the angle between the current and the next vector is checked every time a vector in beeing pulled from the queue and that the ramp is set according to this angle. For example when I want to print a circle, it does not need to ramp down at all. This would greatly improve speed and also quality because the extruder is not able to create blobs anymore and - more importantly - the belt deformation during deacceleration while ramping down would not affect the geometry of the circle. Because each time the machine ramps down quickly the belt is streched, no matter how tight you have your belt.

Maybe this function is allready implemented and I missed the checkbox in Skeinforge? Otherwise I'd very much like to see it in a future release - or I try to implement it myself and add a patch.
Re: Project: Teacup Firmware
September 27, 2011 08:49AM
Quote

checkbox in Skeinforge?

Skeinforge is out of the picture here. A firmware handles G-code, independently of how the G-code is generated.

Quote

I try to implement it myself and add a patch.

A few have tried already, the next step would be to teach the DDA to ramp up/down from/to non-zero speeds. The difficult part here is, we need independent target speeds for each axis, as moving around a corner always requires to move something rounded - which the currently implemented Bresenham algorithm doesn't support.

How an independent ramp for each axis nicely leads to smoothed corners can be seen here: [wiki.linuxcnc.org] . In this picture, ramp-down of one movement and ramp-up of the next movement is shown as "blend time"


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
September 27, 2011 11:38AM
I believe it could be sufficient to turn off ramps at all during curves below a certain angle from vector to vector and just go slightly slower than usual (add a parameter / factor for that). Ramp up and ramp down only happens at the beginning and end of a curve (angle threshold). That should be doable because main parts of ACCELERATION_REPRAP should be usable without any modifications.

What do you think?

EDIT:

I would suggest something like this:
- dda_create creates a new movement and sets all parameters to the regular values including acceleration but sets a flag that we only want to ramp down if the next vector surpasses a certain angle threshold
- let the vector ramp up like usual
- on the next dda_create - if the flag is set - set the feed rate of the current movemt to the last calculated feed rate (the one we just ramped up to)
- turn off ramps at all until a configurable angle between this and the next vector is found
- if so, turn ramps on again and let the next vector ramp down and remove the "no ramps" flag
- dda_create.... and so on

Edited 4 time(s). Last edit at 09/27/2011 05:28PM by Timo Birnschein.
Re: Project: Teacup Firmware
September 28, 2011 01:59AM
instead of a particular angle, we usually use a 'jerk' value- an instantaneous change in velocity on each axis. This is effectively used as a start/stop speed, as well as a blend value on curves. Any sharper curves must ramp to a velocity where the jerk isn't exceeded.

We can't just look at two adjacent moves either- in the case where we're going fast and a gentle curve ends in a sudden sharp corner (eg gregstruder around the bearing sockets) we may need to reduce the velocity of several previous moves in order to obey acceleration and jerk limits.


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: Project: Teacup Firmware
September 28, 2011 04:57AM
I see the problem... :/
Re: Project: Teacup Firmware
September 28, 2011 07:10AM
Just posting to say that Teacup runs nice with Gen 3 old electronics setup. Been running it for quite some time now and couldnt be happier. I hope to encourage others to use teacup with this ancient electronics setup. So far havent got the fan working via g-code, but have never really used fan anyway, and had a little work at start with config file, but was worth it.
Re: Project: Teacup Firmware
September 28, 2011 03:02PM
NoobMan Wrote:
-------------------------------------------------------
> Just posting to say that Teacup runs nice with Gen
> 3 old electronics setup. Been running it for quite
> some time now and couldnt be happier. I hope to
> encourage others to use teacup with this ancient
> electronics setup. So far havent got the fan
> working via g-code, but have never really used fan
> anyway, and had a little work at start with config
> file, but was worth it.


Can you tell us what you did to get it working? A lot of people want to use Teacup with Gen3 but they always have issues. Can you upload the config file or request a Git pull of it?


FFF Settings Calculator Gcode post processors Geometric Object Deposition Tool Blog
Tantillus.org Mini Printable Lathe How NOT to install a Pololu driver
Re: Project: Teacup Firmware
September 28, 2011 04:30PM
Hy smiling smiley Didnt had to change anything except config files. Thats fortunate, coz i wouldnt know how to change anything else. smiling smiley

I remember it took me a while to figure why it was appearing to move only one direction, and i had to change the endstops inverting status. I think defaults for gen3 were the other way around, and it was considering endstop is triggered and tried to get out. Also the thermistor table i basically used the same i had but multiplied last column x4, which i did with copy-paste special in excel.

- About reporting temps, i would say it seems to be less responsive than previous firmware i used, dunno why i have the impression, and i would change that if i knew how. Basically the reported temps had same rythm as meter thermocouple and with teacup they are sort of late. Not the levels, it sort of gets stabilized at same values, just takes more time to do that like maybe ~4-5 more seconds.
- The extruder firmware seems to work with bang-bang instead of pid, and what i would of liked to have in config.h, is a way to avoid compiling all that is not really used, like disable entirely that h-bridge stepper hack, e.g. choose to not use the board for motoring purposes at all (e.g. i use separate stepper driver from motherboard).
- Also its interesting that if the extruder board is powered off, then master keeps reporting the single last value over and over again, instead of reporting 0 or error. It doesnt really matter, since if we suppose the extruder board powers off then heaters are off aswell, motors too, so nothing bad could happen that way. It even could be said its better to keep reporting last value, as that one is probably closer to reality.

Edited 1 time(s). Last edit at 09/28/2011 04:35PM by NoobMan.
Attachments:
open | download - config.h.ec22 (2.2 KB)
open | download - ThermistorTable.h.ec22 (2.5 KB)
open | download - config.h.mb12 (20.8 KB)
Re: Project: Teacup Firmware
September 28, 2011 05:03PM
Is there a simple way to change the jerk value in the firmware? It would be cool if this was something that could be included in the config file to tinker with.

Triffid_Hunter Wrote:
-------------------------------------------------------
> instead of a particular angle, we usually use a
> 'jerk' value- an instantaneous change in velocity
> on each axis. This is effectively used as a
> start/stop speed, as well as a blend value on
> curves. Any sharper curves must ramp to a velocity
> where the jerk isn't exceeded.
>
> We can't just look at two adjacent moves either-
> in the case where we're going fast and a gentle
> curve ends in a sudden sharp corner (eg
> gregstruder around the bearing sockets) we may
> need to reduce the velocity of several previous
> moves in order to obey acceleration and jerk
> limits.
Re: Project: Teacup Firmware
September 28, 2011 05:54PM
Andrew Diehl Wrote:
-------------------------------------------------------
> Is there a simple way to change the jerk value in
> the firmware? It would be cool if this was
> something that could be included in the config
> file to tinker with.

not implemented yet unfortunately


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: Project: Teacup Firmware
October 07, 2011 03:39AM
So I have a couple of machines running teacup and one of them is running a very old build that still uses the old acceleration settings of 1 to 8,000,000 (set at 37500). I would like to update it to the current master and was wondering how to convert the old value to the new value of mm/s^2


FFF Settings Calculator Gcode post processors Geometric Object Deposition Tool Blog
Tantillus.org Mini Printable Lathe How NOT to install a Pololu driver
Re: Project: Teacup Firmware
October 07, 2011 04:47AM
These old values were just "something". You probably have to find out the new values by experimenting.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
October 09, 2011 04:42PM
An experience tidbit here:

On Friday I readjusted the nuts on the threaded rods of my WolfStrap to have less play. Worked beautifully and, while slightly more touque is required, all axes ran from end to end without glitch.

Then ran a Gen7 boards and - boooo - the WolfStrap had step losses. Not much, perhaps 3 out of 10'000 G0's didn't get as far as required. A single bunch of lost steps hoses the whole board, of course. A lot of back and forth followed, uploading older Teacup revisions, injection of debug printf()'s, whatever. As a Teacup developer I suspected a bug, of course.

The result is, at a few very unfortunate angles, the maximum rpm of the stepper motors is a lot lower than usual, because of this bresenham jitter. Well, apparently. Here's a G-code snippet which appears to be quite sensible. STEPS_PER_MM_X = STEPS_PER_MM_Y = 320.000, G0 equals to F500 or 400 RPM of the stepper (which is quite a bit)
G1 X68.03565 Y79.74415 Z-0.20 F200
G0 Z1.
G0 X72.98066 Y75.02701

Once found, solutions include raising current on the Pololus, lowering the axes' maximum speed or using a different microstepping on X and Y.


... which reminds me, we need ACCELERATION_TEMPORAL back ...


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
October 11, 2011 04:04PM
In dda.c, dda_step(), around line 660, there is a stray cli():
...
		z_disable();
	}

	cli();

	#ifdef ACCELERATION_RAMPING
...

Is there a specific reason for this or might this be a leftover from when setTimer() wasn't equipped with it's own cli()'s yet? It looks like this pretty much prohibits interrupts while a movement is in progress.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
October 11, 2011 06:34PM
if I recall correctly that was intended to protect the timer variables during setTimer(), and between setTimer() and rti.

The step interrupt is re-enabled during setTimer(), so if we're running /really/ fast, we might trigger between there and rti. We absolutely do not want to re-enter the step interrupt before returning from it, or we will definitely end up smashing our stack!

If code has changed around it, there may be a more suitable place now.


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: Project: Teacup Firmware
October 11, 2011 11:10PM
Although setTimer contains a cli, it restores the interrupt state via SREG rather than simply enabling interrupts as it can be called from both inside and outside of an interrupt. I'm pretty sure that cli in dda_step should be inside of a

#if STEP_INTERRUPT_INTERRUPTIBLE
#endif

conditional, as it is only needed when running under the interruptible configuration. However, in that configuration is really is needed just before the call to setTimer.
Re: Project: Teacup Firmware
October 12, 2011 06:26AM
Thanks. So I tried with and without this cli() and it doesn't make a difference. At 2560 steps/mm (Z axis, 1/16 microstepping), I can achieve 366 mm/min on the 20MHz Gen7. Enabling STEP_INTERRUPT_INTERRUPTIBLE slows this down slightly to 365 mm/min. Test movement is 50 mm, shorter movements can be a bit faster.

Overspeed results in sudden slowdown, apparently an interrupt flood. Geometry is kept accurate, though, and stepping picks up normally as soon as ramp down is reached.

This translates to 15'570 steps/second or 1280 CPU cycles per step. Let's see how this develops in the future.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
October 12, 2011 10:48PM
"Needed," in this case, is not something that can be demonstrated by simple testing. If interrupts are enabled between the return of setTimer and the return of the interrupt invoking daa_step, then it is possible for an different interrupt to delay the return from interrupt. If this turns out to be long enough that the step interrupt fires again then you've taken the first step toward smashing the stack.

It is possible that the cli is not necessary. However, in order to know that one would have to spend a lot of time analyzing the worst case scenario with multiple interrupts firing at the wrong time. It is much easier to simply leave the cli (confined to the STEP_INTERRUPT_INTERRUPTIBLE case) in the code then it would be to track down a rarely occurring crash at some point in the future. I'd argue that the cli should be left in even if a careful analysis showed it was not needed at the moment - the use of another interrupt at some point in the future might well break the code and it would probably not be an easy bug to find.
Re: Project: Teacup Firmware
October 23, 2011 02:14PM
This week's Teacup updates, uploaded just a minute ago:

-- moved the new endstop handling (thanks to Ben Gamari) from the Gen7 branch to the master branch.

Homing movements are now queued, just like any other movement. One of the effects is, homing movements are now accelerated (but not decelerated).

Another one is, we have now endstop handling with normal movements, it's just unused so far. There is still no plausible strategy to recover a print from hitting the endstop.

A third effect is, homing more than one axis simultanuously is a lot easier to implement now. Please volunteer smiling smiley


-- New in the Gen7 branch is the move from handling distances in steps to handling distances in micrometers.

This allows for up to 4096 steps/mm and accordingly 1/16 microstepping on threaded rod axes.

I still recognize when I uploaded a similar patch a few weeks ago and was asked to go away with that. This time it's even more tested and (of course) the patch-to-the-patch to avoid accumulating rounding errors is included. I've milled several boards with this, with different microsteppings, and it works beautifully. So, if you experience trouble again, we should fix the trouble instead of rejecting the entire thing.

One unavoidable drawback is, steps/mm are now steps/m in config.h. Same number, just multiplied by 1000 and without decimal. When using the Gen7 branch, please review your config.h in this area and compare it to the standard ones. The compiler will remind you, if you forget this.

Edited 1 time(s). Last edit at 10/23/2011 02:24PM by Traumflug.


Generation 7 Electronics Teacup Firmware RepRap DIY
     
Re: Project: Teacup Firmware
October 27, 2011 11:25AM
I've tried a couple of times but I've never been successful in running my Mendel with RAMPS 1.2 with Teacup. One problem that I have is that I just can't get to all the source codes when I open it in Arduino. There's not enough horizontal room to show all the tabs and not enough vertical room to show all the popup menu since there are so many files. Excuse me if this is in a wiki somewhere, but how do people do it.

Also, I don't understand why everyone that writes a firmware need to change the thermistor table format. smiling smiley
Re: Project: Teacup Firmware
October 27, 2011 05:14PM
Traumflug Wrote:
-------------------------------------------------------
> Another one is, we have now endstop handling with
> normal movements, it's just unused so far. There
> is still no plausible strategy to recover a print
> from hitting the endstop.

I'm thinking the print should be paused if any end stop is tripped. Maybe even turn off the heaters and raise the extruder. An error should probably be reported to the host to explain what happened.
Re: Project: Teacup Firmware
October 27, 2011 08:19PM
brnrd Wrote:
-------------------------------------------------------
> I've tried a couple of times but I've never been
> successful in running my Mendel with RAMPS 1.2
> with Teacup. One problem that I have is that I
> just can't get to all the source codes when I open
> it in Arduino. There's not enough horizontal room
> to show all the tabs and not enough vertical room
> to show all the popup menu since there are so many
> files. Excuse me if this is in a wiki somewhere,
> but how do people do it.

We don't use the stupid arduino IDE to access the code. After using a real programmer's text editor, it's almost as bad as going back to notepad. Personally I use kate, but there are plenty of good editors and IDEs around.

Dale Dunn Wrote:
-------------------------------------------------------
> I'm thinking the print should be paused if any end
> stop is tripped. Maybe even turn off the heaters
> and raise the extruder. An error should probably
> be reported to the host to explain what happened.

personally I like how sprinter handles endstops. It keeps track of real position and requested position, and generates appropriate moves.

This means that if some non-critical part of an object grazes an endstop at layer 200, your print turns out fine except possibly for a bit too much plastic at that spot.

This also means that if you have a temporary wiring issue, you can just reattach the wires and the print will continue just fine


-----------------------------------------------
Wooden Mendel
Teacup Firmware
Re: Project: Teacup Firmware
October 27, 2011 10:24PM
I just decided to update my Teacup build to the latest build in the master branch. It does not work for me, I can heat the hotend and check its temperature buts thats it. NONE of the axis will move in any direction.

Notes:
I use Xon/Xoff
I am using Bang Bang because the transistors on my Sanguinololu don't like PID
I use software limits which have been disabled in this latest build.

I am back to using [github.com] until it works again.

Quote
My config

/***************************************************************************\
* *
* 1. MECHANICAL/HARDWARE *
* *
\***************************************************************************/

/*
Set your microcontroller type in Makefile! atmega168/atmega328p/atmega644p/atmega1280

If you want to port this to a new chip, start off with arduino.h and see how you go.
*/
#if ! ( defined (__AVR_ATmega644P__) || defined (__AVR_ATmega644PA__) )
#error Sanguinololu has a 644P/644PA! set your cpu type in Makefile!
#endif

/** \def F_CPU
CPU clock rate
*/
#ifndef F_CPU
#define F_CPU 16000000L
#endif

/** \def HOST
This is the motherboard, as opposed to the extruder. See extruder/ directory for GEN3 extruder firmware
*/
#define HOST

/*
Values reflecting the gearing of your machine.
All numbers are fixed point integers, so no more than 3 digits to the right of the decimal point, please :-)
*/

/// calculate these values appropriate for your machine
/// for threaded rods, this is (steps motor per turn) / (pitch of the thread)
/// for belts, this is (steps per motor turn) / (number of gear teeth) / (belt module)
#define MICROSTEPPING_X 16.0
#define MICROSTEPPING_Y 16.0
#define MICROSTEPPING_Z 16.0
#define MICROSTEPPING_E 16.0

#define STEPS_PER_MM_X (3.401*MICROSTEPPING_X)
#define STEPS_PER_MM_Y (3.401*MICROSTEPPING_Y)
#define STEPS_PER_MM_Z (328.000*MICROSTEPPING_Z)

/// [blog.arcol.hu] may help with this one
#define STEPS_PER_MM_E (48.636*MICROSTEPPING_E)


/*
Values depending on the capabilities of your stepper motors and other mechanics.
All numbers are integers, no decimals allowed.

Units are mm/min
*/

/// used for G0 rapid moves and as a cap for all other feedrates
#define MAXIMUM_FEEDRATE_X 11000
#define MAXIMUM_FEEDRATE_Y 11000
#define MAXIMUM_FEEDRATE_Z 2000
#define MAXIMUM_FEEDRATE_E 2000

/// used when searching endstops and as default feedrate
#define SEARCH_FEEDRATE_X 2400
#define SEARCH_FEEDRATE_Y 2400
#define SEARCH_FEEDRATE_Z 1000
// no SEARCH_FEEDRATE_E, as E can't be searched

/** \def SLOW_HOMING
wether to search the home point slowly
With some endstop configurations, like when probing for the surface of a PCB, you can't deal with overrunning the endstop. In such a case, uncomment this definition.
*/
// #define SLOW_HOMING

/// this is how many steps to suck back the filament by when we stop. set to zero to disable
#define E_STARTSTOP_STEPS 0


/**
Soft axis limits, in mm.
Define them to your machine's size relative to what your host considers to be the origin.
*/

#define X_MIN -106
#define X_MAX 106

#define Y_MIN -132
#define Y_MAX 132

#define Z_MIN 0.0
#define Z_MAX 110

/** \def E_ABSOLUTE
Some G-Code creators produce relative length commands for the extruder, others absolute ones. G-Code using absolute lengths can be recognized when there are G92 E0 commands from time to time. If you have G92 E0 in your G-Code, define this flag.
*/
// #define E_ABSOLUTE



/***************************************************************************\
* *
* 2. ACCELERATION *
* *
* IMPORTANT: choose only one! These algorithms choose when to step, trying *
* to use more than one will have undefined and probably *
* disastrous results! *
* *
\***************************************************************************/

/** \def ACCELERATION_REPRAP
acceleration, reprap style.
Each movement starts at the speed of the previous command and accelerates or decelerates linearly to reach target speed at the end of the movement.
*/
// #define ACCELERATION_REPRAP

/** \def ACCELERATION_RAMPING
acceleration and deceleration ramping.
Each movement starts at (almost) no speed, linearly accelerates to target speed and decelerates just in time to smoothly stop at the target. alternative to ACCELERATION_REPRAP
*/
#define ACCELERATION_RAMPING

/** \def ACCELERATION
how fast to accelerate when using ACCELERATION_RAMPING.
given in mm/s^2, decimal allowed, useful range 1. to 10'000. Start with 10. for milling (high precision) or 1000. for printing
*/
#define ACCELERATION 1500.

/** \def ACCELERATION_TEMPORAL
temporal step algorithm
This algorithm causes the timer to fire when any axis needs to step, instead of synchronising to the axis with the most steps ala bresenham.

This algorithm is not a type of acceleration, and I haven't worked out how to integrate acceleration with it.
However it does control step timing, so acceleration algorithms seemed appropriate

The Bresenham algorithm is great for drawing lines, but not so good for steppers - In the case where X steps 3 times to Y's two, Y experiences massive jitter as it steps in sync with X every 2 out of 3 X steps. This is a worst-case, but the problem exists for most non-45/90 degree moves. At higher speeds, the jitter /will/ cause position loss and unnecessary vibration.
This algorithm instead calculates when a step occurs on any axis, and sets the timer to that value.

// TODO: figure out how to add acceleration to this algorithm
*/
// #define ACCELERATION_TEMPORAL



/***************************************************************************\
* *
* 3. PINOUTS *
* *
\***************************************************************************/

/*
Machine Pin Definitions
- make sure to avoid duplicate usage of a pin
- comment out pins not in use, as this drops the corresponding code and makes operations faster
*/

#include "arduino.h"

/** \def USE_INTERNAL_PULLUPS
internal pullup resistors
the ATmega has internal pullup resistors on it's input pins which are counterproductive with the commonly used eletronic endstops, so they should be switched off. For other endstops, like mechanical ones, you may want to uncomment this.
*/
//#define USE_INTERNAL_PULLUPS

/*
user defined pins
adjust to suit your electronics,
or adjust your electronics to suit this
*/

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

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

#define Z_STEP_PIN DIO3
#define Z_DIR_PIN DIO2
#define Z_MIN_PIN DIO20
//#define Z_MAX_PIN xxxx
#define Z_ENABLE_PIN DIO26
//#define Z_INVERT_DIR
//#define Z_INVERT_MIN
//#define Z_INVERT_MAX
//#define Z_INVERT_ENABLE

#define E_STEP_PIN DIO1
#define E_DIR_PIN DIO0
//#define E_ENABLE_PIN xxxx
//#define E_INVERT_DIR

#define PS_ON_PIN DIO9
#define STEPPER_ENABLE_PIN DIO4
//#define STEPPER_INVERT_ENABLE

//#define SD_CARD_DETECT DIO2
//#define SD_WRITE_PROTECT DIO3


/***************************************************************************\
* *
* 4. TEMPERATURE SENSORS *
* *
\***************************************************************************/

/**
TEMP_HYSTERESIS: actual temperature must be target +/- hysteresis before target temperature can be achieved.
Unit is degree Celsius.
*/
#define TEMP_HYSTERESIS 5
/**
TEMP_RESIDENCY_TIME: actual temperature must be close to target for this long before target is achieved

temperature is "achieved" for purposes of M109 and friends when actual temperature is within [hysteresis] of target for [residency] seconds
*/
#define TEMP_RESIDENCY_TIME 0.1

/// which temperature sensors are you using? List every type of sensor you use here once, to enable the appropriate code. Intercom is the gen3-style separate extruder board.
// #define TEMP_MAX6675
#define TEMP_THERMISTOR
// #define TEMP_AD595
// #define TEMP_PT100
// #define TEMP_INTERCOM
// #define TEMP_NONE

/***************************************************************************\
* *
* Define your temperature sensors here *
* *
* for GEN3 set temp_type to TT_INTERCOM and temp_pin to 0 *
* *
* Types are same as TEMP_ list above- TT_MAX6675, TT_THERMISTOR, TT_AD595, *
* TT_PT100, TT_INTERCOM, TT_NONE. See list in temp.c. *
* *
\***************************************************************************/

#ifndef DEFINE_TEMP_SENSOR
#define DEFINE_TEMP_SENSOR(...)
#endif

// name type pin additional
DEFINE_TEMP_SENSOR(extruder, TT_THERMISTOR, AIO7_PIN, THERMISTOR_EXTRUDER)
//DEFINE_TEMP_SENSOR(bed, TT_THERMISTOR, AIO6_PIN, THERMISTOR_EXTRUDER)
// "noheater" is a special name for a sensor which doesn't have a heater.
// Use "M105 P#" to read it, where # is a zero-based index into this list.
// DEFINE_TEMP_SENSOR(noheater, TT_THERMISTOR, 1, 0)



/***************************************************************************\
* *
* 5. HEATERS *
* *
\***************************************************************************/

/** \def HEATER_SANITY_CHECK
check if heater responds to changes in target temperature, disable and spit errors if not
largely untested, please comment in forum if this works, or doesn't work for you!
*/
// #define HEATER_SANITY_CHECK

/***************************************************************************\
* *
* Define your heaters here *
* *
* If your heater isn't on a PWM-able pin, set heater_pwm to zero and we'll *
* use bang-bang output. Note that PID will still be used *
* *
* See Appendix 8 at the end of this file for PWMable pin mappings *
* *
* If a heater isn't attached to a temperature sensor above, it can still be *
* controlled by host but otherwise is ignored by firmware *
* *
* To attach a heater to a temp sensor above, simply use exactly the same *
* name - copy+paste is your friend *
* *
* Some common names are 'extruder', 'bed', 'fan', 'motor' *
* *
* A milling spindle can also be defined as a heater. Attach it to a *
* temperature sensor of TT_NONE, then you can control the spindle's rpm *
* via temperature commands. M104 S1..255 for spindle on, M104 S0 for off. *
* *
\***************************************************************************/

#ifndef DEFINE_HEATER
#define DEFINE_HEATER(...)
#endif

// name port pin pwm
DEFINE_HEATER(extruder, PD5)
//DEFINE_HEATER(bed, PD6)
// DEFINE_HEATER(fan, PORTB, PINB4, OCR0cool smiley
// DEFINE_HEATER(chamber, PORTD, PIND7, OCR2A)
// DEFINE_HEATER(motor, PORTD, PIND6, OCR2cool smiley

/// and now because the c preprocessor isn't as smart as it could be,
/// uncomment the ones you've listed above and comment the rest.
/// NOTE: these are used to enable various capability-specific chunks of code, you do NOT need to create new entries unless you are adding new capabilities elsewhere in the code!
/// so if you list a bed above, uncomment HEATER_BED, but if you list a chamber you do NOT need to create HEATED_CHAMBER
/// I have searched high and low for a way to make the preprocessor do this for us, but so far I have not found a way.

#define HEATER_EXTRUDER HEATER_extruder
//#define HEATER_BED HEATER_bed
// #define HEATER_FAN HEATER_fan



/***************************************************************************\
* *
* 6. COMMUNICATION OPTIONS *
* *
\***************************************************************************/

/** \def REPRAP_HOST_COMPATIBILITY
RepRap Host changes it's communications protocol from time to time and intentionally avoids backwards compatibility. Set this to the date the source code of your Host was fetched from RepRap's repository, which is likely also the build date.
See the discussion on the reprap-dev mailing list from 11 Oct. 2010.

Undefine it for best human readability, set it to an old date for compatibility with hosts before August 2010
*/
// #define REPRAP_HOST_COMPATIBILITY 19750101
// #define REPRAP_HOST_COMPATIBILITY 20100806
// #define REPRAP_HOST_COMPATIBILITY 20110509
// #define REPRAP_HOST_COMPATIBILITY

/**
Baud rate for the connection to the host. Usually 115200, other common values are 19200, 38400 or 57600.
*/
#define BAUD 115200

/** \def XONXOFF
Xon/Xoff flow control.
Redundant when using RepRap Host for sending GCode, but mandatory when sending GCode files with a plain terminal emulator, like GtkTerm (Linux), CoolTerm (Mac) or HyperTerminal (Windows).
Can also be set in Makefile
*/
#define XONXOFF



/***************************************************************************\
* *
* 7. MISCELLANEOUS OPTIONS *
* *
\***************************************************************************/

/** \def DEBUG
DEBUG
enables /heaps/ of extra output, and some extra M-codes.
WARNING: this WILL break most host-side talkers that expect particular responses from firmware such as reprap host and replicatorG
use with serial terminal or other suitable talker only.
*/
// #define DEBUG

/** \def BANG_BANG
BANG_BANG
drops PID loop from heater control, reduces code size significantly (1300 bytes!)
may allow DEBUG on '168
*/
#define BANG_BANG
/** \def BANG_BANG_ON
BANG_BANG_ON
PWM value for 'on'
*/
#define BANG_BANG_ON 210
/** \def BANG_BANG_OFF
BANG_BANG_OFF
PWM value for 'off'
*/
#define BANG_BANG_OFF 5

/**
move buffer size, in number of moves
note that each move takes a fair chunk of ram (69 bytes as of this writing) so don't make the buffer too big - a bigger serial readbuffer may help more than increasing this unless your gcodes are more than 70 characters long on average.
however, a larger movebuffer will probably help with lots of short consecutive moves, as each move takes a bunch of math (hence time) to set up so a longer buffer allows more of the math to be done during preceding longer moves
*/
#define MOVEBUFFER_SIZE 8

/** \def DC_EXTRUDER
DC extruder
If you have a DC motor extruder, configure it as a "heater" above and define this value as the index or name. You probably also want to comment out E_STEP_PIN and E_DIR_PIN in the Pinouts section above.
*/
// #define DC_EXTRUDER HEATER_motor
// #define DC_EXTRUDER_PWM 180

/** \def USE_WATCHDOG
Teacup implements a watchdog, which has to be reset every 250ms or it will reboot the controller. As rebooting (and letting the GCode sending application trying to continue the build with a then different Home point) is probably even worse than just hanging, and there is no better restore code in place, this is disabled for now.
*/
// #define USE_WATCHDOG

/**
analog subsystem stuff
REFERENCE - which analog reference to use. see analog.h for choices
*/
#define REFERENCE REFERENCE_AVCC

/** \def STEP_INTERRUPT_INTERRUPTIBLE
this option makes the step interrupt interruptible (nested).
this should help immensely with dropped serial characters, but may also make debugging infuriating due to the complexities arising from nested interrupts
\note disable this option if you're using a '168 or for some reason your ram usage is above 90%. This option hugely increases likelihood of stack smashing.
*/
#define STEP_INTERRUPT_INTERRUPTIBLE 1

/**
temperature history count. This is how many temperature readings to keep in order to calculate derivative in PID loop
higher values make PID derivative term more stable at the expense of reaction time
*/
#define TH_COUNT 8

/// this is the scaling of internally stored PID values. 1024L is a good value
#define PID_SCALE 1024L

/** \def ENDSTOP_STEPS
number of steps to run into the endstops intentionally
As Endstops trigger false alarm sometimes, Teacup debounces them by counting a number of consecutive positives. Valid range is 1...255. Use 4 or less for reliable endstops, 8 or even more for flaky ones.
*/
#define ENDSTOP_STEPS 4


FFF Settings Calculator Gcode post processors Geometric Object Deposition Tool Blog
Tantillus.org Mini Printable Lathe How NOT to install a Pololu driver
Re: Project: Teacup Firmware
October 27, 2011 10:26PM
Triffid_Hunter Wrote:
-------------------------------------------------------
> brnrd Wrote:
> --------------------------------------------------
> -----
> > I've tried a couple of times but I've never
> been
> > successful in running my Mendel with RAMPS 1.2
> > with Teacup. One problem that I have is that I
> > just can't get to all the source codes when I
> open
> > it in Arduino. There's not enough horizontal
> room
> > to show all the tabs and not enough vertical
> room
> > to show all the popup menu since there are so
> many
> > files. Excuse me if this is in a wiki
> somewhere,
> > but how do people do it.
>
> We don't use the stupid arduino IDE to access the
> code. After using a real programmer's text editor,
> it's almost as bad as going back to notepad.
> Personally I use kate, but there are plenty of
> good editors and IDEs around.
>

I agree that Arduino IDE leaves a lot to be desired. I ended up using XCODE to edit files which I can't open under Arduino and after spending an hour or so on it, Today, I decided to work on it until it worked and I finally succeded! I did encounter a bug in the home.c code when I turned on software min and max limits to all the axes. I think it's very dangerous, especially in the z-axis to not have this limit. It's possible to tell the printer to move down well beyond the endstop location and crash the head on the bed since Teacup doesn't seem to look at the endstop signal! Anyway, in home.c, there are two errors in lines 82 and 88 where the call

enqueue_home(t, 0x1, 1);

should be

enqueue_home(&t, 0x1, 1);

Another problem I had was that G28 Z0 resulted in the z-axis moving up instead of down as if it was looking for a maximum endstop end even though it was set to minimum. The problem turns out to be a result of both Z-MIN_PIN and Z_MAX_PIN being defined in config.h. On the other axes, the minimum pin takes precedence so if both are defined, it uses the minimum. But with the z axis, it's reversed and so it ends up looking for the Max endstop for z. Either the config.h for RAMPS 1.2 need to be change so only the *_MIN_PIN parameters are defined and/or lines 27-31 of the home.c code need to be rewritten so that the z is consistent with the other axes :

	#if defined Z_MIN_PIN
		home_z_negative();
	#elif defined	Z_MAX_PIN
		home_z_positive();
	#endif

I also think that the maximum feed rate limits of 200 mm/s in the x and y and 600 in the E in the RAMPS 1.2 config are too low. I understand the reasoning for slowing it down to protect users from themselves but it makes more sense to more reasonable average values that a typical tuned machine is capable of like 3000 for x and y and 900 for the E.

My reason for doing this is to see if Teacup can execute G-code faster than Sprinter since it uses integer math. i'm still bother by the fact that microcontroller/firmware can't seem to keep up with short segments. So far, I haven't seen an improvement when run without acceleration. I chose to compare in this way to remove the complications on how acceleration variables are defined even though the algorithm used is supposed to be the same. For instance, Sprinter has separate acceleration parameters for each axis and E while I can only see one parameter in Teacup. I'll continue testing but my impression now is that the Reprap community needs a much faster microcontroller like the R2C2 perhaps.

Thanks to all the contributors to the Teacup project.

Edited 1 time(s). Last edit at 10/27/2011 10:47PM by brnrd.
Sorry, only registered users may post in this forum.

Click here to login