Re: Digest Number 98
Posted by
Andrew Werby
on 1999-07-18 04:30:14 UTC
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?]
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?]
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?]
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?]
able to use standard G-code.]
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?]
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?]
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 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? ]
Andrew Werby
Andrew Werby - United Artworks
Sculpture, Jewelry, and Other Art Stuff
http://unitedartworks.com
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?]
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?]
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?]
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?]
> Regarding the NIST EMC software, the stepper control may be the easiestallow
> 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
> you to issue raw positions commands (Using the STOP command) for two[I don't know how I'd generate all these STOP commands. I was hoping to be
> axes at a rate of about 400 commands per second. This would probably
> be smooth enough, and is much simpler to implement.
>
able to use standard G-code.]
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?]
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?]
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 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? ]
Andrew Werby
Andrew Werby - United Artworks
Sculpture, Jewelry, and Other Art Stuff
http://unitedartworks.com
Discussion Thread
Andrew Werby
1999-07-18 04:30:14 UTC
Re: Digest Number 98
Andy Olney
1999-07-18 15:54:57 UTC
Re: Digest Number 98