Project: Teacup Firmware

Hi all

I have a PWM Driver board 1.1 here. Have the pin to drive the pwm board output to be a special pwm pin or can i use every analog pin on my duemilanove board. And which pin you recommend for extruder heater driver over the PWM board.
I hope you understand what I ask for, because english is not my natural language .

Jörg

I have read a little more on the wiki and see now I have to use the pwm pin 9,10 or 11 because there signal will only be amplified by the board so ignore my post above.

Jörg

atztek Wrote:
-------------------------------------------------------
> I have read a little more on the wiki and see now
> I have to use the pwm pin 9,10 or 11 because there
> signal will only be amplified by the board so
> ignore my post above.

actually, 3, 5, 6 or 11, but not 9 or 10 because the timer on DIO9/10 is used for stepping and can't also be used for PWM

---

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

I've just unpacked my motherboard and have been trying to track down what looked like a hardware bug- any move over a certain speed caused the stepper to vibrate like crazy but still move, as if it's getting a few fast steps then a "long" pause, noise to be dumped up the serial line, memory corruption and crashes.. tried a much older commit and it worked fine, so I bisected and found that commit 851a91 was the culprit- but how does this cause memory corruption, crashes and reboots? I tried removing my arduino from the motherboard, then changing the chip for a known good 328p, with identical results.

I have attached my config.h for others to test, my chip is a 328p, and the failing command is "G1 E100 F2500". Does this occur on anyone else's 328p? How about other chips? Any insights as to why simply not zeroing next_step_time could cause such a lot of bizarre behaviour?

---

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

Triffid_Hunter Wrote:
-------------------------------------------------------
> I have attached my config.h for others to test, my
> chip is a 328p, and the failing command is "G1
> E100 F2500". Does this occur on anyone else's
> 328p? How about other chips? Any insights as to
> why simply not zeroing next_step_time could cause
> such a lot of bizarre behaviour?

I haven't tested it but here my theory:

You have STEPS_PER_MM_E at 320 with F2500 results in 13kHz step pulses. With acceleration that may be the upper limit (without acceleartion its around 30kHz). You also have STEP_INTERRUPT_INTERRUPTIBLE whichtriggers a bug and the step interrupt interrupts itself, in extreme cases multiple times which results in a stack overflow (or interrupt overflow or whatever). Not zeroing next_step_time limits results in longer (wrong) step interrupts and works around the self interrupting bug.
This bug is on my list but haven't figuered out how to fix it properly. During the step interrupt the step interrupt should be disabled at all times.

So if my theory is right disable STEP_INTERRUPT_INTERRUPTIBLE should fix the problem.

Uh, that's a commit by me :-/

Well, I whouldn't have put it into the repo if it didn't fix something. Before the patch, the motor speed whould jump depending on the processing load, even lead to occasional step losses. With ACCELERATION_RAMPING you can hear the speed jump easily when the axis reaches target speed and the processing load becomes (suddenly) lower.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Uh, that's a commit by me :-/

I think timing our step from the previous step time is correct behaviour, but it's certainly problematic at the moment.

> Well, I whouldn't have put it into the repo if it
> didn't fix something. Before the patch, the motor
> speed whould jump depending on the processing
> load, even lead to occasional step losses. With
> ACCELERATION_RAMPING you can hear the speed jump
> easily when the axis reaches target speed and the
> processing load becomes (suddenly) lower.

yeah I figured that's what it was for; I suppose now is a good time to have a discussion about which behaviour is better- slower steps and jitter with processor load, or all-out stack smashing crash if we exceed maximum speed? Perhaps something more elegant than these two?

Ideally, we could hugely reduce the amount of calculating done in the step interrupt, perhaps by only updating position at the end of a move or in main loop somewhere, and downgrading the deltas to 16 bits- does anyone have a machine with a build area bigger than 65535 steps? This won't solve the issue, but will certainly push it up to crazier speeds.

---

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

Triffid_Hunter Wrote:
> ... and downgrading the deltas to
> 16 bits- does anyone have a machine with a build
> area bigger than 65535 steps? This won't solve the
> issue, but will certainly push it up to crazier
> speeds.

... if i replace my halfstep-drivers on the CNC-mill-strap (500x500mm in XY) with the IMS-1/256-microstepping drivers, i'll have max. stepping ranges of 5120000 steps, but then i'll need clocking frequencies above 500kHz too for normal build-speeds!

My normal stepping ranges with moderate microstepping are up to 360000 steps or lower ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Triffid_Hunter Wrote:
-------------------------------------------------------
> a discussion about
> which behaviour is better- slower steps and jitter
> with processor load, or all-out stack smashing
> crash if we exceed maximum speed? Perhaps
> something more elegant than these two?
Theoretically it should be possible to calculate the maximum time it takes to execute the step interrupt, and set that as lower limit. It would depend on the acceleration mode and serial baud rate and perhaps intercom. But I heard hard real time is a bitch.
The other possibility is to check at the end of the step interrupt if there's enough time left, and if not just delay the next interrupt by some fixed value. This should result in some more ore less smooth upper limit
Crashing is for sure the wrong behavior.

> Ideally, we could hugely reduce the amount of
> calculating done in the step interrupt, perhaps by
> only updating position at the end of a move or in
> main loop somewhere, and downgrading the deltas to
> 16 bits- does anyone have a machine with a build
> area bigger than 65535 steps? This won't solve the
> issue, but will certainly push it up to crazier
> speeds.
With 16x microstepping and a m6 threaded rod the build area may be very well 16*200*300 = 960000 steps in one direction. With all those crazy reprap modders around someone somewhere will build such a beast.
There are currently other speed ups possible:
- shorten function call chain in step interrupt or inline them
- no wait for temp in step interrupt
- no move start/move end code in step interrupt

I'm having a lot of corrupt data being returned to the host software, which then makes the host lock up. I've been using Ben's RepG and thought it was the problem but after a few emails and one patch for RepG that did fix initial connection problems I still get dropped o's from ok ALL the time. I have tried sending through gtkterm and had it freeze up on me as well, so now I am inclined to think its a problem with either teacup, Arduino 1280 or linux.

I have debugging turned on in repG and have tried enabling it in teacup but with no extra data output (even in gtkterm). I would like to help debug the issue but I am not really sure how.

I know its not a conflict with anything I've installed because I've tried it on fresh installs of Ubuntu 9.10, 10.04, 10.10 with the same results for all of them. I have a dedicated computer running it with nothing running in the background.

Any Ideas? Should I try the optiboot boot loader instead of the Arduino one? Or maybe burn it without a bootloader?

I should add that I had never used GTKterm before this and may have had something set wrong.

Port "/dev/ttyUSB0"
Speed "115200"
Parity "none"
Bits "8"
Stopbits "1"
Flow control "Xon/Xoff" (also turned on in teacup)
End of line delay "0"

I have also seen it drop the t from t:nnn b:nnn. The problem Ben fixed with his RepG was also a timing issue just on initialization where it would drop the parts of start, either the s, st, or sta. I also have timing issues while trying to upload the firmware to the 1280 via the Arduino 0022 IDE and have to press the reset just the right time.

data corruption eh.. try 76800 baud, although I had to push mine to 500k before I got any data errors at all, which suggests some sort of hardware problem. Are you using one of those ftdi dongles that plug into the main board, as opposed to having the ftdi onboard?

---

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

I have tried 57600 with just as many errors if not more. I am using an official Arduino 1280 mega with the onboard ftdi chip. I bought the Arduino just for this purpose and it has only ever had Teacup on it and a Ramps board plugged into it.

Any suggestions on how to test the hardware?

you could try another reprap firmware, or indeed any arduino project that involves significant serial transfers and see if you get similar error rates.

Have you tried running the board without any reprap electronics plugged in?

---

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

FWIW, we have a limitation of 4095 steps per mm due to numerical reasons in other parts of the firmware (decfloat_to_int()), so with a 16 bit value we could reach 2^15 / 4095 = 8 mm. 4095 is already not enough for most threaded rods and 1/16 microstepping.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hello
Where can I checkout this ARM Cortex-M3 port of the RepRap-firmware?
I'd like to port it to the LPC1343 which is available much cheaper on "digikey.de"

thx in advance
-lev

leviathan Wrote:
-------------------------------------------------------
> Hello
> Where can I checkout this ARM Cortex-M3 port of
> the RepRap-firmware?
> I'd like to port it to the LPC1343 which is
> available much cheaper on "digikey.de"
>
> thx in advance
> -lev

Casainho says he has one, but.... He has reported that he's got a version of teacup working on the ARM, and isn't going to publish the sourcecode until he has his hardware variant working and is ready to start selling it. It's been six months or more now, and still no code, I'd suggest porting it yourself is going to be the quickest way to get working code. That way you'll also get all the latest features, fixes and improvements.

---

--
I'm building it with Baling Wire

porting shouldn't be much work, mostly in and around the various hardware-specific things like interrupts, timers and I/O routines. The rest of the code should simply compile and work once those are sorted.

btw; don't copy the timer system verbatim, we use a few tricks to get a 32 bit timer and a system clock. I expect these will be far more trivial to implement on an stm32, and I strongly suggest you use native implementations rather than copying our tricks

---

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

Guys

Just initialized a repository on github for the code I have written so far for a text (NCurses) based bit of host-ware specifically targeted to work with Teacup.

[github.com]

There really is not much in it as yet except a couple of windows and a minimalist menu. But it is a start.

Initialy it is intended to be a simple machine controller that will download gcode files at the machinery and gove a degree of manual control.

Later perhaps it will be expanded to include a network interface (maybe lpr/lpd compatible) and perhaps a serial device it daisy chains to the machine, so as to make it easy to still use the teacup equipped machine with host-ware you like but monitor/log the interaction.

Being very simple and light weight lends it well to being used with re-purposed hardware (linux based router perhaps) or just recycled legacy PC's.

It is not and will never be a slicer/dicer cam layer. I am leaving this to other folk.

There was conversation a stretch back about using a comms library to standardize the reprap comms. Did Teacup go this way or is it on the to-do list??

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
-------------------------------------------------------
> Guys
>
> Just initialized a repository on github for the
> code I have written so far for a text (NCurses)
> based bit of host-ware specifically targeted to
> work with Teacup.
>
> [github.com]

what an awesome idea! this should go a long way to helping me run my reprap from my ts7250 over the network

> Initialy it is intended to be a simple machine
> controller that will download gcode files at the
> machinery and give a degree of manual control.
>
> Later perhaps it will be expanded to include a
> network interface (maybe lpr/lpd compatible) and
> perhaps a serial device it daisy chains to the
> machine, so as to make it easy to still use the
> teacup equipped machine with host-ware you like
> but monitor/log the interaction.

can use socat for that already, if you want some example source

> Being very simple and light weight lends it well
> to being used with re-purposed hardware (linux
> based router perhaps) or just recycled legacy
> PC's.
>
> It is not and will never be a slicer/dicer cam
> layer. I am leaving this to other folk.

good idea, if we don't have space for xorg, we probably don't have cycles for slicing

> There was conversation a stretch back about using
> a comms library to standardize the reprap comms.
> Did Teacup go this way or is it on the to-do
> list??

That's libreprap, I strongly suggest you check it out. I did suggest to ralith that he provide an includable set of message templates for firmwares, but I don't think that's happened yet.

Please keep your protocol definitions as flexible as possible- I'd like to see this used with other firmwares too!

---

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

Hi

Are the endstops supported in the current firmware, because I have attached my z min endstop to my machine but I can not home with g28 or reprap host software the axis stops when the soft endstops in the firmware are reached. The signal is on the pin d4 on my arduino duemilanova and its high when the endstop is triggered but the software is not stopping. I use currently the firmware triffid-Teacup_Firmware-57a75ec .

thank you

Currently, the only command for homing is G161 (home negative) and G162 (home positive). Both require "X", "Y" and/or "Z" to work, so in your case this whould be

G161 Z

G28 is about equivalent to G1 X0.0 Y0.0 Z0.0 F50.

Endstops are intentionally ignored during normal operation. For a peek into the future, look at the "endstop" branch.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

When i type g161 z in my terminal. the z axis go in the positive direction but i have no max endstop and when i type 162 z nothing happens. I will wait for a version that will incorporat the endstop branch.

Jörg

following again...

Quote

When i type g161 z in my terminal the z axis go in the positive direction

That sounds like an inverted axis. Do normal G1 work the correct direction?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug the g1 and g0 commands are working like expected (they go up when i type g1 z10 f1000 or z10 or go z10) and they go downward when I type z0 or g1 z0 or g0 z0. So only g161 dosent work like expected.

Jörg

Hmm. Can't find an issue in the code immediately. As a workaround you might want to swap 0's with 1's and vice versa in the calls to z_direction() in home.c, line 221 and 238.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I have tried to change the direction of z in home.c no success but as i changed back and blocked the endstop light while tipping in the comand it goes in the right direction and when i unblock the endstop it goes immeditly in the other direction. Next I tried to to uncomment Use_internal_pullups in confic.h but no change in the behavior. All with the g161 z comand.
So how do i invert the signal of the min z endstop.

Jörg

try adding

#define Z_INVERT_MIN

in your config.h

The homing code is designed to go a bit past the point where the endstop triggers, then back out slowly for a very precise reading. If the endstop looks like it's triggered already, it'll just keep trying to back out, giving the behaviour you describe. Makes sense when it's working, but does have a rather non-intuitive failure mode.

---

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

Thank you very much its work now. Now I have to figure out how to build a adjustible z flag so I can home z with different build plats and tapes. BTW wich pin is pin 0 for the thermistor, I gus its analog pin 0 and not digital pin 0.

Thanks Jörg

atztek Wrote:
-------------------------------------------------------
> Thank you very much its work now. Now I have to
> figure out how to build a adjustible z flag so I
> can home z with different build plats and tapes.

could always home Z to max and use the soft limits

> BTW wich pin is pin 0 for the thermistor, I gus
> its analog pin 0 and not digital pin 0.

yep, there's only one analog port so we don't need to specify ports, just pin index

---

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