Help me understand the pulsecoder and mastering data

  • Hi!


    Please enlighten me on this topic.


    How does the pulsecoders in FANUC robots actually work?


    As I have understood, when not supplied with voltage (either through the controller when power is turned on or through backup batteries) they will loose track of their values.

    To me this indicates some sort of incremental encoder.


    But ok, no problem. We provide voltage to the pulsecoder and it needs to be moved past it's "0-mark" (I do not mean the physical axis' zero mark, but rather the pulsecoder's zero mark) in order to establish a pulse count.


    I would assume then that regardless of power loss, the pulsecoder would (once it has established a pulse count) report the exact same pulse count when the physical axis is att a certain position, as it did before the power loss. But it seems as though that's not the case....


    Because when you perform a Quick Mastering after having a BZAL for instance, then the $MASTER_COUN values will be different than before. And sure, I can agree that with the ridiculously high resolution of the pulsecoders, it will be basically impossible to jog the robot back to those exact pulse counts. but after a QM, if you run the robot to it's 0°-marks, wouldn't you then be at the $REF_COUNT values? And if you do a QM while there, wouldn't the $MASTER_COUN be the same as $REF_COUNT then?


    Or am I completely mistaken?


    Please, someone who actually knows, explain it to me. Feel free to draw pictures and treat me like a 5-year old if needed :smiling_face:

  • Place your Ad here!
  • My understanding is the master counts can be put into ref_count and then set ref_done to true. If you are within one motor rev the quick master will work and the ref count will become the master counts

    Thanks, but this doesn't answer my question.

    The procedure you're describing seems like the quick fix for Motoman's infamous "Second Home Position" alarm.

    If you were to follow your procedure, then yes, the master count would be the same as the ref count, but unless your master count is in fact the correct ones, then your positions would be off.

  • Motor absolute position is number of full turns from certain zero+ position within turn.

    Many absolute encoders are absolute within one turn, but require battery backup for multiturn counter. Such encoder would not need to "establish a pulse count".

    The need to "establish a pulse count" by passing the encoder zero mark indicates an incremental encoder with battery backup. After "pulse count established" the zero mark is not in use.

    After "pulse count establish" the zero turn reference is different, and the new master count, after correct quick mastering ,will be different from the old one by exact multiple of full turns.

    Disclaimer: These are my own conclusions, not confirmed information.

  • Motor absolute position is number of full turns from certain zero+ position within turn.

    Many absolute encoders are absolute within one turn, but require battery backup for multiturn counter. Such encoder would not need to "establish a pulse count".

    The need to "establish a pulse count" by passing the encoder zero mark indicates an incremental encoder with battery backup. After "pulse count established" the zero mark is not in use.

    After "pulse count establish" the zero turn reference is different, and the new master count, after correct quick mastering ,will be different from the old one by exact multiple of full turns.

    Disclaimer: These are my own conclusions, not confirmed information.

    Hi,
    Yes, I'm on the same track as you. However, since the master count will allways be different when you need to establish a new pulse count (due to battery loss for instance), I'm starting to think that the encoders/pulsecoders don't have any "zero-flag", but rather that they need a certain amount of pulses before they can start counting again. And this will then (because of the high resolution of the pulsecoders) almost certainly be at a different mechanical position than before, which is why the master count will be different.


    Otherwise, there would have to be a finite number of mechanical positions from where the pulse can be established, and then it would "only" be a matter of having the robot's axes in the correct mechanical position when supplying power to the pulsecoders to be able to establish a pulse.

  • I'm starting to think that the encoders/pulsecoders don't have any "zero-flag",..

    Since Quick Mastering restores mastering precisely within the motor turn, the encoder has to have zero reference position within turn, a.k.a. zero pulse.

    Otherwise, there would have to be a finite number of mechanical positions from where the pulse can be established, and then it would "only" be a matter of having the robot's axes in the correct mechanical position when supplying power to the pulsecoders to be able to establish a pulse.

    The maximum displacement to find the zero mark is one motor turn.

    This is not that much of the axis displacement.

  • Quote from gpunkt

    Hi!


    Please enlighten me on this topic.


    How does the pulsecoders in FANUC robots actually work?


    They works as allways (joke)


    As I have understood, when not supplied with voltage (either through the controller when power is turned on or through backup batteries) they will loose track of their values.

    To me this indicates some sort of incremental encoder.


    In fact, they are absolute pulse coders, but the electronics inside the encapsulation makes them work as incremental (this is the reason they need constant power supply, if supply is lost then the memory is cleared)


    But ok, no problem. We provide voltage to the pulsecoder and it needs to be moved past it's "0-mark" (I do not mean the physical axis' zero mark, but rather the pulsecoder's zero mark) in order to establish a pulse count.


    Not really, the suggested +-10º movement is needed to establish the direction of rotation (positive or negative)


    I would assume then that regardless of power loss, the pulsecoder would (once it has established a pulse count) report the exact same pulse count when the physical axis is att a certain position, as it did before the power loss. But it seems as though that's not the case....


    As said before, this is not the case. When encapsulated electronics loose the supply, the incremental value gets lost (BZAL - batteries drained or pulse coder cable disconnected)


    Because when you perform a Quick Mastering after having a BZAL for instance, then the $MASTER_COUN values will be different than before. And sure, I can agree that with the ridiculously high resolution of the pulsecoders, it will be basically impossible to jog the robot back to those exact pulse counts. but after a QM, if you run the robot to it's 0°-marks, wouldn't you then be at the $REF_COUNT values? And if you do a QM while there, wouldn't the $MASTER_COUN be the same as $REF_COUNT then?


    Ok, point by point:


    It is useless to perform a QM if you dont teach before a QMRef. When you teach a QMRef, you store the pulsecoder counts and angle positions of each axis. Then, when you want to do a QM, you must move manually the robot to the QMRef Position and then perform the QM.


    Doing this, the robot knows that the angles of each axis are known, and then it can calculate the zero position of each axis using the actual pulse coder counts and $REF_COUNT pulse coder values, then storing them on $MASTER_COUNT vars.



    Or am I completely mistaken?


    I think you needed some concept explanations, nothing more.


    Please, someone who actually knows, explain it to me. Feel free to draw pictures and treat me like a 5-year old if needed :smiling_face:


    Hope this helped.


  • Thank you for clarification.

    I am well aware of the need of a well defined reference position being recorded before a QM can be done. If not done (or done the wrong way) then QM is of little to no use.


    Also, the concept of the incremental behavior of an absolute encoder baffled me. But since I wrote the original post, I have come to the conclusion that the encoder doesn't have a defined 0-mark/0-flag, but rather this will be in an arbitrary position that is dependent on what physical position the encoder is at when power is supplied.

  • So, my understanding of this subject is incomplete, but what the heck:


    1. The Fanuc encoders are absolute encoders, mounted to the servo motor driveshaft. As the motor rotates, the absolute value from the encoder ranges between 0 and some maximum (I've heard 4096, but that may be wrong) -- if the motor rotates one way, it counts down to 0 then "underflows" to 4096, and if moving the other way, it counts up to 4096 then "overflows" to 0. So (assuing 4096-count encoders), the motor would have a rotation resolution of 360deg/4096=0.08789deg.


    2. The servo motor rotates multiple times for each degree of axis rotation. The motor feeds into a gear trains (harmonic drives, wave gears, etc) that multiplies the motor's torque, at the cost of speed. It's not unusual for these gear trains to have input/output ratios of 150-250:1


    3. When the robot is booted with dead batteries, the value of the encoder is visible, but the number of rotations (how many times the encoder has passed 0 in which direction) is lost. So the robot knows exactly where the motor is within one rotation, but the larger context has been lost.


    4. The factory encoder values that come with every robot (and unique to each one) represent the exact position of the "Master" position of each axis within the encoder rotation. That's why Mastering works by a "be within one motor rotation of the physical Master position" rule -- the human eyeball is accurate enough to achieve that with good vernier marks. So the human eye provides the "rough" Mastering (to within +/- one motor rotation), and the factory encoder value provides the "fine" Mastering.


    5. #4 happens because it would be impractical to try to perfectly align each axis, and each motor, at 0 before assembly at the factory. Not to mention replacing motors in the field. And when replacing a motor in the field, the 'factory' encoder value must be updated, b/c it's essentially impossible to get two different motors rotated to exactly the same encoder value in that situation.


    ABB works essentially the same way as Fanuc. KUKA does it differently -- instead of absolute encoders, KUKA servos have resolvers -- like a simple quadrature encoder, except generating two sine waves instead of two pulse trains. KUKAs keep track of both the "rough" and "fine" Mastering in memory (and on an EEPROM chip). This makes KUKAs less vulnerable to losing Mastering due to dead batteries, but requires extremely fine Mastering (more than the human eye can manage) any time an axis needs re-Mastering. This is why KUKAs have special tools for Mastering.

  • So, my understanding of this subject is incomplete, but what the heck:


    1. The Fanuc encoders are absolute encoders, mounted to the servo motor driveshaft. As the motor rotates, the absolute value from the encoder ranges between 0 and some maximum (I've heard 4096, but that may be wrong) -- if the motor rotates one way, it counts down to 0 then "underflows" to 4096, and if moving the other way, it counts up to 4096 then "overflows" to 0. So (assuing 4096-count encoders), the motor would have a rotation resolution of 360deg/4096=0.08789deg.

    With all due respect, but this indicates that it would be possible to achieve the exact same mastering data as the original after a BZAL:

    Go to the vernier marks -> perform QM -> Move to 0° with a TP program -> force a BZAL by removing batteries while powered off -> Perform a new QM (robot is already at 0°) and the mastering data should be back at the orginial.


    3. When the robot is booted with dead batteries, the value of the encoder is visible, but the number of rotations (how many times the encoder has passed 0 in which direction) is lost. So the robot knows exactly where the motor is within one rotation, but the larger context has been lost.

    I beg to differ. The encoder value will not be visible/readable until pulse is established, which seems to need more than one motor revolution.
    Until pulse has been established, only the last recorded value of the pulsecoder is present in the system variable.


    I would agree with Sergei Troizky on this one.

  • The encoder value will not be visible/readable until pulse is established, which seems to need more than one motor revolution.

    It should be -- an absolute encoder will always have "live" data of its absolute position, as long as it has power. Many of these encoders are glass disks with binary values inscribed into their surface in radial patterns. Similarly, DRO encoders on machine tools.


    Whether Fanuc servos use this type of encoder, I'm not sure. I have a hazy memory of seeing one disassembled many years ago and having the photo-etched encoder disk, but I could easily be remembering incorrectly.

    I don't pretend to understand how it works, but I think it is very disappointing that in the year of 2023 we still need backup batteries for encoders.

    Good news! KUKAs don't. :icon_smile: OTOH, they get around the battery issue by relying on EEPROMs that do eventually hit their end of life, although they do seem to last decades in most usages.


    Jokes aside, I suppose the manufacturers just haven't felt enough pressure from their customers to put more R&D into a "if it ain't broke, don't fix it" situation. Not to mention the pain factor of getting any new replacement certified through all the various safety requirements.


    In an ideal world, we've have absolute encoders wrapped around every axis, but the amount of custom parts would be a nightmare. Not to mention what field repairs would require.

  • With all due respect, but this indicates that it would be possible to achieve the exact same mastering data as the original after a BZAL:


    Sorry, but I disagree with this.


    INTRO:


    Robot just installed, BEFORE BZALM and no QMRef recorded: If you send robot to 0º, $PULSE_COUNT, $REF_COUNT and $MASTER_COUNT have the same values, and angles of QMRef are 0º (factory default)


    From now on: BZALM has occurred, batteries changed, RES_PCA performed. $PULSE_COUNT values changed from original ones due to lack of power to the pulse coder enclosure. $MASTER_COUNT and $REF_COUNT keeps original values as we still didn't mastered and we didn't record new QMRef


    Go to the vernier marks -> perform QM


    When you do QM, robot calculates the new $MASTER_COUNT values based on $REF_COUNT values and actual $PULSE_COUNT values, but $PULSE_COUNT values are totally different from original $MASTER_COUNT values, so they are not the same as original ones. (factory default was all three vars equal)


    -> Move to 0° with a TP program


    Not sure if you can move to 0º position using a program without calibrating (but I think it can be done changing representation of point coords to JOINT). Lets say its possible, doesn't matter. At this moment you are moving robot to 0 position BASED ON NEW $MASTER_COUNT VALUES obtained from previous QM


    -> force a BZAL by removing batteries while powered off -> Perform a new QM (robot is already at 0°)


    At this point you are using the $MASTER_COUNT values calculated on pharagraph 2...


    and the mastering data should be back at the orginial.


    ... so they are not the same as original ones



    Please forgive me if I sound too prepotent, maybe I have not so much vocabulary to speak more colloquial expressions. Really, it's not my intention, I only want to help.

    Edited 5 times, last by LoPelut ().

  • Hi,

    This was exactly my point.

    IF it was "true" absolute encoders, that are absolute within one revolution and have a 0-mark that is physically/mechanically fixed, then there is a finite number of positions (of the axis) where the encoder will line up with a certain pulsecount, regardless of if there has been power loss to the encoder or not.


    In reality, it is like you describe, which indicates that there is no actual 0-mark on the encoder, but rather that this will be set at whatever position the encoder is at when pulse is established. And this could be basically anywhere. Hence, the new calculated master count will be different.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners