Re: SLO-SYN 12.7 Amp motors

"Harrison, Doug" wrote:

> From: "Harrison, Doug" <dharrison@...>
>
> > -----Original Message-----
> > From: Jon Elson [SMTP:jmelson@...]
> > Sent: Monday, January 10, 2000 3:24 PM
> > To: CAD_CAM_EDM_DRO@onelist.com
> > Subject: Re: [CAD_CAM_EDM_DRO] SLO-SYN 12.7 Amp motors
> >
> >
> > This is a real problem, and not easy to solve with a scheduler that either
> > emits or doesn't emit a step pulse on a fixed interval. Let's build an
> > example.
> > Let's say you need to output 999 steps/sec to achieve the desired feed
> > rate
> > on that axis. let's say that you have the processor interrupted 1000
> > times
> > per second to see whether to output a pulse then. Well, you output a
> > pulse every interval for 500 intervals, skip one interval, and then output
> > 499 more pulses at every interval. That omitted step makes the whole
> > mechanism clunk. This specific example might not make the steppers
> > lose sync, but there are an infinite number of other combinations like
> > this,
> > and some of them most certainly will excite resonances that can cause
> > lost steps.
> >
> The operative word here is interrupt. Software that relies on the
> PC's interrupt system is doomed to a bumpy ride. The closest thing to true
> timing control (short of a dedicated board with its own clock and profiler)
> would be had by addressing the clock chip directly with an assembler
> routine.

Yes, that's exactly how the real time scheduler works on RT Linux. It
takes over the system interrupt clock, and sets the interrupt rate at
whatever rate you need. RT tasks take priority over the OS tasks.

> I believe this is how Doug Yeager's program works. It works well
> too. I ran three axis' simultaneous last night at 15,000 steps/sec and it
> didn't even flinch. This is with a 486.
>
> At least one large CNC control builder has solved the PC profiler
> vs. PC windows interface conflict by going to twin (not parallel)
> processors. One (running under DOS) runs the machine while the other (under
> W95) provides the cute and fuzzy windows graphical interface we all want.
> When you consider how cheap motherboards are, and how powerful the PC is
> when you leave the video out, this seems like a good approach.

Yup, that is really the way to go. But, I don't think the RT Linux environment
would support that. Of course, an off-the-motherboard CPU could do
this, and no OS is really needed, just the RT scheduler and some I/O
management routines. I know some proprietary motion control boards
work this way.

Jon