Help me understand the pulsecoder and mastering data

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

Correct if the master counts are not actually it's a waste of time

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.

Quote from gpunkt

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.

Quote from gpunkt

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.

***Duplicated***

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

Hope this helped.

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.

Quote from SkyeFire

3. When the robot is booted with dead batteries, the value of the encoder is visible...

As I said before, such encoder would not need to "establish pulse count" by moving before mastering.

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.

Quote from gpunkt

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.

Quote from HawkME

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. 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.

Quote from gpunkt

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.

Quote from SkyeFire

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.

Display More

Sorry to dredge up an old thread, was just digging to why the reference position mastering works after battery loss, but not after a zero position mastering. (still confused).

I wanted to clarify the encoder resolutions. They vary by motor model. I do not doubt that much older designs were at one point 4096/rev. However, modern fanuc Pulsecoders have much higher resolutions, which explains some of the massive master count values and the values reported in the system variables:

The servo description manuals don't have much more detail on the operation of the these "absolute" pulse coder. There are references to both battery-less and battery backup encoders though.