Re: regarding future plans for EMC

[Fred Herenius <fred-at-twonky.xs4all.nl>]

Now let's see if that listserver puts it in the right thread without all
those References in the header. Anyways...


Subject: Re: regarding future plans for EMC
From: Paul <paul.corner-at-tesco.net>
> Much of the source code could indeed do with cleaning up and documented.
> My favourite for ease of reading and understanding is the RS274 interpreter.

I'll check it out when I find the time somewhere next week. But I'll ask
again, are there any active plans concerning cleaning etc of code?

> at work, I sit down with the printouts and make a few more notes. With cheap
> flights to the Schipol, perhaps we ought to arrange a European EMC meeting
> sometime.

Certainly sounds interesting.

> P.S. Scroll to the end for info about encoders....
Thanks :->



Subject: RE: regarding future plans for EMC
From: "Eric Keller" <eek105-at-psu.edu>
> I have c2406 which is the non-external memory version of the 24xx dsp.  I
> didn't see much reason to add all that complexity when there is enough
> memory in the 2406.  I haven't designed a board, I have never done surface
> mount before.  I also haven't settled on a feature set for the controller,
> because it would be expensive to have them made and I have lots of potential
> applications.

Do you use code composer or do you know of a free alternative? And I know how
you feel with the 'lots of potential applications'. By any chance in the field
of data aquisition and preprocessing?
And for info on how to do SMT while enjoying the comforts of your own home:
http://www.seattlerobotics.org/encoder/200006/oven_art.htm
Tip: While hobbying can leave you hungry, do not use for pizza afterwards.


From: John Sheahan <jrsheahan-at-optushome.com.au>
>> Pete Cook> ideas.
>> If this is indeed the case, is there any planned date for a feature-freeze?
> is a lot gained by the magic transition to 1.0 ?

In itself nothing is gained by just changing version numbers.
Something is gained however if you have a more clearly defined development
path. For example, you might gain developers. And with a bit more direction
you usually get your code done quicker.

>> Homebrew hardware:
>> Another reason for going the above route of doing it module-wise is as
>> a proof that the modularity is actually working. And if the modularity
>> is actually working you can start thinking about moving modules (in whole
>> or in part) to a platform different than your main pc/alpha/whatever.

> I'm not sure I agree here.
> I don't run emc on my main machines, but on a junky old pile of scrap
> in the workshop.   which is heaps cheaper than the alternatives you
> suggest.  even new pc's tend to be very cost competitive with
> dedicated embedded controller boards.
> economies of scale.. obviously realtime response can be a killer however.

I agree an i386 + a uln2803 based parport solution is cheaper than what I
propose. The i386 you already have lying around. And darlingtons are
dirtcheap, and you probably have those lying around as well.
But (there always is a but), performance of such a system sucks too. So you
get what you pay for. May be enough for some, not for others. The thing is
that PC hardware in general is not all that great at handling interrupts.
Ofcourse this gets somewhat better with modern systems, but interrupt latency
doesn't magically get halved by doubling the number of MHz of your system. You
can get better response from even a lowly microcontroller these days.

The cost picture does ofcourse get a bit muddled by people having old PC
hardware lying around. But then again, I also have lots of other spare
parts, so I should not include those in the cost estimation of an alternative?

The approximate setup I intend to build for a lathe CNC conversion: The
first version of the controller software will just do the (micro)stepping and
handle the encoders, that sort of basic stuff. The second version will also
take care of (parts of) the functionality from EMCMOT.

[Old PC with a cheapo DIY CAN interface]
http://caraca.sourceforge.net/candongle/index.html
This could be upgraded later to a commercially available PCI card, but for
now I'll try to get it working with this design.

Quick cost estimation:
AT90S2313-10SI $ 4.37
MAX232D $1.50  $ 1.20
PCA82C251T/N3  $ 2.04
rest   <=      $ 4.89 
---------------------
total: <=      $12.50 (that's including the DIY singlesided PCB + consumables)

The PCB used at http://caraca.sourceforge.net/candongle/index.html is also
singlesided, but with holethrough components. I intend to use SMT components
and stuff it inside a large-ish DB9 connector package.

Currently I'm not at a place with a decent link so these prices are a quick
lookup. For the at90s2313 and max232 I know for certain it can be done cheaper,
but decided I'd use the figures I could find with just a quick check. The same
goes for the stuff below.

[DSP Controller based stepper board]
tms320lf2407 - DSP Controller                 $15.84
sn65hvd231   - CAN Transceiver                $ 3.83
misc C + R + D + doublesided pcb     <=       $10.33
----------------------------------------------------
subtotal for DSP + CAN related part  <=       $30.00
If internal memory is insufficient, add about $ 5.00

[6 axis controller, max 60V supply, devices 50A max, I'll design for 10A/phase]
24 x IRFZ44A -at- $ 1.11                         $26.64
12 x IR2102S -at- $ 2.66                         $31.92
fudge like fast diodes, sense Rs, opamps      $ 6.44
----------------------------------------------------
                                              $65.00

Add the fred-doesnt-know-how-to-count bonus of ~ 50%, and for a grand total of
$170 (and probably quite a bit less) you have a complete six axis controller
based on good parts (International Rectifier parts are a bit expensive, but
very rugged). If I compare this to the crappy controllers you can get for $250
from a commercial outfit this one is much nicer. Well, at least on the
drawingboard it is ;-> Still prototyping parts of the design...
I know $170 is too much for quite a few of the hobbyists out there. But it's
easy to cut the costs by using less capable pre-fet drivers (discretes if you
feel like it) and cheaper fets. And ofcourse it's possible you only need a
3 axis controller. The DSP part will however be about $30 (or $45 if you
want to include the fact that I cannot count) without many ways too drastically
reduce the cost. Well, building 1000+ will help, but you get the picture.
My aim is to get it done for $125 (and I think that budget even allows for
outsourcing of pcbs if that turns out to be necessary).

>> For example, you could make a board to control the rotational speed
>> of your favorite spindle. Instead of using the PC to generate the pulses,
>> you could use a lowly microcontroller to do that for you, and to accept
>> high-level commands from the PC through a (serial) bus of your
>> preferred flavour. At home I use I2C for this, but in an industrial
>> environment you could use something else.
>> If that concept works for EMCIO, then why not for EMCMOT?

> makes sense. but not serially please. look at the current 'standard
> platform' documents. ethernet or usb seems the only reasonable choice here,
> (if serial means rs232)

No, serial did not necessarily mean rs232. I should have been a bit more
clear. I was thinking more along the lines of RS485, CAN, or whatever bus
is favoured these days. Also note the integrated CAN module in the DSP I
intend to use ;) Add transceiver and you're all set. Also see:
http://www.llp.fu-berlin.de/pool/newproj/CAN/
http://home.wanadoo.nl/arnaud/files/howto/Linux-CAN-bus-HOWTO/book1.html
And as for cost, this can be quite low. As a hobbyist you can construct a
CAN interface yourself cheap. And if you're a time=money company you can buy
a professional PCI card (making sure it's supported).

USB or ethernet (UTP) is also a possibility. If I had have to choose between
the two I'd go for ethernet.

>> And on the subject of homebrew hardware, how about trying to get a
>> repository with plans for homebrew controllers. Schematics for those who
>> like to wirewrap/breadboard/etc. Postscript or other plot-files for those
>> who like to etch their own. I know there are a plenty of schematics on the
>> net, but for the beginning EMC enthusiast it might be much easier if there
>> is a clearly defined list of homebrew designs to choose from that are know
>> to work with EMC, complete with description on how to get it up and running.

> I can provide a web page for this and contribute some stuff if there is
> general interest.

Me == interested. Hope this interest counts as general.

> ISA has reached the end of its life and should be quietly buried.

Indeed. No flowers, no funeral. Put it in a massgrave next to its buddy DOS.

> Sure its easy to design an isa card. but pci is not a lot harder.
> A remote box , say with ethernet and a socket interface makes sense.
> Rabbits and other things can support ethernet with just a couple of
> chips.

I don't fully agree with PCI being only a bit harder than ISA. For ISA you
can get away with basically a few address decoders + application specific
ICs. For PCI you need a bit more. OK, I'll admit this is working knowledge
from a few years back when I really looked into it. Are there any cheap
readily available bridges out there? If so, please kindly point me in the
right direction, because I'm always looking for techniques to be added to
my toolkit. Easiest still would seem to be an fpga + selecting the right
free pci ip.


>> - Just thought I'd ask, anyone else on this list into hobbying with
>>   FPGAs, CPLDs, DSPs, that sort of thing?
> not dsp. 

Ah :) So perhaps you already have working experience with a free pci core?

Mmmh, again longer than planned, so I'll leave it here ;->
> - Are you still reading this?

Fred