Experimental Gen3 Mendel firmware

quick history.
I had bought the electronics for my mendel build from makerbot back in December. When trying to run the firmware the motherboard would reset after a random number of instructions. Searching the forums for a solution and I discovered that the Gen6 mobo was being released, and the common answer was 'wait for it to come out'. So I decided to roll my own after spending days digging through source code.

I seem to be getting decent results with it but I am still waiting on a hot end so it isn't complete by any means. I feel that most of the meat of the program has been completed though, and would like to release the source code if there is interest.

It's been written for a printer using a stepper filament drive, so DC drive motion isnt supported. Re-purposing the max limit switch inputs as out puts, a 1.2 motherboard can control the stepper motors for the X, Y, Z, and E axis. My main objective was to get something to work, so the code is far from pretty in spots. I did however want to add velocity and acceleration control along the XY axis. It doesn't use the DDA algorithm, instead it it breaks the XY vector down to its component vectors and derives the timing of the pulse chain from there. The E axis is also manipulated to accelerate in tandem with the XY vector.

I dont have the hot end yet for this thing, so there is no code to support heater control or temperature readings.

The code does support a small LCD using the SD card reader's control lines and the debug output. It does the job but the amount of data transfer needed to update the LCD slows things down dramatically.

The project is not in Arduino, but AVR Studion 5. I am sure it can be adapted to fit into and arduino project, I just rather work with AVR Studio and program via the ISP.

The motion controls seems to handle skeinforge 39 gcode run from replictorg without an issue. RepRap host does not like some of my STL files so I havent tested with it.

When I get home this evening I will post the source code up on google code unless there is a more preferred place for this kind of thing.

I'm interested in your acceleration algorithm, particularly how you avoid geometric errors with per-axis accelerators.

As far as source repositories, we like git- github and gitorious are two free hosts for git repositories

---

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

Me too New ideas on acceleration are always welcome.

Google Code will work fine. Most RepRappers are used to Git, and use Github, though.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

New interest in understanding the problems involved in the acceleration algorithms.

Im a little confused I thought that 5D uses acceleration algorithms for printing hence its not 3D.

I'm Sorry if these are realy Dumb questions.

Question One are there problems with these algorithms in:-

1/ The regular reprap Firmware?

2/ The Tonkip variety of Firmware?

3/. The Teacup version of Firmware?

4/. Any other I have not thought about?

Question Two.

I've got the wrong end of the stick altogether and you just want to see another method / possibly faster method.?

Question Three.

Is this the reason Nophead dosen't use G code to controll his printers?

Question Four.

Where is the best place to look understand the concept and application of these algorithms within the diffrent tool chains?

---

Bodge It [reprap.org]
=======================================

---

BIQ Sanguinololu SD LCD board	BIQ Stepcon	BIQ Opto Endstop
BIQ Heater Block PCB	BIQ Extruder Peek clamp replacement	BIQ Huxley Seedling
BIQ Sanguinololu mounting	BIQ standalone Sanguinololu or Ramps mounting	Print It Stick It Cut it

My rep strap: [repstrapbertha.blogspot.com]

Buy the bits from B&Q pipestrap [diyrepstrap.blogspot.com]
How to Build a Darwin without any Rep Rap Parts [repstrapdarwin.blogspot.com]
Web Site [www.takeaway3dtech.com]

Realized that some how I've broken the F parameters and would like to have that working again before it's released.

Keep in mind I am VERY green to the RepRap project period.

First and foremost, I decided to build a reprap to help me finish a series of projects Ive been developing and needed some means of rapid prototyping. I was hoping for something a little less hands on as I didnt build the Sells as a project in and of it self. Not that it is out side my abilities, just not how I wanted to spend my time right now. Which explains why I was wanting to write some firmware that would just get the thing working.

With a little research recently I understand the main objectives of the other versions and think they all address them very well. This takes more of an OOP tactic because, in my experience, its easier to maintain objects compared to a library of special functions. OO does have a bit of overhead so I had to choose between sleek and slim or easy to maintain. I chose what works best for me.

Triffid_Hunter:
Putting a pencil on the print head, the drawing matches what the part is supposed to look like. Not sure how that translates to extruded plastic but the geometry looks like it should.

BodgeIt:
Question 1
I was having issues getting the reprap firmware to run with out resetting the processor. Trying to find the offending bit of code was testing my patience to be honest. As to why I did not try Tonkip or Teacup? I didn't know of their existence. I've been working on this for some time before I discovered there was something other than the main stream version.

Question 2
I am not familiar wiith DDA and needed something that worked. I have a good understanding of vector math so thats what I used. Is it faster? possibly. I dont have a benchmark to use.

Question 3
No idea.

Question 4
Not really sure either. Quite possibly the DDA section, gcode handling, etc etc, it's all handled quite differently. Is it better, worse, same? I couldnt tell you


Had I'd known other versions were available at the time, I would have tried those. I feel a bit committed to seeing this one at least attempt to build a part. My intentions are not to out perform an other version, I just wanted something that worked . If some of the methods I've applied can be used to make something better, great. If it isn't going to help improve anything and just be cast aside, Im fine with that too. The better methods usually always prevails and thats how it should be!

CodeRage Wrote:
-------------------------------------------------------
> Realized that some how I've broken the F
> parameters and would like to have that working
> again before it's released.

Release Early, Release Often - potential co-developers like something to play with, even if it's not fully working!

Teacup has no releases yet, just a fairly active git repository

> Question 2
> I am not familiar wiith DDA and needed something
> that worked. I have a good understanding of
> vector math so thats what I used. Is it faster?
> possibly. I dont have a benchmark to use.

If you're familiar with vector math, you probably wrote a Digital Differential Analyzer without knowing its name

Bresenham's line algorithm is one example of a DDA.

> Had I'd known other versions were available at the
> time, I would have tried those. I feel a bit
> committed to seeing this one at least attempt to
> build a part. My intentions are not to out
> perform an other version, I just wanted something
> that worked . If some of the methods I've
> applied can be used to make something better,
> great. If it isn't going to help improve anything
> and just be cast aside, Im fine with that too.
> The better methods usually always prevails and
> thats how it should be!

One of the things I love about the reprap project is that when we reach a fork in the road, we take both ways as a community. Because of this, we have covered immense tracts of experimentation and discovered quite a number of big quality improvers, and uncountable numbers of small ones.

SO I support having multiple firmwares out there with differing goals, it's healthy for the community. Klimentkip/carukip is designed to be simple, teacup is designed to be comprehensive yet small, official FiveD is designed to bootstrap the whole firmware thing and be a baseline.

Give yours a name, decide what niche you'd like to occupy and post early with a list of known issues

---

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

A little late but here it is.

[code.google.com]

Not big on names but the alliteration appealed to me.

Be easy on me, please. The acceleration and velocity code is located in the axis class. Had a small bug in the acceleration equation that I just addressed. I am hoping that it will smooth out the acceleration of the axis when maintained through the main gcode class.

There is a LOT of floating point math, I've kept it out of the interrupts, but it's use in the time stamping for the next step seems to me a bit excessive.

This is my first real open source contribution so please be easy on me :]

after sorting out some case-related stuff (everything except windows is case sensitive ), this compiles with

avr-g++ -DF_CPU=16000000L -o repraprage.elf -mmcu=atmega644p *.c -lm -lc -lm

architecturally, you're running a clock from a timer then busy-looping and waiting for it to reach a certain value before stepping

I'll have a closer look at your code soon

---

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

Have you tried to max out a stepper with this firmware, yet? How many steps per second can you reach?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Yup, thats about the gist of it. Using Toricelli's equation to determine after how many step will it take for the gantry to reach final velocity. If the gantry is in the acceleration stage it determines at what time the axis should be pulsed based on it's position and acceleration. The Cartesian class splits everything up into component vectors before the move. In all reality though the floating point math in axis::time is really slowing things down...

I am starting to eye the mini2440 thats been sitting on a shelve waiting for a project. Torn as to what to do.

Traumflug Wrote:
-------------------------------------------------------
> Have you tried to max out a stepper with this
> firmware, yet? How many steps per second can you
> reach?


It all depends on how many axis run at a time. Ill put the logic analyzer on the X axis and run it back and forth from 200,200 and 0,0 and get back to you

CodeRage Wrote:
-------------------------------------------------------
> Yup, thats about the gist of it. Using Toricelli's
> equation to determine after how many step will it
> take for the gantry to reach final velocity. If
> the gantry is in the acceleration stage it
> determines at what time the axis should be pulsed
> based on it's position and acceleration. The
> Cartesian class splits everything up into
> component vectors before the move. In all reality
> though the floating point math in axis::time is
> really slowing things down...

not familiar with toricelli, but it looks the same as equation 16 in this fascinating article

> I am starting to eye the mini2440 thats been
> sitting on a shelve waiting for a project. Torn
> as to what to do.

I think that 2440 would make an excellent control panel, but systems that big aren't so great at the hard real-time requirements of generating step pulses without a lot of fiddling around..

Better off using it to pre-calculate all the math for a move then dump a binary blob down to a smaller chip which can then concentrate on generating step pulses at the exact right instant. That's how nophead gets his amazing prints

---

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