Encoder with measuring wheel usage to measure product length

[StaRkiJs]

Hello everyone!
Firstly I'd like to say that I'm new to this forum and also new to PLC programming world altogether, that said I really would appreciate your thoughts and hopefully some recommendations as to how to solve the problem I'm struggling with.

What am I trying to achieve?
The goal is to measure the length of an extruded plastic board using encoder with a measuring wheel. Secondary (ofcourse only if the first goal is achieved) - cut the product to length using the data from the encoder.

What have I done?
I've mounted the encoder DBV50E-22EKA2000 to the production line. I've programmed s7-1200 PLC to count the pulses from the encoder and transform the result to length measurement (millimeters). When the board is cut (by existing machinery, using a limit switch to set the board's length) the length is registered and saved to a database.

The problem I've run into.
The measurements of a given product deviates about +/- 5mm. I've attached a graph to show this deviation. In the graph you can see that large amount of boards are within +/- 0.5mm error, but occasionally some are measured with larger error to one or other side of the actual length.

I would like to hear your opinions as to what could cause such results and I would be happy to answer any additional questions about the application I'm trying to solve.

 

[kalabdel]

There are examples for S7-1200 for measuring Length using HSC and it can be very precise.



How did you do it, in detail

 

[johnd_125]

Mechanical slippage of some kind could cause error but I would think that would result in longer boards, more than shorter boards. Perhaps more spring pressure would help.

Abrupt starts and stops of the conveyor might produce some slippage.

Is the action of the cutting causing some kind of movement of the board?

Doublecheck your programming so you are zeroing out properly prior to movement of the board, reading the end value correctly and so on.

Speed is the enemy of accuracy so can you slow down the conveyor or the accel and decel rates?

Also, I'd look hard at the encoder specs to make sure it is capable of the accuracy you are after. Error limits of "± 4 mm/m, subject to the measuring wheel (wheel + surface)" suggest to me you could be off ±16mm on a 4 meter long board....

The wheel is a "wear" item but again I think this would lead to a drift from nominal, in one direction.

 

[Steve Bailey]

How fast is the board traveling? What is your PLC's scan time?
The HSC can count pulses faster than would be possible within the constraints of the PLC scan, but taking action based on the HSC count is limited by scan time.

 

[StaRkiJs]

How did you do it, in detail

* I've configured DI0 and DI1 Input filters to 10 microsec.
* I've enabled High Speed Counter 1
Type of counting: Count;
Operating phase: A/B counter;
Initial dir: Count up;
Hardware inputs A - DI0, B - DI1.
* In Main I've CTRL_HSC block.
Basically the counting is done by HSC counter counting up to 1mm and then being reset, the millimeters are being added up by Counter to centimeters and the centimeters are being added up to meters by another counter.
Those counter values are being saved on each cut of the board.
So the actual board size is calculated by subtracting: 'total value now' - 'total value before'.
It is done this way to for being able to save the total ever produced amount.
I've attached an image with the code. (Sorry for the image being so big)

 

[StaRkiJs]

Mechanical slippage of some kind could cause error but I would think that would result in longer boards, more than shorter boards. Perhaps more spring pressure would help.

The encoder wheel is set with the max spring pressure allowed by the mechanical construction of this particular encoder. There shouldn't be any slippage, at least it feels that way.

Abrupt starts and stops of the conveyor might produce some slippage.

Is the action of the cutting causing some kind of movement of the board?

There actually is no conveyor, the encoder wheel rotates on the produced (by extrusion) plastic board itself. So there are no starts or stops, the extrusion process is stopped only for maintenance works.

Doublecheck your programming so you are zeroing out properly prior to movement of the board, reading the end value correctly and so on.

Speed is the enemy of accuracy so can you slow down the conveyor or the accel and decel rates?

The process is kind of slow - about 800 mm/min which would translate to 4 rpm for the encoder.

Also, I'd look hard at the encoder specs to make sure it is capable of the accuracy you are after. Error limits of "± 4 mm/m, subject to the measuring wheel (wheel + surface)" suggest to me you could be off ±16mm on a 4 meter long board....

Yes, here I would like to hear someone's experience using such measuring wheels. Not sure how I missed this line in the documentation prior to buying this particular encoder, but it was not cheap one. Also I have checked other brand encoders, none of them lists such error limits in their documentation, there is no mention at all.

The wheel is a "wear" item but again I think this would lead to a drift from nominal, in one direction.

I agree.

 

[drbitboy]

What was the target length of the plotted histogram data?

Are those lengths as measured by the encoder and wheel, or are they independent?

I will look at the code to see if it is implicit there, but what is the conversion from encoder counts to mm (count/mm or mm/count)?

There is an analogous problem in using TON-style timers to set the timing of events; see here. Resetting the counter (or timer) will "lose" any counts accumulated between the preset and the reset event. The solution is to reset the counter accumulation, never reset the entire counter itself. Note that, if lost counts is indeed the problem, then the error would have a bias, which is why I asked about the target lengths of the plotted data.

 

[StaRkiJs]

How fast is the board traveling? What is your PLC's scan time?
The HSC can count pulses faster than would be possible within the constraints of the PLC scan, but taking action based on the HSC count is limited by scan time.

The board traveling speed is about 800 mm/sec which would be 4 rpm for the encoder.
PLC reports Currebt cycle time as 1 ms; Longest cycle time 3 ms

 

[kalabdel]

So the actual board size is calculated by subtracting: 'total value now' - 'total value before'.

If you are performing contentious cutting, same size, just keeping loading reference values for next cuts. No subtraction, counter value now+counter value equivalent to desired length = where the cut is to be done. And so one, no resetting of counter, just keep rolling over. Are you using hardware interrupts?

Are the errors the same, different, cumulative?

 

[drbitboy]

What is the capability (i.e. variation) of the uncontrolled process i.e. if every part of the controlled process had zero variability?

E.g. if the process was manual not automated, and you had someone who could use a tape measure to stop and position the extrusion to make the cut, then how much variability would there be? E.g. if the extrusion comes out hot or has a high moisture content, then what variability would you see if the piece were cut exactly to the target length while hot or moist, and then allowed to cool or dry?

 

[kalabdel]

I see the image now and with all honesty I don't have time to go through the code but this sounds like a typical application.
Any, and I do mean any conversion is for operator entry and display *only* and is not to be used for actual cutting. Cutting need accurate HSC values and there should be a way for the operator to fine tune his distance entry that is counter/pulses based; maybe up-down arrows. Once that is done and the first cut is accurate, barring any mechanical issues it should be precise....of that is up to your definition.

 

[StaRkiJs]

What was the target length of the plotted histogram data?

If I got the question right, you mean the actual board size?
The boards were 4010mm +/- 1mm

If I set the coefficient to accommodate for the actual measuring wheel circumference I get similar results to those plotted with the deviation being about +/- 5mm. At the moment I have set the coefficient to 1 so there is no reminders in the calculation process.. I have done this to remove one more possible fault in program which could cause this error.

Are those lengths as measured by the encoder and wheel, or are they independent?

The results plotted are the ones measured by the encoder.

I will look at the code to see if it is implicit there, but what is the conversion from encoder counts to mm (count/mm or mm/count)?

The encoder has 2000 pulses per revolution with 200mm wheel circumference. which translates to 10 pulses per mm.
So in the program the encoder counts are multiplied by 0.1 to get the mm.

 

[StaRkiJs]

If you are performing contentious cutting, same size, just keeping loading reference values for next cuts. No subtraction, counter value now+counter value equivalent to desired length = where the cut is to be done. And so one, no resetting of counter, just keep rolling over. Are you using hardware interrupts?

Are the errors the same, different, cumulative?

There is no cutting being done from my side/program/plc yet. At the moment it is meant for monitoring purposes.

Have not used any hardware interrupts.

The errors are different.

 

[StaRkiJs]

What is the capability (i.e. variation) of the uncontrolled process i.e. if every part of the controlled process had zero variability?

This is a hard one. There definitely is some shrinkage in the process of the board cooling. I've thought about this but in my opinion this could not be the reason for the measurement deviation to both + and - with the most measurements being in the middle.

 

[kalabdel]

There is no cutting being done from my side/program/plc yet. At the moment it is meant for monitoring purposes.

Have not used any hardware interrupts.

The errors are different.

OK, I am certainly not paying attention. What senses the beginning and the end of the product that you are measuring.