"Hardware" GCode interpreter

[aubrey]

Hi Sean,
So latching extra memory onto a PIC is not the mountain that I thought it was.
To clarify, are you suggesting that the pc send GCode to the controler and that the PIC on the controler do the calculations?
If so, is there anyone out there who has the expertise to write the various algorithms to convert the GCode to motor steps?
Best
Aubrey

PS. This whole discussion is probably going to be rather disjointed what with the time difference between us. (I'm 2 hrs ahead of GMT and you are probably 7 or so hrs behind) Anyway, anything for a bit of fun ;>)

[plexer]

I don't see why there is complex algorithms involved if the command is to move the x axes in a certain direction and to a certain position you are just telling the pic how many many pulses to generate to move the axis and a signal to control the direction?

Ben

[andy55]

take a look at www.dynomotion.com

it's a dsp based card that does what's described above (interprets G-code), and additionally there's powerstages on the card for driving motors.
It's all controlled by the dsp software so the powerstages can be used for controlling any type of motor.

I understand the dynomotion interpreter (probably written in C, for the TI dsp) is based on the EMC (www.linuxcnc.org) interpreter. If the manufacturer took a recent EMC version and started with that then it should be under the GPL and the dsp code thus should also be. But if the manufacturer started with an old emc interpreter (public domain) then they might keep their dsp code closed source.
You will most probably need a dsp for this kind of stuff, a PIC or similar will not have the cpu power.

The other solution to the M$ timing problems is ofcourse to use EMC which runs on realtime linux (=predictable timing). To interface with steppers the parport is enough, servos require a servo-card which costs a bit...

[CLaNZeR]

A pic will do it fine running at 48mhz as it does.

My firmware already handles the basic G00 and G01 commands just got to get around to finishing it off at the moment.
Also I think the USB buffer of 64bytes will be more than enough for now.

To start off with you are only probably talking the follwing Gcode commands would be needed for most jobs.

G00 positioning (rapid traverse) (M,T)
G01 linear interpolation (feed) (M,T)
G02 circular Interpolation CW (M,T)
G03 circular Interpolation CCW (M,T)
G04 dwell, a programmed time delay (M,T)
G20 input in inch
G21 input in mm
G90 absolute dimension input (M,T)
G91 incremental dimension input (M,T)

I think when you start travelling at rapid speeds of over 200IPM then time to start thinking of more memory and double processors or even DSP.

Regards

Sean.

[andy55]

nice work,

I presume you mean MHz.

what kind of trajectory profiles does it generate ? acceleration, jerk, or doublejerk-limited ?
for how many axes ?

what about blending/lookahead i.e. if two segments are in the same direction there is no need to slow down in-between.

is yor controller open-loop or closed loop ? (I presume open loop, so not for servo systems).

[CLaNZeR]

Yes Andy MHz! or megacycle per second in ancient nomenclature.

As far as ramping rate you choose because it is easy enough to do a inceremental pause between steps.

At the end of the day, it is not complicated to clock a Step line on any controller..
Take a pin high on the pic chip that is linked to the Step input of any Axis, chuck a pause in and then take it low.
Depending on what the pause is, determines the speed at which the motors will turn.
Take the Direction pin high or low will determine which way the motor spins.

So for ramping simply start off with a longer pause for a set travel and decrease the pause until the correct speed is obtained and when the set length of travel is reached.

How you now control those steps and pauses is down to the Pic code and how it interprets the Gcode it is being fed.

Hopefully your program that has already generated the Gcode will of taken most of the important stuff into account and produced optimised code.

Like I said I have played around with the simple G00 and G01 codes in my firmware and all you are doing is very simple stepping.

Example to control 3 axis.

Set your variables for the X,Y and Z Axis position.

Grab your first line of Gcode that says G01 X100.00 Y050.00 Z010.00

Load your feedrate pause based on 3-Axis moving at same time.

Start your loop
Check X position if it equal to 100.000 position in Gcode command then divide down pause.
If not then Clock your step on the X-Axis and pause.

Check Y position if it equal 050.000 to position in Gcode command then divide down pause.
If not then Clock your step on the X-Axis and pause.

Check Z position if it equal to 010.000 position in Gcode command then divide down pause.
If not then Clock your step on the X-Axis pause.

Do loop again until all Axis equal same as Gcode command.

Of course also between each step you have to check for limit switches and emergency stop, but this can be done with interupts.

This will then move all 3 Axis as smooth as anything and all in sync with out loosing a step.

As you can see in the example above you can easly add ramping by dividing down the pause based upon the correct calculations at a higher pause for the feed rate.

My controller is based around steppers and is cheaper than $900 dollars for a DSP controller, even though the DSP has nice motor controllers built in on it!

Regards

Sean.

[slp_prlzys]

Here's something I found last year,
can't remember where, I think it's
from a University archive somewhere.
Perhaps knowledgeable Zoner's may
find it interesting. Only XY tho.
It's a pdf file but I had to zip it
to reduce file size even a bit,
I'm on dial-up so there's a slight chance
that it get corrupted during upload.

[ger21]

Why don't you just write a front end for Gecko's G100 (G-Rex). It has all the motion routines built in. 6 axis, 4 million steps/sec, lots of inputs and outputs. I think Mariss is trying to make it very easy for someone to create such a front end. There's a lot of info on the Geckodrive Yahoo group.

[CLaNZeR]

Excellent slp_prlzys

Especially like the Circular Interpolation bit, just what I been looking for.

Many thanks

Regards

Sean.

Here's something I found last year,
can't remember where, I think it's
from a University archive somewhere.
Perhaps knowledgeable Zoner's may
find it interesting. Only XY tho.
It's a pdf file but I had to zip it
to reduce file size even a bit,
I'm on dial-up so there's a slight chance
that it get corrupted during upload.

[aubrey]

I don't see why there is complex algorithms involved if the command is to move the x axes in a certain direction and to a certain position you are just telling the pic how many many pulses to generate to move the axis and a signal to control the direction?

Ben

Thanks for the input Plexer.

This is exactly my point!
Either the GCode to Step calculations are done on the PC or they are done on the breakout board.

If they are done on the breakout board, that board will need to have a fair amount of muscle ( = expense)

If they are done on the (M$) PC and sent to the breakout board which then simply takes them (the individual step instructions) and steps the motors (in real time as seen from the perspective of the breakout board based on the receipt of instructions from the PC), then we are at the mercy of the Mr Gates and real "real time" can only be dreamed of because if the M$ OS decides to do something else, the output to the Port is delayed and que'd and when the OS is finished, the complete data que is dumpred to the port as quickly as the port can handle it. Result = step timing screwed!

On the other hand, if the (M$) PC creates the individual step instructions and sends them to the breakout board (as fast as the PC, Port Baud rate etc will allow) and they are que'd/cached on the breakout board, and the breakout board releases the instructions to the motors at the correct intervals, then the timing problem is solved.

QED

[aubrey]

Sorry Guys - Duplicated Submission

[aubrey]

take a look at www.dynomotion.com
.... is based on the EMC (www.linuxcnc.org) interpreter ....
.... which runs on realtime linux (=predictable timing)....

Hey Andy

There are many commercially available systems out there which are pretty decent (and a number which are not). I think the idea should be to make a "FREE" alternative that will solve the problems.

Does anyone know what language (perl or whatever) the EMC app is written in?

To solve the timing problem, even EMC has to run on a special tweaked version of Linux.

Can anyone imagine Bill Gates giving us access to the M$ source so that we can tweak it? Not in my lifetime!