Project: Teacup Firmware

Just found something interesting.

The AVRISP software for arduino programming from arduino's has found it's way into the examples section for the version 18 IDE. Along with some multi serial stuff for the Mega.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Hi,

I have been hacking around your code, made the following changes:

- removed the extruder stuff (I don't have one so it's no use to me) which reduced the code to 8k
- implemented i2c with Peter Fleury's lib and replaced your stepping macros with i2c functions

I got it to compile but I can't get it to respond properly on the serial connection. I get the Start prompt but not much else

I guess there was a problem in the snapshot I used, taken before you fixed serial to work at 115200.

My question is: Were you able to test the full chain, i.e. serial -> g-code processing Gcode -> stepping -> result OK? Shall I get the latest code?

I'm still waiting for the parts I need to hook up the rest of my steppers, and I'm trying to figure out what responses the host software expects, so haven't tried a full toolchain run just yet.

Having said that, it's always a good idea to try the latest code. git rebase is your friend- it re-applies all local modifications to upstream's latest commit

---

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

I just created an account on git. Sheep was taken so I used the alternate sheepdoll. The project is called HIDAvrGcode.

There is no OSX Tiger PPC support, so uploading my assembly version is going to take some time, as it is hard to deal with macports and locating all the pieces needed.

BTW what are you using to drive the steppers? My steppers are big monsters which are about 120CM in diameter, and require 3.5 amps. I just refurbished the control box, which uses standard step/dir signals. At issue is these only move the MM screw at a rate of 8 inches per minute. ( yes I know I am mixing units. )

The reason I bring this up, is I was considering a firmware solution for microstepping based on the AtTiny25, Most of the solutions only go to 2 amps,

Good luck with the host software, I did some reading on the wiki, and it is all over the place.

-julie

I'm using the A4983 carrier from pololu to drive my 0.44Nm NEMA17s.

I compiled my own avr-gcc toolchain, and use it in conjunction with my favourite text editor. I see no reason why you couldn't do the same on any platform or OS.

I'm not on PPC myself, although there are some around which I'm developing a serious hatred for.


The A4983 datasheet has some interesting information and methods for microstepping- I like how they apply the control voltage to a R-2R ladder, then to a comparator with the current feedback so the chip can digitally define a percentage of the user-provided current limit to cut off drive at. It's a simple and elegant way.

Allegro also make a microstepping translator that drives external fets, however I've read that it performs poorly at high step rates due to a too-large and static crossover dead time.

You may want to check out cnczone and similar sites for stepper driver info- they have lots of folk driving big motors with DIY controllers over there.

---

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

OK, I thought I messed up the serial routine somewhere

I'll get the latest and see what comes out of it.

10x

TinHead Wrote:
-------------------------------------------------------
> OK, I thought I messed up the serial routine
> somewhere
>
> I'll get the latest and see what comes out of it.
>
> 10x


Indeed there was a problem with the serial.

You are checking for the ascii char 10 to get the EOL but my terminal sends 13 (CR). I fixed it, I have a working serial.

Now I can debug my i2c stuff, right now nothing get's moving, I guess either the command is not sent or not received, I'll debug that separately.

I think I'll just have to wait for you to stabilize this a little, it looks like what ever G01 I send it goes to the X axis ... not to step just to heat the motor up.

With EOL most terminals send either a CR LF pair or CR.

It is wise to get rid of the spare LF and detect EOL on CR.

Depends on the terminal emulation.

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

ok I'll make it accept chr(13) as well by popular request- my terminal only sends LF.

On another note, I got my MAX6675 thermocouple translator working last night. Expect a blog post about it soon, and code is in git

Still playing with heater output- I'm using OC0A for PWM, still working out the bugs.

---

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

neato, I have a couple of max6675 eval boards that I use elsewhere in my house ( HVAC ) . I've not used them on the reprap .

Triffid_Hunter Wrote:
-------------------------------------------------------
> ok I'll make it accept chr(13) as well by popular
> request- my terminal only sends LF.

The way I wrote the interactive portion on my protocol was to any one of the following as a single line terminator:

CR
LF
CR LF


The only tricky one is CR LF; which is relatively easy, just ignore the LF if preceded by a CR.

I think it's easier to treat both as end-of-line, and simply do nothing with blank lines- don't even say 'ok'

---

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

BeagleFury Wrote:

Quote
BeagleFury Wrote:
> The only tricky one is CR LF; which is relatively
> easy, just ignore the LF if preceded by a CR.

Use a flag to represent eol. Set flag to ignore whitespace if either Cr or LF is seen, unset flag on next valid non whitespace char.

-julie

sheep Wrote:
> Use a flag to represent eol. Set flag to ignore
> whitespace if either Cr or LF is seen, unset flag
> on next valid non whitespace char.

Only problem with this is it excludes the possibility of empty lines. Empty lines might be important if you are interractive and the user expect to see a new prompt every time you hit the enter key. Triffid is correct that if this is not important, then you can simply ignore blank lines completely, and just use either CR or LF as a terminator; devices that send CR LF would simply be treated as a line followed by a blank line...

The model I proposed does assume that if LF and CR are both sent, CR will always be precede LF. One can work around this assumption with additional state, by ignoring the CR following a LF or an LF following a CR, and passing everything else thru.

Regarding the empty lines, I was thinking in terms of code parsing. Most code languages treat eol chars as whitespace.
Editors and interpreters do act where one gets attention by pressing the enter key, multiple times.
-julie

Hi,

I got it to work

It wasn't a problem with your code, it was with mine, I forgot that the I2C address needs to be shifted thanks to the way the Arduino does this ... :/

Anyway it seems to work up to 1000 mm/min after which the i2c communication fails, I will try increasing the frequency to 400 khz.

Hi guys, I've been very quiet lately because I've been implementing constant acceleration instead of the exponential stuff we have been putting up with so far.

I'm also pursuing a really annoying bug where occasionally, a move will instantly finish without performing any steps leaving startpoint != current_position, but moves entered afterwards also won't do any steps until some magic condition is met and everything jumps back into life. Only seems to happen at really high step rates (>20m/min {yes, meters!}, 14000 steps/s), and entering a short move with no acceleration seems to unstick it most often. Any help tracking this down will receive showers of praise.

Apart from that I've clocked my firmware at over 35 Ksteps per second (50m/min @ 42 steps/mm), where acceleration is paramount even with unloaded motors. At this speed, the stepper shaft spins so fast that it almost looks like an electric drill. Here is the advantage of feeding 12v into 2v motors

---

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

Triffid_Hunter Wrote:
> Apart from that I've clocked my firmware at over
> 35 Ksteps per second (50m/min @ 42 steps/mm),
> where acceleration is paramount even with unloaded
> motors. At this speed, the stepper shaft spins so
> fast that it almost looks like an electric drill.
> Here is the advantage of feeding 12v into 2v
> motors

Awesome. Gives me something to look forward to on my own spline rewrite; I'm getting loop cycle timings in the same order of magnitude (a bit smaller, I have to hack thru more bits that you per axis, I think.)

Still need to steal your comms logic too; I've been focused trying to get working usable software in a simulated environment, on both host and firmware side.

Adrian has just posted a ton of info on the current gcode commandset up on the wiki, apparently we can get line numbers and a checksum now.

As for comms logic, I've integrated the ringbuffers into my serial.c and simplified by requiring buffers of size 2^n so there's no better time!

---

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

Hi !

Good news I'm keen on trying the new acceleration code. I'm still to dumb of a git user to get that rebase thing working, so I'll just have to diff your code back into mine.

Regarding the bug I stumbled on it too but at sane speeds, i.e 300mm/min or so, I guess my I2C stuff makes the code slow enough for the bug to occur at lower speeds, I'll keep an eye on it.

hey Triffid_Hunter take a short movie of that motor spinning. That would be fun to see!

If it had any torque that would make the platform fly!

Hi all,

Let me first stress that I don't actually have my motors hooked to any hardware at this point, and I have no endstops connected. I'm just watching the motors spinning back and forth with clothes pegs attached, and listening to the sounds they produce.

I'm currently about an hour into a test run with my firmware and it's looking good so far- that is, the motor sounds seem about right and it hasn't done anything bizarre yet.

I wrapped some nichrome around my thermocouple and tuned the PID loop. Its configuration should be amenable to real extruders. Also, the PID parameters are saved to EEPROM so they survive resets and firmware updates.

I had to enable skeinforge's "extruder always relative" option (with corresponding firmware change) otherwise it overflows a register after several meters of filament.

I accidentally fried my atmega168, so I got a pair of '328s to play with- however my firmware still fits into the 14k available on a '168 with bootloader even with all the debug output enabled. I updated the makefile to tell me sizes for both chips. At the moment it's very tight for the '168, however most of the flash is consumed by debug output code.

The glitch I'd been tracking seems to have disappeared, so either my '168 was already partially fried, or I fixed it while changing something else.

This firmware is now ready to be tested on a fully built machine, although most host-side "talkers" may not think much of the volume of debug info it currently produces.

I have created a file of host-side utility functions, func.sh. instructions within, and those versed in bash scripts will figure it out pretty quickly. It contains a talker (mendel_print function) as well as a slab of debugging utilities

My next task is to clean up all the debug info, maybe create a bitflag register and corresponding M-code or something.

---

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

Hi Triffid !

So is the code in a more or less stable state now?
Also are you planning on adding deceleration too?

TinHead,

It's getting more and more stable all the time- no promises though, as I'm still experimenting with things

deceleration is simply negative acceleration, and already handled by the constant acceleration algorithm I shoehorned in

---

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

I've downloaded your code and have started to make the modifications needed for it to drive my (still incomplete) machine.

The main modification that my machine needs is my X,Y,Z axis use a found stepper controller that expects two coil polarity pins per stepper rather than step and direction, while the extruder driver is one of the pololu drivers, and needs step and direction. The found drivers need "graycode" which requires an extra few bits of storage per stepper, some changed code, etc.

I love how you've done the dda, I was able to change to graycode without making any changes to the dda code at all. Just a few lines in pinout.h, and extra (and quite short) source file, and a header included in dda.c The compiler throws a warning about "statement with no effect" for each of the now unused calls to "unstep" but I figure that's OK.

My arduino is a 168 and the change bumped the size up about 150 bytes or so.

I went searching for space to save, and found something odd. In gcode.c around line 647, there's an #endif for a #ifdef DEBUG that can be moved down to around line 702, effectively removing report current position and read/write abritrary memory location commands. These are already marked as DEBUG, but they're not commented out... So I commented it out and now it fits with space to spare. Just need to find time to load it now...

I also found it strange that making checksums and linenumber required instead of optional reduced the code size. Odd. But whatever. Thanks for the code.

---

--
I'm building it with Baling Wire

i was wondering if there was not a way to make this code more modular in design. so that you could just put in your stepper drivers module, and help clean up the code that way

---

[mike-mack.blogspot.com]

It's quite modular enough. The fact that I was able to change from step/dir to graycode without modifying the dda routine speaks volumes. Positively wonderful for something that is compressed as much as this is.

I've been told that source code is like a gas - it will expand to fill any available space.

I've found that source code is like a gas - when you try to fit a lot of it into a small space it becomes quite difficult (read: impossible) to work with. I've written for microprocessors before. In retrospect, I should have insisted on a larger code-space PIC, thrown the current code out, and started over from scratch. Hindsight...

This code is, from what I've seen, nowhere even remotely close to that point.

---

--
I'm building it with Baling Wire

dissidence Wrote:
-------------------------------------------------------
> i was wondering if there was not a way to make
> this code more modular in design. so that you
> could just put in your stepper drivers module, and
> help clean up the code that way

The issue with microcontrollers is that broad-spectrum modularity massively increases code size. I have endeavoured to strike a balance between modularity and code size that favours the latter without tipping the scales completely.

In theory, the official FiveD firmware should exist closer to the modular end of the scale since it's written in C++, uses floats everywhere and does most things in logical places rather than size-optimal places.

As jgilmore has noted, it should be fairly easy to replace some of my routines with whatever you like, but others are tightly wound in such as the float->integer conversion during gcode interpretation because doing it any other way takes significantly more ram and flash space.

jgilmore Wrote:
-------------------------------------------------------
> The compiler throws a warning about "statement with no effect" for each of the
> now unused calls to "unstep" but I figure that's OK.

Since there's only one call to unstep() at the very bottom of dda_step(), you could just remove it or wrap an ifdef around it or something. In my machine, that macro de-asserts all the step signals in one go, hoping that they've been asserted long enough for the driver to get the picture.

> I went searching for space to save, and found something odd. In gcode.c around
> line 647, there's an #endif for a #ifdef DEBUG that can be moved down to around
> line 702, effectively removing report current position and read/write abritrary
> memory location commands. These are already marked as DEBUG, but they're not
> commented out... So I commented it out and now it fits with space to spare. Just
> need to find time to load it now...

Unfortunately some of my latest changes have pushed the debug size above the 14k available on a '168 with bootloader. I'm using the debug flag to enable/disable firmware-generated debug output without affecting host-oriented debugging functions. At the moment, this makes enough space difference to fit the firmware into 14k while retaining at least some debugging functionality. This can easily be changed as you've noted, and I will make this easier to alter in my next push.

ps: let me know how you go with the heater PID stuff. check out M130-M134 in gcode.c for tuning, and there are defaults in temp.c which work nicely for my nichrome wrapped around my temp probe with no barrel in place.

If you haven't done PID tuning, P factor is for basic reduction of delta, I factor is for long(ish)-term zeroing in on the best output value, and D factor prevents the temperature from changing too quickly and oscillating or overshooting. D should be negative or it will encourage oscillation. I-limit prevents the I-value from becoming so huge that P and D can't reign it in when the temp approaches the set point. I find that I limit * I factor should be about 192.

---

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

Hello all,

my RepStrap is currently in a state where I can exercise a stepper with the test code on [reprap.org] .

Next step would be to exercise the stepper with some SNAP or GCode. So I tried to get FiveD on Arduino as of February 22 running on my generation 2 electronics, Arduino Diecimila, ATMega168. As I couldn't figure the required parameters for avrdude, I simply did a "echo > mendel.pde" and lo and behold, everything compiles and uploads fine with the arduino-0018 IDE.

I even get a

Start
OK

in the serial console. But every attempt to send some GCode manually results in odd behaviour. After typing "M1", a M is sent back, but not the 1. Something like "G0 10 10 10" results in the previously missing 1 being printed, and a few more characters, but nothing looking like an action or even a new "OK".

What might be missing?


Another question is, how the pinout relates to the physical connectors. The X axis is defined to "AIO0" and "AIO1". Are these the first two of the six analog inputs? Is it even possible to run this firmware with just one stepper connected?


Last not least, how would you prefer to receive patches? A .gitignore file wouldn't be that bad, for example ;-)


Thanks,
Markus



P.S.: I think it's a good move to drop the C++ stuff, as the ++ is actually a -- for realtime and high performance code.

P.P.S.: Actually, I tried as well to use one of the older firmwares, but the SVN repo seems to be pretty much messed up in this area.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY