Project: Teacup Firmware

good news all, we've finally been approved for a house with a workshop space, will take us a couple of weeks to get sorted and settled, and then hopefully I'll be able to do some serious testing of our firmware

---

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

The beginning of my start.gcode file looks like this

G21 (Metric FTW)
G90 (Absolute Positioning)
G161 X0 Y0
G0 X135 Y0 F2000 (Move to purge plate for warmup)
G161 Z0
G0 Z3.5
G92 Z0
G0 Z10 
M109 S185 T0 (Extruder Temperature to 195 Celsius)
M105
G04 P20000
G92 E0 (Reset extruder position)
G0 E1000 (Extrude 500mm onto purge plate)

If I issue these commands one at a time through mendel_talk, it works. But if I do the same thing with mendel_print, The Z axis begins to descend while the X is still moving toward the purge plate as though it were already processing the G161 Z0.

When it arrives at the purge location, it halts and never moves on . It doesn't finish descending to the switch and it never processes another command. No further communication is possible until a reset.

Sounds like we're missing a call to wait_queue somewhere... Not sure why that would produce a freeze though

---

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

"Skeinforge in absolute dimension mode generates a lot of G92 E0. Although absolute E mode won't work zeroing all axis is a bad idea. "


Why a bad idea?

The G92 E0 clears the register. This is needed with some Reprap controllers that have a finite E register. When Skeinforge used an E value of extruded filament the E values could be huge on a large job. Skeinforge now sets E value as the material feed distance so is reduced by a considerable factor. But the numbers can still get big.

Edited 1 time(s). Last edit at 04/09/2011 12:39PM by emt.

---

Regards

Ian

Triffid_Hunter Wrote:
-------------------------------------------------------
> good news all, we've finally been approved for a
> house with a workshop space, will take us a couple
> of weeks to get sorted and settled, and then
> hopefully I'll be able to do some serious testing
> of our firmware


That's great news. but isn't it that you were approved for a workshop space that comes with a house?
That's what I keep looking for ;-) the realtors and girlfriends tell me I'm nuts.

emt Wrote:
-------------------------------------------------------
> "Skeinforge in absolute dimension mode generates a
> lot of G92 E0. Although absolute E mode won't work
> zeroing all axis is a bad idea. "
>
>
> Why a bad idea?
>
> The G92 E0 clears the register. This is needed
> with some Reprap controllers that have a finite E
> register. When Skeinforge used an E value of
> extruded filament the E values could be huge an a
> large job. Skeinforge now sets E value as the
> material feed distance so is reduced by a
> considerable factor. But the numbers can still get
> big.
We have a misunderstanding. I meant if G92 E0 sets x,y,z to 0, the following x,y,z moves will be wrong, and sooner or later hammer some soft or hard endstop.

Triffid_Hunter Wrote:
-------------------------------------------------------
> Sounds like we're missing a call to wait_queue
> somewhere... Not sure why that would produce a
> freeze though

If I put a G04 command in to give it time to reach the purge location, it works fine. Feels like It starts the G161 too early and then gets interrupted by completing the G1 move.

I'm very close to functional now. I still can't get my extruder stepper to reverse. I thought I had this working before but now it only turns in one direction.

Hi all, cloudmaker reported on the wiki here "Pulled the latest sources from the teacup git repository, and now Z Axis mouvement occurs only if I activate #accelerate_ramping." Can someone confirm, and hopefully bisect?

Sliptonic Wrote:
-------------------------------------------------------
> If I put a G04 command in to give it time to reach
> the purge location, it works fine. Feels like It
> starts the G161 too early and then gets
> interrupted by completing the G1 move.

yep definitely missing a queue_wait then, commit f4e4788 pushed.

> I'm very close to functional now. I still can't
> get my extruder stepper to reverse. I thought I
> had this working before but now it only turns in
> one direction.

sounds like an electrical issue, but just to be sure, swap the controller to another axis and see if the problem moves with it or not. If not, then the problem is either in the firmware or on your board, in which case you'll have to do some rewiring to test further, or write/find an extremely simple I/O tester program.

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
>
>Sliptonic Wrote:
-------------------------------------------------------
>> sounds like an electrical issue, but just to be
>> sure, swap the controller to another axis and see
>> if the problem moves with it or not. If not, then
>> the problem is either in the firmware or on your
>> board, in which case you'll have to do some
>> rewiring to test further, or write/find an
>> extremely simple I/O tester program.

To test this you could just swap the step/dir for one of the axis and the extruder in the pinout. If the extruder works in both directions after and the axis doesn't you know the problem is in the board.

Hey everybody,

Any plans to put support for dual extruders into the firmware?

Andrew Diehl Wrote:
-------------------------------------------------------
> Any plans to put support for dual extruders into
> the firmware?

plans, definitely. implementation? none yet.. I'm thinking of using an array of extruder pinout definitions similar to heaters to implement this, then copy 'tool' (as set by M6) somewhere in dda_start as an index into that array (so we don't switch extruders halfway through a move). I think we can share direction and step if we leverage enable sensibly, which will keep things simple in dda_step. Perhaps we'll end up adding a tool index to struct TARGET?

---

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

Andrew Diehl Wrote:
-------------------------------------------------------
> Hey everybody,
>
> Any plans to put support for dual extruders into
> the firmware?

Is there any machine out there with multiple extruders?

Markus Amsler Wrote:
-------------------------------------------------------
> Is there any machine out there with multiple
> extruders?

It's chicken and egg I think.. let's be first to support it

---

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

> Is there any machine out there with multiple
> extruders?

YES (almost)

And I just finished a set of experiments printing with nylon. Conveniently, ABS dissolves in acetone while Nylon does not

Now as soon as there is dual extruder support in skeinforge and teacup we're set to do some pretty awesome things.

I just posted some preliminary work on multiple extruders in a new branch. I think the most interesting part is how simply it integrates into teacup's existing code! Basically we just add a tool field (T) to struct TARGET, update it in M6 and fiddle some enable lines in dda_start. SO the way to use this is that all extruder stepper controllers share dir and step, but each has its own enable line. There is also code to alter the default sensor referenced by M104/M105/M109 so you should define your extruder sensors first and in the same order as your DEFINE_EXTRUDER entries.

Also included is some intercom stuff, we weren't setting the destination address in packets but we were checking them. This probably should be separated out before it hits master.

---

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

Cefiar Wrote:
-------------------------------------------------------
> With thermistors:
>
> 1. Make sure to measure the thermistor bias
> resistor and feeling that in rather than trusting
> the value on the actual resistor (eg. 4590 ohms or
> 4780 ohms or whatever instead of assuming it's
> 4.7k). This will correct a bit of skew in ANY
> system. It may not be much at the default temp,
> but it can compound the issue at higher temps.
>
> 2. Your thermistor isn't placed in the centre of
> your nozzle (that is where you want the plastic to
> be), so it will never read the exact same value.
> You need to figure out what that difference will
> be (varies with every nozzle/heater/thermistor
> setup). If you feel it necessary, you can always
> compensate with the temp table.
>
> 3. Many (not all) of the default temp tables FAIL
> to track the thermistor curve well at the higher
> values (eg: over 150C and gets worse with higher
> temps). There is a forum thread on thermistors
> that details the issue. It may be worth generating
> a table with more data points and then removing a
> lot of the lower temp ones (where it is more
> linear, see the thread for more detail, it covers
> it better than I can here). Note that this depends
> entirely on the thermistor beta curve and how well
> the table tracks this curve.

The default thermistor table that comes with teacup is optimized in this manner. Well, it is if it's still the one that I generated. I generated 50 temperatures, and deleted most (all?) of the ones below 100C, and pruned until I got something reasonable with 20 values. If you examine the file, you will see the temperature for each entry given in the comment after the entry, so you can examine it and determine this yourself.

The original 5D firmware stored these in straight "degrees C" whereas Teacup stores "degrees C * 4"
also known as 14.2 fixed point notation. Thus the need for the degrees C in the comment.

---

--
I'm building it with Baling Wire

Quote

SO the way to use this is that all extruder stepper controllers share dir and step, but each has its own enable line.

Good concept! If one day something like a toolchanger appears, the code will swallow that nicely as well

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I can't seem to get my heated bed to turn on. It works with the other firmwares I've tried (5D, different flavors of Tonokip), so it's not a hardware issue (RAMPS 1.1 / Arduino 2560). I've also tried sending the gcode directly using the Arduino serial monitor (M140 S100) to no avail. The relevant line from my config.h is:

DEFINE_HEATER(bed, PH5)

This should be right, since my bed is hooked up to pin 8. Any thoughts on what could be wrong? I'm happy to post debug output if you give me commands to type.

TMaccius Wrote:
-------------------------------------------------------
> I can't seem to get my heated bed to turn on. It
> works with the other firmwares I've tried (5D,
> different flavors of Tonokip), so it's not a
> hardware issue (RAMPS 1.1 / Arduino 2560). I've
> also tried sending the gcode directly using the
> Arduino serial monitor (M140 S100) to no avail.
> The relevant line from my config.h is:
>
> DEFINE_HEATER(bed, PH5)
>
> This should be right, since my bed is hooked up to
> pin 8. Any thoughts on what could be wrong? I'm
> happy to post debug output if you give me commands
> to type.

the switch at heater.c:104 needed to be expanded or heaters on timers 3/4/5 won't be initialised. I have pushed a commit for you to try.

---

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

My pondering about per-axis acceleration (which I have oft said is the ultimate goal for our DDA) has given me an idea- can we work out which axis limits head acceleration the most, then work out how many steps it will take for it to reach full speed, then work out acceleration for other axes such that they also reach full speed at the same time? Will this preserve geometry? Can we then use look-ahead to sensibly define a per-axis deceleration gradient given delta velocity and a maximum corner radius or some other relevant overlap figure?

This will also allow different acceleration factors per axis so we can for example have hard acceleration on Y yet light on X if the machine has a very light Y carriage, and two extruders sitting on the X carriage. One side effect of this would be that hexagonal infill could be faster than diagonal if oriented to the axis with higher acceleration.

I hope to investigate these soon, if anything occurs to you please post so we can flesh it out

---

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

Hi

I´m have build my repstrap mechanic and try now to make my electronic and software play nice together. I have a Arduino duemilanove connected to a generation 2 stepper controller 1.2 and a nema 17 hooked up to this. I have verified the electronic works with an example code from here Example code . I have verified 2 pin combinations that work but when i upload teacup to my arduino i can only use the m114 and m115 command on a terminal. A G0 x10 command will result in no move of the x axis stepper but m114 shows " ok X:100,Y:0,Z:0,E:0,F:400 ".

So i have some questions.
Is it necessary to connect the min endstops to make the stepper move ( I have tried to command out the min endstops in config.h, no success) .
Is the config.h.dist working with a arduino duemilanove out of the box or must i alter the file to work with my arduino.(I have changed only the name and steps per mm to my repstrap.)

If somebody can give me a hand in this i would be very grateful.

Thanks Jörg

Jörg:

the default pinout in config.h.dist assigns both a thermistor and X_STEP to the same pin. The thermistor takes precedence. Choose another pin and update your config to suit

I probably should change that at some point, the pinout in config.h.dist is the pinout for my homebrew motherboard with max6675 instead of thermistor so I don't get any conflicts.

Apart from putting thermistors on analog pins, you can pretty much connect anything anywhere, although heaters prefer PWMable pins (see appendix at end of config.h)

---

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

Thank you Triffid Hunter

Now it works in the terminal. Now I need only a working host program Because the reprap host will not connect to teacup (I know why and I too find the behavior of the programer silly that make it extra incompatible ).

I work on a windows machine, by the way so will try repsnapper and replicatorg .

By Jörg

Is anyone using teacup on Gen 3 electronics with a separate extruder controller? The firmware code has a big error message that indicates it's not tested. Thanks.

brnrd Wrote:
-------------------------------------------------------
> Is anyone using teacup on Gen 3 electronics with a
> separate extruder controller? The firmware code
> has a big error message that indicates it's not
> tested. Thanks.
I use it. But I have wired my gen3 motherboard a bit special, so I can't say the wether config.gen3.h will work out of the box for default wiring. Just try it out by uncommenting the #error line and report what you got.

Triffid Hunter:

Let there be heat! Thanks for the patch. My heated bed is working now.

brnrd Wrote:
-------------------------------------------------------
> Is anyone using teacup on Gen 3 electronics with a
> separate extruder controller? The firmware code
> has a big error message that indicates it's not
> tested. Thanks.

it'll stay that way until someone with a vanilla gen3 setup tells us what needed to change for it to work correctly- want to be that someone?

---

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

For intercom extruder/heated bed I have currently the following hack in my config.h

DEFINE_TEMP_SENSOR(extruder,	TT_INTERCOM,		0)
DEFINE_TEMP_SENSOR(bed,			TT_INTERCOM,		1)

#define HEATER_extruder HEATER_noheater
#define HEATER_bed HEATER_noheater
 
#define HEATER_BED 1   // 1 is the intercom temp channel

Is this an acceptable workaround to go into config.gen3.h?

I also attached a hackish patch which implements multiple thermistor support on the extruder. I have 2 different thermistors (10k and 30k) for extruder/heated bed, and I simply like correct temperatur readings. I'm pretty sure there must be a more elegant way, but I didn't find it.

Triffid_Hunter Wrote:
-------------------------------------------------------
> brnrd Wrote:
> --------------------------------------------------
> -----
> > Is anyone using teacup on Gen 3 electronics with
> a
> > separate extruder controller? The firmware code
> > has a big error message that indicates it's not
> > tested. Thanks.
>
> it'll stay that way until someone with a vanilla
> gen3 setup tells us what needed to change for it
> to work correctly- want to be that someone?

Perhaps when I have more time in another month if I'm not on RAMPS by then.

I'm under pressure to get some things built with the Mendel now. Most of the parts takes several hours to print and I've been running into problems with the host-firmware stalling. Someone posted that it might be the gen 3 mb resetting itself. I'm not sure what it is but it's very frustrating.

Markus Amsler Wrote:
-------------------------------------------------------
> For intercom extruder/heated bed I have currently
> the following hack in my config.h
>
> DEFINE_TEMP_SENSOR(extruder, TT_INTERCOM, 0)
> DEFINE_TEMP_SENSOR(bed, TT_INTERCOM, 1)
>
> #define HEATER_extruder HEATER_noheater
> #define HEATER_bed HEATER_noheater
>
> #define HEATER_BED 1 // 1 is the intercom temp
> channel
>
> Is this an acceptable workaround to go into
> config.gen3.h?

we use the dummy heaters to trigger M-code support for various features? Ideally we shouldn't need dummy heaters for that.. The whole heater/sensor thing needs another layer of abstraction so local or remote becomes irrelevant, we can do it properly when that layer gets written.

Until then, commit if it works

> I also attached a hackish patch which implements
> multiple thermistor support on the extruder. I
> have 2 different thermistors (10k and 30k) for
> extruder/heated bed, and I simply like correct
> temperatur readings. I'm pretty sure there must be
> a more elegant way, but I didn't find it.

seems elegant to me. I would have had multiple named tables and a pointer in the temp struct pointing to the relevant one, but I think your way is even more elegant than that- we use an array index rather than a pointer to the exact same effect.

Maybe add a couple of defines so we can name them rather than using the raw indexes in the config file.

---

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