Re: [CAD_CAM_EDM_DRO] Re: Lost Steps, freqmod, pulse generators, etc.

Matt Shaver wrote:

>
> > From: Alan Marconett KM6VV <KM6VV@...>
> > I'd like to know more about the "freqmod module"...
>
> There was quite a discussion of how best to implement a step pulse generator
> back on 1/10/00 in a thread called, "SLO-SYN 12.7 Amp motors". Here are some
> excerpts to bring you up to speed:
>
> <Begin Excerpt>
> > Matt Shaver wrote:
> > 3. Darrell also said, "I think the main thing in using these drivers is
> > getting the timing correct in EMC." This is something I have yet to be able
> > to do, and is a problem that Fred has been working on for some time now.
> > Without going into all the details the problem is that there is a some
> > jitter
> > in the step output of the EMC. Generating the step pulses stresses the real
> > time part of the software considerably and much work has been going on to
> > reduce the jitter.
>
> From: "Matt Shaver" <mshaver@...>
> > > From: Jon Elson [SMTP:jmelson@...]
> > > 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.
>
> > From: "Harrison, Doug" <dharrison@...>
> > 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.
>
> RTlinux uses channel 0 of the 8254 Counter/Timer chip to generate interrupts
> at the correct times to ensure that real time tasks are serviced punctually.
> The scheduler is the piece of software that controls this operation. The
> scheduler has two modes, "one shot", and "pure periodic". In all past
> versions of the EMC, Fred has used "one shot" mode to schedule the stepper
> control task that generates the step pulses. The downfall of this is that for
> every run of the stepper task, the 8354 is reprogrammed. The trouble comes
> from the fact that the 8254 is on the ISA bus side of the PC architecture,
> and therefore the reprogramming time is lengthy as it's limited by the ISA
> bus clock speed. The recent work Fred has been doing has two goals:
>
> 1. Switch all real time tasks to "pure periodic" mode and make the slower
> task (servo task/trajectory task) periods multiples of the fastest task
> (stepper task) period. This will eliminate reprogramming the 8254 after
> initialization which will save a great deal of wasted overhead. His initial
> tests have shown substantial improvements in both minimum achievable task
> period and jitter reduction.
>
> 2. Convert the stepper task to "velocity mode", rather than "position mode".
> Presently, the servo task runs every few milliseconds (determined by the .ini
> file variable) and the stepper task runs at a rate determined by the
> combination of MAX_VELOCITY and the lowest value of INPUT_SCALE. The actual
> formula is:
>
> 2(MAX_VELOCITY x INPUT_SCALE) or for my system, 2(1.25 x 4000)=10kHz
>
> Every time the stepper task runs it writes either a one or a zero to the
> output pins on the parallel port, so the highest step rate is 5kHz (for me).
> The servo task figures that once it has issued the command to the stepper
> task to move to a new position that it has been done by the next time the
> servo task runs. The result is exactly the problem that Jon described in his
> post (see above). The first version of the stepper task simply output all the
> pulses for each axis as soon as possible and then went idle for the remainder
> of the servo task period, like this:
>
> _-_-_-_-_-_-_-___________-_-_-_-_-_-_-___________
>
> Later versions incorporated sophisticated algorithms Fred came up with to
> distribute the occasional errors in pulse period, but there are still
> harmonics in the output step frequency. The next versions will have the servo
> task commanding the stepper task to output pulses at a certain _rate_. The
> stepper task will keep track of the pulse count and the servo task will be
> able to read back the position from the stepper task and control the step
> rate. Savvy readers will exclaim at this point, "Hey! That's just how a servo
> system works!". This also has the side effect of making stepper systems with
> encoder feedback possible with minimal software changes (after all, WHERE the
> position feedback comes from doesn't matter much at that point). Fred is
> somewhat reluctant to adopt this idea as it brings with it some addition
> complication and uncertainty. What is a good value for the P gain in a system
> like this? As soon as you move to a system that is partially driven by error
> values, the whole weight of PID comes crashing down on you with perhaps
> unpredictable results. Nevertheless, it's a worthwhile experiment.
>
> >.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.
>
> Of all the commercial "software only" programs, I've heard the most positive
> comments about Yeager Automation. I was wondering: Does the user interface
> keep updating and respond to keypresses (like feedrate override requests)
> while cutting?
> <End Excerpt>
>
> Freqmod is the software module that resulted from Idea #2 above. It improved
> things dramatically, but it still isn't good enough. The basic problem is
> that we'll never get the pulse timing resolution fine enough using the timer
> tick interrupt in the PC. Programs that do well at pulse generation sit in a
> tight code loop polling one of the counters in the 8254 (or maybe the RTC
> chip) to know when it's time to toggle the step signals. The down side to
> this is that the user interface is frozen while this is going on. There might
> be time to occasionally peek at the keyboard buffer to check for an "abort"
> keypress, but there won't be time for real time position display updates
> (these will have to wait until the end of each block).
>
> > hear more about what Jon Elson is doing on the Parallel port
>
> See Jon's post about what he has in mind.
>
> > As I understand, there was a previous project to do an
> > interface, with optical isolation, buffering, etc., and that may have
> > lead to what Jon is working on now?
>
> The Wonderboard project was aimed at simplifying the wiring for CNCPRO based
> systems. I don't know what's happening with it.
>
> > Any thought to the PCI bus addressing? Has anyone used it with a
> > home-brew interface? Looks like PCI bus cards want to put things on new
> > addresses (PCI). And my new development system (the one stays stays
> > clean in the office) is PCI card only! :>(
>
> PCI bus was considered, and for the reason you mention; there are many PCI
> only systems. There are three problems:
>
> 1. The user has to open the box. Then there's the problem of getting all the
> wiring out of the PC. This leads to using ribbon cable and a set of ribbon to
> screw terminal translator boards that cost $75/each (you need 2 of these for
> the STG card).
>
> 2. Using PCI (in small volumes) usually means using an interface chip from
> PLX, which adds about $40 to the board right off the bat, and that's just to
> get ISA out of PCI (more or less).
>
> 3. Then there's the biggie; Intel and other PC makers are looking forward to
> a slotless world. Horrifying? Yes! But the same situation exists now with
> laptops. Considering the lifespan of laser printers (I've had my LJ4L for
> years now), I'm hoping that parallel ports will be around for a while.
>
> Matt
>

The last comment above on slotless machines is all the more reason to build a set of distributed tasks including a (master cpu) of
somekind, control panel, etc. The trick is to make it open standard so multiple approaches (on board) still play right with the
whole.

Dave

I think Jon Elson is headed in the right direction. :-)