Jump to content
OMRON Forums

Unrelated motors abort/kill on limit switch of others (?)


AccurateMovements

Recommended Posts

Kill behavior observed:

While Motor 1 was executing the "home1" cmd from a PLC script, an "unrelated" motor2 triggered its limit switch causing motor1 to kill! (amplifier killed, coast to stop)

 

Abort behavior observed:

If motor1 is simply jogging (#1j+) and motor2 triggers its limit switch motor1 aborts! (ramp to zero velocity, remain enabled)

 

This sounds like expected behavior of two axes in a coordinate system, except these are two unrelated motors (so far as I know).

 

Hmmmm, this is quite strange considering that there are no known relationships defined between these two motors. I do not have any coordinate systems defined. I carefully read the documentation on coordinate systems assuming that all motors may be placed into a default coordinate system (zero, perhaps), which might explain the relationship. I did not find this theory supported in the documents which I read.

 

Motor[1].FaultMode = 0

Motor[2].FaultMode = 0

 

My goal is quicker machine initialization. I would like to home motor1 and motor2 at the same time. If motor2 homing to the limit switch kills the homing of motor1, then this plan of homing two at once will not work. (There is no mechanical interference between the two, so this is a "safe" situation.)

 

How can I configure the two to "better ignore" each other during the homing process and have them home at the same time?

 

Thank You.

Link to comment
Share on other sites

  • Replies 5
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

The following quotes are from Power PMAC User's Manual:

 

It is possible to put all of your active motors in a single coordinate system for completely coordinated action; it is also possible to put each motor in a separate coordinate system (up to the limit of the number of possible coordinate systems) for completely independent action.

 

It is expected that most Power PMAC users will not have an active C.S. 0 (&0), with motors assigned to axes in that coordinate system. Motors that have not been assigned to an axis in any coordinate system automatically use the “time base” (% override value) of C.S. 0.

 

Fault Sharing

All of the motors in a coordinate system react to an automatic fault of any motor in the coordinate system, including fatal following error, amplifier fault, integrated current limit, hardware or software overtravel limit, and encoder loss fault. The specific reaction – enabled stop or disabled state – for various types of faults is determined by the value of saved setup element Motor[x].FaultMode for each motor.

Motors do not automatically react to faults of motors in other coordinate systems. If you wish motors to react to these faults, you must implement this feature in your own routine, probably in a PLC program.

 

I hope this clarifies the matter.

 

Regards,

Link to comment
Share on other sites

Hello Sina,

Thank you for taking the time to review my question. I had read the manual you are quoting before posting and I read it again while trying to debug my system, the details in the manual are appreciated.

 

The question remains - how do motors that are not assigned to a coordinate system behave? (Case 3 below)

I believe there are three states for a motor:

  1. Assigned to a coordinate system with other motors
  2. Assigned to a coordinate system individually (only motor in sys.)
  3. -> Not assigned to any coordinate system. <-

None of my motors are assigned to a coordinate system but still affect each other(!) Is this expected? Since I don't read anywhere that motors are automatically assigned to a coordinate system, limit switches from one affecting another, to me, seems to be unexpected behavior.

Troubleshooting -

Is there a way to ask a motor if it is part of a coordinate system, if one does not already know the relationships? May I ask a coordinate system which motors are assigned to it?

 

Although it does not address the question and seems unnecessary, I realize that I should be able to get the desired behavior by placing each of my motors in their own coordinate system.

 

Please help me clear the "fog" regarding motors and their limit switch interaction when they are not assigned to a coordinate system.

 

Thank You.

 

The following quotes are from Power PMAC User's Manual:

 

It is possible to put all of your active motors in a single coordinate system for completely coordinated action; it is also possible to put each motor in a separate coordinate system (up to the limit of the number of possible coordinate systems) for completely independent action.

 

It is expected that most Power PMAC users will not have an active C.S. 0 (&0), with motors assigned to axes in that coordinate system. Motors that have not been assigned to an axis in any coordinate system automatically use the “time base” (% override value) of C.S. 0.

 

Fault Sharing

All of the motors in a coordinate system react to an automatic fault of any motor in the coordinate system, including fatal following error, amplifier fault, integrated current limit, hardware or software overtravel limit, and encoder loss fault. The specific reaction – enabled stop or disabled state – for various types of faults is determined by the value of saved setup element Motor[x].FaultMode for each motor.

Motors do not automatically react to faults of motors in other coordinate systems. If you wish motors to react to these faults, you must implement this feature in your own routine, probably in a PLC program.

 

I hope this clarifies the matter.

 

Regards,

 

 

Link to comment
Share on other sites

Motors in Power PMAC are always assigned to a coordinate system. By default (that is, on re-initialization), they are all assigned to C.S. 0. Effectively, they are "parked" here, awaiting an explicit assignment. Since they are in the same coordinate system, they will share fault response.

 

To see where motors are assigned, simply issue a command like:

 

#0..31->

 

and Power PMAC will report the axis definitions of all of the motors, including the coordinate systems in which they are defined. Note that a motor with a "null" definition (e.g. #5->0) in a coordinate system is still in that coordinate system for purposes of time base and fault response.

Link to comment
Share on other sites

Curt,

Thank you, you have directly answered both of my questions. I see now that a motor is always assigned in a coordinate system (My Case3 posted previously is not a valid state.). I was looking for the line which said, "By default..." and the answer is that they are in coordinate system 0 and thus would share fault actions. (Just because they share timebase of cs0, that didn't explicitly tell me that they were in that system, but now I know for sure that they are.)

 

Motors in Power PMAC are always assigned to a coordinate system. By default (that is, on re-initialization), they are all assigned to C.S. 0. Effectively, they are "parked" here, awaiting an explicit assignment. Since they are in the same coordinate system, they will share fault response.

 

 

Thank you for this answer as well, which was, "To which coordinate system are my motors currently assigned?"

To see where motors are assigned, simply issue a command like:

 

#0..31->

 

and Power PMAC will report the axis definitions of all of the motors, including the coordinate systems in which they are defined. Note that a motor with a "null" definition (e.g. #5->0) in a coordinate system is still in that coordinate system for purposes of time base and fault response.

 

I was able to move my motors to unique coordinate systems, after which time, they were able to successfully home to their limit switches and would not affect unrelated motors.

 

Thank You again for the answers, my project is off and running again!

Thanks.

Link to comment
Share on other sites

Most people who home into a limit switch temporarily disable the limit-switch functionality for the duration of the homing-search move by setting Motor[x].pLimits to 0. After the finding the trigger, and settling at the end of the post-trigger move (which usually includes an offset out of the limit using Motor[x].HomeOffset), Motor[x].pLimits is restored to the address of the limit inputs.
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...