Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
HomePos Behaviour Using SSI Absolute Encoder
#1
Hello, I'm working in a project and the Encoder I'm using is a SSI Absolute (25 Bits - 13 Bits Single Turn, 12 Bits Multiturn, Gray Code).

I'm currently getting a strange behaviour from the capture position. Everytime I do a reset with the motor in a position, the capture position changes to a different one, what is not expected from an absolute encoder.

Since the capture pos depends on the HomePos, I checked and it is what is changing everytime a reset is done. The HomePos is related to the last position before the reset and not to the reference zero as it should be expected while using an absolute encoder.

I would like to know what could be causing this behaviour and what parameter might be related to it.

Some Info of my project:
PowerBrick[0].Chan[2].SerialEncCmd = $1819;
Motor[4].pAbsPos=PowerBrick[0].Chan[3].SerialEncDataA.a;
Motor[4].AbsPosFormat=$72001907;
Reply
#2
Motor position variables tend to be position relative to the Motor's power on position. This is true for at least Motor[x].Pos, Motor[x].ActPos, Motor[x].DesPos.

To get the (compensated encoder) position relative to home, you would take Motor[x].ActPos-Motor[x].HomePos.

On a HOMEZ or HMZ, PMAC does not change the value of Motor[x].ActPos, but instead changes Motor[x].HomePos based on the captured absolute position so that Motor[x].ActPos-Motor[x].HomePos is your captured absolute position. This means the Captured position should change and HomePos should be the power on position.
Reply
#3
(05-31-2019, 03:17 PM)Eric Hotchkiss Wrote: Motor position variables tend to be position relative to the Motor's power on position. This is true for at least Motor[x].Pos, Motor[x].ActPos, Motor[x].DesPos.

To get the (compensated encoder) position relative to home, you would take Motor[x].ActPos-Motor[x].HomePos.

On a HOMEZ or HMZ, PMAC does not change the value of Motor[x].ActPos, but instead changes Motor[x].HomePos based on the captured absolute position so that Motor[x].ActPos-Motor[x].HomePos is your captured absolute position. This means the Captured position should change and HomePos should be the power on position.

Right, ActPos is relative to the absolute power on position, so it should be an absolute position when using an absolute encoder. The Capture Pos depends on the ActPos value and the HomePos value, shouldn't the HomePos position always be absolute 0 as reference position for absolute encoder? It's absolute, the zero is known, after a reset the encoder reference should not change, and the ActPos should not too as it's reading an absolute position value (raw data), so what could be changing the read value after a reset? (the motor is not moved).
Reply
#4
Even for an absolute serial encoder, your position comes from two sources.
Motor[x].Pos/ActPos is created by looking at the change in the number Enctable[n].pEnc points at since PMAC starts up (or since Motor[x].ServoCtrl was set =1). This is purely incremental and ignores the value on startup.
Homez/HMZ, reading the absolute encoder to set Motor[x].HomePos.
Reply
#5
(06-03-2019, 09:48 AM)Eric Hotchkiss Wrote: Even for an absolute serial encoder, your position comes from two sources.
Motor[x].Pos/ActPos is created by looking at the change in the number Enctable[n].pEnc points at since PMAC starts up (or since Motor[x].ServoCtrl was set =1). This is purely incremental and ignores the value on startup.
Homez/HMZ, reading the absolute encoder to set Motor[x].HomePos.

Yes, I understand that. But my problem is that if I move motor till a X in the capture position and then do a reset (using $$$ or in the source), the capture position that is read is different than it was before, without moving motor again.

I've tried working with the PowerOnMode and the AbsPosFormat, but with no success. And sometimes if I do a second reset after the first one, the capture pos values goes to zero, really strange behaviour.
Reply
#6
What do you mean by capture position? I feel like I was misunderstanding your question. Looking back over, it sounds like you just mean the position displayed in the IDE after a $$$ or #4hmz. Is this correct? Maybe the HomePos value is changing, but the real question is why does my position look like nonsense after a $$$ or #4hmz?

This could easily mean the scale factors for ongoing vs power up positions don't match or a number of settings. I'd like to start with Motor[4].AbsPosFormat

Motor[4].AbsPosFormat looks a little funny. We normally say Motor[4].AbsPosFormat=$AABBCCDD and look at each byte individually
Motor[4].AbsPosFormat=$72001907
DD=$07=7 Read from first register starting at bit 7
CC=$19=25 Read a total of 25 bits
BB=$00=0 When reading remaining bits from second register, start at bit 0
AA=$72=114 Use a format of ????
AA should be 0-3 for signed/unsigned binary/grey code.
Reply
#7
(06-03-2019, 02:39 PM)Eric Hotchkiss Wrote: What do you mean by capture position? I feel like I was misunderstanding your question. Looking back over, it sounds like you just mean the position displayed in the IDE after a $$$ or #4hmz. Is this correct? Maybe the HomePos value is changing, but the real question is why does my position look like nonsense after a $$$ or #4hmz?

This could easily mean the scale factors for ongoing vs power up positions don't match or a number of settings. I'd like to start with Motor[4].AbsPosFormat

Motor[4].AbsPosFormat looks a little funny. We normally say Motor[4].AbsPosFormat=$AABBCCDD and look at each byte individually
Motor[4].AbsPosFormat=$72001907
DD=$07=7 Read from first register starting at bit 7
CC=$19=25 Read a total of 25 bits
BB=$00=0 When reading remaining bits from second register, start at bit 0
AA=$72=114 Use a format of ????
AA should be 0-3 for signed/unsigned binary/grey code.

By captured position I mean ActPos - HomePos, that is the position we see in the IDE.

I'm using AA this way: First A as 7 because we have 25 bits of data, we need to shift 7 bits to the left to have it as MSBs, it can be done using the first A as indicated in the manual. The second A is set as 2 to get the conversion from gray code to unsigned binary. I even tried using $02 instead of $72, without this shift, but get the same results, sometimes it just goes to zero (both ActPos and HomePos goes zero).

The rest is exactly as you pointed.

I tried testing changes in PowerOnMode too, do you have a guess about this parameter? It's a stepper motor and I'm using hybrid mode. I would keep PowerOnMode as 2, but I tried other configurations.
Reply
#8
I'm attaching our absolute position read slides. They go over doing the read (from hmz or power up with PowerOnMode set), but not the actual gate serial settings (SerialEncCmd).

If you move the motor by hand, does it seem to move by the appropriate number of motor units?
If so, you probably have the correct value of Motor[x].PosSf and Motor[x].Pos2Sf. As well as ongoing position setup in general.

If that is correct, take a look at Motor[x].AbsPosSf, this should match Motor[x].PosSf.

I am still skeptical of Motor[4].AbsPosFormat, but it sounds like changing it does not fix your problem.

You could also check the value of PowerBrick[0].Chan[2].SerialEncDataA and see if this is the position data you expect (position bits can change by rotating the motor).


Attached Files
.pdf   Serial On-Going Position.pdf (Size: 897.15 KB / Downloads: 6)
.pdf   Absolute Position Read.pdf (Size: 818.84 KB / Downloads: 8)
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)