What is this ?

It depends.

Noise or not depends completely on what this is. Are you looking at an analog signal coming into the PLC? Or is this an analog output? Is it simply the result of some mathematical calculations which have analog input/inputs in the equation?

If this is an analog input value of some sort, I would suggest yes, it may be noise.

If it is an analog output, no, it is not directly noise, but could be the effects of noise upstream in the process.

If this is a value that is calculated in the PLC in various spots of the program, this could be the result of an asynchronous scan. Status of certain values is updated continuously, rather than once per scan. I have seen where poorly placed calculation blocks in ladder, which are both enabled and controlling at the same time, can vary the resultant address value that they both share.

So, in a nutshell, exactly what is it you have trended for us.
 
Simple

It is quantizing error. This is caused by low resolution feedback. Noise what not be the same amplitude. This is caused by some reading or change in readings changing by 1 count. This could easily be a velocity. Sometimes you get 10 counts per time period and some times you get 9 or 11. I bet it is a trend of speed calculations from an encoder. It could be position and the encoder is rocking back and forth but that is rocking pretty fast.

BTW, this is the kind of information I look for when I help people out. I like graphs. A picture is worth a 1000 words.
 
Last edited:
Peter is correct, it is an encoder input. Velocity tag.
So thats what its called...quantizing.
Would speeding up the encoder help correct this?
Thank you
 
Peter,

If its a encoder what can be done to solve this? and this would be caused by low resolution? not high?

starting to get more and more into motion (I love this stuff)
 
geniusintraining said:
Peter,

If its a encoder what can be done to solve this? and this would be caused by low resolution? not high?

starting to get more and more into motion (I love this stuff)

Not Peter, but the idea is the change in position with a low resolution feedback device leads to large errors in the velocity of the device.

Higher resolution fixes the quantizing error, by getting a more defined postion to feed into the velocity equation.

Peter has done a few posts on the Velocity/Accel resolution nessecary, and since Velocity/Accel is to Position/Velocity, same ideas apply.
 
Now there are 2 ways to get over this error.

A. Take longer timestamps between calculating velocity. Not good if you want to be taking fast, accurate measurements & doing something with it.

B. Get a higher resolution encoder. This is a much better solution for most systems.
 
Some of this answer depends on what the units of the trended value are. If the units are counts per unit time then more resolution is the ticket. If the value is a scaled value in engineering units per second, for example, more resolution may not help. If the converted value is an integer it can only change by one unit no matter how much base resolution the measuring device has.

So, what are the units and what is the data type?

Keith
 
Peter Nachtwey said:
BTW, this is the kind of information I look for when I help people out. I like graphs. A picture is worth a 1000 words.
Good, I have lots of graphs to post in a few months
 
Quantizing always exists in the digital world

If get an encoder with twice as many counts per revolution you will reduce the size of the spikes by a factor of two. Quantizing error is inversely proportional to the resolution or counts per revolution.

I finally got a chance to blow the picture up and really look at it.

What I can see is that the mechanics are very good. If you look closely you will see the speed is about 7.2 and if you ignore the quantizing spikes you can see the speed is very constant at 7.2. This plot is 1 second long. I can see that there are no small increases or decreases in the speed so there is no wobbling or cogging. I can usually determine the rpm and or teeth on on the gears by looking at a graph. I can't here because the mechanics are very good. Give the mechanical designers and builds an atta boy!

Now notice the size of the spikes. My best estimate is the spikes are about 0.9. 0.9 / 7.2 is 1/8. This means that each time period the controller is seeing about 8 counts and some times 7 and some times 9. What I can also tell is close if not exactly 8 counts per time period. This can be determined because the number of times there are 9 counts is about the same number of time there are 7 counts. Because there is just a little jitter in sampling, sometimes the while be just short of of 8 counts but the 7.99 counts still shows as 7. Other times 9 counts will just managed to be squeezed into a sample period. This happens when the is a count immediately after the sample period begins. If I knew the sample period I could tell more.

The quantizing error becomes worse as the system slows down. Some motion controllers count the time between counts when the system is slow. Count the time between pulses allows a motion controller to estimate a fractional number of counts which can reduce the slow speed quantizing by a significant amount. In other words, at high speed counts counts per period. At low speeds count the time between counts. The switch is made automatically so the user doesn't need know the details.

Ok, I am showing off. However, this skill is very handy when trying to determine what the problem is, electrical, quantizing or mechanical. I can see problems in minutes or seconds, as in this case, that others have been fighting for months. That is $$$$$. Hopefully this is obvious to everybody now. Don't lose this thread.

From the articles I have written and the other posts I have made on the topic of resolution you should be able to tell this is almost a religious issue with me. We use technology that you all have heard of before so we can reduce the quantizing error by a factor of 100 to 1000. This is necessary when you are trying to use this data for feedback on a PID. Think about this. If KTM Rider is using this for PID feed back the control output will change by 12.5% if the derivative gain is used. The derivative gain is multiplied by the error between the target and actual speed so if the speed has 12.5% spikes the control output will have 12.5% spikes.

KTM Rider should tell us exactly what he is doing.
 
Peter Nachtwey said:
Now notice the size of the spikes. My best estimate is the spikes are about 0.9. 0.9 / 7.2 is 1/8. This means that each time period the controller is seeing about 8 counts and some times 7 and some times 9. What I can also tell is close if not exactly 8 counts per time period. This can be determined because the number of times there are 9 counts is about the same number of time there are 7 counts. Because there is just a little jitter in sampling, sometimes the while be just short of of 8 counts but the 7.99 counts still shows as 7. Other times 9 counts will just managed to be squeezed into a sample period. This happens when the is a count immediately after the sample period begins. If I knew the sample period I could tell more.
Peter you alway talk about the need for high resolution but I have never seen the explaination broken down quite like this. Very good point.

Of course the question always is how do you figure out how high of resolution encoder you would need? Yes I know you would say the higher the better but we have a lot more failures out of these higher resolution encoders. There has to be a trade off but I don't know the formula for that one
 
TWControls said:
POf course the question always is how do you figure out how high of resolution encoder you would need?
If you are not using advanced techniques or gearing, then it depends on how much quantizing your system can tolerated on the output. To do this you must look at the PID controller. If there is no error the PID outputs no correcting signal. It there is one count of error due to quantizing then the output will change by:

Ki*T+Kp+Kd/T

or newest controller has a double derivative gain which is a gain multiplied by the error in acceleration. In this case the output changes by

Ki*T+Kp+Kd/T+Kd'/T^2

Where

Ki is the integrator gain, multiplied by the sum of position errors
Kp is the proportional gain, multiplied by the position error
Kd is the derivative gain, multiplied by the velocity error
Kdd' is the double derivative gain, multiplied by the acceleration error
T is the sample time in seconds

If 1 count of quantizing error changes the output by one 1 volt, that is too much. THERE IS NO POINT IN HAVE 16 BIT ANALOG OUTPUTS IF THE OUTPUTS ARE CHANGING BY 0.1 VOLTS.

The insanity I see over and over again is that people want 16 bit analog outputs and yet get low resolution feedback where a 6 bit analog output would do.
 
I will have to do some trending on one of our machines. We have only had it for about 6 months but have already had two encoder failures. We have ran into this before with the same resolution encoder on another machine. ON that one we lowered the resolution of the encoder and changed the gearing of the encoder accordingly. This solved the encoder failure problem without any adverse effects. On this one changing the gearing is not an option so as we lower the resolution of the encoder we will not be able to gain it back anywhere else. This is a crude motion controller so I don't think it will matter but need to dig into the machine a little deeper

Thanks
TW
 
Back
Top Bottom