Length Measurement Without High Speed Encoder Module

Your choices for an encoder will be either a quadrature pulse code, a gray code, or a serial communication protocol.

An absolute encoder is simply an encoder that retains its positional reference point, even after cycling power.

There are other forms of position measurement that you might consider, such as Hall sensors, resolvers, RVDT, LVDT, etc. However, you need to consider what degree of resolution you actually require, the repeatability, the span of the measurement, physical mounting, reliability, and system cost.

Unfortunately, it is difficult or impossible to give you more information with the limited set of requirements you have supplied.

The primary consideration at this point is a solution that does not require the use of a high speed counter module to communicate position signals to the PLC.

Yes, but that requirement does nothing to tell us "what you are measuring, over what range, speed, accuracy, nor the physical constraints under which this sensor must operate.

It's like calling up your doctor on the phone, telling them "you don't feel good", and expecting a remedy based on just that given information.

Not quite, but appreciate the humor. In regard to your initial statement,

"Your choices for an encoder will be either a quadrature pulse code, a gray code, or a serial communication protocol."

Which of these does not require the use of a high speed encoder?

The application requires measuring the linear distance of paper that is indexed between cycles by way of a measuring wheel. The index speed is 1 ft/s. Accuracy is not critical as the paper is used as a mask to prevent clogging of a vaccum plate, and is indexed to prevent contamination between cycles. Range is not a consideration for this application, and there are no physical constraints.

In this case I am calling my doctor to tell him I have a sinus infection, and need some antibiotics. What does he recommend? At which point he calls me in a Z-Pack, everybody is happy, and we didn't make a monumental task out of a snotty nose.

It wasn't humor, but a metaphor.

The point is that there is not enough information to create a design that meets your needs.

Let's start with what you need as far as data input to your PLC, first. For example, is it a digital input or analog input? What is the protocol or voltage range?

I could go on and on with questions like these to further narrow down your requirements, then we stand at a place where we can start searching for a sensor solution, but we still need to consider other factors as far as what you are measuring. Again, what your are measuring is not clear to me other than paper of some unknown length with some non-specific degree of resolution.

Maybe we should back up and ask why the current system you have is not meeting your needs?

The index speed is 1 ft/s.... Accuracy is not critical.... Range is not a consideration... no physical constraints

Where these criteria are present, and the index speed is constant for all jobs, you only need a timer in the PLC software to activate your guillotine at a specified time interval. eg for 5ft lengths, set the timer to send an execute command every 5 seconds...

No antibiotics required...

Never mind.

Thanks. Have a great day.

So let me get this straight...

You do not wish to use a high speed counter to talk to a slow speed undefined PLC to measure to some unspecified accuracy. You are not even sure if an absolute or incremental encoder should be used with this undefined PLC.

I presume from the lack of detail of your question that you do not understand how to program the PLC to do this because you'd then already know the answer to your question.

Well my answer to is this.

What about just changing the encoder module instead to one that outputs less pulses per rotation, allowing for a lower counter speed at the cost of some positional accuracy reduction?

You may be able to do it with digital sensors that sense when a certain position has been reached and feed that back to the PLC. This may be very problematic (and dangerous) for precise positioning, overrunning and location detection however as unlike an encoder signal you won't know the exact position at all times.

Given the available information I don't think you can (or should) change.

Frankly this sounds like the OP is trying to say that they're smarter than the engineer who designed the system. Unfortunately the OP doesn't know the right words to prove their brilliance.

Assuming that you can handle slower pulses, then I suggest you search for a shaft in the system with a slower rotation speed in the indexing system and use the encoder on that shaft.

You describe this as essentially an indexing controller with only modest requirements for sensitivity and accuracy, then it may be possible to have a single magnetic sensor on a shaft, (one pulse per rev) and then stop after the required number of revs. I suspect that the PLC could handle the signal from a magnetic/HALL transistor sensor directly if you have spare channels.

What you will lose with this though is the possible precission and adjustment for different job runs.

The high speed encoder and a matching PLC would enable relatively finer control over the amount indexed each time, allowing absolute minimisation of the consumable paper mask.

The amount that you might save in getting the lower tech solution might be very quickly taken away in the lifetime cost impact of having to pay for all the mask material that will be used.

Can what you ask be done? YES absolutely!!

Should it be done? Depends on other multiple cost factors beyond the encoder and PLC that you are currently looking at.

I had submitted this and have pulled it back to edit.

Is it possible to have your mask pre-printed with an indexing mark? Or is it possible to have the mask marked visibly after each index? Or is the mask fed into a shear or chopper after exiting the equipment? An optical sensor could detect these indexing marks on each cycle (or the scrap reaching a light beam on the output) and use that signal to drive the PLC response. That is another "one pulse" signal method for the PLC.

Calculating feed distance from wheel - Encoder is good .

As Drive for motor is being controlled - timer function could be adapted through PLC for Drive control system if present application permits .

A PLC has a defined scan time that is based on the type of electronics and the size of the program. It reads it's inputs once every scan and then processes the information but it only knows if the input is high or low. If the frequency of your pulses is such that two pulses arrive at the input in one scan interval it will interpret this as a single pulse. Worse if your pulses are the same frequency as the scan time the input will only ever read high (coinciding with the pulse 'mark') or read low (coinciding with the pulse 'space'). The PLC will not know that the input has changed and changed back again in the intervening period so it will not register any movement of your paper web. Reading pulses with a PLC will not work reliably unless both the mark and the space are at least two scans in length i.e the scan frequency is 4x the input pulse frequency. This has implications for either the web speed or the accuracy to which you can measure. High speed counter inputs get over this problem by bypassing the scan time and processing the pulse inputs within the module. The information is then presented to the PLC CPU as a number that can be added to the running count in the programme. The cutting accuracy will still be compromised as the running total may be incremented by say four or five counts per scan. So if you set it to cut at 1187 counts the cut will be made at the minimum of 1187 but if the previous update was 1186 (not reached he target so awaits a further update) then the cut will actually be made at 1190 or 1191 counts.

Friends,

In addition to this good answer, many PLC's include the ability to do an interrupt of the program scan whenever an input changes state (details are chosen when it is set-up), so even if the scan time is slower than the frequency of the input signal one can keep up. Of course, if there are too many input events then the PLC is at risk of exceeding its watchdog timer and it all crashes. As advised by a number of people, this issue can be filled with pitfalls and problems, so any on-line advice we give can be totally worthless to you.

--John M.

Specifc controller for rotory encoder is available . Hence , controller's output can be used with PLC interface as well .

There are also some PLC platforms that incorporate a high speed quadrature decoder in their I/O hardware.

The more I look at this problem the more I come to the conclusion that this is a micro-manager searching for a cost cutting claim.

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=397844&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D397844

High speed digital controllers are available . Their output can be interfaced with PLC unit .

Perhaps a mechanical solution would be a better way to go. Envelopes were made with a high degree of accuracy and no electronics enveloped. The use of Geneva movements (a start, stop mechanical movement) http://www.youtube.com/watch?v=t7ZnHDdIvn0. And at sometimes thousands of envelopes per minute. Big or small they were handled with a mechanical movement.

You don't say the lengths you are wanting or the pause time you want so it would be hard to give you a definitive answer.

Another plausible approach.

The problem with all proposals though is that a qualified engineer (mechanical, electrical and/or software) must be hired or contracted for any of them to work. That will immediately destroy any cost saving budget.