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?

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.

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.

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?

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.

Keep up the good work guys.

Jerry

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

Thanks - Its good to brainstorm with people who are open to considering someone else's input and ideas.
(group) 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

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.

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:
Live with it
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:

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


Downside of each solution

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

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

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

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.

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 ;>)

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

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

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.

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

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.

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.

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.

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.

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

Sorry Guys - Duplicated Submission

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!

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

My firmware already handles the basic G00 and G01 commands ...

G02 circular Interpolation CW (M,T)
G03 circular Interpolation CCW (M,T)


Hey Sean,
In the "Process GCode on the breakout board" option, it is the G02 and G03 commands that have me scared. From my limited knowledge of PIC programming, when you start using floating decimal arithmetic, the poor PIC has to really jump thru hoops and the EFFECTIVE speed of the processor is greatly reduced as it now has to run thru a number of algorithms (the floating decimal subroutines) to do the math.
Scary Stuff!!!
Aubrey

aubey,
did you look at the development boards or the control boards.they are module based for fast prototyping.they have memory and realtime clock onboard.could the onboard clock be used to overcome the windows delay problem.

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.
Hi Gerry,
Begs the question "Why hasnt someone done it yet?"
Also, still relies on the timing being triggered by the M$ PC from what I can see.
Best
Aubrey

Time to lay it out so that everyone can see what I am getting at.

Givens:
1) Both Micro$oft and to a lesser extent, Linux, operating systems to a lesser or greater degree do not always set the port pins at the exact moment that the application wants them to.
2) EMC has to be loaded on an optimised OS installation but with Micro$oft there are no other options.
3) Eratic timing can cause skipped steps, tool gouging and a host of other problems which can mean wasted money when looking at our time, effort, doctors bills for high blood pressure and material cost of the workpiece.

It is also accepted that :
1) There are a number of solutions out there that overcome (to a greater or lesser degree) the problem. Unfortunately, most of them cost money.
2) There are a number of ways to overcome this problem but as a hobbiest, I would like to be able to say that I was a member of the GROUP that came up with this particular solution AND THE DARN THING WORKS WELL!

For the purpose of getting clarity on where I am comming from and what I think our goal should be, the attached document should help.

The thinking is as follows:
1) As everyone has thier own preference as to CAD Packages, this wheel does not have to be re-invented. We will use the GCode output from the CAD Package as the source.
2) The GCode generated by the CAD Package will be retrieved by our StepMaker software and computed to a string of 2 letter words which will be stored to a pre-processed file on the disk drive. This step is necessary especially for those who have slower computers in thier workshop. Some of the G02 and G03 commands may take the PC longer to step calculate which could mean that the mill will have finished the previous steps before the PC has calculated where the next step/s are to take it. This "Buffer Underrun" scenario could also be the reason for erratic or problematic behavior on some mills.

As the pre-processed file contains no itterations or loops, it may be massive.
Imagine if you were to store each step command that is sent to your mill when you run your favorite GCode file. This is EXACTLY what the pre-processed file contains!

3) Now we take the pre-processed step instruction file and run it through the breakout board feeder application. The Feeder App sequentially reads the file from start to finish and sends it to the breakout board. There will of course have to be protocols set up so that the breakout board can pause the stream so that an overrun situation is prevented.

Now, What happens in the Breakout Board?

First lets look at our 2 byte "word".
If we put them one behind the other, we effectively have a bitstring 16 bits long.
Using the first 2 bits, we have 4 options available. ie. 00, 01, 10, 11

Assume that process branching happens as follows:

00 = output the last 10 bits to the motor driver pins (assuming 5 motors with step and direction)

01 = output the last 4 bits to the auxiliary relay pins (assuming 4 relays with on/off capabilities)

10 = "Canned Procedures". Here we can zero any axis, change timing rate for steps to be sent to the motors or anything else that we may decide to incorporate into the software design.

11 = "Send to LCD Display" ie. "1100000000000000" should clear the LCD Display, "110000000100000" should put the character "A" on the LCD.

Now, what does the board do?
PIC1 is busy listening for traffic on the connection to the PC.
The first thing it gets is a command which it interprets as "Is it OK to Start?"
PIC1 resets the board and starts receiving the data and storing it to the memory chips (4 in my drawing)
When the last memory is full (or the end of transmission flag received from the PC), PIC2 is told to start.
PIC2 queries PIC3 for the address of the next (in this case, first, command)
When PIC3 receives a memory location request from PIC2, the location is returned to PIC2 and the next memory location pointer is incremented in PIC3.
If the next memory location is on the next memory chip, PIC3 signals PIC1 to re-fill the memory chip that has just been finished.
In the meantime, PIC2 has retrieved the word from the memory location and processes it.
PIC2 then waits for the timing pulse and executes the command.
When the command has been executed, PIC2 queries PIC3 for the location of the next command and the whole process starts again.

You will notice a number of PICs in the drawing apart from PIC1,2 and 3. my thoughts are that a small (<$2.00) PIC is an easier way to impliment PWM and all the other good stuff than complicated boards. Want to change the way it reacts, change the program - infinite possibilities!

Comments Please

Best

Aubrey

Lets try the attachment again - Sorry ;>{

Hi Gerry,
Begs the question "Why hasnt someone done it yet?"
Also, still relies on the timing being triggered by the M$ PC from what I can see.
Best
Aubrey

The G100 won't be available for another week or two, although you can purchase it in 2 piece form right now (see the website).
There are alpha versions of Mach4 available that can run it right now. Not sure about the timing, but I think it's controlled by the G100.

Aubrey,
A lot of what you are talking about is over my head.

I do wonder if you are over-simplifying the requirements of a real machine in operation. Acceleration and deceleration are not performed in gcode. Feedrate override is going to wreak havoc with what you have already fed into the buffer. Feedhold, Estop, same problem. You will want to be able to pause the program at any instant, then recover and continue. Because these events all happen on the fly, they cannot be anticipated within a fully processed program path.

How about execution of one line of gcode per input? This involves Windows quite a bit.

Just add these to your list of things to do. But, carry on :)

Hey Sean,
In the "Process GCode on the breakout board" option, it is the G02 and G03 commands that have me scared. From my limited knowledge of PIC programming, when you start using floating decimal arithmetic, the poor PIC has to really jump thru hoops and the EFFECTIVE speed of the processor is greatly reduced as it now has to run thru a number of algorithms (the floating decimal subroutines) to do the math.
Scary Stuff!!!
Aubrey

I saw this little guy a while back: the uM-FPU Floating Point Coprocessor. You can find it at the Parallax (http://www.parallax.com/detail.asp?product_id=604-00030a) site. Uses SPI to communicate with your processor. It does the floating point stuff, plus you can program macros (formulas) into it. If you go to the Parallax site they have documentation on interfacing to their products and some programming documentation too. Hope this helps...


Evodyne

Aubrey,
A lot of what you are talking about is over my head.

....Acceleration and deceleration are not performed in gcode....

Point taken - how are they handled currently?
I assume that they are handled within a specific GCode Command.
Also, does the Accelleration/Deceleration apply to ALL GCodes or only to the rapid movement commands?


Feedrate override is going to wreak havoc with what you have already fed into the buffer. Feedhold, Estop, same problem. You will want to be able to pause the program at any instant, then recover and continue. Because these events all happen on the fly, they cannot be anticipated within a fully processed program path.....

If you look on the document, you'll probably notice an alarming abscence of a keypad! One will be needed!
If a wait for user intervention is required, all we need is a "Canned Command" that will pause PIC2 untill the operator has changed the tool or done whatever is needed.


How about execution of one line of gcode per input? This involves Windows quite a bit......

If the PIC has to do all the calculations, in my opinion the situation will arise that the next step needs to be sent to the driver boards but the PIC has not yet worked out what the next step is. This will probably be just as bad as missing a step.


Just add these to your list of things to do. But, carry on :)


Thanks (I think!) Please remember that this is not "My" project. If it was, it would be a non-starter because I definitely do not have anywhere near the expertise in all the required areas to pull it off. It will have to be a group effort if it had any chance to see the light of day.

But if it does....... It will be a great little achievement.

I saw this little guy a while back: the uM-FPU Floating Point Coprocessor. You can find it at the Parallax (http://www.parallax.com/detail.asp?product_id=604-00030a) site. Uses SPI to communicate with your processor. It does the floating point stuff, plus you can program macros (formulas) into it. If you go to the Parallax site they have documentation on interfacing to their products and some programming documentation too. Hope this helps...


Evodyne

Hi Evodyne,
As far as I know, the Parallax product (Basic Stamp) operates under "Interpreter" mode which already slows it down.
Maybe I am wrong - does anyone know for sure?
This is NOT to say that it is a bad product at all ! !
Simply put, a standard algorithm will run faster as a compiled code than under an interpreter all other things being equal.

And to make things more interesting : I believe (not confirmed) that the Parallax Basic Stamp used some or other PIC as its CPU.
I have also heard (once again - NOT CONFIRMED) that this may have changed.
Please guys - DO NOT QUOTE ME ON THIS! It is what I have heard and is definitely subject to confirmation. I don't want to step on anyone's toes.

Aubrey

Aubrey wrote: We are dealing with the Micro$oft Window$ operating system.
Then 2 sentences later:
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

I'm sorry to chant "Linux", but really cannot see any other choice without shelling out lots of money for a realtime system with expensive compilers and tools.

Some of you want to be part of a group with a better solution. There is such a group, you just have to join it: The Enhanced Machine Controller, or EMC.

The low level parts of EMC is written in C. That is: hardware I/O, stepping/servoloop, trajectory planning, kinematics, interpretation of G-code and low level execution of operator I/O, lots more. The user interface is written in other languages as far as I know.

It relies on RTAI for realtime service. RTAI is extensively used also in commercial controllers and PLC's and is well debugged and of course source is available for it. Do not underestimate the complexity of writing a realtime kernel or scheduler from scratch. It will be needed also for a microcontroller or things will get even more complicated. Realtime means actions will be executed to well defined time limits, it does not necessarily mean these time limits will be very small. So there is a limit for how many steps/sec a certain hardware can deal with regardless of software design.

If you need more speed than the PC hardware can provide, EMC have solutions to this: Use a hardware step generator made up from a programmable gate array, EMC has open and well defined software interfaces to make this simple. (I went to this solution to gain the speed I wanted). Or you can choose a hardware that controls servo motors equally easy. The drivers for these have already been written, so you just pick one that suits you. Should your requirements not be fulfilled by an existing hardware/driver, you can write your own. It will be a fraction of the work writing everything yourself, and you will all along benefit from the work other people do at other levels of the software.

I think you should only reinvent the wheel if there are only square or too expensive wheels existing. So I suggest you look closely at EMC to see if it will not be quite close to what you need.

OK, so I'm biased since I run EMC and have a good performer for a really low price. The PC running it would otherwise have been in the dumpster long ago, and the mentioned hardware cost me just over $100, and can do 300 000 steps/sec if I ever find drives that can swallow them that fast.

Einar

CLaNZeR:
You might also be interested in this too.
http://www.khwarzimic.org/takveen/helix.pdf
I was going to post the pdf itself but better from
the source.

Point taken - how are they handled currently?
I assume that they are handled within a specific GCode Command.
Also, does the Accelleration/Deceleration apply to ALL GCodes or only to the rapid movement commands?

The controller has to send steps at the proper rate for accel and decel.

Accel and Decel are handled by the controller, and are independant (sort of) of the G code.

Any time the machine increases speed, or decreases speed, it needs to accelerate and decelerate. Motors can't go from 0 rpm to any given rpm instantly; they must accelerate.

Last time I mention this, but the Gecko G100 will handle all the accel and decel. You feed it coordinates and feedrates, and I believe it will do the rest, in hardware. I think that's the easiest way to go. It's not that expensive, either, imo.

Last time I mention this, but the Gecko G100 will handle all the accel and decel. You feed it coordinates and feedrates, and I believe it will do the rest, in hardware. I think that's the easiest way to go. It's not that expensive, either, imo.

The Gecko might do this, but it does not know what the other axes are doing.
So the path will not be correct unless moving only in a direction parallel to one of the axes. A move in one axis must be related to the others. Unless of course we talk about a machine like a coordinate drilling machine where only the endpoints of every move matters and not the path it takes between them.

So all G1 moves must be coordinated. For a G0 it may not matter (assuming no clamps or other obstructions). Some machines may even choose the fastest route on each axis for G0, making the move a dogleg path.

The Gecko might do this, but it does not know what the other axes are doing.
So the path will not be correct unless moving only in a direction parallel to one of the axes. A move in one axis must be related to the others. Unless of course we talk about a machine like a coordinate drilling machine where only the endpoints of every move matters and not the path it takes between them.

Yes, it does know what the other axis are doing. It treats each move as a vector made up of each axis component. I don't know how to explain how it works, but I'm pretty sure it does. Like I said before, there is plenty of info on this on the Geckodrive Yahoo group.

@Ger: Sorry I confused G100 with the "old" Geckos. Just went over and browsed through the manual for it, and from that it looks like the G100 is the hardware that can be used to implement a multi-axis controller. But if it comes with the capabilities you mention, the manual does not say so. It refers to what it could do [given the right program], not what it will actually do as delivered. In fact it is built up very much like my system, except mine uses the PC CPU instead of the Rabbit microcontroller, and a separate board (from Pico-Systems) with the FPGA clocking out the steps. And the software is already done (EMC). So it looks like the G100 can do it if the software is finished. I don't know if it is, so can't comment on it's actual capabilities. Maybe there is a soft[/firm]ware manual somewhere?

It looks like the G100 have what it takes to make a non-continous move A->B without a complicated program. (It does the steps using the PGA hardware). It gets a lot tougher if you do not want it to stop at B, but smoothly continue in another direction to C, then to D, and so on. Near each corner, it must be continuously be reprogrammed to the new direction, taking into account how it may be allowed to divert from the correct path. Like you correctly wrote: it cannot instantly go from one speed to another.

I just went and looked at the manual myself. Your right, it looks like you need to write your own motion algorithms. I thought that Mariss was working on this before, but haven't been following it lately.

Here's his latest post on his group:

Home, Encoder jog, Speed control, DAC in and DAC out has been added and
works. Also added and being tested is autonomous run.

Autonomous run is kind of exciting; download and test a program; once
it works to your satisfaction, preface the whole thing with "auto<cr>",
disconnect the USB cable and the G-Rex runs the whole thing without a
PC. The application program gets stored in the battery-backed SDRAM in
the Rabbit.

Right now about 3,000 X,Y coordinates can be stored (about 32kB). Once
I figure out how to use Rabbit extended memory effectively, that number
will grow to about 30,000 X,Y coordinates. That should be enough for
most people without the G-Rex being tethered to a PC.

Because things are progressing so rapidly, I'll wait until this feature
works semi-properly before I post the Rabbit source coude.

Mariss


I believe his source code is in the G101 folder of the Geckodrive Yahoo group, titled "ISR Stuff" or something like that.

Hi Einar,
I was waiting for one of the Linux converts to pick up on this discussion!

I'm sorry to chant "Linux", but really cannot see any other choice without shelling out lots of money for a realtime system with expensive compilers and tools.

Don't get me wrong, what you are saying is true IF you are comfortable with the Linux platform.
Personally, I am not.
I have tried to install Linux from way back, Early Red Hat, Suise 6, Fedora - the EMC "BrainDead" install and on and on.... NEVER got it right :tired:

As to the cost issue, Yes it will be more costly to get it going on a Micro$oft platform, no arguements there!!!

But if the enthusiast is NOT an IT fundi and does not have an intimate personal relationship with the Linux OS, there are also other "costs" to be considered:
1) Frustration in trying to get your Linux based PC working properly in the first place. This has always been my own biggest headache with any Linux OS install that I have tried.
2) This "frustration" then takes the enthusiast down the M$ Window$ route simply because they probably already have a Window$ based PC at home or if they are prepared to continually reboot, the MS-DOS route for the CAM functionality.
3) The choice of CAD software is very much a personal one and the majority of choice lies in the Window$ platform range. Some very good - some very bad, some expensive and some free. The choice is up to the individual.

I would not like to know how many folk have simply chucked the CNC hobby because of the cost in time and money to get them to where the REALLY want to be - watching thier (probably home built) CNC Mill machine some component that they have spent hours designing.

Have a look thru the threads on this site and count the number of folk looking for solutions to broken tools, gouged workpieces and bad finishes. I have seen a number of them.



The low level parts of EMC is written in C. That is: hardware I/O, stepping/servoloop, trajectory planning, kinematics, interpretation of G-code and low level execution of operator I/O, lots more. The user interface is written in other languages as far as I know.

OK - as it is open source, we have somewhere to go to see how others do it and either "borrow" some of the routines as is or make the necessary adjustments to suite our purpose. As long as the results are also free to the public, where is the harm?
And if our group effort makes a solution that WORKS, even if it costs a couple of hundred Dollars, and we save one person from walking away from the hobby, I personally thing it would have been worth it!

As an aside: a large majority of the members of this forum earn thier income in US$. There are some of us that don't. When we see a price tag of US$100.00 we go into shock as it equates to a LOT of money in our local currency.


I think you should only reinvent the wheel if there are only square or too expensive wheels existing.

Don't you just love the human race? They are always trying to invent a "BETTER MOUSETRAP".

So I suggest you look closely at EMC to see if it will not be quite close to what you need.
OK, so I'm biased since I run EMC and have a good performer for a really low price. The PC running it would otherwise have been in the dumpster long ago, and the mentioned hardware cost me just over $100, and can do 300 000 steps/sec if I ever find drives that can swallow them that fast.

One of the original definition parmaters that I put forward was that this project would be Micro$oft Window$ based. Why? Most of us are more comfortable with Window$ than with Linux.

I am not saying that the EMC/Linux solution is inferior or bad. On the contrary, it is probably the best solution available at this moment. But not for many of us out there!

What we need is a way to take the output from our favorite (Window$ based) CAD application and make our (proudly home built) mill cut our parts from blocks of raw material without the problems that are inherently encountered when using Window$.

Best
Aubrey

CLaNZeR:
You might also be interested in this too.
http://www.khwarzimic.org/takveen/helix.pdf
I was going to post the pdf itself but better from
the source.
NICE!
We will definitely refer back to this later in the project.
Aubrey

The controller has to send steps at the proper rate for accel and decel.

Accel and Decel are handled by the controller, and are independant (sort of) of the G code.

Any time the machine increases speed, or decreases speed, it needs to accelerate and decelerate. Motors can't go from 0 rpm to any given rpm instantly; they must accelerate.

Last time I mention this, but the Gecko G100 will handle all the accel and decel. You feed it coordinates and feedrates, and I believe it will do the rest, in hardware. I think that's the easiest way to go. It's not that expensive, either, imo.

So if my understanding is correct, the "pre-compiler" will have to work out what the pause between each step is to be to get the motor from rest to the cutting feed rate required and then back to rest at the end of the particular cut so that the appropriate timing delays can be incorporated in the 2 byte command stream that is generated.

Question: Does the Gecko G100 receive actual GCode from the computer and if so, is it able to keep up with commands like G02 and g03? Also, what kind of processor/s does it have onboard?

Best
Aubrey

The Gecko might do this, but it does not know what the other axes are doing.
So the path will not be correct unless moving only in a direction parallel to one of the axes. A move in one axis must be related to the others. Unless of course we talk about a machine like a coordinate drilling machine where only the endpoints of every move matters and not the path it takes between them.

So all G1 moves must be coordinated. For a G0 it may not matter (assuming no clamps or other obstructions). Some machines may even choose the fastest route on each axis for G0, making the move a dogleg path.

This would really be a problem when making a 3 dimentional cut! :nono:
Best
Aubrey

Yes, it does know what the other axis are doing. It treats each move as a vector made up of each axis component. I don't know how to explain how it works, but I'm pretty sure it does. Like I said before, there is plenty of info on this on the Geckodrive Yahoo group.

Sorry Guys - Now I am getting confused!
Is there anyone who can give us a run-down from PC OS/CAD Package to mill axis motors and the results/problems that they are getting?
Best
Aubrey

Hi Everyone,
Big thanks to Paul for opening a "Group Projects" sub-forum for me.

I have initiated 3 threads:
"CNCZone Driver Group Project" outlines the basic concept and participants (group)
"Project Comments" for general comments :cheers:
"Request For Comment" for wish lists and must have lists and fighting about them. (chair)

Those of you who would like to come onboard, please add an entry to the "CNCZone Driver Group Project (http://www.cnczone.com/forums/showthread.php?t=15492)" thread listing your strengths and areas of expertise.

Thanks
Aubrey

I have tried to install Linux from way back, Early Red Hat, Suise 6, Fedora - the EMC "BrainDead" install and on and on.... NEVER got it right :tired:

OK. I know how you feel as I also installed Linux and had many fights before giving up. That was also "way back". But installing BDI RC46 was so easy I could not believe it. Boot CD, click on install to hard disk, answer a few questions, then leave it until done. More recently I installed Linux on another machine, this time a video surveillance (ZoneMinder) and the same again, a few questions first, then it did the rest by itself. No need to babysit waiting for new questions, reboots, install umpteen "security patches" and licenses. And no, I'm not a Linux freak, I install it where it is required for the job at hand.

But OK, I just thought you wanted to see the chips flying as soon as possible. Did not mean to start a religious war. :p
But the EMC source will surely be a good resource if building on another system. The source can be loaded and viewed in Windows.

Did not mean to start a religious war. :p
Don't worry, no offence taken!
I use windows all day every day and roundly curse it (flame2) at least every hour.
Funny thing about democracy... Its the only "system" that by definition, allows other "systems" to also be acceptable.
Best

Has anyone considered using an FPGA? Check out this board for $99:

http://www.digilentinc.com/info/S3Board.cfm

It's just a matter of using the Xilinx tools to create the software. I just finished a course at cal state where we designed a 16-bit RISC processor and loaded it into the FPGA.

This thing is great too because it has VGA out and a PS/2 port. So you could have a monitor and keyboard.

Hi, I am looking for a (reasonably) economical way to run a "planned" 4 axis mill / router. (hobby use)

I am very tempted by Rhino, which is win based, so it would be handy of course to use the same computer for the control as well.

I found these motors

http://www.imshome.com/mdrive42acplus_mdi.html

which can plug right into a USB port and AC. IMS provides some control software (m code) as well.

I have no experience at all with G code / cnc yet, so wide open to various approaches. I am just curious if there is a way we can use something like this to simplify our life of making a CAD to CAM arrangement.

Hi Guys,

I have been watching you guys talking about G-Code Interpreter. Some one opting for DSP and some one for PIC, and of course some people being scary about PIC will not do, DSP will do, what about circular interpolation.

Good news for every one that I have implemented linear and circular interpolation in a PIC, yes PIC18F458/PIC18F452 running at 40MHz and I have made some STARS of various corners and aspect ratio, and some round shapes, rectangle with sharp corners, and recatngles with round corners too.
In both metric and inch units.

I will soon be posting the schematic and the test code in hex format for you guys to test. Once I finalize the main interface cause right now I have graphic LCD 128x64 KS0108 based controller, and a 4x3 keypad installed. I am going for 240x128 T6963C based LCD and some really serious input interface for it to represent my work piece.

Later I am planning to decode the following mostly used G-Codes in the
PIC18F458/452

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

Till then
Regards for every body on CNCZONE

An exact stop trajectory planner is not hard to implement using any hardware or software. By that I mean that the machine comes to a full stop at the end of each move, and so it also starts all moves from a full stop.

The trick (if you want to do 3D moldmaking or complex paths in general) is to make a trajectory planner that 'cuts corners' within a specified tolerance and keeps up the velocity of the machine. That is nontrivial, and I'd be delighted to look at any open-source implementations anyone has come up with. I've tried to understand how it's done in EMC2, but really going through the code and math requires more time than I have right now...

This also sounds a lot like what the NCPod (www.oemtech.com/ncpod) does, although it seems to have been in beta testing for quite a long time. Does anyone know the status of the NCPod?

Hello all
nice to meet you
can any one provide me Processor Breakout Board ( pcb and schematich )
thank you