Bump

 

are looking at a shafted resolver or a frameless(on a shaft)

There are magnetic rotary encoders that are not as subject to humidity/moisture as optical encoders.

 

I've been using incremental rotary encoders that have a shaft that I put an encoder wheel on, usually 12 inch circumference. The TRD series from Automation Direct. I'm just wondering about the PPR. is 2500 - 5000 PPR too high?

 

We use the TRD's along with a 1' wheel on several rolled material applications, its been a while since I programmed the last set of machines we built but I think we've been using 2000 pprs.

 

I posted a question about a material measurement problem I had some time back. Got some really knowledgeable responses and in the end solved our issue of material wrapped around a roller with the encoder riding on that very spot. Different material thickness gave different lengths.
I made changes and it's good to go.

But there are still accuracy improvements needed on our other lines that need to be pretty accurate. One of them came from one or more members of this forum and will be implemented. The change will be to have the encoder ride on idler rollers as suggested in the comments.

So, here is my current question.

Background
The setup I'm using on the machine that measures length and needs to be as accurate as possible uses a 2500 PPR optical encoder. With the "gear ratio" it comes out to around 4400 PPR per foot on the existing line. The encoder / counter setup has one counter that counts up to the pre set, 4400, or in the new machine 2500, no "gear ratio" and then gives an output via built in micro relay to the printer to print the foot count, resets and starts over. The counter is currently set as an up only counter so if the material goes in reverse, or has vibration the count still adds. It also runs a second counter to display the actual foot count for reference.
*** The new counters will be up/down counters to counter any slight reverse or vibrations.

My question is would I be better off with a lower PPR encoder, or am I ok with the 4400 PPR ( 2500 PPR on the new line I'm building)? Which would be more accurate, the 2500 PPR, or is 600 PPR ok. I need the best I can get.

I'm asking this because I've purchased encoder / counter combos, chinese, that use 600 PPR encoders. They're used on material cutting lines that don't need to be extremely accurate so I've only done basic calibration on them.
The lines I'm currently building and upgrading need to be as accurate as possible. They'll be measuring and printing foot counts, 0001, 0002, 0003, on material from a couple hundred feet to as much as 2K-5k foot runs so a small error is amplified on a 3k run. Our CEO / Manager who is a pretty smart guy, not your average CEO, insists that our competition's length counting is more accurate than ours. The main issue, possible slippage, with our existing counting will be fixed using idler rollers to eliminate that issue.

Thanks, in advance.

I am a bit unclear on how you are dealing with bounce or reverse but NO, PPR is not an issue. As you are already aware higher resolution can equate to higher accuracy (as long as the rest of the servo/measuring system can keep up).

Are you having a measuring or readout issue with the current setup?

 

I am a bit unclear on how you are dealing with bounce or reverse but NO, PPR is not an issue. As you are already aware higher resolution can equate to higher accuracy (as long as the rest of the servo/measuring system can keep up).

Are you having a measuring or readout issue with the current setup?

Thanks,
We're having measurement accuracy issues. Inconsistent foot counts that are caused by a couple of issues that I know of. When I first set this one line up it wasn't great but way better than what they had and i was pressed to get it up and running asap. And in the beginning thay weren't running the large material on it. Now that we are growing and facing stiffer competition the errors are an issue.\

This is a list of the 2 changes I am making.

Slippage issue. the encoder runs on a conveyor shaft, this conveyor is the drive that pulls the material so slippage can be and is an issue depending on the size of the material.
We're adding in a set of idler rollers that will have the encoder on them thanks to someone on this forum .

Reverse counting and vibration. the current counter doesn't reverse, so along with the obvious, vibration can also add to the count. All counters will be set as up/down.

So the original line is getting a set of idler rollers and a new counter box with up/down and the new line will have idler rollers for the encoder too.

As for bounce, are you talking about contact bounce? The relay output to the printer has a programmed 20ms closure. Contact bounce hasn't been a problem but i still might go with the open collector output if the printer can handle it. Just need to check with them. I'm using Automation Direct CTT series counters, > CTT-AN-A120

For now the plan is to use a 1 foot circumference wheel on a 2500 PPR encoder with A / B outputs to the counter using idler rollers. The line wont go over 40 FPM so I should be good to go. In the near future I want to have the encoder directly on the idler roller shaft.

 

We use the TRD's along with a 1' wheel on several rolled material applications, its been a while since I programmed the last set of machines we built but I think we've been using 2000 pprs.

The mentioned counter is receiving the encoder signal(s)? Can't say I have ever seen it done that way, but in theory, at 10,000 cycles/second, it seems like it should keep up with the count as long as you don't try to move too fast. To test this, I would slow the line down really slow and see if the error follows the speed. If the error gets better at lower speeds, I suspect the counter is not keeping up with the encoder pulses.
But how do you handle errors? A robust motion controller can compensate for a certain amount of signal error, which is fairly common.

It probably isn't the best way but it's what came to mind when I needed a pulse for the printer every foot LOL
Yes, the A/b encoder signals go directly to the input 1 & 2 on the counter.
I did the math on the cycles/second and came out with 3333.33 hz @ 40FPM. I'm obviously no professional and could easily be wrong on this. My figures are.

5000 (5k) is the frequency of the encoder signal. I use 5000 because using both A/B inputs doubles the frequency of the 2500 encoder.
the max line speed will be 40 FPM so 40 RPM with a 12" wheel
5000 Xs 40 = 200,000 cycles per minute
to get the hz
200,000 / 60 = 3333.33 hz, or 3.33k the counter is set at 5K input frequency. the counter is supposed to be able to handle 10k

just to give you an idea of how the original setup worked. When I set it up we did quite a few test runs @ 100 feet. We used flat material and the first test runs were non stop start to finish. after calibration the accuracy and repeatability was very good. then I ran some runs with start / stops to simulate what they would be doing as users. < this is a QC line for the material. The results of the start/stop runs were good too.
i ran calibration tests often and still good.
so this line ran for years with little issues because the material was nice, small, and flat. the machine operator also followed the procedures. at one point they decided to use it for much larger material and of course without asking me if it would be good to go with it, not to mention they had a different operator at this point . This material is big, stiff, very heavy, and wrinkled. so slippage became an issue right away. I gave them some procedures to cut the slippage and if followed it did ok. then I find out that a want to be technician decided to speed up the line to full speed which causes more vibration and slippage. so to make it compatible with the larger material and more accurate I'm modifying the original line by adding idler rollers and an improved counter setup. They're going to B$%^ but the speed will be programmed in the VFD.

to give you an idea of the operators I deal with, I've told them a thousand times. you have to reset the counter when you start a run. ya, ya ya, ok . and they never do, i guess because they know better. so the first foot is whats left over from the count of the last run and the run can be off as much as one foot right away. rant over

 

It probably isn't the best way but it's what came to mind when I needed a pulse for the printer every foot LOL
Yes, the A/b encoder signals go directly to the input 1 & 2 on the counter.
I did the math on the cycles/second and came out with 3333.33 hz @ 40FPM. I'm obviously no professional and could easily be wrong on this. My figures are.

5000 (5k) is the frequency of the encoder signal. I use 5000 because using both A/B inputs doubles the frequency of the 2500 encoder.
the max line speed will be 40 FPM so 40 RPM with a 12" wheel
5000 Xs 40 = 200,000 cycles per minute
to get the hz
200,000 / 60 = 3333.33 hz, or 3.33k the counter is set at 5K input frequency. the counter is supposed to be able to handle 10k

just to give you an idea of how the original setup worked. When I set it up we did quite a few test runs @ 100 feet. We used flat material and the first test runs were non stop start to finish. after calibration the accuracy and repeatability was very good. then I ran some runs with start / stops to simulate what they would be doing as users. < this is a QC line for the material. The results of the start/stop runs were good too.
i ran calibration tests often and still good.
so this line ran for years with little issues because the material was nice, small, and flat. the machine operator also followed the procedures. at one point they decided to use it for much larger material and of course without asking me if it would be good to go with it, not to mention they had a different operator at this point . This material is big, stiff, very heavy, and wrinkled. so slippage became an issue right away. I gave them some procedures to cut the slippage and if followed it did ok. then I find out that a want to be technician decided to speed up the line to full speed which causes more vibration and slippage. so to make it compatible with the larger material and more accurate I'm modifying the original line by adding idler rollers and an improved counter setup. They're going to B$%^ but the speed will be programmed in the VFD.

to give you an idea of the operators I deal with, I've told them a thousand times. you have to reset the counter when you start a run. ya, ya ya, ok . and they never do, i guess because they know better. so the first foot is whats left over from the count of the last run and the run can be off as much as one foot right away. rant over

Is the material Pulled Through the line? Is it placed on a roll or is it cut into sheets?
If I understand correctly, you are slicing one foot of material (movement) into 4,400 pulses, so if you are capturing all the pulses and NO slippage, that is damn precise at approx. .002727"...
I would separate the issue in the constituent parts, usually mechanical and control/electrical. Shooting from the hip, I would compare moves for repeatability AND see if any error is consistently in the same direction. This could provide clues to a mechanical slippage issue.
Of course, there is the usual needed verification of cabling and routing that is Very important. Do you have an oscilloscope to check waveform?

Again, I have never done or seen motion control done that way. If it works, good on ya. I just can't picture how you handle errors, ramp up, ramp down.
If you need really, really precise, usually two encoders are used, and a comparator is setup. There needs to be some way to compare the requested move with the actual move.

EDIT Does the counter always measure the rising or falling edge of the pulse? If Not, this will accumulate as error since the material is moving during the time slice between rising/falling.

 

to give you an idea of the operators I deal with, I've told them a thousand times. you have to reset the counter when you start a run. ya, ya ya, ok . and they never do, i guess because they know better. so the first foot is whats left over from the count of the last run and the run can be off as much as one foot right away. rant over

Operators can be a blessing or a curse, but usually they are both.

 

It sounds like there could be variations in the starting point registration.