Re: [CAD_CAM_EDM_DRO] Re: servo driver on a chip ?

jzmuda2000 wrote:

>[snip the real thread, so I can respond to the hijacked postscript part ;) ]
>P.S. Admittedly this "home made mill" is still a work in
>progress...so take what I say with a grain of salt. I am stll
>learning. (I have finished the three motor control boards and the X-
>Y table. Still haven't got a spindle or proper Z axis. That work
>thing keeps interferring with my hobbies.)
>
>P.P.S. BTW, JR Kerr Engineering even has a simple open source G-
>code interpreter on their web site. It will drive three of these PIC
>Servo SC chips. A limited repetoire of G code commands.
>
>Therefore, in order to use these PIC Servo SC chips with any "real"
>software (e.g., EMC)...since all these "real" packages will output
>is STEP and DIRECTION...he has a feature where the PIC Servo SC
>chip will accept STEP and DIRECTION commands...and then turn around
>and do the closed loop PID algorithm to actually move the servo.
>
>

Actually, EMC supports true closed loop servo control, just not with a
parallel port. In fact, even when running steppers, the step/direction
output driver synthesizes a feedback position for the higher level
trajectory planner code (and PID). I believe that EMC is the only
machine controller that does this, until you get to the multi-thousand
dollar range. (and of course free is way less than that :) )

>Pretty silly if you ask me. You are basically making a Servo look
>like a stepper. But that is because all the high level machine
>control software (e.g., EMC) expects to interface to a Servo using
>STEP and DIRECTION. At least without any standard for high level
>servo commands (that all Servo driver chips understand directly)
>(like perform a co-ordinated three axis move from (x1, y1, z1) to
>(x2, y2, z2)) that is what we seem to be stuck with.
>
>

EMC has drivers for parallel port (step+dir), hardware step+dir
generators (USC from Pico Systems), generic I/O cards (for digital at
least, and analog is trivial to write), and several "true" servo cards,
that have analog output and encoder feedback in hardware: Vital Systems,
Motenc, Servo-to-go, Pico Systems PPMC, and Mesa 5I20. You can even
load drivers for any or all of these devices, and run mixed
stepper/servo/software step+dir/analog servo drives and motors
simultaneously.

>But, again, my understanding may be limited. But that is what I
>have been able to conclude. It may be that for certain special
>Servo drive hardware...(e.g., something common like Gecko
>drives)...EMC (and others) know how to "talk" the "special language"
>of a Gecko drive...and so can use some HIGHER LEVEL command language
>to direct the servo motor controller...and not just STEP and
>DIRECTION.
>
>

I see that the protocol is in the chip manual, which is half the problem
with writing a driver for EMC. There have been discussions (on emc IRC)
recently about adding a serializing interface to EMC2, which could be
used with serial, USB, and ethernet connected devices. Once that
infrastructure is there, writing a picservo driver for EMC2 is very easy.

>But...I sure concluded that STEP and DIRECTION was the only way I
>was going to control my servos...after I bought three sets of PIC
>Servo SC chips. I concluded this when I realized that there wasn't
>an EMC driver available that understood the high level binary
>commands that the PIC Servo SC chips supported. (Just using EMC as
>an example, here. Not trying to pick on it. And, anyway, it would
>be the chip vendors job to provide such a driver.)
>
>

There is a generic problem with this kind of device in a true
closed-loop system. It's "turnaround time", the measurable lag from the
time the controller starts asking for status (such as motor position),
until that data has been completely received by the control and new
commands can be sent. The PIC-SERVO has a minimum packet size of 4
bytes per servo (start, unit ID, command code, checksum), and the status
packet with 32-bit position is 8 bytes minimum (I think - I only scanned
the docs). I also happened to notice a 0.51 ms command processing
delay, which I've conveniently ignored for now. Looking at a 3-axis
system, that's 3 PWM update packets (a 6-byte packet) and 3 status
return packets (at 8 bytes each, minimum). That's 42 bytes, or 420 bits
per update. The maximum baud rate for the chip is 230400 baud, so it's
roughly 2 milliseconds per update, which is a little slow. Actually,
since this is a slow update rate, there would probably need to be
another packet sent, a "start programmed motion" command, that gets sent
to all units on the serial bus simultaneously, else you'd have the first
axis a millisecond or so ahead of the last. Of course, if you want more
data back than just position, or you add axes, the update rate goes down
accordingly. (Note that this delay problem doesn't exist for normal
"open loop" controllers, because they don't use returned position data
for anything but displaying position, if that)

Of course, you could use one of the more advanced control methods, but
there are potential issues there as well, since the axes are being
independently controlled, not coordinated.

>This brings up the thought that perhaps I should write my own EMC
>driver for the PIC Servo SC chipset. If I don't want to use the
>STEP and DIRECTION interface option. Yeah. That is true. But then
>I would have to find the time for THAT project, too. :-)
>
>

Feel free to write a driver - we'd love to see it ;) Otherwise,
soembody may write one anyway, since we would want to have samples of
drivers that use the lower level communication layers. (don't hold your
breath, but it could happen :) )

>Anyone care to jump in an correct me...on any of the points in my
>postscripts?
>
>

Apparently ;)

>As I said, I am still learning.
>
>

We all should be, even the most experienced of us.

>And I must apologize for hijacking the thread....with my overlong
>postscripts.
>
>

Still an interesting topic, I think.

- Steve