Re: [Emc-developers] research on optical encoders
On Mon, 10 Aug 2015, Nicholas Mc Guire wrote: Date: Mon, 10 Aug 2015 08:40:02 +0200 From: Nicholas Mc Guire der.h...@hofr.at Reply-To: EMC developers emc-developers@lists.sourceforge.net To: EMC developers emc-developers@lists.sourceforge.net Subject: Re: [Emc-developers] research on optical encoders On Sat, 08 Aug 2015, Peter C. Wallace wrote: I think the trick the Resolute encoder uses is this: the image is captured in a perhaps sub microsecond flash of the LED, and then the image can be shifted out of the sensor at a leisurely rate. The specifications sort of suggests this (very fast capture (ns) time, but only multi KHz maximum update rate) Peter Wallace Mesa Electronics They may in fact use a laser for illumination as AFAIK you can get higher peak power with a pulsed laser than a LED. These are in the $30 region for 75W peak 40 ns pulse width, not much vibration or motion blur in 40 ns :-) the problem is not the vibration in the 40ns but that the recorded encoder image is more or less a random position within the vibration range of the device + vibration of the laser - I was thinking about compensations like done with satelite images where multiple pictures are taken and then the signals are compensated by filtering out szintilation effects If the actual sampling is in the multi kHz range only then that would be well in the modes that such systems can have and one - worst case - would have the full vibration in the positional information. Just wonder if there are any detection algorithms that look into such issues. Naively one could do a fft on the position data under the assumption that motion should be constant/known-trajectory and that could reveale such vibration/aliasing induced errors. http://www.osram-os.com/osram_os/en/products/product-catalog/laser-diodes/high-power-laser-diodes/pulsed-laser-diodes/hybrid-pulsed-laser-diodes/index.jsp ( thank you Harold Edgerton ) thx! hofrat Not sure vibration in the 10 KHz and up range is a serious problem here as it takes significant energy to get even tiny displacements at 10 KHz or so in the heavy mechanics used with precision encoders. Motion blur _is_ an issue but this is solved by the strobed lighting. -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Got an almost show stopper buglet in the most recent 2.8.0-pre
On Monday 10 August 2015 16:26:18 Gene Heskett wrote: To be specific, G92.1 is not clearing #5061, the g54 X offset. Possibly not clearing #5062 or #5063, all of which I use to calibrate the machine I can code around it as there's nothing to stop me from putting a line in the earlier code to clear it. It works from the MDI interface. #5061 = 0.000 And it works in the gcode too. Except that doesn't stop the positioning error. I go to the MDI and enter G1 F5 X0.331, and it runs to nominally -0.887, a bit over an inch from where it should be going. This is immediately after a G92.1. I think I could use a clue. We have OOT company we're supposed to meet for dinner shortly, so it will be a bit before I get back to a keyboard. Thanks all. The symptoms are a continuously growing X offset in where it goes when the program, assuming its at zero, tells it to move to 0.337 preparatory to executing a G38.2 to find the jig contact, which it should find by 0.425, the #5061 thereby recorded then being moved to the G54 co-ordinate system. Instead it was running to a - value about 3/4 away, and every iteration of the program made the error larger. Cheers, Gene Heskett 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) Genes Web page http://geneslinuxbox.net:6309/gene -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Got an almost show stopper buglet in the most recent 2.8.0-pre
On Monday 10 August 2015 18:15:42 andy pugh wrote: On 10 August 2015 at 21:26, Gene Heskett ghesk...@wdtv.com wrote: To be specific, G92.1 is not clearing #5061, the g54 X offset. Possibly not clearing #5062 or #5063, all of which I use to calibrate the machine Why do you think that it should? The Docs say: G92.1 - reset axis offsets to zero and set parameters 5211 - 5219 to zero. And I can't read. Duh. G92.2 - reset axis offsets to zero. This is 'touch offs' only? If you want to reset G54 to Zero the code is: G10 L2 P1 X0 Y0 Z0 I'll do that, after homing it all, then relocate my jog doohicky so I can drive close to it, then find it with the G38.2's. That repeatability is the general idea of all this. Thanks Andy. Again, from the docs: G10 L2 P- axes R- P - coordinate system (0-9) R - rotation about the Z axis G10 L2 offsets the origin of the axes in the coordinate system specified to the value of the axis word. The offset is from the machine origin established during homing. The offset value will replace any current offsets in effect for the coordinate system specified. Axis words not used will not be changed. Program P0 to P9 to specify which coordinate system to change. 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) Genes Web page http://geneslinuxbox.net:6309/gene -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Got an almost show stopper buglet in the most recent 2.8.0-pre
On Monday 10 August 2015 19:52:51 andy pugh wrote: On 11 August 2015 at 00:10, Gene Heskett ghesk...@wdtv.com wrote: G92.2 - reset axis offsets to zero. This is 'touch offs' only? No, it is _only_ the G92 offset. (Which you might well not be using) I think I see. The previous msg was the magic spell though, and I now have that 20 lines of code doing as it is supposed to. And I have relocated the x offset from the jig, to the left edge of the guage blocks on the jig, but haven't recalibrated the Y offset just yet. Thats tomorrows project, while I am mulling whether or not I make the jig, either air driven to bring it in or out, or, if I can figure out how to drive a cdroms tray motor to flip it down or up electrically. So I'm going to go rooting around in the fleabay midden heap for a suitable 12 volt air valve and a mini air cylinder. I have 80 or so psi in the garage, so a 1/4 double action cylinder, with a 12 volt driven spool valve seems like the simplest way to automate it. Thank you Andy. 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) Genes Web page http://geneslinuxbox.net:6309/gene -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] research on optical encoders
On Monday 10 August 2015 02:40:02 Nicholas Mc Guire wrote: On Sat, 08 Aug 2015, Peter C. Wallace wrote: I think the trick the Resolute encoder uses is this: the image is captured in a perhaps sub microsecond flash of the LED, and then the image can be shifted out of the sensor at a leisurely rate. The specifications sort of suggests this (very fast capture (ns) time, but only multi KHz maximum update rate) Peter Wallace Mesa Electronics They may in fact use a laser for illumination as AFAIK you can get higher peak power with a pulsed laser than a LED. These are in the $30 region for 75W peak 40 ns pulse width, not much vibration or motion blur in 40 ns :-) the problem is not the vibration in the 40ns but that the recorded encoder image is more or less a random position within the vibration range of the device + vibration of the laser - I was thinking about compensations like done with satelite images where multiple pictures are taken and then the signals are compensated by filtering out szintilation effects If the actual sampling is in the multi kHz range only then that would be well in the modes that such systems can have and one - worst case - would have the full vibration in the positional information. Just wonder if there are any detection algorithms that look into such issues. Naively one could do a fft on the position data under the assumption that motion should be constant/known-trajectory and that could reveale such vibration/aliasing induced errors. And once the vibration period is known, an auto-correlation over that time period could improve the accuracy quite a bit, perhaps as much as 10x if the vibration is bad enough to hear. The problem then is the resultant position data, if the machine is moving, is now old by the amount of time the butterfly transform took, then the auto-correlation over the period its output could detect, which could be even slower than the butterfly transform that did the FFT. Its faster than a true FFT by quite a bit, and has the added advantage that running it twice, the second time on the data output by the first pass, which restores the original data. Or is the butterfly transform old hat for FFT, and something even newer faster has taken its place? Its been probably 20 years since I played with it on an 16 bit machine I haven't heard a lot about it since. A 256 bucket transform on that machine took several seconds IIRC. Not having enough memory I never tried a 1024 bucket test. http://www.osram-os.com/osram_os/en/products/product-catalog/laser-d iodes/high-power-laser-diodes/pulsed-laser-diodes/hybrid-pulsed-laser -diodes/index.jsp ( thank you Harold Edgerton ) thx! hofrat -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers 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) Genes Web page http://geneslinuxbox.net:6309/gene -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] research on optical encoders
On Sat, 08 Aug 2015, Peter C. Wallace wrote: I think the trick the Resolute encoder uses is this: the image is captured in a perhaps sub microsecond flash of the LED, and then the image can be shifted out of the sensor at a leisurely rate. The specifications sort of suggests this (very fast capture (ns) time, but only multi KHz maximum update rate) Peter Wallace Mesa Electronics They may in fact use a laser for illumination as AFAIK you can get higher peak power with a pulsed laser than a LED. These are in the $30 region for 75W peak 40 ns pulse width, not much vibration or motion blur in 40 ns :-) the problem is not the vibration in the 40ns but that the recorded encoder image is more or less a random position within the vibration range of the device + vibration of the laser - I was thinking about compensations like done with satelite images where multiple pictures are taken and then the signals are compensated by filtering out szintilation effects If the actual sampling is in the multi kHz range only then that would be well in the modes that such systems can have and one - worst case - would have the full vibration in the positional information. Just wonder if there are any detection algorithms that look into such issues. Naively one could do a fft on the position data under the assumption that motion should be constant/known-trajectory and that could reveale such vibration/aliasing induced errors. http://www.osram-os.com/osram_os/en/products/product-catalog/laser-diodes/high-power-laser-diodes/pulsed-laser-diodes/hybrid-pulsed-laser-diodes/index.jsp ( thank you Harold Edgerton ) thx! hofrat -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] research on optical encoders
A median filter shall be a good start here On 10. August 2015 08:40:02 MESZ, Nicholas Mc Guire der.h...@hofr.at wrote: On Sat, 08 Aug 2015, Peter C. Wallace wrote: I think the trick the Resolute encoder uses is this: the image is captured in a perhaps sub microsecond flash of the LED, and then the image can be shifted out of the sensor at a leisurely rate. The specifications sort of suggests this (very fast capture (ns) time, but only multi KHz maximum update rate) Peter Wallace Mesa Electronics They may in fact use a laser for illumination as AFAIK you can get higher peak power with a pulsed laser than a LED. These are in the $30 region for 75W peak 40 ns pulse width, not much vibration or motion blur in 40 ns :-) the problem is not the vibration in the 40ns but that the recorded encoder image is more or less a random position within the vibration range of the device + vibration of the laser - I was thinking about compensations like done with satelite images where multiple pictures are taken and then the signals are compensated by filtering out szintilation effects If the actual sampling is in the multi kHz range only then that would be well in the modes that such systems can have and one - worst case - would have the full vibration in the positional information. Just wonder if there are any detection algorithms that look into such issues. Naively one could do a fft on the position data under the assumption that motion should be constant/known-trajectory and that could reveale such vibration/aliasing induced errors. http://www.osram-os.com/osram_os/en/products/product-catalog/laser-diodes/high-power-laser-diodes/pulsed-laser-diodes/hybrid-pulsed-laser-diodes/index.jsp ( thank you Harold Edgerton ) thx! hofrat -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- Diese Nachricht wurde von meinem Mobiltelefon mit Kaiten Mail gesendet. -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] research on optical encoders
Since everything is in motion, how will this interact with the PID or other timing loops? I wonder if that would be sufficient to filter out the vibration. On Aug 10 2015 1:04 AM, Julian Wingert wrote: A median filter shall be a good start here On 10. August 2015 08:40:02 MESZ, Nicholas Mc Guire der.h...@hofr.at wrote: On Sat, 08 Aug 2015, Peter C. Wallace wrote: I think the trick the Resolute encoder uses is this: the image is captured in a perhaps sub microsecond flash of the LED, and then the image can be shifted out of the sensor at a leisurely rate. The specifications sort of suggests this (very fast capture (ns) time, but only multi KHz maximum update rate) Peter Wallace Mesa Electronics They may in fact use a laser for illumination as AFAIK you can get higher peak power with a pulsed laser than a LED. These are in the $30 region for 75W peak 40 ns pulse width, not much vibration or motion blur in 40 ns :-) the problem is not the vibration in the 40ns but that the recorded encoder image is more or less a random position within the vibration range of the device + vibration of the laser - I was thinking about compensations like done with satelite images where multiple pictures are taken and then the signals are compensated by filtering out szintilation effects If the actual sampling is in the multi kHz range only then that would be well in the modes that such systems can have and one - worst case - would have the full vibration in the positional information. Just wonder if there are any detection algorithms that look into such issues. Naively one could do a fft on the position data under the assumption that motion should be constant/known-trajectory and that could reveale such vibration/aliasing induced errors. http://www.osram-os.com/osram_os/en/products/product-catalog/laser-diodes/high-power-laser-diodes/pulsed-laser-diodes/hybrid-pulsed-laser-diodes/index.jsp ( thank you Harold Edgerton ) thx! hofrat -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] research on optical encoders
On 10 August 2015 at 12:38, EBo e...@sandien.com wrote: Since everything is in motion, how will this interact with the PID or other timing loops? I wonder if that would be sufficient to filter out the vibration I suspect that it would. If not, then a DPLL (possibly with the accelleration matched to the machine setting) would be one way to filter the output. But then you effectively have a DPLL attempting to model the machine, and you might as well use the machine for that... -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
