Encoder with measuring wheel usage to measure product length

[StaRkiJs]

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

Sorry, maybe I have not been clear from the start.
There is already working production line which extrudes plastic board.

The board length to be cut is set by a limit switch. When the board reaches the limit switch, a signal is sent to both - the saw and to my plc to register the board length.

The board is being cut by pneumatic 'flying saw' - so a little about the saw, basically when receiving signal 'to cut' (from the limit switch) it pneumatically 'attaches' to the board by clamping itself to the board, then it moves forward with the force of the board being extruded and cuts the board with the circular saw. after cutting it releases itself from the board and get pushed back to the start position by pneumatic cylinder.


So to reply to the actual question - there is no physical beginning and end of the product at the point where the measuring wheel is rotating. The actual board length is determined by measuring distance between the 'cut' signals from the limit switch.

 

[arpus4KM]

I think we still need to know if you are seeing the variance in your calculations as well as your product?

Is only the product coming out long, are your counts coming out short or long? do they match each other? is there a correlation between the two that can decisively say that the problem is with the programming and not just the physical limit switch having an issue activating at the right point each time?


Need to eliminate that the flying cutoff isn't miscutting or slipping on the product, and then need to know that the amount you measure is consistent with the amount cut off.


and what I gather is the encoder is purely for measurement, not to actually tell it when it activate, the cutoff activation is purely a physical limit switch?

I would be wondering if you are getting variation due to the nature of physical limit switches. any chance to swap this to a laser that is more repeatable?

 

[drbitboy]

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

That's not what I asked, but it's actually a more informative answer; I asked the wrong thing because I didn't read the OP closely enough .


So the boards that are measured independently are 4010m +/- 1mm, and the wheel measures them as 4030mm?

From what has been written about the coefficient (RL_coef, IIUC?), it appears that you (OP) believe that the actual wheel is slightly smaller than 200ms circumference, or more to the point, you believe that the wheel-encoder system gain is less than 0.1mm per count. How did you arrive at that belief? The reason I ask is that using the R-input to reset the counters that accumulate mm almost certainly throws away counts, which will result in a stochastic distribution of measured lengths for the same board.

As noted earlier, from the web page for the DBV50E-22EKA2000, the "Error limits" specificating for the wheel+encoder is "± 4 mm/m," but that is qualified as "subject to the measuring wheel (wheel + surface)." I don't think it is clear if that is a statement of accuracy or precision: if it is a statement of accuracy, then the process as-is (+30mm error over 4m ~ 7.5mm/m) operates at worse than that spec; if of precision, the the process as-is (1.8mm stddev over 4m ~ 0.5mm/m) operates at better than that spec.


[Update: scrap the rest of this post]



Caveat: how does the current measuring-only program know when to start counting and to stop counting? I.e. how does it "know" (detect)

1. when the start of the board is at some fixed position under the wheel,
2. AND then when the end of the board is at that same position under the wheel.

[Update: scrap this query, I did not understand what was going on: Also, if you run the same board through the measuring system 100 times, what does the distribution look like?]

 

[drbitboy]

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

Yah, I missed that too, but it was in the original post: currently the wheel+encoder is only measuring, but maybe someday, if the wheel+encoder+HSC+PLC system measurement accuracy and precision get good enough, then the wheel+encoder could be used for triggering the saw. The advantage would mean that, whenever the board length changes, that the operator could simply enter a new number into the HMI, instead of moving the limit switch (which is presumably what they do now).

So it sounds like the triggers for the counter are the limit switch events, which obviates my query about how the program "knows" when to start and stop measuring.

Sorry to ask because you probably are, but are you (OP) allowing for the kerf?

 

[StaRkiJs]

I think we still need to know if you are seeing the variance in your calculations as well as your product?

The variance in encoder measured size is +/- 5mm
The variance in actual board size (measured with tape, after the boards have been cut and stacked) is +/- 1mm. It is the mechanical limit of the machinery, there is some play in the limit switch, some in the saw.

Is only the product coming out long, are your counts coming out short or long? do they match each other? is there a correlation between the two that can decisively say that the problem is with the programming and not just the physical limit switch having an issue activating at the right point each time?

Need to eliminate that the flying cutoff isn't miscutting or slipping on the product, and then need to know that the amount you measure is consistent with the amount cut off.

I can't definitely say that there is or is not correlation.
As stated before the limit switch and the saw has some errors of course, but they are limited to +/- 1mm in the board sizes.

and what I gather is the encoder is purely for measurement, not to actually tell it when it activate, the cutoff activation is purely a physical limit switch?

I would be wondering if you are getting variation due to the nature of physical limit switches. any chance to swap this to a laser that is more repeatable?

Yes, the encoder is purely for measurement (at least at the given moment until and if at all I will solve the problem).
Swapping the limit switch to a more precise one would (maybe) help with the actual board size error being +/- 1mm but I don't see how it would help my cause?

 

[Peter Nachtwey]

I like the idea of using the encoder and wheel to activate the flying cut off saw. However, it is hard to control a pneumatic system with precision over time. Air compresses too much and the pneumatic cylinders get too dirty and sticky. I would replace the pneumatic cylinders. A flying cutoff saw must be able to track the material accurately and when the cut starts, there should be no force that is pushing or pulling the saw. The motion profile for the flying cut off saw must be exact.
How thick is the extrusion?

Also, ditto the comment above about not reseting the encoder counter.

How do you gear the flying cut off saw to the extrusion if the encoder is not used for gearing and generating feed forward?

 

[drbitboy]

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.

Agreed, but it is an important one: to be blunt, if you don't know this you will not be able to control the process.

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.

"The middle" is an fuzzy term; we already assume the system gain of the wheel is not exactly 10 counts/mm. Unless we have physically measured the circumference of the wheel, we don't know what "the middle" means, and even then there is still the effect of the wheel-surface interface. For example, there were a few posts earlier about spring pressure; since the boards are plastic, have we considered that with enough pressure the wheel could deform the plastic board, so the spring pressure can affect the linear measurement (cf. here)? Maybe the plastic does not deform enough to make that an issue, we don't know.

My gut feel is that most of the issues I am bringing up are second-order effects that can be either ignored or calibrated out.

That said, another source of measurement system noise is the scan time: 1-3ms; with the board moving at 800mm/s and ~10count/mm, that means about 80-240count/scan, suggesting the per-scan count measurement precision is +/- 40-120count (someon check my math). A preliminary review of the code posted by OP makes me thing the real culprit is the use of counter resets, which is essentially throwing away those 40-120counts/scan at each mm event. I am pretty sure that those counter values are DINTs and overflow is not a problem, so why not reset after each saw event+measurement and use the total count at the next saw event? Even better would be using the saw event as a trigger to a "Hardware interrupt OB," and that OB does an immediate read of the HSC to a common tag, which the Cyclic program handles its next scan.

 

[drbitboy]

How do you gear the flying cut off saw to the extrusion if the encoder is not used for gearing and generating feed forward?

I think OP wrote that the pneumatic device doesn't control the saw's longitudinal motion, but rather actually grabs the board, at which point the saw is fixed relative to the board, so there need for neither digital nor analog implementation of a flying shear.


Yeah, here it is:

... when receiving signal 'to cut' (from the limit switch) it pneumatically 'attaches' to the board by clamping itself to the board, then it moves forward with the force of the board being extruded and cuts the board with the circular saw. after cutting it releases itself from the board and get pushed back to the start position by pneumatic cylinder. ...

 

[drbitboy]

Can the process speed be turned down at all? It might be useful to see how the character (distribution) of the measurement(s) change(s) at half- or quarter speed.

 

[StaRkiJs]

So the boards that are measured independently are 4010m +/- 1mm, and the wheel measures them as 4030mm?

Correct, measures as 4030 +/- 5mm

From what has been written about the coefficient (RL_coef, IIUC?), it appears that you (OP) believe that the actual wheel is slightly smaller than 200ms circumference, or more to the point, you believe that the wheel-encoder system gain is less than 0.1mm per count. How did you arrive at that belief?

Honestly, the coefficient had been introduced because I tried another encoder + measuring wheel before.
But I have not removed it because it applies to this wheel also in my opinion.
This wheel uses NBR O-ring which as johnd_125 stated before is prone to wear, also I think it isn't that accurate to 200.00 mm to begin with - by my calculations deviation by 0.1 mm in the wheel's circumference would give 2mm error in total length of a 4000mm board.
So I've kept the coefficient in the program, although not using it at the moment for this purpose.

The reason I ask is that using the R-input to reset the counters that accumulate mm almost certainly throws away counts, which will result in a stochastic distribution of measured lengths for the same board.

Ok, so from this and what kalabdel said in his posts, I gather that I should scratch this program and do it somewhat simpler by calculating the length straight from the HSC, still keeping the MOVE and multiply blocks in between for the coefficient.

The advantage would mean that, whenever the board length changes, that the operator could simply enter a new number into the HMI, instead of moving the limit switch (which is presumably what they do now).

Yes, this is the end goal. I'm just starting small and already with huge problems.

Sorry to ask because you probably are, but are you (OP) allowing for the kerf?

Any question is alright. No, at the moment I am not considering the kerf, because it is just another static error introduced. Similar as the coefficient.
At the moment I'm not after the accurate measurement as in 4010mm board being measured as 4010mm board, - I am okay with it being measured as 4030mm, but what I'm after is the deviations in the measurements from one another.



I've not finished this reply yet and there are already more, I really do appreciate the help, thanks guys. sorry for me being slow

 

[StaRkiJs]

How thick is the extrusion?

24mm (about an inch)

How do you gear the flying cut off saw to the extrusion if the encoder is not used for gearing and generating feed forward?

drbitboy 's reply

Can the process speed be turned down at all? It might be useful to see how the character (distribution) of the measurement(s) change(s) at half- or quarter speed.

Theoretically it is possible, but honestly it would be hard to get approved (since it would cost money).

 

[drbitboy]

At the moment I'm not after the accurate measurement as in 4010mm board being measured as 4010mm board, - I am okay with it being measured as 4030mm, but what I'm after is the deviations in the measurements from one another.

Excellent, that is absolutely the right choice to make here; I finally realized that's where you've been all along.

 

[kalabdel]

The board length to be cut is set by a limit switch. When the board reaches the limit switch, a signal is sent to both - the saw and to my plc to register the board length

How are the signals from the limit switch/s connected to the PLC. You may use hardware interrupts on rising edge (or falling if there's a limit at the end, or if the same switch is used for star and end the you have two events, rising and falling edges) to capture the HSC current count or use HSC_CTRL_EXT which has a capture feature. That should improve precision.