Re: Response to Matt Shaver's response

> From: hansw <hansw@...>
>
> Low cost, at what cost !

Minimal outlay of hardware dollars at the expense of having to tinker with
the software to get acceptable performance. Once the software is figured out,
it costs nothing to duplicate.

> Yes, so far understood.. but what are your units for "Let's say you are

using a delay of 100 " , 100 what ?

100 iterations of the timing process. In the EMC, the stepper pulse
generating task is called by IRQ0 (int8), which is the output of CH0 of the
8254 in the PC. The frequency of these interrupts is user selectable by
choosing what value gets programmed into the 8254 for CH0. The faster your PC
is, the smaller you can make this value. On a 350MHzP2 I can run with a value
of 12 (decimal). The 8254 is clocked at 1.193182 MHz, so with a divisor of 12
I get interrupts at the rate of 99432 Hz, or about every 10uS. Every 10uS the
timing process runs and the delay variable is decremented. When the delay
underflows, the step bit is toggled (actually there are two delay variables
for each step bit to increase the resolution. A delay of 100 would really
mean two delays of 50). For a delay of 100 the output frequency would be
(1/100 X 10uS) 1kHz.

> My idea would be to SHARE the load, let the outboard hardware do the pulse

generation plus some more, and let the PC do the

> number crunching.

I agree.

> Except the 8254 is not intelligent, and would still require handling from

the main CPU.

True, but it is a lot less work for the CPU to program the 8254 and get the
step pulses from its output, than to use the PC's internal 8254 as described
above.

> The DDSP is special, it's moderately fast and has a few built in features

that are perhaps more directly suited to Servo

> control, that said; it does have Digital I/O and could be used. Reading the

prelim. spec. sheet it does not make me see anything

> to write home about. TI have been doing faster DSP for years...
>
> Anyway, I don't think DSP speed is needed for a Load Sharing approach like

I plan. I've been designing with Microcontrollers

> since 1980 and my choice today is the PIC series, writing code in "C' and

assembly. ( The new Scenix looks real promising ).

I didn't mean DSP, I meant one of these:
http://products.analog.com/products/info.asp?product=AD9850

You use PICs? What a coincidence, so do I! Here's a combination of these two
things:
http://www.njqrp.org/mbrproj/9850dds.html

Somewhat off topic, yet interesting to me:
http://www.stevef.demon.co.uk/qrp2k/qrp2000home.htm

> > If you go that route
> > (external hardware) there is the additional problem of accumulating the

count

> > of step pulses for each axis so that the control software can keep track

of

> > position.
>
> Why is that a problem ? Steppers loose steps normally because of mechanical

reasons. If you send it 1000 steps it should do 1000

> steps, accumulating them and keeping track would be easy in the External

Hardware and the PC could also do it... I don't see

> this as a problem at all.
> Only closing the loop would allow for real feedback about lost steps.

I think the difference in our thinking on this point is that I am talking
about "dumb" external hardware, and you are talking about "intelligent"
peripherals. Obviously if you use a PIC as the step pulse generator it can
keep track of the pulses it outputs. If I use an 8254, I'll also need an
up/down counter to accumulate my step count. The counter will have to be
readable by the CNC software running on the PC.

The next stage of experiments to increase the step frequency resolution is to
combine the Kulaga/Mauch DRO board with one of these:

http://www.web-tronics.com/webtronics/ar-b9221.html

> > Also the comm link between the external hardware and the PC has to
> > have sufficient bandwidth to allow reading all the count registers and
> > writing step frequency updates at least every few milliseconds.
>
> Correct, and I think with the external uP programmed to be as autonomous as

possible in it's tasks, will reduce the need for

> large bandwidths.

I acknowledge the truth of the above statement ;) Why not give it commands
like, "G1X2.3875Y4.2946F4..." (just kidding!).

> Your statement "writing step frequency updates at least every few

milliseconds.", well lets look at the simple RS-232 running at

> what is considered normal HIGH speed of 115,200 Baud. It takes 86.8

Microseconds to send a single byte. I'm not sure what the

> "Few" in "few milliseconds" is, but lets say 2 as Few and plural

milliseconds it can't be 1 mS, but could be as little as 2mS.

>
> In 2mS the simple 115,200 connection can send AND receive 23 bytes ( full

duplex ) That's 46 bytes of data total.

>
> Then comes the question of how these bytes are implemented.
>
> If the control instructions were done in human readable ASCII it most

likely will require several of those 23 byte to transfer a

> command.
> Using binary commands there (I expect you know all of this, I am not trying

to insult anyone) 256 possible commands in one byte

> and if that is not enough make it a 2 byte command structure and then you

have 65536 possible commands. Now, with a 2 byte

> command structure you would still have 21 bytes of DATA space every 2mS...
>
> All of my RS-232 designs are made to run at 230400 Baud and getting a 2X

RS-232 card cost as little as $20-30 for a two port

> version. But 230400 is not "normal" so I would not design my external CNC

system for it...However I would make it be available

> for my them that wanted to implement it. BTW most modern Motherboards have

UARTS that will do over 460,800 Baud, just Micrsoft

> never released the driver for it.
>
> With command and data buffering in the external hardware, the bandwidth

requirements go down even further, such buffering is

> possible. Pulses generation would be much more predictable doing it this

way, I've done it so many times I've forgotten how

> many..
>
> There are also two sets of hard wired hand shake lines in every RS-232

port, and these could be used for emergency stops, or

> anything else that needed immediate attention.

Well, maybe we could eliminate the command word entirely and just exchange
all data every servo cycle:

X_rate <2 bytes> Output
Y_rate <2 bytes> Output
Z_rate <2 bytes> Output
A_rate <2 bytes> Output ;I threw in a fourth axis
X_pos <3 bytes> Input
Y_pos <3 bytes> Input
Z_pos <3 bytes> Input
A_pos <3 bytes> Input
DigOut <1 byte> Output
DigIn <1 byte> Input

TOTAL 22 bytes

OK, on the face of it I'll buy into your proposal. I've had good luck with
serial comm reliability over short, high quality cables, but you could add a
2 byte CRC for CYA purposes.

> Then there is the USB.... well for the Slower version ( 1.5mbs ) you

multiply the 23 bytes by 16 so you would have 368 byte per

> 2mS slot... and the Fast (12mbs) USB about X 130 will do... or 2990 bytes

per 2 mS slot...

I'm really interested in USB as ISA slots are getting scarce in new PCs. I
haven't got any direct USB experience, but I thought that determinism was an
issue. I guess if you're alone on the bus it's not a big issue since there
wouldn't be any other contenders for control of the bus. Beyond this I'd have
to study up on USB to be able to make any intelligent arguments or
suggestions.

Firewire is another good interface. One of the goals of this group is, "IEEE
1394 in real-time environments (RT-Linux)":
http://eclipt.uni-klu.ac.at/ieee1394/

CAN bus is another possibility and I think there either is, or will be, a PIC
with onboard CAN controller. Another idea I was kicking around for a while is
a completely distributed system with a uP at each node (motor, sensor, etc.)
all communicating over a high speed multidrop bus (then I sobered up and
thought no more of it ;) ).

> 2) I would like to close the loop ( enough said about that recently , there

are benefits, using (say) Dan's DRO, it should be

> possible, regardless of Servo or Stepper, to use the DRO and confirm

positions. I have yet to see a program do that... How

> about EMC ? )

Yes this is being added very soon. The code to read the DRO board is written,
what remains is to connect it to the motion system which won't require much
more effort.

> Yes ! it may take more than 1 Microcontroller to do all of this, that's

fine, they are cheap. ( don't look at catalog prices

> they are inflated by 200-300% for good reason) Doing multiple uP's in a

design is not difficult, my serial 7 seven port

> multiplexer ( see my web site) has Eight PIC's all talking and running

full duplex and bandwidth galore...

>
> It has been done and it can be done cheaper so everyone can write programs

for it, even for the MAC... (arrrg!)

Got a target price for your CNC control peripheral?

> > Well, here is a pretty good study (with actual figures) of the real time
> > performance of the standard version of Windows NT:
> >
> > http://www.hyperkernel.com/paper1.html
> >
>
> Interesting, but very biased... They would love to sell the HyperKernal I'm

sure... If they had published the source code for

> the test programs, it might have been a different thing ( much like Sieve

Algorithm test code's are published, which are used

> as part CPU speed testing, etc. ).
>
> That said; I think the figures are most likely reasonable, I just don't

trust things like this that have commercial bias and no

> real documentation. And yes ! I would understand the code, it's what I

do...

More on their test procedures are in this file, it's not the source code,
but...:
http://www.hyperkernel.com/bench.zip

> > Test data on the performance of RT-Linux can be found in these two

articles:

>
> HANG ON A MINUTE..... let's compare Apples to Apples ! There are several

Real Time Windows NT kernels out there..

>
> How about using this product and similar test conditions

http://www.hyperkernel.com/paper1.html

>
> Is the a similar test for straight Linux not the R/T version ?.

I think one of the articles below has some figures on the real-time
performance of regular Linux. I'm willing to agree that the real-time
performance of standard NT and Linux are equivalent for our purposes, and
that they're equally unsuitable for a CNC control using only a PC (no
auxiliary CPUs) as the platform. I'm also willing to concede that the
real-time performance of NT with commercial extensions and RT-Linux are
essentially equivalent. The most significant difference is that RT-Linux is
much cheaper. See:

http://www.vci.com/buy/north_american_packages.html

> > http://rtlinux.cs.nmt.edu/~rtlinux/papers/usenix.pdf
> >
> > http://rtlinux.cs.nmt.edu/~rtlinux/papers/lj.pdf
> >
>
> I'll read these tonight...

OK!

> How about improving the g-code documentation... Unless I've missed it in my

web searching I have not yet found a single well

> documented version. Of course the web is so vast I found about a 1000 pages

on g-code and 320,000 for CNC ... I just don't have

> the time to look at them all..

Send me your regular mail address and I'll send you a bale of documentation.
Unfortunately, it's a paper only proposition. As for a URL, this one isn't
too bad (stolen from Yeager Automation's FAQ page):

http://www.wokingham.demon.co.uk/prog/programming.htm

As to who is in charge of RS-274, the best answer I can give you is that no
one is. As far as I know the EIA is finished with it, the committee is
disbanded, never to meet again. The National Center for Manufacturing
Sciences wrote a greatly expanded version called RS-274NGC (Next Generation
Controller), but it was never finalized (I can send you the draft copy). The
world's greatest expert on the subject (that I know of anyway) is Tom Kramer.
His web site has lots of information. He wrote the G code interpreter used in
the EMC. It's documentation can be gotten from:

http://www.isd.mel.nist.gov/personnel/kramer/publications.html#RS274NGC2

> As my American friend once said, "We have the best politicians money can

buy " !

Let me rephrase that as, "We have the most expensive politicians money can
buy " !

Matt