What is this ?

Thanks all,

I know this is not my thread but this is good stuff…

Most likely was this encoder designed to run at a faster speed? hence the originator of the equipment had a lower resolution? or there was not a reason to care about the feed back precision it was not being display?

If …say you have this issue, could you scale the input to ‘lesson the impact’?, if you scale to IPM verses FPM would this help and make the "quantizing error" not as noticeable?
 
geniusintraining said:
Most likely was this encoder designed to run at a faster speed?
Click to expand...
You missed the point. At slow speeds you get fewer counts per period so one count of quantizing error is a larger percentage of the total counts in that period.

hence the originator of the equipment had a lower resolution? or there was not a reason to care about the feed back precision it was not being display?
Click to expand...
???? What about motion controllers? Often the actual speeds are not displayed but you always care about the feedback.

If …say you have this issue, could you scale the input to ‘lesson the impact’?, if you scale to IPM verses FPM would this help and make the "quantizing error" not as noticeable?
Click to expand...
The numbers would be smaller but the percentage of change per count would not. Scaling doesn't help.
 
Well Peter the "Servo Controller" I was going to do the logging on with the encoder problem isn't what it states it is. It two solenoid setup. One for high speed and one for low speed to get it into position. Pretty much a High Speed Counter with 4 outputs. According to my numbers dropping the resolution won't be a problem on this one. Of course these are a lot easier to figure out than a real Servo Controller
 
Still trying to absorb this,

The error was caused by a cheep encoder…someone spec the machine and tried to save a buck and got a encoder with to few counts per/rev,?

But if this encoder will not work for higher speed and we know that it won’t work for slower speeds then why would someone even build the encoder in the first place?

I have read a lot of Peter’s post, but I have not got a general rule of thumb (if there is one) can you ever have too many counts? If I am traveling (motion) say…7 meters, would I, could I spec the same encoder if I was moving 1 meter

"…In gearing applications, the master axis feedback should have as high a resolution and accuracy as possible so the slave axis (or axes) can follow a smooth motion profile.."

This was taken from Peter’s article http://www.hydraulicspneumatics.com/200/Issue/Article/False/21744/Issue

What would be "accuracy as possible"? is this solely dependent on the controller? And has little to due with the application itself?



And by the way thanks for the article Peter, they are helping…believe it or not
 
Peter Nachtwey said:
You missed the point. At slow speeds you get fewer counts per period so one count of quantizing error is a larger percentage of the total counts in that period.
Click to expand...

Ok now I am confused. Let me explain the aplication I have and what I did.
Machine has 3 motors Main, Vacuum Belt, Seperator.
Vacuum Belt and Seperator are servos that are set up as followers.
Main Drive is a DC motor with an encoder attached to the chain it drives.The servos share the encoder for feedback.
When the machine would sit you could see the followers. Also the speeds were erratic when you ramped up. (Vacuum Belt and Seperator)start to move.It would be very small movements and would not happen every time.

To correct this problem I went to a LOWER count encoder. Why did this fix the drifting at the stopped postion and during ramp up?

Am I missunderstanding what you are saying? I associate resolution with counts. The higher the count the more the resolution.
 
Some of it is dependent on the controller you are using

If you are using a Micrologix then you can only handle 20kHz. This makes the speed you are running affect the resolution of encoder you can use

Now if you are using a product such as Peters RMC100 you can go the 120Mhz.

So I think the first question is what where you using
 
Ok got a little more time now, had to go the breakfast with the wife

Let's take one of our low level machines for an example. I call it low level but it actually does an extremely good job. I just say that because it is a Micrologix 1200 compared to a fully blown motion controller such as Peter offers

Initially it had a 2048 encoder, a 4" measuring wheel and ran at 6ft/s

With these numbers our maximum rpm of the measuring wheel is 9.77rpm (20kHz/2048)

This equates to a maximum speed of 122.7 in/s(9.77*4*PI) or 10ft/s

Now when we dropped the gearbox ratio in half to double the speed of the system to 12ft/s we ran into accuracy problems.

Interestingly enough the it was not that inaccurate. It had a method of calibrating for error and once calibrate it would run close to tolerance. After some hunting I realized that the calibrate multiplier was extremely low. If it was suppose to go 50,000 counts to get to position it only had to go 40,000 counts

That is when I realized I had not thought about the 20kHz limitation of the Micrologix 1200. At 12ft/s with a 4" wheel and a 2048 encoder I was pushing the encoder over the max
12*12/(4*PI)*2048 = 23468hz

The quick solution was to drop the encoder resolution to 1024 which doubles the maximum speed the encoder can run but also cuts it accuracy in half. With the 1024 encoder the accuracy was cut from .006" to .012"

Now tolerance wasn't a problem on this machine, as long as it runs within a 1/16" it is great but this made the drive oscillate and unable to get into position. Now on a system like this it really wouldn't be called quantizing error, it is more of jumping out of the tolerance band. The solution for this was to open the tolerance band up since one count of the encoder would cause it to jump out of tolerance. I don't know Peter, what would you call this besides a reason not to use a inexpensive PLC to do a motion controller job :)?

This could be what Clay was seeing
 
Resolution Is Good, The More The Better!

TWControls, I wouldn't mess with you 4 speed 'servo controller' it will not make any difference.

Clay B., I would have to know more about your application but I can see where a low resolution encoder would appear to improve performance. If the motion controller can't see the error then it will not try to correct. It is sort of an ignorance is bliss for motion controllers. However, it is still ignorance. You couldn't be holding position as accurately and you may not be using the derivative gain. I think you are just covering up the real problem. There are a lot of things that must be done right to take advantage of higher resolution. Here is a little story about that.

[Position and Time]
In the mid '90s Temposonic introduced an SSI MDT rod with 10 micron resolution. My first impression was WOW, about 2.2 times better resolution! However, I quickly found out that the data sampling was not done synchronously to the motion controller. What does this mean?

Our traditional MDT in the mid 90s ( before RMCs ) only had a 27.5 MHZ counter and would sample or average 4 times to get a resolution of .001 inches. We used the start/stop method which is kind of like a sonar or radar. With 1 sample we had a resolution of .004 inches but we knew when this position was valid because we started the interrogation from the motion controller.

The SSI rods would sample the position asynchronously so we had no idea when the data was valid. SO WHAT IS MORE ACCURATE, the .004 inch resolution start/stop or the 10 micron SSI? The .004" start stop method was. Here is why. I always knew when the sample was taken when I used the start stop method. The SSI 10 micron position was a fraud. If I am moving 10 inches per second then I am moving .010 inches each millisecond. Since I didn't know when the SSI position is valid then the position could have been taken any time while moving .010. This mean the real accuracy was .010 inches while moving 10 inches per second and .050 inches when moving 50 inches per second. It took a while to beat this into the brains of the Temposonic folks. The point? A position alone is meaningless if there isn't a time or time interval associated with it.
[/Position and Time]


[off topic]
Peter Ponders. Time, nothing seems to exist without it.
[/off topic]

Back to resolution.

The first goal of a digital PID is to try to emulate an analog PID. That means the goal is to have infinite input and and output resolution and infinite update rate.

You want to use the highest resolution encoder you can. That way each count that passes represents a smaller distance that passes. This provides finer velocity measurements.

You want more resolution. As much as is practical. One can find encoders with 5000 lines per revolution pretty easily. A good motion controller will see each edge so the motion controller should see 20000 counts per revolution. At 1 revolution per second the motion controller would see 20000 counts per second or 20 counts per millisecond. If the motion controller updates every millisecond it will see the counts change by 20 each millisecond if the encoder is turning one revolution per second. Since the quantizing error is 1 count, the motion controller will see counts bits most of the time and sometimes 19 counts. This means the quantizing spikes as in KTM_Riders trend will be 5% of the average speed of 20 counts/second. If we used a 10000 line encoder we would get 40 counts per millisecond so the speed error would be 2.5% so getting more counts pre revolution or per inch is good.

As far as what is practical goes. My feed back from venders is that it is very easy to get 5000 lines per revolution encoder and that 10000 line encoders are much more expensive because the wheels must be made bigger to fit all those lines in. One can always gear the encoder so it spins faster than the motor shaft. This will effectively raise the resolution but one must be careful that the gearing is tight. Use timing belts.

Genius, at higher speed the resolution becomes less critical because the motion controller will see more counts per millisecond and therefore the error cause by 1 count to due quantizing will not be too bad.

Applications like extruders require VERY high resolution feedback. The material is often extruded very slowly some times a slow 1 inch per second. If the feedback only has a resolution of 0.001 inch per count then the motion controller will see on average 1 count per millisecond. Sometimes the motion control will see 2 counts and other times 0. In this example the quantizing error is 100% of the average. This makes it very difficult to use the derivative gain and worse yet to gear to.

Now think about this. What if the extruder is only moving 0.1 inches per second. The motion controller would not see any change for about 10 milliseconds and then the encoder would change by 1 count. During this time the motion controller is increment the target position but it doesn't see the position change and it winds up the integrator during those updates where a change in position isn't see.

Another thing to think about. What if you want to decrease the extruder controller update rate to 250 microseconds? Now if the extruder is moving only 0.1 inches per second then the motion controller would see the position change only every 10 millisecond as before but this would be 40 controller scans. The controller would go nuts because it wouldn't see the extruder move for 39 scans

What is really a joke is the adds you see for motion controllers that advertise 64 micro second updates. This is only handy if you are controlling very small motors at high speeds and have extremely high resolution.

TWControls, actually our encoder counters only go up to about 8-10 Mhz. We have never had anybody exceed this. The 120 MHz is for the Temposonic and Balluff rod feedback.

Your comments about exceeding the 20 KHz counter of a MicroLogix are valid. If you buy encoders that provide 20K counts per revolution then it will be easy to exceed 20 KHz. This means that those that don't use motion controller and try to do the control in the PLC are doomed from the start or have very simple motion requirements. I shake my head an wonder why when I see posts from people having problems getting their PLC motion programs to go. They may save $1000 in up front costs and then waste thousands get their system to go and it never will work as well so this will cost production for the rest of the life of the machine.

Wow, I did a Terry ( post too long to read without falling asleep ). What the heck it is Sunday morning, I have had my coffee and now the sun is shining. It looks like a wonderful day.
 
Peter Nachtwey said:
TWControls, actually our encoder counters only go up to about 8-10 Mhz. We have never had anybody exceed this. The 120 MHz is for the Temposonic and Balluff rod feedback.
Click to expand...
You are correct, I had been researching your product and flipped back and gave the wrong spec. Thanks for correcting me
I shake my head an wonder why when I see posts from people having problems getting their PLC motion programs to go. They may save $1000 in up front costs and then waste thousands get their system to go and it never will work as well so this will cost production for the rest of the life of the machine.
Click to expand...
It all depends on what you are doing with it. On the machine in the post above the HSC was fine because the cycle time was so slow. The HSC takes much longer to get into position but this machine only cycles every 30 seconds so it didn't really affect the output on the machine

Now I have a good example of the difference between an HSC and a motion controller on one of our systems that cuts shorter parts. The first on has a HSC setup similar to the one posted above and was capable of cycle times of 3.6 seconds. The next on I put a Controllogix setup on with a M02AE. Although the physical speed of the drive system on this one was slower we were able to get cycle times of around 1.3 seconds. Significantly lower.

But we weren't satisfied there so we took it a step further. Another another advantage of the motion controller is its ability to anticipate getting into position. This machine stops at position, then stamps and shears at the same time. The time between the solenoid valves being signaled to shift, actually shifting, beginning to move and slightly touching the part was .4 seconds. Now on our HSC setups this is lost time because those setups can't reliably anticipate when the part will be in position. But with the motion controller we actually fire the solenoid when the part is .4 seconds away from being in position. 1.3 seconds was good but .9 was even better

So pretty much the difference is
HSC 3.6s
Motion Controller 1.3s
Motion Controllers Reliability .9s
Wow, I did a Terry ( post too long to read without falling asleep ). What the heck it is Sunday morning, I have had my coffee and now the sun is shining. It looks like a wonderful day.
Click to expand...
I didn't fall asleep. Your post much more interesting than Terrys :)
 
I see the light or the encoder does

Now I see what you are talking about. Nice explanation Peter. I liked the fact you used temposonic rods. I have Husky injection mold machines in the plant and all have several Temposonic rods. When I first started we had a machine still using a rotary encoder for clamp position. Thats when the light went off so to speak.

Not sure what you guys know about mold machines so I will explain this feature in detail.

The feature is called "Mold Protection". Basically the way it works is you get to a certain position on Mold Close and you drop the pressure on your stroke cylinder by a certain amount (usually a percentage of total pressure) you then start a timer to see if you make Mold Close position. If you do not make Mold Close postion you set an alarm.

Now that I have that explained. Here is what would happen when you had the error you were talking about.

As you dropped the pressure you also dropped speed and from time to time you would Clamp Up when you should not have.

Basically I setup another PLC that read the encoder data the machine used. I noted that when the machine would close up on a part when it was not supposed to that the encoder count was off.
I changed the encoder under the theroy that it was just bad and getting false signals. From what I understand from you is that it could have just been an error just from resolution. The encoder was 1000 lines.

As an end user it makes me wonder how many times this is over looked.

And as Genuis said thyis has been a very good thread and I have learned some things. Looks like tomorrow I am going to take a closer look at that machine I mentioned earlier.
 
Are the encoders mounted on your extruder motor mainly to regulate RPM? I am only familiar with extruders for the tire industry. On those RPM is critical but I am unfamiliar with mold machines
 
Not an extruder. We move this really big hunk of steal really fast then stop it just before it smashes into another really big hunk of steal. Then we squirt some plastic in and make a part that can land in a landfll in the very near future.

We have IMM (injection mold machines) from 300 ton to 850 tons.

Its like an extruder but has a clamp on the end. You have all the fun controls of an extruder plus controls slinging several toms of steal around. And what got me on this sight to begin with. Alot of our machines use S5 PLC's writen in STL.
 
Back
Top Bottom