I agree that you can’t get away from it. But you can minimize it and I wanted to provide what I thought is an interesting data point; the extent to which some engineers go to minimize it.
I doubt that they actually lines at those speeds. They use absolute encoders and likely just read the position on every control loop. Seriously you can't get away from it. With 40 million lines if the shaft turns at 60 RPM or one revolution per second it is moving slow but the total number of edges is 16 million per second and you could find hardware fast enough but at 3,000 RPM it would be a lot harder. The entire reason I brought up the subject is because people started posting about shielding and star grounds. That is not the kind of noise we are talking about. Quantization happens even in an electrically quiet environment and results from design decisions made such as the sample interval, number of lines of the sensor, and the rotation speed. It gets worse as you go slower. On Mon, Jun 21, 2021 at 1:15 PM Thaddeus Waldner <thadw...@gmail.com> wrote: > > Okuma machine builders really don’t like quantization noise so they use 40 > million CPR encoders on the axis motors. > > > On Jun 21, 2021, at 11:34 AM, Chris Albertson <albertson.ch...@gmail.com> > wrote: > > > > Quantization noise is fundamental and present in all digital systems. > > There is absolutely no way to avoid it. All you can do is minimize it. > > > > To know how fast a shaft is spinning or how far it moves, you have to > count > > edges and if you get 100 counts you just can not know if you are closer > to > > 100 or to 101 counts. Basically the counter always rounds down even if > at > > 100.99999 it tells you "100". So the cound is "wrong" 50% of the time. > > This applies not only to encoders, but A/D converts and every other kind > of > > measurement. > > > > This is the nature of digital data, of representing the world with a > fixed > > number of bits. > > > >> On Sat, Jun 19, 2021 at 4:00 PM John Dammeyer <jo...@autoartisans.com> > >> wrote: > >> > >> But doesn't the 7i92 FPGA deal with quadrature encoders and therefore > >> doesn't really need to deal with a sampling process but instead looks at > >> edges? And because of the way quadrature works, with the A/B phasing > you > >> don't get the same types of errors compared to polling a bit level X > times > >> per second and trying to decide when it's high/low. > >> > >> John > >> > >> > >>> -----Original Message----- > >>> From: Chris Albertson [mailto:albertson.ch...@gmail.com] > >>> Sent: June-19-21 3:21 PM > >>> To: Enhanced Machine Controller (EMC) > >>> Subject: Re: [Emc-users] Machining question > >>> > >>> There are two kinds of noise, > >>> 1) electrical noise superimposed on the signal. > >>> 2) quantization noise from the sampling process. What happens here is > >> that > >>> the computer counts the number of line crossings during a given time. > it > >>> is just random luck when the time starts so on average there is a plus > or > >>> minus one count error. > >>> > >>> So a one count error sounds small but lets say we have a 600 count > >>> encoder and we are running at 500 RPM and sampling 100 times per > second. > >>> This works out to 50 counts per period. a one count error is a 2% > >> error. > >>> You will see a larger percent error at slower speeds or with a lower > >>> resolution encoder. > >>> > >>> So even with perfect wires and perfect grounding and zero electrical > >> noise > >>> the RPM speed is going to jump around randomly over a 4 RPM range > because > >>> of unavoidable quantization error. > >>> > >>> The solutions either the use a larger sample time apply a low-pass > >> DIGITAL > >>> filter to the signal. No amount of analog filters on the wires will > >> work. > >>> > >>> On Sat, Jun 19, 2021 at 2:55 PM Gene Heskett <ghesk...@shentel.net> > >> wrote: > >>> > >>>> On Saturday 19 June 2021 12:59:19 John Dammeyer wrote: > >>>> > >>>>> I need to do a couple of things. For one the AC Servo makes a lot of > >>>>> electrical noise. The frame of the motor is connected to earth > >>>>> through power line ground. But my bench setup has the control side > >> 5V > >>>>> not isolated from the 'PC' side (optos are kind of useless here) and > >>>>> although the Pi4 doesn't appear to have any trouble the scope shows a > >>>>> pretty noisy encoder signal. > >>>> > >>>> You are about to learn the star ground system I think. > >>>> > >>>> Thats where all grounds go to a single bolt, and no other grounds are > >>>> allowed anyplace. > >>>> > >>>> Shielding in motor cables ends without touching the motor, only > >> connected > >>>> to this same single bolt which is grounded. The common line of any > >> power > >>>> supply is connected only to this bolt, and the common grounds to every > >>>> piece of pcb in the system comes from that bolt. The used to be green > >>>> static ground wire in any power cord is rerouted to this bolt. And > >>>> static grounds on a power supply are fed from this single bolt. > Because > >>>> the psu case is usually bolted down wherever its at, you may have to > >>>> uncover the supply and remove any connection from the earth labeled > >>>> terminal, and the psu's case. It may be a screw in the corner of a > pcb, > >>>> but it needs to be removed. > >>>> > >>>> Anything connected to ground at some other point in addition to that > >> bolt > >>>> becomes an antenna, is called a ground loop, picking up both magnetic > >>>> and electrostatic noises. I had to learn that the hard way while > >>>> building the Sheldon, blowing two 7i90HD boards out by picking up 80 > >>>> volts p-p of switching noise that reached up to the bandwidth limits > of > >>>> both of my 100mhz scopes. Hell on an fpga with a 3 volt limit. I > >> killed > >>>> the power and redid it to the single bolt model, and that 80 volts of > >>>> noise was reduced to under 100 millivolts. Took me about a week to > find > >>>> all the connections that should not have been made. Even a small > bypass > >>>> capacitor to a local ground instead of back to that bolt can become a > >>>> lethal weapon to the elecronics. Its a noise injector in that case. > >>>> > >>>> The whole idea is to make the ground, if it bounces from a lightning > >>>> strike on the can on the pole that powers your place, which may make > >> the > >>>> whole system bounce 100+ kilovolts, and if you are in that circuit at > >>>> that instant it WILL get your attention. BUT, everything tied to that > >>>> bolt should bounce in unison, meaning an individual board input will > >>>> only see the difference signal its being fed with, and it should > >> survive > >>>> that lightning strike with no damage. > >>>> > >>>> My soap box as a CET just collapsed, so I'll do an Andy Capp and > >> shudup. > >>>> > >>>> > >>>>> ===================== HAL code =================== > >>>>> Second is some of the HAL parameters and reducing to 0.003 makes the > >>>>> display more stable. # Use ACTUAL spindle velocity from spindle > >>>>> encoder > >>>>> # spindle-velocity bounces around so we filter it with lowpass > >>>>> # spindle-velocity is signed so we use absolute component to remove > >>>>> sign # ACTUAL velocity is in RPS not RPM so we scale it. > >>>>> > >>>>> setp scale.spindle.gain 60 > >>>>> setp lowpass.spindle.gain 0.003 > >>>>> net spindle-vel-fb-rps => scale.spindle.in > >>>>> net spindle-fb-rpm scale.spindle.out => > >>>>> abs.spindle.in net spindle-fb-rpm-abs abs.spindle.out > >>>>> => lowpass.spindle.in net spindle-fb-rpm-abs-filtered > >>>>> lowpass.spindle.out > >>>>> ===================== end HAL code =================== > >>>>> > >>>>> But I'm still using the original signal for at speed and the LED > >> never > >>>>> comes on nor does it know it's at speed. I should probably be > >>>>> filtering the RPS rather than RPM I think? > >>>>> > >>>>> ===================== HAL code =================== > >>>>> net spindle-vel-fb-rps => spindle-near-speed.in1 > >>>>> net spindle-ramped => spindle-near-speed.in2 > >>>>> > >>>>> # ---Setup spindle at speed signals--- > >>>>> # the output from spindle-near-speed 'near' component is sent to > >>>>> spindle.0.at-speed # and when this is true motion will start. The LED > >>>>> in the pyvcp-panel.xml is renamed to be a LED. net > >>>>> spindle-near-speed-led <= spindle-near-speed.out => > >> spindle.0.at-speed > >>>>> ===================== end HAL code =================== > >>>>> > >>>>> John > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: andy pugh [mailto:bodge...@gmail.com] > >>>>>> Sent: June-19-21 2:48 AM > >>>>>> To: Enhanced Machine Controller (EMC) > >>>>>> Subject: Re: [Emc-users] Machining question > >>>>>> > >>>>>> On Sat, 19 Jun 2021 at 07:11, John Dammeyer < > >> jo...@autoartisans.com> > >>>> wrote: > >>>>>>> I'm finding the AXIS Spindle speed oscillates about +/- 5 RPM. > >> I > >>>>>>> thought that I was filtering it. > >>>>>> > >>>>>> It generally needs to be filtered, but it is possible you are > >>>>>> filtering it, but not enough to get a steady reading. > >>>>>> > >>>>>> For whatever reason encoder velocity does always seem to be a bit > >>>>>> noisy, despite the counters using timetamped edges and all the > >> other > >>>>>> tricks that might help. > >>>>>> > >>>>>> -- > >>>>>> atp > >>>>>> "A motorcycle is a bicycle with a pandemonium attachment and is > >>>>>> designed for the especial use of mechanical geniuses, daredevils > >> and > >>>>>> lunatics." > >>>>>> ? George Fitch, Atlanta Constitution Newspaper, 1912 > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Emc-users mailing list > >>>>>> Emc-users@lists.sourceforge.net > >>>>>> https://lists.sourceforge.net/lists/listinfo/emc-users > >>>>> > >>>>> _______________________________________________ > >>>>> Emc-users mailing list > >>>>> Emc-users@lists.sourceforge.net > >>>>> https://lists.sourceforge.net/lists/listinfo/emc-users > >>>> > >>>> > >>>> Cheers, Gene Heskett > >>>> -- > >>>> "There are four boxes to be used in defense of liberty: > >>>> soap, ballot, jury, and ammo. Please use in that order." > >>>> -Ed Howdershelt (Author) > >>>> If we desire respect for the law, we must first make the law > >> respectable. > >>>> - Louis D. Brandeis > >>>> Genes Web page <http://geneslinuxbox.net:6309/gene> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Emc-users mailing list > >>>> Emc-users@lists.sourceforge.net > >>>> https://lists.sourceforge.net/lists/listinfo/emc-users > >>>> > >>> > >>> > >>> -- > >>> > >>> Chris Albertson > >>> Redondo Beach, California > >>> > >>> _______________________________________________ > >>> Emc-users mailing list > >>> Emc-users@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/emc-users > >> > >> > >> > >> _______________________________________________ > >> Emc-users mailing list > >> Emc-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/emc-users > >> > > > > > > -- > > > > Chris Albertson > > Redondo Beach, California > > > > _______________________________________________ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
