Re: PC to controller comunication protocols

--- In CAD_CAM_EDM_DRO@yahoogroups.com, stan <stan.distortion@...> wrote:

>
> Hi all. For a while I have been working on a microcontroller program

to take

> in g-code sent over a serial line (COM) and translate it to machine
> movements. It's going ok so far, it can take basic g-code such as

would be

> created by eagle for PCB milling (user contrib script, cant remember

who but

> thanks a lot) but it's causing a big hold-up to implement the more
> complicated functions such as curves (bloody floating points :) ).
> One plan is to put an interpreter on the PC to take in any g-code that
> confirms to the spec and turn it into simplified code that the
> microcontroller can handle as-is.
> This will still used lines of g-code sent one by one directly over

the serial

> line (ascii). The idea is any PC can be plugged into it and work

with no

> special software, just hyperterm, gtkterm or... whatever it is macs use.
> Can anyone suggest an alternative to ascii-over-serial? It needs to

be a

> common and free to use protocol that doesn't lock the system into one
> specific OS or software component. I have had a look around but have

only

> seen either systems for direct control over the parallel port or
> vendor-specific systems that keep their protocols close to their chest.
> If something like that exist then I'm at the point where it would

make sense

> to use it, otherwise I'll stick to ascii-over-serial.
> Thanks.
>

You don't say what your micro controller is but I am working on a
similar idea. I use plain ASCII as it is easy to generate and receive
on almost any platform. It's easy to go long distances too if you need
to keep your PC in a swarf free area! With a simple terminal program
you can test it easily too. Bandwidth is not an issue (I use 9600
Baud) so any form of compressed protocol has no real advantage and is
another overhead and potential bug source. A smart move is to buffer
the commands as you will get to the point where you want to program
lookahead. You cannot do this unless you can inspect the buffer. I use
software (XON/XOFF) handshaking rather than hardware (RTS/CTS).

My project started with a PC then I tried one of the larger PICs but,
like you have discovered, the floating point becomes a problem once
you leave simple G Codes, so it's back to a PC again.

Are you writing from scratch or clipping bits from EMC and others? I
have cheated a bit as my core code is derived from TurboCNC V3.1. I
have transliterated the code from Pascal to C. I have buggy versions
running on a Vortex86 processor under Linux. I ditched an
MSDOS/OpenDOS version as I wanted networking and multitasking. The
Vortex card has a parallel port and GPIO which is handy too.

I recently acquired a FOX Linux platform from Acme and this looks
ideal for a low power totally embedded solution at a low price. The
only problem is the development has to be carried out on a Linux box
first (I use Ubuntu) and then you load it into the platform for
testing. The Vortex is powerful enough to host the compiler which
makes it a compile-and-go system which I prefer. If it ever gets
completed I will open source in on SourceForge.

If I had the time I would like to program a CNC interpreter in Forth.
I just love the language and there is a lovely ARM32 based device
called the BV511. Too may projects, too little time...

Regards

David