Re: pic-servo & EMC

[Thanks for your patience in explaining some of this, Andy. I'm still
mostly in the dark, but I'm seeing some light at the end of the tunnel...]

> Message: 16
> Date: Sat, 17 Jul 1999 22:10:01 -0700
> From: "Andy Olney" <aolney@...>
> Subject: Re: EMC and PIc-Servo
>
> Andrew -
>
> I have talked with both Fred Proctor and Jeff Kerr (picservo designer)

about

> what it would take to make EMC run a picservo.
>
> [Thanks for running this down, Andy. I'm going to need a little help
> translating some of this, though, so bear with me...]
>
> Here is Fred's reply:
>
> Andy,
>
> I was forwarded your question on the possibility of adapting the EMC
> code to interface to a servo board. This is quite possible. I prefer
> using dumb I/O cards that have DACs and encoder counters, using the CPU
> for all calculations, but if you have an I/O card already then it makes
> sense to keep that and avoid paying for an I/O card.
>
> [Are these features (DACs -whatever they are- and encoder counters)
> standard features on I/O cards? If they had them, would they still be
> "dumb"? I've put an I/o card in my computer when I needed an extra

parallel

> port, but I didn't think they did much more than route signals to and fro.
> Is Fred referring to the pic-servo card as an I/O card?]

The dumb i/o card Fred is referring to is the $880 Servo To Go card which
can read (in hardware)
8 encoders and do a digital to analogue conversion of EMC's control output.
This analogue control output is sent to a servo amplifier which powers DC
servo motors.

[So if the Servo-to-go card is "dumb", is the Pic-Servo "dumber"? Or are
they functionally equivalent? I suppose a "smart" card would be one with a
DSP on board? ]

>
> You described taking the voltage output, which is proportional to the
> desired velocity, and feeding this to the servo board. The board would
> then close the loop on velocity, which is probably not what you want.
> You can take the *input* to the PID calculations,
>
> [What are PID calculations?]

Proportional, Intregral, Derivitive calcs are essentially a way to make a
servo follow a commanded position with the minimun undershoot or overshoot
and max smoothness.

[Is this the analog control output referred to above which actually moves
the motors, or something else?]

>
> and pass this directly
> to the board. There are no extintf.h functions for this since I don't do
> this now, but they could look like this:
>
> extern int extPosWrite(int axis, double pos);
>
> This would be called instead of the PID calculations done in
> pidRunCycle, e.g.,
>
> // assume 'softwareServo' is set somehow to non-zero for usual, 0 for
> hardware boards
> if (softwareServo) {
> emcmotStatus->output[axis] =
> pidRunCycle(&emcmotStatus->pid[axis],
> emcmotStatus->input[axis],
> jointPos[axis]);
> }
> else {
> emcmotStatus->output[axis] = 0.0; // FIXME-- could read DACs on board
> and fill this in
> extPosWrite(axis, jointPos[axis]);
> }
>
> I haven't tested this but it's close to what will work.
>
> --Fred
>
> [Uh, are these commands I'd have to give EMC, or is this a summary of the
> programming work that would have to be done?]

He is describing where to alter the EMC code to talk to the Pic Servo.
The function "extern int extPosWrite(int axis, double pos);" would have to
be written to talk to the picservo through a serial port. I am guessing you
would want to access the serial port through the RTLinux subsystem to be
sure of communicating in a timely manner.

>
>
> Jeff Kerr also said that he was able to talk to 2 axis at about 400
> commands per second:
>
> [But I need to talk to 3 axes, I think.. Would that slow things down, or

be

> impossible, or what?]

Hopefully three axes could be done at a slightly slower rate.

>
> > Regarding the NIST EMC software, the stepper control may be the easiest
> > to implement, although inelegant. We have implemented some contouring
> > schemes reading the positions and commanding velocities and have gotten
> > good results down to about 30 commands/second. Another alternative it
> > to use two serial ports with two controllers on each port. This would
> allow
> > you to issue raw positions commands (Using the STOP command) for two
> > axes at a rate of about 400 commands per second. This would probably
> > be smooth enough, and is much simpler to implement.
> >
>
> [I don't know how I'd generate all these STOP commands. I was hoping to be
> able to use standard G-code.]

The Picservo has a special STOP command which in effect lets you issue a
stream of position commands without stopping at all. The function "extern
int extPosWrite(int axis, double pos);" would issue these commands under
EMC, which is interpreting the G-codes.

[Oh, I see- why do they call it a "Stop" command? One would think "Go"
more appropriate (but I guess that's already taken). How are commands to
the pic-servo board differentiated from commands to the rest of the system?
Are there any more of these that I should be aware of? What would you do if
you actually wanted the thing to stop, like in an emergency?]

>
>
> To get EMC talking to a Picservo it looks like at least the following

would

> have to be done:
>
> 1. Write Fred's external interface.
>
> [Who would be the one to do that- Fred?]

Good question. I think I know what it needs to do, but it would take be a
long time to learn how to write, compile, debug etc.

[If Fred's not up for it, would Jeff be able to do this? If so, would he
want to?]

>
> 2. Figure out how to make a serial port talk to the picservo from within

RT

> linux ( There is some code for a serial port interface on the RT linux
> site).
>
> [Is this still a problem then? Is this something that hasn't been done
> before? Would the serial port be used to convey the positional feedback
> information to EMC while the parallel port is issuing the directional
> commands?]

There is a stepper interface to the PicServo ( another little circuit
board ) but the goal would be to talk entirely via serial port, which
implies a serial connection.

>
> 3. Write the standard external interfaces to setup and initialize the
> picservo boards as well as read the limit swithces etc.
>
> [Since these are standard, could they be copied from somewhere? Is this up
> to me to do (as you can probably tell, I'm hardly qualified for the job)

or

> is this an easy task for Jeff Kerr?]

I was referring to EMC's external interface functions, which have to be
customized for each set of hardware.

[Is this simply a matter of choosing hardware from a list, or does it have
to be written in C++, hexadecimal, or something else?]

> I sure there is more to it as always. I am not much of a C programmer
> understatement !) but I would like to get these little servo boards going
> with EMC also.
>
> Andy Olney
>
> [Since this all sounds extremely daunting (not to mention the "more to it"
> part), is there any servo card that IS currently supported by EMC? What
> about the Servo-to-go? ]
>

I am interested in the Pic Servo because is looks to be a cost effective way
to add closed loop motion control to my mill.

Andy

[While it's the cheapest thing I've come across that has "servo" in the
name, it sounds like actually using it with EMC is a long way off- or is
this all really simple stuff that these guys are going to be able to
implement quickly so people like me can just "point and shoot"? What, if
anything, is actually supported presently, that I can just buy and hook up
to my servo mill? Learning to use Linux is going to be hard enough for me-
writing all this code is going to have to wait for another lifetime...]

Andrew Werby - United Artworks
Sculpture, Jewelry, and Other Art Stuff
http://unitedartworks.com