Re: [CAD_CAM_EDM_DRO] Re: emc help

Greg wrote:

>Hello
>I guess having been an cnc enginneer for the last 10years,I tend to
>assume people understand what i mean.
>I all the thing you have said are on the surface correct but in
>reality are completely wrong.
>
>The servo update time which in emc's case is determined by the pc and
>limited by the communication to the stg board,as well as the max
>encoder input rates and maximum accurate control of the d/a converter.
>
>

OK, most people run the servo update rate at 1 KHz. This is adequate
for many
applications. But, there's nothing enforcing this. EMC has definitely
been run
at 10 KHz before. My boards that connect through the parallel port is
limited by the speed of the communication over the IEEE-1284 channel.
But, a 133 MHz Pentium classic can do the 3-axis cycle, plus all the digital
I/O and supervisory functions in under 100 uS. So, it could probably run
a 5 KHz update rate, and allow enough time for other tasks in the
non-realtime
section. A 333 MHz Pentium II does it in 50 uS, so even that pretty old
CPU could do 10 KHz updates well. Eventually you hit the wall on the
parallel port, and the CPU can't push bytes any faster. I think that would
hit at about a 20 or possibly 25 KHz update rate.

A PCI board would likely be able to close the servo loop at 50 KHz or
better. Up in that neighborhood you start getting into the realm of
DSPs that can bypass all the folderol of OS's, memory management
and complicated bus-bus bridges, and turn around an I/O read request
in under 100 nS.

>So the realistic rate cannot be 999ipm ,especially with the
>limit of .0001 resoulution or 10000 counts an inch.
>At 400 ipm or 6.6666 ips is equal to 66khz of encoder,which makes
>800ipm a max for a standard 150khz encoder(assuming a little head
>room)
>
>

Well, now, we weren't talking about encoders, we were talking about the
software. If you NEED to go faster, you need faster encoders. My boards
have a very artificial limit of about 300,000 counts/second imposed by
the digital filtering of the encoder signals. That seemed to be a
reasonable
limit for the application.

>
>Then there is the case of how fast the processor can close the
>servo loop,which become even harder with each additional axis.
>Which is why i asked what the limit is when you make a multiple axis
>translation.
>
>Then we come to the case of point to point moves ,Or high speed
>contouring,This is even a worse strain for the processor as you have
>trajectory changes every few thousandths(determined by your step
>distance and step over),All this will bring most cnc's to there knees
>long before 400ipm(i have had fanuc's programmed at 999ipm with the
>overide at 200% that couldnt go 50 ipm).
>Not mention the accell/deaccell limits of the motors and drives.
>
>

Yes, in the hobby world, talking about much over 100 IPM is just blather.
It takes REALLY expensive drives to make a metal-cutting machine
move at the rates modern commercial CNC equipment do.

>So i ask yet again what is the max realistic feed rate that Emc will
>support for the following:
>1 a simple one axis move
>2 a 3 axis move
>3 a point to point contour move
>
>

Well, I really can't tell you. I USE a milling machine driven by EMC,
and I know what the performance of the servo drives is pretty accurately,
and EMC has no problem driving this machine to its limits. But, that is
NOT much, because it is a Bridgeport with relatively wimpy servos
(1/8 Hp continuous, about 1/2 Hp peak). This is entirely adequate for what
I do, but others may need more performance. I am completely confident
that EMC will perform well up to 100 IPM no matter what you throw
at it. Others have reported some serious problems with the lookahead
of the trajectory planner when you try to runa router at 400 IPM. There
is an advanced trajectory planner that was developed a few years ago that
should fix these problems, but it has a pesky software bug that causes it
to hang in certain cases. Experts are looking into it, but haven't
found the
problem yet.

I still believe that extremely high feedrates can be controlled accurately
by EMC, but the trajectory planners suffer from some problems with
high feedrates for extended periods. It is not a case of the machine
running with large errors or slowing down, it is a case of the machine
suddenly jerking to a stop. The old scheme just couldn't keep up, the new
one hangs due to that bug. My understanding is that the new planner
can handle extended runs, like tens of thousands of blocks of G-code
at 400 IPM, as long as you don't set up the conditions that trigger the
thing to hang. I think it is Les Newell that has the router running at 400
IPM, but I'm not absolutely sure that is the right name.

Jon