Re: [Emc-users] Servo counts
With 32 bit counters, in most cases, you don't have to worry about roll over at all.. Dealing with roll over issues can be tricky.. Dave On 2/19/2011 5:35 AM, Roland Jollivet wrote: 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 -- 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
Re: [Emc-users] Servo counts
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
Re: [Emc-users] Servo counts
On 19 February 2011 10:35, Roland Jollivet roland.jolli...@gmail.com wrote: Surely there is no need to have a 32 bit counter? A 16 bit counter should suffice? Yes and no. The Mesa FPGAs actually use a 16 bit counter, but this is expanded to 64 bits by the EMC2 drivers, then re-exported to the HAL pins as 32 bits. I think the policy is that all encoder counters in EMC2 are 64 bits internally. The reason is that the encoder counts are used to track the positions of the axes, typically axis position is simply encoder counts x scale. There is absolutely no expectation that an encoder counter will roll-over at an integer number of base units, and in fact there is no requirement for the encoder scale to be an integer, less still an integer factor of encoder counts. An example of where this matters is the bldc component, which uses the encoder counts to derive the absolute position of the motor rotor. If the motor has a 1000 count encoder (ie not an integer factor of 2^32) then when the encoder rolls-over the angle calculation will be incorrect, and the motor will either stop, lose torque or start running in the wrong direction. Originally that component used a 32 bit counter, but was later expanded to 64 bits. 32 bits can track a 3000rpm motor for a few hours. 64 bits can track one for half a million years. The former latter is too long, but the former is too short, and that is worse. There would be an option to check the current axis position against the previous and check for a 31-bit rollover (it's signed) but the computational overhead of doing that is probably higher than simply shuffling a few more bytes through the adder. -- atp Torque wrenches are for the obedience of fools and the guidance of wise men -- 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
Re: [Emc-users] Servo counts
On 19 February 2011 12:56, Roland Jollivet roland.jolli...@gmail.com wrote: Is it practical(for a low cost encoder board) to have only 8bits per encoder. Yes, that would almost certainly work fine, but the EMC2 component would have to track it with a 64-bit internal counter. Luckily, by a quirk of signed binary, adding the delta of a rolled-over 8, 16 or 32 bit signed value to a 64 bit accumulator just works, with no special trapping needed. You would be limited to 256 encoder counts per rev though, I think, if you wanted to only use 8 bits. -- atp Torque wrenches are for the obedience of fools and the guidance of wise men -- 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
Re: [Emc-users] Servo counts
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
Re: [Emc-users] Servo counts
Roland Jollivet wrote: 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 You have conflated two distinct concepts here - encoder resolution and following error. Following error calculations have nothing to do with the encoder counter width, they're done in floating point after the hardware counters have been extended to whatever the driver wants (32 or 64 bits). Considering a pretty fast G0 traverse of say 40m/min, then 32mm is traversed in 48ms, plenty of time to get an update. Look at it in terms of count rates vs servo rates: a fast encoder can do a few MHz, and emc typically runs the servo loop at 1 or more kHz. That leaves a few kCounts per servo cycle, more or less. So a 13 bit signed counter is probably large enough, and 16 bits is comfortably large in most situations. 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. There is almost no time spent reading redundant data. On the PCI cards, a 32-bit read takes the same or less time than a smaller width read. As explained elsewhere, the counter itself is only 16 bits, and you don't save anything by reducing that to 13 or 14 bits, since you still have to read two bytes to get the count. - Steve -- 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
Re: [Emc-users] Servo counts
Roland Jollivet wrote: 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? 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) Math error! :) You don't read (4*8) bytes per axis, it's 4 bytes or 4*8 bits. At least for the encoders on a Mesa system. Reading 4 encoders at 32 bits each is 16 bytes, which takes around 16 microseconds over EPP (it's a couple of microseconds for any reasonable PCI system). 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. A 4 byte read is only 4 bytes less than an 8 byte read, and it only saves around 4 microseconds over an EPP bus. The reduction in possible count rate is pretty terrible. You would have to increase the servo cycle rate (or at least the encoder read rate) by a factor of 256 to be able to support the same count rates as a 16-bit encoder register. That involves 256 times the number of bytes being transferred. By making the read take twice as long, you don't have to increase the rate at which that thread runs, and the total number of reads is actually around 1/128 as much. In other words, a 16-bit count is enough that you can use a 1-2 ms servo cycle without really being concerned about a counter overrun. If you reduced the count to 8 bits, you would need to read the encoder register 256 timed as often to support the same count rate. Say your encoder will only move 2000 counts in 1ms. An 8-bit counter can only count +127/-128 counts, so you would need to read an 8-bit encoder counter16 times every millisecond to just barely handle that rate. You're reading 1 byte16 times instead of 2 bytes one time. Loads more data transfer needed for the simpler case. - Steve -- 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
Re: [Emc-users] Servo counts
Roland Jollivet wrote: 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. I use a 24-bit counter on my parallel port-connected boards. Rollover definitely happens on systems with higher resolution or long travels, and is handled by the driver. The Mesa cards that plug into a PCI slot don't have to worry as much about the overhead of reading 32-bit registers. Rollover is less likely on those, but still possible. Yes, a 16-bit counter would have been sufficient on my boards, mostly I used 24 as that is what was provided by the Servo-to-Go board (LS7166 chips). I was trying to stay as close to the STG in functionality as I could. But, I'm not sure moving down to a 16-bit counter is much of a simplification. Jon -- 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
Re: [Emc-users] Servo counts
Roland Jollivet wrote: 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? 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. If you read the counters at 1 KHz, then a 256-bit counter can probably only accept 127 counts in that period so that the direction of the rollover can be determined with certainly. I have several systems that run over 128,000 counts/second. If the CPU sampled the position faster, that would be less of a problem. But, all the other overhead means that the overhead directly due to the number of bits in the position counter is probably small. Jon -- 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
Re: [Emc-users] Servo counts
On Sat, 19 Feb 2011, Jon Elson wrote: Date: Sat, 19 Feb 2011 14:08:40 -0600 From: Jon Elson el...@pico-systems.com Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Servo counts Roland Jollivet wrote: 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. I use a 24-bit counter on my parallel port-connected boards. Rollover definitely happens on systems with higher resolution or long travels, and is handled by the driver. The Mesa cards that plug into a PCI slot don't have to worry as much about the overhead of reading 32-bit registers. Rollover is less likely on those, but still possible. Yes, a 16-bit counter would have been sufficient on my boards, mostly I used 24 as that is what was provided by the Servo-to-Go board (LS7166 chips). I was trying to stay as close to the STG in functionality as I could. But, I'm not sure moving down to a 16-bit counter is much of a simplification. Jon And we have a similar situation with our EPP based cards, because we want the driver to see the same register set for all our cards whether EPP, USB, PCI Ethernet or whatever. So there are some inefficiencies inhernet in the commonality. So far this has not been a real issue. There actually is capability in our EPP interface firmware to do arbitary byte sequence reads and writes with no addressing overhead (via the TRAM) so you could write a specialized 7I43 driver that only reads 8 bits of encoder count if you so wished. OP: So this gives me an idea: If you want only 8 bit count, one thing to consider is to maintain a larger count, but only read the high half if needed (by the samplerate and maximum encder count rate) 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
Re: [Emc-users] Servo counts
Peter C. Wallace wrote: , and I believe Pico systems is adding this feature as well. Yes, our UPC board (PWM servo controller) has had the firmware support for this for several years. I finally found some time to bang my head around the driver software to use the timestamp info to perform the velocity estimation. It works quite well. A MAJOR problem I had in tuning small, low inertia motors was that the apparent velocity jumps due to the quantizing of encoder position resulted in a LOT of velocity noise at half the sampling frequency (SERVO_PERIOD) . This came through the PID's D term to make tuning very hard. Add a little more D and the noise pulses in the velocity became dominant and made the servos audibly noisy as well as mechanically rough. Feeding the estimated velocity derived with the time stamp data greatly smoothed this roughness. I can do a demo with the old way and the estimated velocity way, and the difference can be heard from yards away! So far, I only have this implemented on the UPC, I hope to eventually get it on the USC and the PPMC as well. Those interfaces have a less pressing need for the improved velocity computation. Also, adding the readout of 8 additional bytes of data per four axes does increase CPU load from the driver code, so I made it an option that can be enabled on the loadrt command line. Jon -- 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
