Project: Teacup Firmware

madscifi Wrote:
-------------------------------------------------------
> Sergey Batalov, I've identified the problem in the
> firmware. From the trace you linked to:

Oh.. Thank you very much! I will try your suggestion and report the result.

Sergey.

I have my SEARCH_FEEDRATE values set very low but it doesn't seem to affect the feedrate during a G161. A G161 goes faster than I would like on my machine and shakes everything when it abruptly stops at the switch.

The comments say the SEARCH_FEEDRATE is also used as the default feedrate and when I do an initial G1 without passing a feedrate it goes very slowly as I would expect.

Can someone confirm that searching is actually obeying the maximum SEARCH_FEEDRATE or point me to the bit of configuration magic that I missed?

Look at home.c, the code is pretty straightforward. First step is to run into the endstops at high speed, second step is so back off at SEARCH_FEEDRATE.

You have an application where the high speed part should be skipped? Me as well and if we're two, I think introducing a HIGH_SPEED_HOMING flag (to switch that off) in config.h whould be justified.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

That makes sense to me. I think the way EMC2 works is like that as well. It has a SEARCH_VELOCITY for quickly locating the home/limit switch. and then a LATCH_VELOCITY for slowly approaching the switch a second time for accuracy.

madscifi Wrote:
-------------------------------------------------------
> I was able to reproduce the problem and was able
> to verify that the above fixes the specific
> problem.

madscifi,
I tried your patch and it works!

Thanks again.

FWIW, here are two patches which reduce RAM usage to an amount which easily allows to have an 8 line move buffer on an '168 again. Not sure wether it's a good idea to apply them, as I have good results with a 4 line buffer and the variable copying adds some 200 bytes binary size, so likely it reduces maximum speed a bit (from 700 mm/s to 680 mm/s or so).

They apply against current master.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> FWIW, here are two patches which reduce RAM usage
> to an amount which easily allows to have an 8 line
> move buffer on an '168 again.

free ram is far more important than free flash. We can use up the very last byte of flash without issues, but we need free ram for our stack. if it still fits in the '168's flash, apply away

---

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

Quote

apply

Done.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi

I have downloaded a newer version of teacup in zip format.
As I tried to upload the firmware to my reprap, I had an error. Here is the pic and my confic.h(altered for my machien).



config.h

Can you help me and tell me what is wrong in my confic.h.
I use an 328 arduino and gen 2 electronic.

Thank you

Edited 1 time(s). Last edit at 05/16/2011 05:55PM by atztek.

your config shows a zero where your image shows THERMISTOR_EXTRUDER, the zero should work. THERMISTOR_EXTRUDER is defined in ThermistorTable.h which may not be included before config.h in some places.

I think we're using the extra value to select different temperature tables for different thermistors, if you're not using that feature a zero should be fine.

---

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

when I delete the term THERMISTOR_EXTRUDER and replace it with a zero then there shows another error.



so what should I do now?

Thank you

Jörg

It looks like you may have an old ThermistorTable.h. Does yours have '#define NUMTABLES 1' at the top? does the definition look like uint16_t temptable[NUMTABLES][NUMTEMPS][2] PROGMEM = { ? can you git checkout ThermistorTable.h and reproduce the same error?


ps: we've passed 1000 posts! thanks everyone!

---

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

Hi Triffid

I Have made the changes to ThermistorTable.h like you indicated.

Here is my old ThermistorTable.h

And now with the changes it compiles and get uploaded see


Thank you very much

p.s. now i need to test it a little

I now have a temp reading of T 0.0 , this let me thinking of having not the right temp table so i changed the config.h to DEFINE_TEMP_SENSOR(extruder, TT_THERMISTOR, 0,1)

what gives me a temp reading of T : 534.0

thats very odd to me because its so high and so accurat with no after point numbers.

so what should i do? I will download the last master branch as zip and look for some differences in themistor table.h

Bye Jörg

p.s. after testing a little bit the temp reading decrease with heating from 534 to 531 or lower and when cooling it increase

so it function backwards

p.p.s. I alterd the thermistortable.h to the last github comment and altered confic.h to
DEFINE_TEMP_SENSOR(extruder, TT_THERMISTOR, 0, 0)

and now i have some sane temp readings and they increase when heated. So now I need only the right table but this I can figure myself.

p.p.s.2 I have tried some different thermistor table now but the temp reading are of by more than 10 times the real temp for exemple I read t :8.0 and if i thouch the hot end i get burned
And yes I have tried the thermistor table for my thermistor first but it was so extremly off that I tried others too and they all are so extremly off.

Edited 3 time(s). Last edit at 05/17/2011 11:07AM by atztek.

Just a minute ago I committed a patch which is intrusive enough to possibly break movements. Of course I tested this, but one never knows ...

Here's the commit message, which explains the advantages:

Store distances in the TARGET structure always in micrometers.

This is a intrusive patch and for now, it's done for the X axis only.
To make comparison with the former approach easier ...

The advantages of this change:

- Converting from mm to steps in gcode_parse.c and back in dda.c
  wastes cycles and accuracy.

- In dda.c, UM_PER_STEP simply goes away, so distance calculations
  work now with STEPS_PER_MM > 500 just fine. 1/16 microstepping
	on threaded rods (Z axis) becomes possible.

- Distance calculations (feedrate, acceleration, ...) become much
  simpler.

- A wide range of STEPS_PER_M can now be handled at reasonable
  (4 decimal digit) accuracy with a simple macro. Formerly,
  we were limited to 4096 steps/mm, now we can do 40'960 steps/mm
  and could easily raise this another digit.

Disadvantages:

- STEPS_PER_MM is gone in config.h, using STEPS_PER_M is required,
  because the preprocessor refuses to compare numbers with decimal
  points in them.

If you're in doubt, compare the X axis to other axes, the patch affects only the X axis for now.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Why don't you do something like

#define STEPS_PER_M (STEPS_PER_MM*1000)

and the config.h would remain largely backwards compatible.

@Traumflug:
I just printed a test object with the new code, and the x-axis is "wandering" with increasing height. It looks like after many moves the x-axis doesn't come back to the same spot.

In fact I'm pretty sure the machine must know its position in steps to avoid "wandering". It's perhaps best to revert the changes for now and push them into it's own branch, until this "wandering" issue is resolved.

Edited 1 time(s). Last edit at 05/19/2011 02:35PM by Markus Amsler.

I was down for a few weeks while waiting for a new Pololu driver and when I got back to printing I downloaded this commit [github.com] to find changes to acceleration in the config file without as much as a note to how they related to the old ones and after attempting to use it I found that Xon/Xoff no longer worked so I went back to using commit [github.com] . With a lot of tweaking and a new stepper motor for my extruder I am print reliably at 120mm/s. The only thing that needs fixing is the host software. After trying RepG and Repsnapper only to have failed communications I went back to using GTKterm with Xon/Xoff. Since that point I haven't had a single issue not even a pause in the printing.

Thank you everyone for all your hard work but please keep the experimental stuff in their own branches. Teacup has reached mainstream whether you guys like it or not and putting all the experimental stuff in is going to cause all kinds of issues.

All of this was printed @ 120mm/s

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote

Why don't you do something like

#define STEPS_PER_M (STEPS_PER_MM*1000)

The obvious solution It doesn't work, because the preprocessor doesn't accept floating point values in #if's. See dda.h:

#if	STEPS_PER_M_X >= 4096000
	#define	um_to_steps_x(dest, src) \
		do { dest = (src * (STEPS_PER_M_X / 10000L) + 50L) / 100L; } while (0)
#elif	STEPS_PER_M_X >= 409600
	#define	um_to_steps_x(dest, src) \
[...]

Inserting your suggestion with STEPS_PER_MM_X = 10.123 will prohibit compilation.

Quote

It's perhaps best to revert the changes for now and push them into it's own branch, until this "wandering" issue is resolved.

Of course I did tests myself and an entire Gen7 board milled just fine. No wandering. Thats some 50'000 lines of G-Code on the X-Y plane.

So I'm glad I pushed to the master branch and you had the chance to detect a potential flaw. I have no idea how wandering could be caused by this change, because all the stepping stuff is unchanged. Right at the beginning of dda_start() distances are calculated in steps, with the function cited above, the rest is untouched. Precision shouldn't suffer either, because everything is still integer maths.

Can you help me?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I didn't know the preprocessor was so dumb. Perhaps there's some clever way around this comparison but I didn't found one.

I epxlained the wandering problem like this:
The internal state of the firmware x-axis is now in um. But the machine state is always in steps. The um_to_steps_x introduces some rounding error, e.g. for a 100um move you should move 33.3333 steps or so. But obviously you can only move 33 steps, but the firmware state is updated by 100um. So gradually the firmware state and the machine state diverge. Unfortunatly I don't see a way around it, other then keeping the firmware state in steps.

I'm not sure why you didn't notice it. Perhaps milling is not so sensitive to wandering. Or your gcode precision/STEP_PER_M_X combo didn't introduce any rounding error. Or the error was symmetric and canceld itself out.

The idea is sound, but it looks like this is an ugly 'the devil is in the detail' case.

so we need to work in absolute coordinates- that is, find the relative steps after converting um to absolute position in steps. That way we don't have any wandering because moving 100um will move 33 steps the first time, and 34 steps the next time

---

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

I'd like to lend support to Sublime's suggestion that there should exist a well tested stable branch (or tags, or snapshots).

ok let's do it.

Is 47d8de a good commit to start our stable branch at? It's close to current head, but before the controversial 'internal position in um' commit

---

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

It's not exactly well tested yet, but one has to start somewhere. I'll pull a copy and start running in on my machine. Does anyone have any suggestions on a good way to track which configurations are known to work reliably?

ok everyone, hold onto your hats, prepare for repository breakage. master will be stable, and I'll create release candidate and devel branches. new stuff goes into devel, when we decide whether or not we like it, it goes in rc, and when rc has been well behaved for a while it goes into master as a new version

---

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

ok, repository breakage complete. Since master has gone back a few commits, expect git pull to choke without some massaging.

has anyone tried the sdcard, eeconfig or multi-extruder branches? They need to be merged into devel I think, or at least rebased...

---

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

41 minutes. This was quick. May I remember you we had a release branch already and it didn't work out?

Anyways:

Quote

I'm not sure why you didn't notice it. Perhaps milling is not so sensitive to wandering. Or your gcode precision/STEP_PER_M_X combo didn't introduce any rounding error. Or the error was symmetric and canceld itself out.

Clearly I noticed there are rounding errors, but I don't see how they whould accumulate. In fact, the rounding now in dda.c/.h was done previously in gcode_parse.c, so it's still unclear what changed to the fundamental situation. Inevitably, there's always some rounding.

It's not like I introduced this to insert some fancy idea, it's to make it work for many users at all. Since the introduction of the Pololus we have 1/16 microstepping, requiring a STEPS_PER_MM_Z of 2560. This UM_PER_STEP macro in dda.c simply doesn't work out for such numbers, it solves to zero. So, unless we find another way to calculate distances, we have to get his approach to work.

Can we start with finding out what's different in your setup from mine? I have a STEPS_PER_M_X of 320000 and use absolute coordinates. What is yours? Can you find out how many steps are moved on 45 deg commands? They should be the same for X and Y, obviously.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> 41 minutes. This was quick. May I remember you we
> had a release branch already and it didn't work
> out?

if I recall correctly we had a less stable codebase and fewer testers. Now we're in a position where most of the groundwork is done, and most of the patches coming in are experimental things which frequently upset the regular users. I think perhaps our original attempt was premature and now may be a better time.

I'll be merging eeconfig, sdcard and multi-extruder into devel sometime within the next couple weeks if you don't beat me to it, and I know at least eeconfig changes enough things that it's sure to cause havoc if dropped on the unsuspecting

---

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

Traumflug Wrote:
-------------------------------------------------------
> there's no gen7 config in our repository.
>
> There's one in the Gen7 repo which is outdated. My
> mistake, I've removed it.
>
> Try with the one appended to this post, as soon as
> Teacup is compilable again I'll post one into the
> Tecup repo.


Thank you, this fixed my problem.

I have made a Gen 7 board myself, and have now successfully uploaded the Teacup firmware. I am trying to test out the board with just a stepper motor attached to the X axis controller. Using reprap host 20100806 I get this message. I have made no changes to the config.h file.

I am guessing that it has something to do with the fact that I have no thermistors or heaters attached to the board, although I tried crudely attaching thermistors to both the TEMP1 and TEMP2 headers on the board with no success. Experimenting with commenting out the

Quote

#define TEMP_THERMISTOR

line did not help either. Is there any way I can test out the board with just the stepper motor attached?

Quote

Now we're in a position where most of the groundwork is done, and most of the patches coming in are experimental things which frequently upset the regular users.

Hmm. Now, where should this micrometer distance thing go? It isn't a new feature, it's a fix to an existing flaw - even if the patch obviously works not perfectly on the first attempt.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY