Ardunio G-Code Parser

i updated the documentation page on the wiki: [reprap.org]

please let me know if there are any errors.

i'm looking forward to doing some drawing with GCode later this week.

Well time for my contribution to the bike shed color problem...

I know that G code is quite common, especially here in the states, but there are better options out there. G Code was great for non intelligent machines as it could be implemented with a calculator or the computer in your wrist watch. G Code relies on having the complicated bits done in pre-processing, determining things like feed rates, RPM, chip loading, ect. I seem to recall a sub standard to CIM techniques that moves machine control one step lower in the chain. So that you send a different file to the machine, then the machine makes the G Code or what ever it requires to run. Check this link about CIM.

[en.wikipedia.org]

[ieeexplore.ieee.org]

Heres an example about this sub standard as it would be used by a milling machine. When you compile your G Code you write it special for the machine your going to run it on. If you have multiple machines you need to re-write that code for multiple machines or you need identical machines. This CIM sub standard would specify a surface footage, min and max chip loads and such parameters, rather then RPM and FPM. Then the machine would decide what tool to use, what RPM can it use for that tool, and what FPM it can use. Making one code for two machines. One machine might have a .25 inch mill and the other might have a .5 inch mill. If the .5 inch mill machine is in use, you could run the same code on the smaller machine. Does that theory make sense.

So REPRAPer's might have different feed rates for their differnet extruder heads and different constraints in thier machines. To me it feels like this CIM sub standard would make for a more free and open design. Allowing some one to slice and dice the STL, then send the code to Zach.

So what is this standard you ask me... I wish I could remember it. I found it a couple years ago, but don't have the time to find it again. I believe this sub standard is much more common over the big drink in Europe, so perhaps some one else can chime in about it.

Any one heard of this or something similar before? Perhaps it was a beer induced hallucination.

Jared Harvey Wrote:
-------------------------------------------------------
> This CIM sub standard would specify a
> surface footage, min and max chip loads and such
> parameters, rather then RPM and FPM. Then the
> machine would decide what tool to use, what RPM
> can it use for that tool, and what FPM it can use.
> Making one code for two machines. One machine
> might have a .25 inch mill and the other might
> have a .5 inch mill. If the .5 inch mill machine
> is in use, you could run the same code on the
> smaller machine. Does that theory make sense.

Surface footage (how fast to cut) and chip loads (how deep to cut per blade) are tool specific. If you specify them, you have already chosen what milling bit you use. No sense for the machine to choose the tool then. The only variables left are the tool radius (decides spindle speed) and number of flutes (decides FPM). And you need to specify a maximum tool radius as well, otherwise you can discard all your toolpaths. And a layer thickness, because not all bits like all depths. Then you have basically moved the whole CAM layer into the CNC controller.

With an extruder you have other problems as well. If you change the extrusion thickness, you also change the layer thickness, and need to do the whole CAM process from scratch. Extruders aren't as flexible as milling bits.

--Blerik

i'm okay with gcode. its clunky and old, but its used everywhere and imho that makes up for most of its failings.

not only that, but its plaintext with human units which means people can easily write gcode by hand, or use a gcode generator.

next?

Zach,

Can you change the firmware so it doesn't use M7 and M9 anymore, but M100+ ones? I don't think it works when you use a big cnc machine as RepStrap, and find that your extrusions don't stick to each other because of the mist cooling...

I'll try and perfect the GCodeWriter this week, so it is compatible with your Arduino G-Code Parser. That way you can print directly from the host software.

--Blerik

yeah, although its a bummer that we cant use any of these 'standard' gcodes.

I know it won't be in shed 1.0, but perhaps shed 2.0 could have this color.

I found some of the standards check RS-494 also known as BCL, then there's ISO 4343.

Read up about it some at [www.encyclopedia.com]

Have you seen this pcb video? [www.youtube.com]

Ray Wrote:
-------------------------------------------------------
> Have you seen this pcb video?
> [www.youtube.com]

Nice, very nice!

Quote

Have you seen this pcb video? [www.youtube.com]

I remain grumpy that there seem to be no nice desktop mill kits like the fireballcnc easily obtainable in the UK; or at least in the bits of europe easily searchable in english

You have it so easy over the other side of the pond...

Hey guys,

I noticed some comments in the GCode parser module (process_string.pde) about performance:

//we do it like this to save time. makes curves better.
//eg. if only x and y are specified, we dont have to waste time looking up z.

and on reviewing the code I realised that the parser is rescanning the instruction string several times (i.e. whenever has_command() is called, and again for search_string()). If we change the parser to scan the string only once that should give a nice boost to performance.

I had a go at it (see the attached file) - what do you think?

My reprap is about half built so I can't run this yet. I did build the new process_string.pde with the arduino tools and it builds without errors and comes out a few hundred bytes larger but it should be faster. Anyone willing to try it out? It will no doubt have a bug or two :-D.

If the size is getting a bit too large then it could be optimized to drop it down a bit.

Cheers,
Darran.

PS. Edited to fix some obvious bugs in the attached file.

Edited 4 time(s). Last edit at 06/04/2008 08:27PM by Daz.

Daz

> I had a go at it (see the attached file) - what do
> you think?

This looks like really good work. As it happens, I have been doing quite a bit of work on the G-code firmware this week and hope to submit this to SVN soon. I will have a go at integrating the work you have done and will report back when I have done so.

Once again, well done.

these code submissions are great, guys! i havent had time to try them out yet, but i plan on doing that ASAP.

once i get them tested, i plan on making a new release of the arduino firmware. great work!

Great work on the G-code people!

I am a cnc machinist by trade and this is very interesting, to the point I am currently building a McWire. I would like to propose macro capability added to the cnc g-code.

info is at this link...
[www.gefanuc.com]

This I realize is very advanced, maybe just a pipe dream.

This may be beyond the realm of the reprap project and more in line with what [www.linuxcnc.org] can do, I don't really know?

Can you use emc2 program at [www.linuxcnc.org] to control the arduino and related electronics?

Thanks for your hard work and your help.

Sorry, the link to fanuc did not work.

How can I attach the pdf file?

Here is the attachment to the fanuc macro b info.

Also to explain G50 code a little.

G50 is a setting that allows the spindle to go up to the set RPM (say S1000) and not any higher. Useful for lathe work when using constant surface speed, although I guess it could be used on a mill. Some old controls used it for a zero setting as well, similar to G92. G50 S1000 (maximum speed) or G50 X0 Y0 (zero setting).

G92 is not used very often in practice in the places I have worked. G54 thru G59 are used on a mill for work offsets (establish distance from home point to work zero point.

Yes, it can be done.

I've already got a proof of concept working (temperature control and feedback).

See here: [forums.reprap.org]

Been away for a while, updated my firmware from 1.0 to 1.3, nice to see all the improvements on it! The feedrate and arcs are especially nice, along with some error checking i wont have to code now.

I've been milling boards, and have started milling 3d objects out of plant Styrofoam (milled out a chess rook), will test this new code out, now that I have some free time again.

Some other things I'll be working on soon
-work on the documentation
-mill single sided arduino, icd2, and stepper boards
-adding eeprom support to buffer gcode, and some settings
-improving the host software
-would like to add an emergency stop using interrupts
-learn about converting different file formats to gcode
-play with eagle3d, and blender

Can someone set it up so I can commit code and edit the wiki, or the builder blog? Thanks

Edited 1 time(s). Last edit at 07/01/2008 10:05AM by mellery.

Hi mellery,

you've done a great work on the g-code parser.

i'm in the process of testing the setup of my cnc machine built using the reprap project info. i uploaded your g-code parser to my arduino and tried to send some commands. all i was getting is this:
Recieved: G

processing string...

WARN: unknown instruction - G

doneRecieved: 01 X1.0 Y1.0 Z0.0 F300

processing string...

WARN: unknown instruction - 01 X1.0 Y1.0 Z0.0 F300

done

i entered the command through the arduino software just to check if it's ok.

am i doing it right or there is another way that i should send the codes?

thanks

I think Zach did some work on his g-code interpreter before to change trig to other algorithms.




If you divide a circle into quadrants, and record a set of x,y coordinates for a 90 degree rotation, then these can be both negated for opposite quadrant, or one or the other axis negated for mirroring.

It's actually even easier than that, work wise:

If you start on the top of a circle at the 0/360 deg mark Y is at a maximum, and X is zero. moving clockwise to 45 deg, X will become equal to Y, and then at the 90 deg mark, X is equal to the radius, and Y is equal to zero.

So, you can also keep the signs, but swap the absolute values for X and Y such that an n degrees after 45 degrees, x=(y at 45-n degrees), and y=(x at 45-n degrees)

So then, you calculate a series of x and Y measurements for a bit better precision than you need(, and later scale them to get the correct radius.)
that way, you can precalculate 1/8'th of a circle using your compiler, or cut and paste, and then, using a jump table based on the angle's position within those 45 degree sectors, you have a precalculated factor to multiply your radius by.


Mentioning radius, z^2 = x^2 + y^2, so you can even drop half of the 1/8'th of a circle table... say the Y coordinates, and calculate them, using the original radius. y = (z^2 - x^2)^0.5 All speed/memory usage trade offs.

Hello,

Great work man!!
I'm trying to do a parser myself, and I'm having some trouble. If you could post your latest code updates concerning how do you handle the G codes and the M codes together it would be great Thanks in advance

Continue your great work