Control Extenal Servo Motor via I/O

T

Thread Starter

TheFabricator

Hi,

I am trying to control a external servo motor from a robot controller via I/O communication.

Can someone give me an idea of the steps involved to achieve that?
 
Pretty vague request- this has a lot of generic information based on speculation. don't know what the motion requirement are. assuming robot is main control of the machine and no separate plc or motion controller? if so, then a programmable servo drive(s) can execute motion profiles on command via IO.

servo is basically a slave device waiting for commands. It has limitations. Goes something like this:

- highest priority is safety circuit. safety devices satisfied and operational reset of safety controller/relay is tied to the safety inputs of the robot and programmable drive

- bringing the system up is something like:
1. wait on safety circuit satisfied and reset

2. when ready, robot tells axis to initialize, waits for completion

3. system ready to run.

4. robot controls sequence of operation via IO and monitors for
success/failure, faults etc. continue as long as all good.

- define io interface between the robot and programmable drive. this could include:

safety system ---> servo & robot
1. axis and robot enable
may have immediate stop and delayed enable drop out (which allows logically driving a hard stop before safety enable removed).

servo ---> safety
1. monitor aux signal. may not be necessary

robot output ---> servo input
1. enable/disable where robot commands servo enable disable. tied in with the safety circuit (typically in series)

2. robot commands servo to initialize. servo axis executes homing routine, home offsets, and any required initialization functions.

3. move command output(s) from robot that tell the axis to execute pre-programmed moves or profiles. Often they are binary commands or coded if there are multiple move profiles. requires definition.

4. controlled stop command- may not be required, but often is- in case there is an event (jam, process condition) that requires the servo to do a controlled stop but not a hard stop

5. hard stop command- could be part of estop circuit (time delayed loss of the safety enable allowing load to be driven to a stop before enable removed).

6. reset. requires definition- might be a fault reset, reset of position control following interrupted motion (estop or controlled stop).

servo output ---> robot input
1. homed & ready, lets the robot know the servo has homed, is enabled, not faulted and ready to play nice in the sandbox

2. in motion, lets the robot know two things: in position and in motion. this way the robot may command motion, then monitor state of the axis as in motion and completion of motion.

3. fault status. robot should know if axis state is faulted or not. separate from homed/ready output

4. an in-position output is sometimes handy if there are external forces working against the axis.

there are a boat load of other possibilities that are application specific and "public opinion" will vary greatly.

this can all go a lot of different directions.

my humble opinion: when limited to IO interface on a programmable drive, I'm always left feeling like I want more. Motion networks like Ethercat make everything available for use, really fast and super reliable. That said, there are some pretty nice programmable servo's out there- Yaskawa comes to mind right away. lots of systems are deployed with IO interface and it can work fine if the requirements are simple and well defined.

good luck
 
Top