You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old September 8th, 2006, 04:35 PM   #1
KTM Rider
Member
United States

KTM Rider is offline
 
Join Date: Sep 2006
Location: Oregon
Posts: 8
What is this ?

Can somebody tell me what kind of noise this is....or if it is noise?
Attached Files
File Type: doc Noise.doc (75.5 KB, 172 views)
  Reply With Quote
Old September 8th, 2006, 06:08 PM   #2
russrmartin
Member
United States

russrmartin is offline
 
Join Date: Aug 2002
Location: Eastman, Wisconsin
Posts: 745
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.
  Reply With Quote
Old September 8th, 2006, 06:30 PM   #3
Peter Nachtwey
Member
United States

Peter Nachtwey is offline
 
Peter Nachtwey's Avatar
 
Join Date: Apr 2002
Location: Vancouver, WA, US
Posts: 6,574
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 by Peter Nachtwey; September 8th, 2006 at 06:33 PM.
  Reply With Quote
Old September 8th, 2006, 08:02 PM   #4
KTM Rider
Member
United States

KTM Rider is offline
 
Join Date: Sep 2006
Location: Oregon
Posts: 8
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
  Reply With Quote
Old September 8th, 2006, 08:02 PM   #5
geniusintraining
Lifetime Supporting Member + Moderator
United States

geniusintraining is offline
 
geniusintraining's Avatar
 
Join Date: Jun 2005
Location: SC
Posts: 5,054
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)
__________________
www.PLCCable.com PLC Communication Cables, PLC Trainers, Fluke Meters, MicroLogix, ControlLogix, Siemens, Allen Bradley and more... all your automation needs... ((NEW)) After Market 1784-U2DHP Allen Bradley USB to DH+ and Gateways
  Reply With Quote
Old September 8th, 2006, 09:09 PM   #6
CroCop
Member
United States

CroCop is offline
 
Join Date: Aug 2005
Location: Utah
Posts: 1,050
Quote:
Originally Posted by geniusintraining
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.
  Reply With Quote
Old September 8th, 2006, 09:14 PM   #7
CroCop
Member
United States

CroCop is offline
 
Join Date: Aug 2005
Location: Utah
Posts: 1,050
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.
  Reply With Quote
Old September 8th, 2006, 09:19 PM   #8
KTM Rider
Member
United States

KTM Rider is offline
 
Join Date: Sep 2006
Location: Oregon
Posts: 8
How do you figure out what resolution you need to remove the quantizing?
  Reply With Quote
Old September 8th, 2006, 09:29 PM   #9
CroCop
Member
United States

CroCop is offline
 
Join Date: Aug 2005
Location: Utah
Posts: 1,050
http://www.plctalk.net/qanda/showthread.php?t=24111

http://www.plctalk.net/qanda/showthread.php?t=20970


Bottom line? Get the highest resolution feedback device you can.
  Reply With Quote
Old September 8th, 2006, 09:43 PM   #10
kamenges
Member
United States

kamenges is offline
 
kamenges's Avatar
 
Join Date: Nov 2002
Location: Brillion, WI
Posts: 3,608
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
  Reply With Quote
Old September 8th, 2006, 09:51 PM   #11
TWControls
Lifetime Supporting Member
United States

TWControls is offline
 
TWControls's Avatar
 
Join Date: Oct 2005
Location: Roanoke, VA
Posts: 2,081
Quote:
Originally Posted by Peter Nachtwey
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
  Reply With Quote
Old September 8th, 2006, 10:14 PM   #12
Peter Nachtwey
Member
United States

Peter Nachtwey is offline
 
Peter Nachtwey's Avatar
 
Join Date: Apr 2002
Location: Vancouver, WA, US
Posts: 6,574
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.
  Reply With Quote
Old September 8th, 2006, 10:34 PM   #13
TWControls
Lifetime Supporting Member
United States

TWControls is offline
 
TWControls's Avatar
 
Join Date: Oct 2005
Location: Roanoke, VA
Posts: 2,081
Quote:
Originally Posted by Peter Nachtwey
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
  Reply With Quote
Old September 8th, 2006, 11:01 PM   #14
Peter Nachtwey
Member
United States

Peter Nachtwey is offline
 
Peter Nachtwey's Avatar
 
Join Date: Apr 2002
Location: Vancouver, WA, US
Posts: 6,574
Quote:
Originally Posted by TWControls
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.
  Reply With Quote
Old September 9th, 2006, 09:03 AM   #15
TWControls
Lifetime Supporting Member
United States

TWControls is offline
 
TWControls's Avatar
 
Join Date: Oct 2005
Location: Roanoke, VA
Posts: 2,081
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
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 10:58 PM.


.