Conver absolute encoder raw values to modulo 360

[Peter Nachtwey]

I can see you guys don't take hints. The trick is to use the absolute encoder like an incremental.
Only the bottom 16 bits are required so and the absolute encoder counts with 0xFFFF. A PLC can handle 16 bit numbers easily.
First, find a way to initialize the value inc_counts at startup or homing. In this case you may use the absolute counts to initialize inc_counts.

inc_counts = inc_counts + new_counts - old_counts

This works well with 16 bit math even if the new_counts from the absolute encoder rolls over.
Now it is easy to check to ensure 0 <= inc_counts < 3600

What bothers me is that we are led to believe that 1 count = 0.1 degree exactly.

The resulting code is much less than drbitboy's
It is also easy to add a turn counter.
Notice that the mod() or div() function isn't required after initializing.
The inc_counts could simply be set to 0 after hitting some input if not moving too fast.

 

[drbitboy]

Oh Peter, spinning me up with an all too cursory and misguided analysis. Again .

The trick is to use the absolute encoder like an incremental.

Which is exactly what my second code example does:

int32_t diff = newraw - this->last;

The resulting code is much less than drbitboy's

Not when one revolution is configured to be 3600 encoder counts. Maybe if the PLC used a base-60 CPU architecture. Re-configuring it to be some power-of-two per revolution, of course, as @lfe already mentioned, would make the code much shorter i.e. a one-liner.

Oh, I'm sure it could be code-golfed to execute equivalent logic with fewer characters and lines, but every functional step in the m3600(...) routine is necessary.

In fact, masking the 32-bit, 3600PPR input to 16-bits, as @Peter Nachtwey suggests, would be a pointless, unnecessary extra step that brings no improvement to the algorithm. Masking higher bits also runs the risk of missing whole revolutions if the product of the angular rate and the sample period is too high.

This ain't my first rodeo.

 

[ndzied1]

What is not clear is the “why” of this exercise.

Is it a school exercise?
Is it to know where a flywheel is within its rotation?
Is it to track positions on a flighted conveyor?

Also, the OP asked for a function to determine the modulo 3600 value from the absolute PUU value. BUT, in most applications the only thing that matters is how much the PUU changed from the last plc scan.

From the graph shown earlier, PUU rolls over regularly. Then using Peters hints and maths you keep track of the modulo position something like this.

PUU_diff = PUU - PUU_last_scan;
pos_mod3600 = (pos_mod3600 + PUU_diff) % 3600;

PUU_last_scan = PUU;

The key idea here is that you never care what the actual value of PUU is. You only care about the difference since the last time you looked at it. So long as you do your calculations every scan you will have the modulo value you desire.

This assumes PUU rolls over as shown in the image posted earlier in this thread.

 

[Peter Nachtwey]

My method doesn't require a divide or mod instruction except for maybe at first.

inc_counts = new_counts - old_counts  // Treat as signed numbers. Then underflows don't matter.
old_counts = new_counts

if inc_counts >= 3600 then
     inc_counts = inc_counts - 3600
     tunes = turns + 1
else_if inc_counts < 0 then
     inc_counts = inc_counts + 3600
     turns = turns - 1
end_if

 

[drbitboy]

My method doesn't require ...

Oh please

1) It still needs a divide (or a multiply) to convert to degrees.

2) Also, you essentially took my second version and made it less robust, because more importantly it now fails if the encoder turns more than one revolution between two samples.

The right way to handle this is to configure the device to have the PPR be a power of two e.g. 4096, as @lfe stated over a dozen posts ago. Then the MOD becomes a bitwise AND, and as a side bonus the conversion to REAL degrees has no roundoff error, at least relative to the integer value input.

The devil is in the edge cases; handling edge cases is what makes code robust. I cut my teeth decades ago coding ground data pipelines to autonomously process spacecraft data that were far more complex than this. Not braggin', just sayin': you're outa your league here.

 

[martinplc]

Hi guys, based on drbitboy suggestions i have written the following code in ST language and i have tested it on physical devices. I am confirming that it works.

IF HommingEvent THEN
EncoderRAWprev:=0;
EncoderModulo :=0;
END_IF;

Diff := EncoderRAW - EncoderRAWprev;
EncoderRAWprev := EncoderRAW;


EncoderModulo := EncoderModulo + diff;
EncoderModulo := EncoderModulo MOD EncoderPUUperRotatiton;

IF EncoderModulo < 0 THEN
EncoderModulo := EncoderModulo + EncoderPUUperRotatiton;
END_IF;



By the way the simplified aplication is: The servo motor axis is coupled with a rotating wheel. The wheel is rotating indefinite number of rotations. At a given trigger, the wheel needs to position itself in a correct absolute position (example 20 degrees, 50 degrees but never more than 360 ).Once the trigger is lost the wheel continues to rotate indefinitely.

As the previous machine was the developed with siemens plc that has modulo 360 capability out od the box, the idea was to create a function that will give the simular output as the siemens plc in order to facilitate transition to the new equipment.