HSC Encoder Zeroing with Sync input

qwazee

 

ibrahim454

Hello friends,
In a project HSC Encoder is controlling a rotating axis shows 0-360 Degrees.

I am using Z phase of the encoder to reset counting value of HSC Counter for every revolution. The problem is the reset point of the encoder is not same with the zero point of the axis.

I am trying to use an offset value to change zero position of my encoder; I mean I am set to axis base point and sub the instant value of the encoder and this point gives me zero, but that is not work for other points of encoder.

I need to do some mathematical operations, circular shifts, may be use Mod(360). But I couldn't handle for it easly. Is there any idea about it ?

Hello.

Have a look at the attached SCL code. You did not mention all the detail required, so tags were used that needs assignment. The end result is a displacement given as a REAL number.

Does this help you?

(preview)

 
Hello Again, I am working on this suggestion with FW 4.4 CPU ,

What about if there a gear rate between encoder and load,

there is a 6,5 Gear rate between encoder and load, How can I add this reate

ibrahim454

Hello Again, I am working on this suggestion with FW 4.4 CPU ,

What about if there a gear rate between encoder and load,

there is a 6,5 Gear rate between encoder and load, How can I add this reate

Hello Ibrahim. May this message find you well.

I suggest that you have a reference on the load side.
Keeping the reference on the Z-phase of the encoder will cause problems.

It may be an inconvenient suggestion.
Having one sensor trigger per (load) rotation will the simplest solution.

I am assuming you are using a rotary axis.
The situation is different if the load is moving linearly.
On a linear axis one reference is suggested on the load side.

Does this help you?
What are your thoughts?

I understand the following:

1-Rotating axis 0-360

2-Sensor at the zero point of axis

3-Position axis as degree angle from zero point.

If the positions are the same and do not change I would calculate/convert that only once at machine setup and use those figures my "GoToPosition". > iPosition1 and iPosition2 etc.

Setup the input device at zero degree to generate hardware interrupt and in the hardware interrupt capture HSC current count > iHSC_CurrentCount := %ID1000:p

iGoToPosition1 := iPosition1 + iHSC_CurrentCount;

iGoToPosition2 := iPosition2 + iHSC_CurrentCount

IF bDoNext AND NOT bDoNextEdge THEN

                     Encoder.NEW_RV := iPosition1 + iHSC_CurrentCount

ED_IF;

bDoNextEdge := bDoNext;

(that could be a array of positions to go from iPosition[i] to next element

When the reference count is reached an HSC hardware interrupt is generated where you setup your motion control/positioning and set a tag to prepare for next position.

Do not reset the counter just let it rollover.

For setting positions I recommend coding a block to use for commissioning where you can rotate the axis in manual mode (I assume you are able to job the machine to position) and capture the HSC current count and use that to calculate and save  your iPositions

ibrahim454

Thanks for reply,
Yes it is a Rotating axis controlling by angle -360/+360,
Unfortunately, there is no sensor on the load side,

The axis referenced by manually at first start up, then encoder is only hardware for positining.

The System was comissioned as that way before. I am trying to build same system exactly without changing any hardware but I couldn't figure it out. I decided to use just use A and B phase of encoder, but it could cause lost count.

Hello Ibrahim,

Your response contain vital information.

You do not need a reference / sync signal.
The user provides that functionality for us.

You do not need the Z-axis for the following concept.
You should not allow the HSC to be zeroed by any outside signal.
The count of the HSC is left as is.

1. A dual phase encoder is essential. I would strongly suggest the use of quadrature pulse, which means you will have x4 pulses that of your encoder specification. Encoder rated as 2000ppr will give have 8000 pulses counted by the PLC.
   
   
2. On startup you mark a bit that blocks movement until the user manually moved the rotary axis in position.
   
   
3. The user moves the system to a position. It is best if it is a fixed position. This could be two markings, one at a fixed position and one on the rotary part.
   
   
4. The user confirms that the manual correction is done. Continue to the next step if the position is fixed. Else the user should say which position is used as a reference.
   
   
5. The current encoder count is captured {#dintEncBias}, as well as the position {#realDegBias}. The position could be fixed or user defined. This is the reference point for all future positions. It is legal for as long as the PLC is powered or until the user reference the position again.
   
   
6. The code could look like:

// Assume system can physically only move [-360° .. 360°]
// Assume there is no slip between drive and load axis
// #totalPulse -> {pulse-per-rev specification of encoder} x {multiplier}
// {multiplier} is 4 when quadrature style HSC is used
#dintEncDiff := (#encoder - #dintEncBias);

#realDegDiff :=
DINT_TO_REAL(#dintEncDiff)
/ DINT_TO_REAL(#totalPulse)
/ realGearRatio
* 360.0;

#realDegValue := #realDegDiff + #realDegBias;

 

The Z-pulse can be worked back into the control as a check mechanism. It is a good engineering design to do so, but the position calculation is not dependant on it. Discussion on this point is beyond the scope if this discussion.


Does these notes carry value?

I played around with your sample program a bit and re-attched it with a few changes.

Counter is now setup for A/B four fold.

Unchecked the option for for Syn.

Added three hardware interrupts; for examples.

One interrupt is triggered when reference value is reached.

One interrupt is triggered on rising edge of digital input 0.6(or0.5 I already forgot) and another with digital input .07. One interrupt retrieves the current counter value that you can use as I described earlier. The other interrupt is another idea you can use to reset the counter instead of my previous idea of letting the counter to roll over; if you prefer to reset the counter you can use a digital input rising edge to trigger an interrupt that calls HSC to reset the counter which should be fast. Theoretically speaking calling HSC instruction is slower than a simple move instruction but I will guess not by more than a few microseconds.

Another thing I was thinking about and haven't tried yet is to connect the Z phase to a digital input (of course) and set it up with an interrupt as I described and use it exactly as an input device with either of the interrupts I described earlier to either capture the count value or reset the counter.

Kal.A

<snip>
1-Rotating axis 0-360

2-Sensor at the zero point of axis

3-Position axis as degree angle from zero point.

</snip>

Hello Kal.A,

I hope to encourage you to re-evaluate your assessment.
Look again at what Mr Ibrahim wrote to us.

(1) Rotating axis 0-360
Provision is made for the load side to move 720° ->  [-360 .. 360°] -- for me also it would have made sense to limit only 360°. It follows that the wrap around of the encoder's DINT number will not happen. But it is important for the user program to ensure the load axis does not pass its software limits. I do hope some mechanical limit is worked in somewhere!

(2) Sensor at the zero point of axis
An existing system is reversed engineered. There is no sensor on the load axis. The encoder is on the motor side and a gearbox between motor and load axis. The encoder will see 6.5 rotations for every load rotation.

(3) Position axis as degree angle from zero point
The user moves the system manually after powerup and tell the system what the degree position is. We do not know if it is a fixed position or some random position. We do not know if it is a zero position.

I am of the opinion that public debate can bring our stronger designs. Ultimately Mr Ibrahim should decide what works the best for him.

Kal.A, to continue conversation, what are your technical opinions on this case? Would it help if Mr Ibrahim supply us with a more comprehensive description of the system?

qwazee

 

Kal.A, to continue conversation, what are your technical opinions on this case? Would it help if Mr Ibrahim supply us with a more comprehensive description of the system?

 Thanks for clarifying. I re-read the thread and understand less now than I thought I did before

We'll see what he comes up with.

qwazee

 

Kal.A

<snip>
1-Rotating axis 0-360

2-Sensor at the zero point of axis

3-Position axis as degree angle from zero point.

</snip>

Hello Kal.A,

I hope to encourage you to re-evaluate your assessment.
Look again at what Mr Ibrahim wrote to us.

(1) Rotating axis 0-360
Provision is made for the load side to move 720° ->  [-360 .. 360°] -- for me also it would have made sense to limit only 360°. It follows that the wrap around of the encoder's DINT number will not happen. But it is important for the user program to ensure the load axis does not pass its software limits. I do hope some mechanical limit is worked in somewhere!

(2) Sensor at the zero point of axis
An existing system is reversed engineered. There is no sensor on the load axis. The encoder is on the motor side and a gearbox between motor and load axis. The encoder will see 6.5 rotations for every load rotation.

(3) Position axis as degree angle from zero point
The user moves the system manually after powerup and tell the system what the degree position is. We do not know if it is a fixed position or some random position. We do not know if it is a zero position.

I am of the opinion that public debate can bring our stronger designs. Ultimately Mr Ibrahim should decide what works the best for him.

Kal.A, to continue conversation, what are your technical opinions on this case? Would it help if Mr Ibrahim supply us with a more comprehensive description of the system?

 Thanks for clarification,

Yest, It is a kind of revers engineering. 

It would be better if I give more details;

-Encoder is a HTL encoder with 500 PPR, A, B and Z phase available

-There is a gear between Encoder and axis 6,5; Thus encoder rotates 6,5 times per axis rotation.

-There is no mechanical limit on the axis, Thus Axis can turn clockwise or counter clockwise forever.

-the only points is to know angle of the Axis for clockwise +360, -360 degree for counterclockwise. Doesn't need to know how many turns of the axis.

-Neither reference sensor, nor limit sensor is including for the Axis.

-At the comissioning, referencing of the axis will be done manuelly by user, then it remains on the memory, only renew the reference of the axis be done after maintaining.


If I just use A and B phase of the encoder;
For example I rotate axis clockwise 10 turns; My final angle must be exact zero;
Thus encoder counts in ID1000 will be ;
Gear

ID1000=10 X GearRation X TTL = 32,500 

then I take the mod and convert it to 0-360 Degrees;

Angle_Axis= [ID1000 Mod (GearRation X TTL) ] X 360 / (GearRationxTTL) 

Theorically equation gives me angle of the axis but is it work real?

and what happen if I turn 10 turns clockwise and Then Half Round around counter clockwise; 
my final destination must be  -180 Degree. 

Thanks for reply.

 Hello.

The best engineering solution is using an absolute encoder. What you are doing now has risk, especially if you do not have a sensor confirming a position.

Your description of the 10 turns do not yet make sense to me. Allow me to pause at the quoted points.

ibrahim454

 -There is no mechanical limit on the axis, Thus Axis can turn clockwise or counter clockwise forever.

-the only points is to know angle of the Axis for clockwise +360, -360 degree for counterclockwise. Doesn't need to know how many turns of the axis.

Not having a mechanical limit is not too much of a problem. My previous remark that contains the steps still stands. The formula needs some tweaking to ensure the range is maintained.

The problem is with the minus degrees.

Requesting a movement of -720° is okay. The minus indicate the direction. The position is the problem. Starting at 20° moving -720° should end up at 20°. If you make it -20°, all hell breaks loose.

What happens now if you move +360°? Do you end up at -20° or +20°?

This is a vital piece.