MACRO encoder zero

Does/should the macro encoder zeroing work the same as zeroing an encoder in the main rack?

 

I have

 

ZeroFLHWPMSEnc1->u.io:$600034.18.1; // Gate1[4].Chan[0]
ZeroSpareEnc02->u.io:$90074c.20.1; // Gate3[0].MacroOutB[0][3]

 

Setting the first one to 1 zeroes the encoder and sets itself back to 0 as expected.

 

Setting the second one to 1 zeroes the encoder sometimes but usually goes to 16/31 counts and DOESN'T set itself back to 0 so the encoder keeps attempting the zero.

 

The first one is a Acc24E2S the second one happens to be a Acc24E2S at $9000.

 

Is this normal for MACRO? How can I properly zero the encoder?

In the first (local) case, you are directly reading the hardware counter (in units of whole counts), which has been zeroed.

 

In the second (remote over MACRO) case, you are reading a software-interpolated value (in units of 1/32 count) sent over the ring. The fact that it has a magnitude of less than 32 shows that the counter itself has been zeroed. With the timer-based sub-count interpolation, there is a half-count (16/32 count) offset so that the moving interpolation provides the same value in both directions. If there was movement that stops, the sub-count interpolation saturates at +/- 31/32 of a count as it stops.

 

In the local case, if you looked at the result of the encoder conversion table that processed this encoder, you would see the same effect.

From an application's perspective, for zero-ing an encoder counter, it is best to point a real or virtual motor to the data source and use the HOMEZ command (motor[].pAbsPos must be set to zero).

Thanks for the replies.

 

I guess the bit in the macro output doesn't get reset because it is just that, an output. I just need to know to reset it myself.

 

To look at the local ECT output should I look at EncTable[n].PrevEnc multiplied by EncTable[n].ScaleFactor? What is the equivalent?

 

The idea of using a Motor is what I was thinking. We do this for some encoders. We do not do it for all encoders as one of our Turbo developers says the active motors add an overhead. This throws up a lot of questions concerning timing and the schedule of direct reads, processing ECT, processing motors, and RTI wich may be described somewhere and we will have to look at later (a servo-cycle delay between reference and measurement encoders can make our machine appear out of spec).

 

For now can you tell me the impact of the increased overhead of using motors? We would have 49 encoders to read in addition to 19 real motors.

Obviously, activating software motors to do further processing of encoder positions will add to the processor load. The question is whether this will be worth it, compared to the extra code you would have to write yourself (considering both development effort and processor load).

 

The ECT executes at the beginning of the servo interrupt tasks, acting on hardware data that was latched in at the servo interrupt. As the ECT is independent of motor tasks, it will process data synchronously regardless of whether the data will be further processed by a motor later in the interrupt.

 

If you want to do further processing of your own that will keep the results fully synchronous to that of further motor processing, you must ensure that it is done every servo cycle. You can set Sys.RtIntPeriod to 0, so the PMAC will at least try to execute the RTI tasks every servo cycle (but if the computational loads get very heavy, as from complex motion calculations, it is possible for it to skip cycles). I would advise doing the extra processing in a custom "servo algorithm" for a single additional motor. Many users use a Motor 0 servo for additional processing of this type.

 

To look at the ECT result, you can use the integer EncTable[n].PrevEnc multiplied by the double EncTable[n].ScaleFactor. However, if PrevEnc could roll over in your application, you must account for that. The result value that the servo uses -- (double) EncTable[n].DeltaPos -- is the new value of PrevEnc minus the old, with rollover handled, already multiplied by ScaleFactor. If you use this, you define your zero position in software yourself.

 

As a test, I would use the IDE task manager's "Tasks" screen to evaluate how much extra servo time using PMAC motors to do this processing would cost you. The motors would be activated (Motor[x].ServoCtrl=1) but always disabled, so there would be no trajectory or loop closure calculations.