"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?

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