Project: Teacup Firmware

Sublime Wrote:
-------------------------------------------------------
> 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.
>

I encountered the same problem today with RAMPS 1.2 config file. In this case, it was because the enable pins need to be set to inverted and the config file has those lines commented out.

#define	X_INVERT_ENABLE
#define	Y_INVERT_ENABLE
#define	Z_INVERT_ENABLE

I also added one for the E since I didn't find it

#define	E_INVERT_ENABLE

I see the same settings in the Gen 6 config.h file. Perhaps, that's also your problem.

Quote

Teacup doesn't seem to look at the endstop signal

Now, that's intentional (and often discussed), as there is no procedure to recover from a hit into the endstops. That said, it should be a lot easier to implement something like that now with the new homing code. Endstop checks are already there, just the bits to handle it are missing.

Quote

Anyway, in home.c, there are two errors in lines 82 and 88

Good catch! It should show up in git in a few minutes.

Quote

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

I've choosen the code you suggested here. Ideally, we'd use both endstops and figure out the size of the build room here ...

Quote

My reason for doing this is to see if Teacup can execute G-code faster than Sprinter since it uses integer math.

I've recently measured Teacup to 15570 steps/second on a 20 MHz Gen7. This translates to 1870 CPU cycles per step. Looking at Repetier Firmware, there's a section which claims a uint32 by uint32 division takes no less than 670 cycles, more than a third of the step processing. We need such a division for acceleration, unfortunately.

Repetier provides much faster assembly to divide an uint32 by an uint16, but I've also detected edge cases where the int16 Teacup uses overflows (more than 8192 acceleration steps).

Quote

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.

Without acceleration, stepper motors simply can't get up to their maximum speed for mechanical reasons, so if your motors move without acceleration you're far behind what's possible. More likely, communications over the serial line is the bottleneck here. Raising MOVEBUFFER_SIZE in config.h helps a lot, you can raise it up to the point where 90% RAM are used. "make" in the command line will report RAM usage.

Another way to tackle this bottleneck is to turn on XONXOFF and to use a file sender which doesn't wait for an OK before proceeding with the next line. Most serial terminals like GtkTerm or Putty provide a function to send a file.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

I encountered the same problem ...

Added these two to the repository as well. Thanks, brnrd.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
Without acceleration, stepper motors simply can't get up to their maximum speed for mechanical reasons, so if your motors move without acceleration you're far behind what's possible. More likely, communications over the serial line is the bottleneck here. Raising MOVEBUFFER_SIZE in config.h helps a lot, you can raise it up to the point where 90% RAM are used. "make" in the command line will report RAM usage.

With Sprinter, I didn't see a difference when printing from the host or from a microSD card. I don't know enough to figure out exactly where the bottleneck is but it seems to me that we're pushing the limits of the AT Mega microcontroller. A 1 mm move at 40 mm/s takes 25 ms. That means that the microcontroller has to be ready to generate the next set of pulses to drive the motors in less than 25 ms. Since it cannot, the head pauses and a blob forms. With smaller steps, you don't see the blob since they're too close together but the extruded filament comes out too thick. In my observation, it doesn't look like the AT Mega can keep up with the current firmware that are available. The addition of acceleration just adds to the amount of processing that the AT Mega has to do for each move. I'm sure that we can come up with better hosts, slicing tool and firmware to overcome the problem with the microcontroller, but eventually, the community has to move on to a faster microcontroller. I hope I'm wrong on this.

Currently, with 1/16 microstepping on a typical Mendel, maximum speed is about 160 mm/s. 25 ms equals to half a million CPU cycles which is plenty for preparing the next movement. Also movements are prepared as the G-code comes in, not neccessarily while the machine is moving. A longer movement will fill the whole movement queue, so there's nothing to prepare if a few quick ones follow.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> A longer
> movement will fill the whole movement queue, so
> there's nothing to prepare if a few quick ones
> follow.

I think what you mean to say is, a longer movement allows the move queue to fill with prepared moves, so a subsequent few very short moves will have no delay.

And by "very short", we mean down at the level of minimum print resolution unless your printer is insanely fast...

---

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

I'll give this a try then.

Right now, I just want to be able to print even at 40 mm/s without the head vibrating and creating blobs when going around curves and circles. I'm not going after super high res or supersonic speed yet.

brnrd Wrote:
-------------------------------------------------------
> I'll give this a try then.
>
> Right now, I just want to be able to print even at
> 40 mm/s without the head vibrating and creating
> blobs when going around curves and circles. I'm
> not going after super high res or supersonic speed
> yet.

this requires trajectory planning and move blending, something that hasn't made its way into teacup (or sprinter) yet.

marlin and sjfw have this capability, both based off grbl as far as I know

---

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

Quote

marlin and sjfw have this capability, both based off grbl as far as I know

They have trajectory planning, but no move blending, unfortunately. All they do is to slow down at a corner to keep the jerk within reasonable limits.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

What else can you do without straying from the correct trajectory?

---

[www.hydraraptor.blogspot.com]

I tried to run Teacup on gen3 and run into a problem with the Extruder firmware.
I have thermocouples on ADC6 (A6) and ADC7 (A7). But when I set "#define TEMP_BED_PIN AIO7" I get the error:

error: 'PINC7' undeclared (first use in this function)

in extruder.c line 26.

AI06 does not give a error.

I tried to find out how arduino_168_328p.h, arduino.h, analog.h and analog.c work together. But I got lost in the ASCII World of & # << | ||.

Help plz.
Chris

ADC6 and ADC7 are analog inputs only, they cannot be used for GPIO. PINC6 is totally separate from ADC6.

For some reason, they're set as inputs in io_init, which assumes that they're dual analog/gpio pins.

you should be safe to comment out lines 25 and 26 in extruder.c so it'll behave.

we probably should alter the definitions for AIO6 and AIO7 in arduino_168_328p.h to find other spots where we've assumed that they're dual analog/gpio pins.

---

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

Quote

What else can you do without straying from the correct trajectory?

You want to "stray" from the given trajectory. Either you do it in a controlled way with the stepping algorithm, or physics does it for you. It's just like disabling acceleration in firmware doesn't make acceleration in physics going away.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> marlin and sjfw have this capability, both based
> off grbl as far as I know
>
> They have trajectory planning, but no move
> blending, unfortunately. All they do is to slow
> down at a corner to keep the jerk within
> reasonable limits.


Have you looked at Repetier? I'm trying to run it now. It's supposed to have path planning and trajectory smoothing.

Repetier also copied the Grbl approach, so it's the same.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

It's been a while since I've played with Teacup but I'm checking in again.

I've got a cupcake equipped with gen3 electronics and a pololu carrier board for a stepper extruder driver. I'm thinking Teacup would be a good match here.

I've got the current version from github installed. I'm able to move the XYZ axis and I can set and monitor the hot-end and bed temperartures. So far, so good.

However, I'm not able to drive the extruder stepper yet. I'm wiring from the SDA/SCL pins on the MB to the STEP/DIR pins on the carrier but so far, no joy.

One other thing that I don't understand. After I connect from pronterface, everything works great but shuts off after 30 seconds if I don't move any axis. So if I set temps to heat up, they will heat for 30 seconds and then everything will shut off. If I move any axis, it turns back on and resumes heating. To be clear, the printer remains online and the mb will respond to commands, but the stepper drivers and heating elements are off.

Sorry if I missed basic documentation somewhere but thanks for any help.

Quote

everything works great but shuts off after 30 seconds if I don't move any axis

That's expected with all heaters off. With at least one heater on, temp_all_zero() in temp.c should kick in. Obviously, Teacup thinks there is no temperature set to something != 0. Do heaters match the temp sensors?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> everything works great but shuts off after 30
> seconds if I don't move any axis
>
> That's expected with all heaters off. With at
> least one heater on, temp_all_zero() in temp.c
> should kick in. Obviously, Teacup thinks there is
> no temperature set to something != 0. Do heaters
> match the temp sensors?

Yes. I'm getting two accurate and independent readings from the two heaters. With either or both heater turned on, it still turns off after 30 seconds.

Quote

With either or both heater turned on, it still turns off after 30 seconds.

I can't find anything wrong in the sources. Are your sources up to date?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Perhaps you've seen it, I'm consolidating all the Teacup branches these days. Down from 14 to 9 branches already. Actually, it's nice to see what's already there, just waiting to hit master, like SD Card support and configuration through host software.

The ecosystem of all the forks is a bit too complex, though, and I can't rebase them to more recent Teacup versions. So, if you have something in your branch which you think should be in the main Teacup repo, please speak up and I'll fetch that. Patches sent here to the forum are also welcome, of course.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I think eeconfig could be generalised to a runtime configuration system like sjfw. then if we add SD card autorun.g support, we can store the configuration on a SD card.

I've pushed all my interesting local branches

---

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

Quote

I think eeconfig could be generalised to a runtime configuration system

I think you're the natural candidate to do this.

BTW., your pushes didn't hit the public yet.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> I think eeconfig could be generalised to a runtime
> configuration system
>
> I think you're the natural candidate to do this.

possibly, perhaps someone will beat me to it.. I haven't looked at that code in so long that I'd be seeing it with fresh eyes anyway!

> BTW., your pushes didn't hit the public yet.

ah yup they're all there

---

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

ACCELERATION_TEMPORAL is back. See: [github.com]

A slightly different implementation this time, to reach the same goal. Basically, it calculates all axes independently and tries to share this one step timer for all axes.

This undoubtly exhibits the problem of extremely short delay requests, down to zero. Where zero means "do this step at exactly the same time you did the last step". An approach to deal with this situation is implemented here: [github.com]

Both patches together are on the Gen7 branch, so interested people please give it a try. Low speeds only so far, as there's no actual acceleration happening yet. But I'd be interested if your steppers sound reasonably and geometry is kept. You turn on this new stuff by #defining ACCELERATION_TEMPORAL in config.h (and turning off the other accelerations).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Guys

It has been a while, I have been changing jobs and helping other folks with there machines. Finally got some time on my own.

I pulled down the latest fresh copy of the master branch to make a new firmware from, and found the following errors when compiling:-

andy@quicksilver:~/Data/Common/development/Teacup_Firmware$ make
CC mendel.o
In file included from dda_queue.h:4,
from mendel.c:34:
dda.h:14:5: error: floating constant in preprocessor expression
dda.h:17:7: error: floating constant in preprocessor expression
dda.h:20:7: error: floating constant in preprocessor expression
dda.h:23:7: error: floating constant in preprocessor expression
dda.h:31:5: error: floating constant in preprocessor expression
dda.h:34:7: error: floating constant in preprocessor expression
dda.h:37:7: error: floating constant in preprocessor expression
dda.h:40:7: error: floating constant in preprocessor expression
dda.h:48:5: error: floating constant in preprocessor expression
dda.h:51:7: error: floating constant in preprocessor expression
dda.h:54:7: error: floating constant in preprocessor expression
dda.h:57:7: error: floating constant in preprocessor expression
dda.h:65:5: error: floating constant in preprocessor expression
dda.h:68:7: error: floating constant in preprocessor expression
dda.h:71:7: error: floating constant in preprocessor expression
dda.h:74:7: error: floating constant in preprocessor expression
make: *** [mendel.o] Error 1

Thought you might like to know.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Hi aka47,

every version I upload is tested on my setup. Only possible conclusion is, your setup is different. Could you attach your config.h, please?

If you're experimental, you might want to try the current Gen7 branch with ACCELERATION_TEMPORAL. This will be the stuff allowing EMC2-quality look-ahead and geometrical accuracy should be already there. Now looking for an algorithm to find out acceleration distance for each axis individually.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

My config.h is the ramps 1.2 header that came with the fresh download.

Attached here.

My Makefile is also the one that ships with the firmware attached also.

The errors suggest a type casting issue in the dda code and headers.....

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Thanks, aka47. Got the same error with your config.h and found the problem. To fix it, replace

#define	STEPS_PER_M_X					(5023*MICROSTEPPING_X)

with

#define	STEPS_PER_M_X					80368

i.e., calculate the value manually and insert a single number only. It's a bit disappointing the preprocessor can't so this for us.

BTW., your STEPS_PER_M_Z seems too high.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

The above issue is fixed in all the config.h templates now.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I hadn't tuned any of the steps per mm etc.

Was just doing a test build with the minimum changes before getting into transferring in my usual values.

I think it should be possible to keep the calculation if the result is explicitly is cast into it's final type. Even though both numbers are integers the compiler etc seemed to do the multiplication etc as a float which was then wrong to be stored in an integer data type.

An explicit number with no math is perhaps as good. Particularly if the comments tell the user how to arrive at that figure.

Thanks for sorting that I will fetch down the latest and try again.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.