ref: PC to controller comunication protocols

On Wednesday 27 February 2008 14:54:38 dgoadby wrote:

> Too may projects, too little time...

If there was ever a general theory of everything this would probably be at its
core :)
Cheers for the reply. I would be interested in seeing your work so far, I'm
going to be working on the g-code interpretation for a while so may be able
to spread the load a little there.
Good points about the ascii and buffers, ascii gets a lot of criticism for
being an antique but it has worked well with character filtering and error
checking just falling into place. As for the buffers, EMC and similar have
always seemed fragile to me by relying on a full blown OS running in
realtime, that was kind of where this thing started, letting a
microcontroller handle all the timings.
When I started this I wanted a simple, single chip, platform independent
solution for turning drawings into parts. G-code presented it's self as the
only real fixed standard (LOL, the spec's are well defined though) in the
world of CNC so that was the obvious place to start. I had expected to find a
standard microcontroller based system being used for machine control with a
standard form of communication between the PC and the microcontroller,
something where the PC does all the number crunching and throws a string of
speeds, positions and on/off signals to the microcontroller to buffer and act
on. This doesn't seem to be the case though, god only knows where the folks
who wrote the g-code spec in the 60's thought the floating point units where
going to come from. So, kind of stuck with g-code as the only sensible thing
to use for communications.
Since starting this a lot of 'extras' have been added. Going to have to go
back to the start and stick with the original plan, a single chip to suck in
g-code and spit out stepper or servo signals. For now only the very basic
g-code instructions are understood but from the discusions on this forum it
seems like that could be enough for something like this to be usefull.
I was going to say 'then maybe someone with a better brain than my own could
figure out how to make an AVR draw circles'... Then Mr. Mattison's reply
arrived. Cheers, I hadn't heard of the algorithm involved before but I'll be
looking into it, if you would be willing to share the relevant parts of your
work I would be very interested.
One thing I have done to leave space for expansion was to split the program
into 3 parts, communications, calculations and control with each part
isolated and communicating with the others through buffers. Something similar
may be usefull for your project, as you say the parts are not expensive and
separating things has made adding extra components to the program much
simpler.
Forgot to mention, I'm using AVR's for this, a mega85345 at the mo but trying
to stick to the functions common to all models to keep the code portable. So
far it's all my own work, mainly as an education in assembly but no one else
has been daft enough to get involved either. I know I should be working in C
but a relative persuaded me to learn BASIC when I was younger so languages
with any kind of structure just don't make sense (that's my excuse and I'm
sticking to it...) so it's assembly (and fortran) all the way :)
cheers

--
Every solution breeds new problems.