Hello everyone

I have been very busy lately rewriting the RepRap Arduino G-code firmware for purposes in fact not directly related to RepRap (PCB milling and other subtractive processes), but which I think will be interesting and useful to people here. Therefore I am posting my efforts. The main improvements are as follows;

1. Stepper control is done in an interrupt routine controlled by a hardware timer, allowing for smoother stepping with more accurate feedrates. Most importantly, this means stepping is synchronous whereas reading and interpreting G-code is synchronous. This is important for point (3) below.

2. Acceleration - the steppers will smoothly accelerate from a standing stop up to the desired speed, at a rate set in the _init.pde file. They will also decelerate at the end of the move. This means much smoother movement and fewer lost steps when moving at high velocities (most of all with G0 moves).

3. Lookahead - the system will read and process the next move while a move is being made. If the next move is reasonably parallel with the preceding move (decided by looking at the change in velocity in each axis and comparing with a constant in _init.pde) then it will not decelerate but continue in one smooth move. This means that something like

G0 X10
G0 X20
G0 X30

will execute as one move equivalent to

G0 X30

with minimal pausing between moves.

4. Improved arcs - I was rather stung by some criticism that I received for my earlier G2 and G3 (arc) code for the RepRap firmware. Therefore I have rewritten it using an implementation of the midpoint circle algorithm, meaning that arc moves are now true arcs with step-level accuracy. Helical moves (arc with simultaneous Z-axis movements) are also supported, and arcs work correctly with the lookahead feature.

5. Faster reading and processing of G-codes

6. True G0 moves - for G0 moves, movement will now be carried out with maximum speed in the dominant axis. Before, the maximum speed applied to the move as a whole, so that diagonal moves were being carried out at below maximum speed.

7. Completely separate metric and inch constants - all the constants in _init.pde are defined for both millimetres and inches. Of course in reality, I suppose most people will only use one or the other.

8. Various minor bugfixes etc.


There's a few things to be borne in mind. Firstly, I don't have an extruder on my machine so I have been unable to test that the extruder/fan etc. is still working. I haven't really touched much in this code but I would appreciate if someone could verify that this is OK.
Secondly, it has been a real struggle to get all this to fit inside the 14.5k or so available on the Arduino. Therefore, there some possibly hard-to-read sections of code where readability has been sacrificed for size (and sometimes speed). I have commented the code as best I can but please don't complain that it's not the neatest piece of programming ever. Also, I have included optimised versions of several routines from the Arduino code in optimal_routines.pde - by doing this, about 1k has been saved.
Thirdly, I work with metric units. I have done some basic testing with inches but not as extensively. Again I would appreciate feedback here.
Fourthly, make sure to set up the constants in _init.pde properly. For example, if you had a maximum feedrate of 1000mm/min with the old firmware, it will not actually have gone that fast because the delay between steps would have been smaller than the time to take them. With the new code, the hardware timer will actually try to take steps at this rate and your motors will very likely stall. So be prepared to adjust your settings. My motors stall in any case at anything faster that about 300mm/min so I have no idea if the code can handle anything faster than that.

Please, please, please try this out and give some (constructive) feedback. I can understand if people say "half of this is quite unnecessary for RepRap" but it is all things which I have needed for my own work, and which perhaps might be useful to others too.

I would recommend the most up-to-date version of the Arduino software since I had some problems with function prototypes in earlier versions.

All the best,

Chris Meighan
[www.chrismeighan.com]

Hi Chris,

Thank you so much for posting this. I am still struggling to get gcodes to work properly, so I'm happy to try new firmware to see if it fixes things.

Setup: windows pc, single-arduino reprap

Background: i have moderate success using replicatorG_0001, with the arduino running gcode interp from reprap-arduino-firmware-1.3. there are still strange intermittent problems where replicatorG hangs, or it appears comms drop out between pc and arduino. could not get replicatorG0002 to work. things work pretty well with the RR Host running things, so i begin to suspect software instead of wiring/hardware... anyway thats the background...

so i happily downloaded your new code and tried to compile with arduino_0011, and that did not work at all, as you mentioned might happen.

got arduino_0012 and now the code compiles ok, but gives this error:

Sketch too big; see [arduino.cc] for tips on reducing it.

Binary sketch size: 15516 bytes (of a 14336 byte maximum)

-----

The board is set to Arduino Diecimila, and your code is in a folder on the desktop named "reprap_new_firmware". i compile by opening reprap_new_firmware.pde with Arduino and clicking the "verify" button - maybe i'm compiling it wrong, not sure.

Anyway, this is probably not the type of feedback you were hoping for, but if you could offer any pointers they would be most appreciated.

Thanks! - pumper

Pumper, Chris, et al,

I haven't tried this yet, but (from reading Chris') message, in which he wrote:
>
> Also, I have included optimised versions of several routines from the Arduino
> code
> in optimal_routines.pde - by doing this, about 1k has been saved.

I suspect that the optimized routines are required to save space, and they were either not being picked up properly -- or your compile included both the optimized and originals of those functions.

Chris,
If you could give some more detailed info on which files need to be put where, that would be much appreciated -- especially for a nearly-arduino-newbie such as myself. Your Gcode interpreter sounds great -- and (in fact) was a major factor in my getting off the fence and starting to build a cartBot to repStrap with. Like you, I'd like to be able to do both additive and subtractive machining.

Best regards,

Larry Pfeffer

> I suspect that the optimized routines are required
> to save space, and they were either not being
> picked up properly -- or your compile included
> both the optimized and originals of those
> functions.
>
> Chris,
> If you could give some more detailed info on which
> files need to be put where, that would be much
> appreciated -- especially for a

The optimised routines are in the file optimal_routines.pde which is part of the archive I posted. They have different names to the Arduino firmware versions so that they get compiled in instead, so in fact you shouldn't need to do anything special.

I think what the problem is that I have been using the latest version of the Arduino frontend in Linux, but a slightly older version of the AVR libraries. I have noticed before that the most up-to-date versions take up more space. If you are using Windows, then the libraries are packaged together with the Arduino software, and so they are probably the most recent (thus too big) versions.

What I will need to do is try compiling it with Windows and see if I can get the code to fit. I am very busy this week so it will probably not be until next week that I can look at it, sorry

Chris Meighan
[www.chrismeighan.com]

Hey Chris - thanks tons man!

I'm looking at the software now. It'll be a bit before I get to try it on my Darwin, as I've got the old stuff working acceptably at the moment and I don't want to kill it just yet, but it sounds like you've fixed all the issues I've been having with the software.

I've been using Zach's Experimental Gcode Interpreter because it supports his magnetic encoder for the extruder; I'll have to hack that into your code, but hopefully it shouldn't be too hard. I wanted to switch it to a timed interrupt anyway, so this is a step in the right direction. Since we're a little tight on memory anyway, this might be a good time for me to fire up the Sanguino kit I've got.

One thing - did you mean that reading and interpreting Gcode is asynchronous in the original post? Versus synchronous stepping - that'd be great, if we could de-couple reading and interpreting Gcodes from actually executing the step commands. That's what I wanted to do, but I don't quite have the coding skills to do that. Yet.

Anyways, I'm stoked on this, more later!

Wade

Hi Chris,

Wow, wonderful work.

Another way of shrinking the Arduino code is to preprocess everything you can, like inch to metric conversion & relative moves. All the Arduino would have to do is line, arc, accelerate & control the extruder. Everything else could be processed beforehand with a script.

An example of a preprocessing script is gcode_step in export_plugins in skeinforge. Preprocessing scripts are easy to write because you don't have to optimize your code for space or speed.

To answer Wade's question, yes, decoding of G-code is separate from stepping. The first is done in the main loop, and the second in a timed interrupt routine. This means that the next command can be read and decoded while the current one is being carried out - this is necessary in order to make a decision about whether to decelerate and accelerate between moves or just keep going. It also reduces to almost zero the pause between moves.

Good luck with hacking in the magnetic encoder code, I have had such a hard time getting all this to fit. "a little tight on memory" is one hell of an understatement!!! One option which I have been considering is setting up defs so that you can optionally leave out certain bits that you are not interested in - acceleration, arcs, extruder - when memory is tight. A completely modular approach would be better but we don't have the space for that.

Obviously with the Sanguino there's a lot more room, but for now I would like to keep this in reach for people (like myself!) with just the Arduino.

> Another way of shrinking the Arduino code is to
> preprocess everything you can, like inch to metric
> conversion & relative moves. All the Arduino
> would have to do is line, arc, accelerate &
> control the extruder. Everything else could be
> processed beforehand with a script.

That's true, not sure how this would work with G-code from other sources. For example, I have been using software like CamBam to do subtractive milling, and experimenting with pcb-gcode for PCB isolation routing. It's not always so easy to control the output of such software so I would rather that the firmware does as much as possible.
Actually, the inch to metric and relative moves etc is in fact a pretty tiny part of the firmware code compared to the things like acceleration and G-code decoding. But of course any reduction in size helps.

Chris Meighan
[www.chrismeighan.com]

For handling gcode from other sources, whatever code the Arduino is using to process those commands would be ported over to the preprocessing script. So if the Arduino can handle it now, the script should be able to handle it also.

Indeed, the code for each conversion is tiny, but there are many of them. The inch to metric and relative moves were the first that came to mind. Also, one of the arc code formats could be converted to the other format, whichever is easiest to process. For example if the Arduino code for handling arcs in I, J format is shorter than the code to handle radius format, than the script could convert all radius format codes into I, J codes. Also, the lookahead system which converts
G0 X10
G0 X20
G0 X30

into one move equivalent to

G0 X30

could be handled by the script.

I don't know all the cases that the Arduino handles, but all the little code handling for each case adds up.

When I try to compile this on a mac (from arduino 12 host software), I get:

In function 'void RR_setupSerial()':
error: 'UBRRH' was not declared in this scope In function 'void RR_serialWrite(unsigned char)':
In function 'void RR_analogWrite(uint8_t, int)':
In function 'void SIG_UART_RECV()':

Thanks Chris!

Code was WFT release (Works First Time) using Arduino 0011 Alpha.


Only by setting the Arduino com: port up on the PC as a generic serial printer.
Was I able to Cause some overrun of the Arduino serial buffer.
I will take a look and will look at xon/xoff for flow control the extra code could be too tight on the Arduino.

I will also take a look at using Arduino 0012 tomorrow time permitting.

Tried your code Just after getting Replicator G 002 going after a couple of hours of fiddling. I think Its a race condition on the serial receive with old firm ware and Replicator G.

Bodge 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]



Edited 1 time(s). Last edit at 01/11/2009 03:19AM by BodgeIt.

I try to summarise my case:
I use ubuntu 8.10 (intrepid ibex)
The avr versions:
ii avr-libc 1:1.6.2-1
ii binutils-avr 2.18-3
ii gcc-avr 1:4.3.0-2

arduino 0012

I needed to extract the .zip files in a directory named 'reprap_new_firmware', else the arduino software pop-upped a dialog, asking permission to create this directory and copy the reprap_new_firmware.pde file into it. I needed to manually copy the other files too (into the same directory), because it complained reprap_new_firmware.h: no such file.


Now, i have this compilation error:

o: In function `extruder_set_direction(bool)':
multiple definition of `temptable'hardware/libraries/ThermoplastExtruder/ThermoplastExtruder.o:/home/lama/Desktop/down/eddigi_dec18/arduino-0012/hardware/libraries/ThermoplastExtruder/ThermoplastExtruder.cpp:78: first defined here

/home/lama/Desktop/down/reprap/reprap-new-firmware/reprap_new_firmware/applet/core.a(wiring_analog.c.o): In function `analogReference':

/home/lama/Desktop/down/eddigi_dec18/arduino-0012/hardware/cores/arduino/wiring_analog.c:35: multiple definition of `analog_reference'

o:/home/lama/Desktop/down/reprap/reprap-new-firmware/reprap_new_firmware/applet/reprap_new_firmware.cpp:623: first defined here

I would like to ask, which exact library versions are needed?
So Im curious about the versions of these packages:
arduino
avr-libc
binutils-avr
gcc-avr

Im out of luck with the firmware packages...

Hi

I only know a little about Windows. At one time you could only use Arduino 011, O12 gave errors. I don't know if that is still the case.

Have you read the info here?

[objects.reprap.org]

Regards

Ian



Edited 1 time(s). Last edit at 01/15/2009 12:48AM by Ian Eagland.

Hmm, if I remove arduino-0012/hardware/libraries/ThermoplastExtruder directory, it compiles successfully.

Why there is a conflict? (the ThermoplastExtruder comes from the Gcode-interpreter in reprap-arduino-firmware-1.3.zip file).

But the size are too big:
Binary sketch size: 15462 bytes (of a 14336 byte maximum)

Bigger then 1kB, its huge...

So why is that enourmous difference between different avr-gcc?

Which are the "lucky numbers"?

Ok. There is something definitely going on.

I tried to compile this firmware using hardy avr-libc package.

1. I downgraded avr-libc to 1.4.7 (from 1.6.2).
2. I deleted all the .o files from arduino-0012/hardware/libraries/*/*.o
3. Compiled in arduino-0012

Now the binary sketch size is 15684 (it was 15462).

I try to hunt down the right combination of packages...

I downgraded avr-libc to 1.4.5 from here:
[blog.coldtobi.de]
The resulted codesize: 15722 bytes (from 15684).

I downgraded the gcc-avr from 4.3.0-2 to 4.1.2 (from the same blog).
The resulted codesize: 13780 bytes

I upgraded the avr-libc to the default one (in intrepid): 1.6.2-1
The resulted codesize: 14600 bytes


Summarization:
Maximum size: 14336 bytes

avr-libc 1.6.2 (default in intrepid 8.10
gcc-avr 4.3.0
codesize[FAIL]: 15462 bytes

avr-libc 1.4.7 (default in hardy heron 8.04)
gcc-avr 4.3.0
codesize[FAIL]: 15684 bytes

avr-libc 1.4.5
gcc-avr 4.3.0
codesize[FAIL]: 15722 bytes

avr-libc 1.4.5
gcc-avr 4.1.2
codesize[PASS]: 13780 bytes

avr-libc 1.6.2
gcc-avr 4.1.2
codesize[FAIL]: 14600 bytes

Im going to sleep now, but I will try the improved firmware tomorrow, or in a few day!

Thanks for the new firmware, it promises much improved quality by removing the pauses between commands, but I am having a few problems. The first is that resetting the origin with a G92 hangs unless I insert a pause. The length of the pause needs to be long enough for the endstops to be reached. The 5 seconds in the attached code is not sufficient for general use. Is there a better solution than this?

G21
G91
G0 X-3000
G0 Y-3000
G0 Z-3000
G4 P5
G90
G92 X0 Y0 Z0

G1 ... etc

I am also having problems with erratic speed when filling a rectangle with diagonal lines, but I have not yet been able to produce a small file to demonstrate the problem. Has anyone any experience which might point me towards a solution?

I got this compiling on arduino13_linux2 for an atmega328. I had to switch back to the arduino provided functions instead of the optimized ones but it looks like the 328 will work great!

Binary sketch size: 15552 bytes (of a 30720 byte maximum) (yay!)

hi,

i've been looking for G-Code interpreting firmware only (without the extruder functions) for the arduino for some time now.

i like your work, and thought that i could customize your work by commenting out the (for me) unnecessary items but no luck.

would you please be kind and post the G-code only firmware for the arduino ?

thank you in advance

Hi Chris,

I found your rewrite intriguing, especially the overload of built-in Arduino functions.
However, I didn't get the latter to work; I've tried it on various versions of the Arduino IDE, although only on Mac OS X, but always get issues with multiple definitions of global variables.
I was wondering if you have any insight into why this is and some experience with known-to-work combinations of your code, Arduino IDE version (and OS if that matters).

Cheers,

~/= Marius

--
We are Elektropeople for a better living.
[reprap.soup.io]
[www.metalab.at]

I downloaded the older versions of avr-gcc and avr-libc from [ a href="http://blog.coldtobi.de/1_coldtobis_blog/archive/21_updating_avr-gcc_binutils_to_get_the_devices_update_now_also_includes_deb_files.html"] here [/a] as instructed, and got the error (among others) of as: unrecognized option `-mmcu=atmega168'. avr-gcc was calling /usr/bin/as instead of /usr/bin/avr-as. I fixed it by renaming as and symlinking. hopefully I'll remember I did that the next time I try to compile something...

This looks like a wonderful bit of work though. Kudos to Chris for doing it. Running out of space on a microcontroller is no picnic! I'm impressed that you managed to get it all to fit. And you're right on the money about the sanguino being nice, but not what a lot of people have. I'm using the arduino still, and thank you for taking the time to get it to both fit and work in the space available.

Now to resolve the rest of those pesky errors and upload it! (I'm not using the arduino java thingy... I dislike java so very much)

---
Of course, you could probably achieve the same effect with a couple of bent paperclips and some duct tape. But that's true of most things. -- Steve DeGroof

Hi,

I am trying to compile reprap_new_firmware, I am using windows Arduino 11 and using the librarys that came with reprap-arduino-firmware-1.3


I get the following error message;


o.data+0x11): multiple definition of `temptable'
hardware\libraries\ThermoplastExtruder\ThermoplastExtruder.o.data+0x0): first defined here


C:\DOCUME~1\Mick\LOCALS~1\Temp\build12676.tmp\core.a(wiring_analog.c.o).data+0x0): multiple definition of `analog_reference'


o.data+0x66): first defined here
Couldn't determine program size: C:\Documents and Settings\Mick\Desktop\MCU's\arduino-0011-win\arduino-0011\hardware/tools/avr/bin/avr-size: 'C:\DOCUME~1\Mick\LOCALS~1\Temp\build12676.tmp\reprap_new_firmware.hex': No such file


I should also point out that in different versions of Arduino I seem to get different error messages.

Any help would be fantastic.
Thanks in advance.

Michael.

Sorry about all those smileys! Not sure what happened there!

Michael.

Micheal: Read back on this thread, I had the same problem.

Basically you need remove other reprap firmwares, and leave only the
one what you want to compile.

It is sad, the original author never came back to this thread. :-\

Khiraly

Thanks for your reply, I managed to email chris a while back and he advised the same, and of course it worked. Chris is travelling for a while hopefully when he's done he would like to progress the firmware further.

The lookahead works well as does the ramp up /down but I think I may of hit the limit for the step frequency on the arduino!!

Thanks
Mike

Hello People...........

I have been using this firmware with no real probs on a Duemilanove, I have just been trying to upload to a Nano? No sucsess, I can get it to upload using Arduino 16, However It does nothing the Led on the nano just flashes once a second ( I mean the Led connected to pin 13? (I think) not the TX/RX led's.

Has any one else tried and did it work????

I have a also had problems with the Deumilanove with hitting the max step rates, Has anyone tried running the Arduino's at higher than 2Mhz?

Any help would be a god send right now as I still can't get hold of Chris Meighan.

Michael Duffin.

Hmm, As this seems to of died of death i'll answer some of my own questions for other peoples future reference.

The Nano's do work fine, I was lucky enough to have one with a duff bootloader!!

And I beleive I have altered the timing of timer1 on the arduino correctly, It no longer divides by 8.

I had to multiply the delay value for this new clock speed, else moves were simply completed 8 times faster than they should of been!

I seem to be able to step at much higher rates than before but still not as high as I would expect running at 16Mhz, Hopefully one day someone will be able to explain why?????

Should any one return to this thread.

Hello,

Can someone help me out what is the difference between the new Sanguino Gen 3 firmware and Chris's Gcode interperter?

Will the Generation 3 Firmware do machining on a cnc subtractive process?

Cheers

DeWayne