On Sat, 19 Feb 2011, Roland Jollivet wrote: > Date: Sat, 19 Feb 2011 14:56:19 +0200 > From: Roland Jollivet <roland.jolli...@gmail.com> > Reply-To: "Enhanced Machine Controller (EMC)" > <emc-users@lists.sourceforge.net> > To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net> > Subject: [Emc-users] Servo counts > > I see. And is the time stamp used as an integral part of the EMC > calculation? Or rather, does the Pluto interface for example, also supply > the same info?
Dont know if the Pluto does, its FPGA resources are pretty limited. The PID comp in EMC master or 2.5pre can make use of the better velocity estimation from the encoder for its D term, making it output much less noisy. EMC's software encoder counter also has the improved velocity estimation, and I believe Pico systems is adding this feature as well. > > What I'm also wanting to know is; > If a system has 4 axis, that's 4 x (4x8) bytes to read per sample (=128 > bytes) > > Is it practical(for a low cost encoder board) to have only 8bits per > encoder. Since each sample is now only a 4 byte read, the sample rate could > be far higher, and the hardware becomes a lot simpler. Its possible but there will be tradeoffs, I'm not sure what hardware would have so few resources nowadays that it would make sense. Its true that on a slow interface (like EPP) you could read faster but its also true that you would likley be _forced_ to read faster, so for typical EMC 1 KHz sample rate systems where a 8 bit encoder counter would be quite limiting (128 KHz max) you might need to read 2 or 3 times faster for good encoders, wiping out any reduced data transfer overhead advantage. We use a 256 bit encoder counter in our SoftDMC firmware, since we usually have 10-50 KHz sample rates, its not much of a limitation. > > Regards > Roland > > > On 19 February 2011 14:40, Peter C. Wallace <p...@mesanet.com> wrote: > >> On Sat, 19 Feb 2011, Roland Jollivet wrote: >> >>> Date: Sat, 19 Feb 2011 12:35:27 +0200 >>> From: Roland Jollivet <roland.jolli...@gmail.com> >>> Reply-To: "Enhanced Machine Controller (EMC)" >>> <emc-users@lists.sourceforge.net> >>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net >>> >>> Subject: [Emc-users] Servo counts >>> >>> Hi all >>> >>> I'm trying to figure something out; >>> >>> With a servo type system using quadrature feedback, I see that "*the EMC >> ini >>> file uses two variables, FERROR and MIN_FERROR to define acceptable >>> following error for each axis. Think of MIN_FERROR as the following error >>> allowed at very low velocity and FERROR as the distance allowed during >> rapid >>> moves*." >>> >>> Now I know that each system has it's own intrinsic resolution, and that >>> machines move at different speeds, and that the CPU and read-update speed >>> has an effect, but considering that each encoder is read a number of >> times a >>> second; >>> >>> Surely there is no need to have a 32 bit counter? A 16 bit counter should >>> suffice? With a machine having 1u encoder resolution, the max count >> before >>> roll-over would correspond to a FERROR of around 32000 counts, or 32mm >>> >>> Considering a pretty fast G0 traverse of say 40m/min, then 32mm is >> traversed >>> in 48ms, plenty of time to get an update. >>> >>> So what I'm wondering is why do the Mesa cards use 32 bit counters for >> the >>> encoders? >>> >>> Would a 16bit counter not suffice? It just seems that there is a lot of >> time >>> spent reading redundant numbers from encoders, and that things could be >>> simplified with 16 bits. >>> >>> Regards >>> Roland >> >> >> Mesas HostMot2 firmware uses 16 bit counters (which would >> theoretically allow a ~32 MHz count rate at 1 KHz sample rate) >> >> The actual 32 bit hardware register has a 16 bit encoder count in the low >> half >> and 16 bit timestamp (of the last encoder edge) in the high half for >> encoder-counts/delta-time velocity estimation. >> >> Peter Wallace >> Mesa Electronics >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> _______________________________________________ >> Emc-users mailing list >> Emc-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/emc-users >> > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your (")_(") signature to help him gain world domination. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
