Jump to content
OMRON Forums

Motor xx Fatal Following Error Limit not high enough


Recommended Posts

  • Replies 9
  • Created
  • Last Reply

Top Posters In This Topic

Thanks for your answer Steve. This are not very high values in our system configuration, although they are higher than the usual ones. It's just when the telescope slews (1.0 deg/s) to the target we don't mind about the following error, as long as it's kept inside a safety range. The current following error is low enough to stabilise the telescope when being on tracking and doing acquisitions, in this case the telescope moves at a much slower rate (often around 0.01 deg/s). So we want to have a kind of dynamic fatal following error limit, depending on type/speed of the current movement.


Could you please explain the procedure to re-scale the feedback? I see that Ixx08=1 and Ixx09=1 on our current application.

Link to comment
Share on other sites

We need to find a way to physically reduce the count density of the feedback device. Typically once there is a reduction, Ixx08 and Ixx09 would be increased by the same ratio (assuming the same sensor for both Ixx03 and Ixx04) to allow the same PID values, or, maybe some intermediate adjustment of 1xx03/04 and gains. You would then maintain two different sets of ECT entries, one set for the regular feedback and one set for the reduced feedback. To switch between the two feedback device (even on the fly) is simply changing Ix03, Ix04, previous actual position, and previous actual “velocity” position in a single servo cycle in a PLC0. I know you have a number of special filters and user servo – I’m not sure how this will impact the situation so I will need some details on your feedback setup and these connections.



Example from motor #1 to Motor #2 (UMAC):

(From the SRM memory map section)

Y:$000x8A/0A Motor previous actual source position value

Y:$000x9D/1D Motor previous velocity-loop source position


M1->Y:$8A,0,24,S ; Motor #1 Previous Actual Position

M2->Y$9D,0,24,S ; Motor #1 Previous ‘Velocity’ Position

M3->X:$3502,0,24,S ; Encoder #2 ECT converted data



I103 = $3502 ; Was $3501 (default)

I104 = $3502 ; Was $3501 (default)

M1 = M3

M2 = M3



Link to comment
Share on other sites

From what I understand from your explanation, the way to reduce the count density would be inside the ECT, could you be more specific how could I achieve this? And which other parameters would be affected due to this scaling?

I think it's not needed to re-scale the feedback on the fly, once this new reduced ECT configuration is established I can change the fatal following error limit forever, this seems easier and less error prone to me, or am I wrong?


Do you need any variables information or configuration? Please let me know and I can post it here or send it to you by email.

Link to comment
Share on other sites

Basically we could process the raw encoder register in the ECT as a parallel x word and not shift to get 32 times reduction but as I remember your feedback was not out of a gate encoder register but some memory location generated by a PLC0 or user servo. I will need to know the details of how your feedback is done to come up with a workable scheme.
Link to comment
Share on other sites

  • 2 months later...

Sorry for the interruption, we were working on other higher priority projects. Giving some time to this again.


Two questions have arisen:

1. When I reduce the gear ratio from the feedback, lets say I would divide it by 32, isn't there a loss of resolution?

2. Would an alternative where I just disable the internal limit and use a variable for checking in our user written servo be a valid approach? Or could this somehow be dangerous? I mean this is the only known part of the code where a new demand to our servo drives is calculated, this is why I came up with this place being the apparently optimal, as here is where the following error is used to produce a new demand.

Link to comment
Share on other sites

There would not be a loss of resolution as the LSB of the feedback device would still be used if this is currently an ECT processed encoder from a PMAC servo gate.


What is the source of this feedback?


Your approach in #2 is valid (could also be in a background or RTI PLC) but you may want to have a "check", as in a simple counter, that any program move could check first that the code is running whether it is a user servo or a PLC (background or RTI). Even user servo could be inadvertently deactivated with Ixx59.

Link to comment
Share on other sites

Thanks for your answers Steve, but the one about #2 I'm not sure to have understood it. What did you mean about having a "check"? If user servo is disabled this would be dangerous so do you mean apart from the UserServo modification, another PLC that checks that Ixx59 is active and if not doesn't allows to move?


I wanted to implement something like this in the user written servo code section:

Tracking is the slow high precision movement, and slewing the faster one.


If (MTRNUM = 2)

;Checks if a slewing period starts

If (isTracking = 1) And(current_velocity > min_slew_velocity)

isTracking = 0

I211 = 0



;Checks if a tracking period starts

If(isTracking=0) And(current_velocity < min_slew_velocity)

isTracking = 1

I211 = tracking_fatal_following_error_limit



;Stops the movement if higher following error exceeded

If (following_error > slewing_fatal_following_error_limit)


RETURN(0) ;Break execution and return zero current demand



;Here new current demand depending on current and demanded position is calculated with PID






Here is our current ECT setup, we are only using motor #2 as a real motor, feedback is obtained from encoder on motor#1, and motor #3 is for synchronization purposes, if you need any more info please don't hesitate to ask us for it:

























Link to comment
Share on other sites

By “check” I mean something that positively determines the user servo (or PLC) is running. A counter would be a very simple technique, as in P99=P99+1. The host computer, or other PMAC program starting motion or closing the loop, would check that the counter is in fact counting.


If motor #2 is looking at a real encoder you could have another ECT entry to implement my #6 post.

Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...