"Hardware" GCode interpreter

[DukerX]

I've been toying around whit some of the free CNC control programs that can be found on the net, and most of them relie on a parallel port to run the servo/stepoper drivers.
I don't like hooking up some heavy gear to the LPT port on my computer, as the wiring is too much of a hazzle, and the LPT port has a finite number of IO lines. And not to mention the timing issues in Windows.

What I'd like to do is to program a MCU to interpret gcode blocks on the fly, being fed from a serial connection from the computer.
The gcode could be sent to the MCU using a simple program like hyper terminal.
To configure the MCU, a little Visual basic application could be used to make a config file that is sent prior to the gcode, so the axis, max move-speed and all other required information doesn't have to be hard-coded into the MCU.

I'm currently working on a simpler version, that doesn't use GCode, but my own simple control syntax, and it also just operate one axis at a time.
I'm trying to build this from stuff I already have in my "junk box" and geccodrivers are not something to be found there, but I have alot of sanyo STK6713 stepper drivers that I have ripped from discarded xerox-machines.

Is his a "finished" topic or should I post some more info?

Similar Threads:

• Deckel Dialog11 "interpreter" dialog4
• Grizzly X3 / ProMiCA "hardware only" CNC kit / Gecko 203V / EMC2
• Problem- X Axis "Goes Off Pattern", "Awry", "Skewed", "Travels"
• Problem- "Go To Z" button ignores my feedrates in Gcode
• Need Help!- Lost ability to "post gcode"

[aubrey]

Had a similar idea when trying to find a way around the Micro$oft timing delay issue.
Basically the idea was to write a VB App to generate the control commands (each command being 2 bytes long) to a file and then to send the file to the controler via the Comm1 port and the controler would store the lot in memory.
The first 2 bits are for toggling the mode (Movement[X,Y,Z..], Settings[feed rate, coolant on/off etc], Internal Subroutines [Return X to Zero etc], Display [to show a message on a LCD Display or current co-ordinates)
The rest of the 2 byte word used to control motors or whatever.
A PIC processor would simply read each 2 byte word and send it to the appropriate output array as set by the first 2 bits. This process would be timed by the settings.
The problem was that no-one could tell me how to connect a substantial (256mb plus in the form of a PC Memory Card/Simm Strip) amount of memory to a PIC. This would be required as each step would be represented by a 2 byte word as there would be NO PROCESSING of co-ordinates done by the PIC - it would simply do what it was told to at the timing interval that was currently active.
AND the entire program would have to be held in memory BEFORE the stepping started to prevent a "buffer underrun" scenario taking place. (Has anyone ever seen how many steps a "simple" GCode command can generate - a small [ie 20 letter or less] command can generate many thousand steps)

Apart from the memory problem, everything is very basic and should give good and reliable results and designing/building the circuit should not be too bad as all that has to be done is take the output pin/s from the PIC through a sufficiently heavy transistor switch and directly to the motor/relay or whatever.

I had to move the project to the "would have been nice" archive but if anyone has some answers, it can very easly be moved back to the "work in progress" directory.

[CLaNZeR]

I have done this myself for my controller at http://www.cncdudez.com , there is a processor link that shows the board and anyone is welcome to the firmware. All the pins are documented there also if anyone wants to make their own board or firmware to suit.

When I first started playing I used a Pic Chip that could only offer me serial port control and while this was fine, and will except packets of 256 bytes a go, you still have sometimes the limit of the 115200 baud rate slowing you down.

I am now using the 18F4550 USB/Serial chip and the USB buffer works a treat when send commands, it so fast and the delay is not even noticed.

At the moment I have just done a simple Jog control protocol as shown on the development link of the site. But plan on doing a gcode interpreter routine within the Pic, just starting with the basic G and M codes.
Just time as usual to get around to it.

Must admit using a processor controller blows away the noise and smoothness when running the motors and well worth the effort.

Regards

Sean.

[aubrey]

I have had a look at the product mentioned - nice one.
The Micro$oft issue regarding the timing still has an influence on the result if my interpretation of the methology is correct as the controler software (which generates the commands and sends them to the LPT port at the required timing intervals) is running over the Window$ operating system.
AND WINDOW$ SOMETIMES FINDS OTHER THINGS TO DO which can delay commands being sent to the LPT port. Once Window$ has finished doing what it wants to, the que is released to the LPT Port and there may be a number of commands in the que. Nett result is that the tool is stepped a whole bunch as quickly as it can (or if they are too fast for the motors to react, they may be skipped) and the tool is damaged or the workpiece is gouged.
In my scenario, the actual physical timing is done by the board and Window$ is left out of the timing equation altogether.
As you mention, there is a 115200 baud rate limit to some of the communication devices and although the USB is faster, the operating system is still able to cause problems.
Using the methodology that I outlined, the computer that the controler is connected to can be a 386DX40 with a 9600 baud rate on the communications device and things will still operate at the required step interval rate because Window$ has absolutely no control over the timing because ALL the commands are off the windows platform BEFORE the job begins.
If there is a problem, look for it on the controler.
With a Window$ controled environment, you need access to the OS source code (and you need to understand it!) to be able to get to the root of the problem.

Please note that I am NOT flaming any existing system whatsoever!!!!

My requirements are that I am able to very accurately mill graphite (my mill is at the X-Axis Done stage) to make electrodes to use in my spark eroder (still awaiting 3 Phase Power) to make dies for my 22 ton Injection Molding Press (3rd Dec 05 painted base and starting to re-assemble and reconditioning die clamp mechanism.)
As the electro-mechanical relays and timers on the press are over 55 years old (read knackered) and replacements are impossible to find, I have had to write an app in VB to do the controling (using a K8000 Velemann card as an interface). Here a timing variance of 1 or 2 tenths of a second is not critical but in the mill it will chip or shatter the graphite and I'll be left wondering why it happened and cursing that I cannot reproduce the problem as the (Window$) timing glitch will happen somewhere else next time.

So, Does anyone have an answer to the "how to connect large memory to a PIC" problem?

[CLaNZeR]

What size memory you looking at?.

How many lines of Gcode you talking bout storing?

They do cheap little 4megabit ram chips that run on SPI protocol with approx 5 wires to connect to pic chip, If you want to go bigger then you are either now going upto using a pic with more i/o lines or going for MMC card connectors.

I designed a programmer that I know longer sell that used to read and write to TSOP memory chips at http://www.mcesdk.com

So it can be done with a pic chip and any size memory chip you want, as long as you got enough I/O pind for the address lines and the data lines.
You can also daisy chain the memory chips to increase size.

Regards

Sean.

[CJL5585]

Keep up the good work guys.

Jerry

[aubrey]

Hi Guys.
Sean: Now I think would be a good time to "Come Clean"! As far as electronics are conserned, I AM NOT EVEN A NEWBIE!
In my life I have built a "Fuzz Box" for a guitar (late 60's) which somehow put 220 volts into the pickups and melted them.
In the late 70's I built a few disco light "ring counters" which worked after much cursing etc.
This year I assembled the K8000 breakout kit (which has not been plugged into anything yet as of 7 Dec 2005. Who knows what will happen when it is connected - I'm scared!)

Basically what I am saying is I do not know what I am doing when it comes to electronics.

My strengths are in the mechanical (qualified journeyman) and programming (IT Manager - programing in VB, HTML, ASP, PHP, JavaScript etc) fields.

Now to get back to your post:
What size memory you looking at?.
At lease 256mb and expandable.
Thought of using the memory strip that is normally used on a computer motherboard as they are freely available.
Another option (seeing that PICs can "talk" via USB would be to use a USB Memory Stick)

How many lines of Gcode you talking bout storing?
As the GCode will be "pre-processed" to the 2 byte words which the PIC will simply output to the necessary output pins at the required timing intervals, there will be no GCode as such.
This approach means that the actual "work" of taking a GCode command and converting it to the X/Y/Z axis movements required can be done using a VB application and the results stored in a file on the computer hard drive.

HOWEVER it must be taken into consideration that some GCode commands can generate thousands of individual steps and each step will be represented by a 2 byte word.
ALSO, there will be no "LOOP" commands, Macros or Stored Procedures executed by the PIC.
Another consideration would be the lead screw pitch. Most motors (stepper) require 200 steps (I think) to do 1 revolution (no fancy half stepping etc yet) so a movement of 1mm on a 2mm pitch screw would require 100 steps. On a 1mm pitch screw this would be 200 steps.

No matter which way you look at it, it is going to be BIG to put all the individual steps of an entire GCode program into memory at the same time.

I have had a number of thoughts about getting around this problem but for now, I have to do some work. I'll post them later today.


Aubrey

[aubrey]

Thanks - Its good to brainstorm with people who are open to considering someone else's input and ideas.
No single person is Right all the time and no single person is Wrong all the time.A Group of competent open minded individuals will solve ANY problem eventually.

Aubrey

[mdreitzusa]

have you looked here
http://www.futurlec.com/index.shtml
they have a lot of development boards for making embedded control systems.prices look good to.

[aubrey]

The Parameters:

• We are dealing with the Micro$oft Window$ operating system
• The source of the GCode is up to the individual

The Problem :

• The way that Window$ works internally makes for unreliable timing when sending data to any of the output ports (LPT, Comm, USB)
• This means that data sent to such a port will not necessarily arrive there when it should
• This situation may or may not happen at a point where it will actually make a difference

If a number of steps are qued in the computer output buffer while the operating system is busy elsewhere and are released to the port in uncontroled rapid succession, one or more of the following may occur:

• Accuracy may be compromised in that the stepper motor is not able to react quickly enough. This will result in steps being skipped.
• Tool breakage will occur if the proper timing intervals are not complied with.
• The quality and uniformity of the finish may be shot to hell. This may not be apparent on rough cuts but will certainly be noticable on finishing cuts in certain materials.

Just think about it: How many times have you seen threads on this forum where someone is cursing the machine that they have spent many $ and many more hours researching, developing and constructing very nice examples of CNC mills and they just cannot get them to do what they should do.
Then they spend more $ on other programs to drive thier rigs.
Then its the turn of the motor driver cards. - More $ - etc etc

And the cause of the problem remains erratic timing due to the way Window$ works internally.

Now there are going to be a whole bunch of guys who start chanting "LINUX, LINUX" and I refer them to the first parameter I defined in this submission: We are dealing with the Micro$oft Window$ operating system.

So what are the options:

1. Live with it
2. Come up with a solution to ensure that we, the humans, are not to be screwed around by the shortcomings of the operating system

Personally, I want to go with option 2!

As far as I can see, there are 3 ways of solving the problem:

1. Place the GCode to Step program on a PIC (or similar) Microprocessor
2. Generate all the stepping instructions and send them to the controler in bulk and let the controler release them at the correct timing intervals
3. A combination of the 2

Downside of each solution

1. Anyone who has played with floating decimal libraries on a PIC will know what I mean when I say "Challenging".
   Not to say that it is impossible, simply that it is going to take a loooooong time to develop and debug.
   It is also going to require a very large PIC.
   A simple VB app could be used to transfer the GCode source from the hard drive to the PIC
2. This will require a VB app to generate all the stepping instructions and send them to the controler in bulk (easy part).
   A MASSIVE amount of memory will be required to be available to the PIC. Work it out yourself - Take the time (in seconds) to run your longest running GCode source, multiply that by the number of steps that are executed per second by the motors and multiply by 2. That should give you an idea of the number of bytes of memory that are required.
   
   A "subset" of this method would be to have 4 (or more) memory sets that are "filled" by one PIC (communicating with the computer).
   A second PIC would start at the first memory set and pass the instructions to the outputs at the correct intervals.
   When the second PIC is done with the last instruction of the current memory set, it can tell the first PIC to fill it again and move on to carrying out the instructions on the next memory set.
   The first PIC would then do so and any minor delays would not be of any consequence at all.
   The would be a problem is if the computer starts hanging and PIC 1 was not able to fill the memory location needs to execute the instructions in that memory location but under normal circumstances, the memory should have been recharged before it was needed.
   There would also be a problem if the rate of execution was greater than the rate of retrieval but in existing conventional systems, this would also be present.
   
3. Passing some of the more easily processed GCode to the PIC so that it can generate the step requirements (ie "Straight Line" movements) while passing the step instructions for the more complicated (circles spirals etc) movements. This will reduce the "traffic" between the computer and the PIC but if there are a lot of "complicated" elements, it will still be overwhelming

Personally, I see option b as the way to go with the "subset" as the cheapest cost route if the electronics boffins amongst you can figure out the circuitry.

Comments Please

Aubrey

[aubrey]

Hi Mike,
Thanks!
Had a look at the site but as I said before, I'm an electronics moron.
Did have a look at the PIC 18 prices. With a single exception, they are all less than $10 each, which is not really money if at the end of it all we can get our mills operating accurately, reliably and consistently.
Even if there are 5 PICs in the final product, the savings in bad jobs, broken tools, blood pressure and time will more than make up for the initial cost.
Best

Aubrey

[CLaNZeR]

I think the idea of using a memory chip and a dedicated controller as a good idea, but I do not think you need to go that mad with the memory as you simply use this as a buffer.
Windows is not gonna give that huge of a delay and even with a small buffer it could handle a delay of a few seconds if not more from the serial or USB port.
With the printer port you are switching Clock lines and direction lines and a small glitch will make the motors run noisey or even pause for a second here and there.
But with the printer port you are sending every pulse of the Step Clock.

Based on the threads and motors I use on my frame, the motors are 1.8 degree with 200 pulses 1 revolution and I use a 3mm thread, so in 1/8 mode then we are talking 533.333 pulses to move it 1mm.
So to move 100mm we are talking over 50,000 pulses over a time period depending on what speed we want to move the motors.

You can now see why Windows has problems.

But the same is not for USB or Serial as all you are doing is sending a command that will tell the Pic Chip to send 50,000 pulses with the pause between steps to get your speed.
So for this example telling your machine to move 100mm via USB or Serial, you are pretty well guaranteed you will not get a glitch or a pause.

The only pause you will get is the time between commands being sent.
The USB buffer has a 64byte buffer and even using this small buffer correctly you can hardly see any pause at all, if any because while the motor is moving the next command is already in the Q.

Now using a small memory chip that is less than $5.00 you can have 540672 bytes of memory that can be shifted in and out of the Pic chip at 256bytes at a time.
You now have a huge buffer, even if you stick to the standard basic Gcode.

G00X000000Y000000Z000000

(resolution of 000.000)

Say 24 bytes for each command that will cover a small enough resolution for most people and you could buffer over 22000 lines at a time.
If you wanted to make sure that you had no interuption at all then the nice thing about these memory chips is that you can read and write 256bytes at a time to each page. So now you could use two low cost Pic Chips, one would sit there collecting data and filling up the buffer and the other would be dedicated to reading the next gcode translating it and moving the motors.


Regards

Sean.

[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.