[Emc-developers] Encoder Diagnostics
After finding that my spindle encoder had drifted, and was counting 686 of the 720 counts, leading to rather unconveninally-pitched threads, I find myself wondering if it would be sensible for the encoder function to set a pin to counts since last index on every index event. This could be monitored in HAL to raise a warning. Or is this a use-case for the latched pins which are only partly explained in the docs. (and which don't exist for Mesa encoders) -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Encoder Diagnostics
On Tue, 20 Dec 2011, andy pugh wrote: Date: Tue, 20 Dec 2011 14:18:10 + From: andy pugh bodge...@gmail.com Reply-To: EMC developers emc-developers@lists.sourceforge.net To: EMC developers emc-developers@lists.sourceforge.net Subject: [Emc-developers] Encoder Diagnostics After finding that my spindle encoder had drifted, and was counting 686 of the 720 counts, leading to rather unconveninally-pitched threads, I find myself wondering if it would be sensible for the encoder function to set a pin to counts since last index on every index event. This could be monitored in HAL to raise a warning. Or is this a use-case for the latched pins which are only partly explained in the docs. (and which don't exist for Mesa encoders) low level hardware wise, Latch_on_index is avalable on Mesa Encoder counters so could be used to verify count. This feature is used with home on index so would have to be shared with homing, that is, mod encoder count checking would need to be disabled while homimg. Theres also a sticky quadature error bit that will detect things like both A and B changing at once -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ 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. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Encoder Diagnostics
On Tue, Dec 20, 2011 at 02:18:10PM +, andy pugh wrote: After finding that my spindle encoder had drifted, and was counting 686 of the 720 counts, leading to rather unconveninally-pitched threads, I find myself wondering if it would be sensible for the encoder function to set a pin to counts since last index on every index event. This could be monitored in HAL to raise a warning. Or is this a use-case for the latched pins which are only partly explained in the docs. (and which don't exist for Mesa encoders) The idea is great - but I'm not sure about counts since last index. You should think bigger. There are lots of ways encoder hardware can detect problems: invalid quadrature transitions, extra or missing counts between indexes, and maybe more. If the encoder hardware knows pulses per rev (which is not the current scale value it knows) it can detect missing index too. A non-emc machine I worked on would detect missing index when homing (it stopped when there should have been one by now) - emc can't do this currently and it will search forever for an index. I think encoder hardware could have extra parameters to configure these detection features (for example, a ppr parameter), and then one or more fault outputs. They are free to do this now; the canonical encoder interface is a minimum recommended feature set. I think I recall hearing that the mesa firmware detects invalid quadrature transitions (often caused by interference) but the hal driver doesn't make that information available. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Encoder Diagnostics
Chris Radek wrote: There are lots of ways encoder hardware can detect problems: invalid quadrature transitions, extra or missing counts between indexes, and maybe more. If the encoder hardware knows pulses per rev (which is not the current scale value it knows) it can detect missing index too. A non-emc machine I worked on would detect missing index when homing (it stopped when there should have been one by now) - emc can't do this currently and it will search forever for an index. It would need to have an error threshold. When the spindle starts or reverses, the counts per rev will be off. Also if the spindle is moved by hand it could throw the count off. Invalid quadrature transitions could be normal whenever the spindle is not running, ie. typical dithering plus electrical noise. I think both the Mesa and I know the Pico Systems encoder counters have digital filters to suppress invalid transitions of short duration. The Pico Systems encoder model in the FPGA hardware has a latch that is set by the rising edge of the index pulse, and is reset by reading the index register. So, the driver could sample the position count every time there is an index pulse detected, and compare to position at the last index. This will NOT give a number identical to the encoder counts/rev except at very low speeds, however. Any time the encoder is turning above one count per servo period, it can come up short or long. So, you would have to exceed an error margin before declaring a fault. On an axis, particularly, whenever the encoder reverses direction, you would get a difference count that was approximately zero, because the second index pulse is returning to the same axis position as the last index. So, this sort of thing is non-trivial, and you have to cover all the cases to avoid false trips. Jon -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Encoder Diagnostics
On Tue, 20 Dec 2011 11:49:42 -0600, Jon Elson wrote: Chris Radek wrote: There are lots of ways encoder hardware can detect problems: invalid quadrature transitions, extra or missing counts between indexes, and maybe more. If the encoder hardware knows pulses per rev (which is not the current scale value it knows) it can detect missing index too. A non-emc machine I worked on would detect missing index when homing (it stopped when there should have been one by now) - emc can't do this currently and it will search forever for an index. It would need to have an error threshold. When the spindle starts or reverses, the counts per rev will be off. Also if the spindle is moved by hand it could throw the count off. Invalid quadrature transitions could be normal whenever the spindle is not running, ie. typical dithering plus electrical noise. I think both the Mesa and I know the Pico Systems encoder counters have digital filters to suppress invalid transitions of short duration. The Pico Systems encoder model in the FPGA hardware has a latch that is set by the rising edge of the index pulse, and is reset by reading the index register. So, the driver could sample the position count every time there is an index pulse detected, and compare to position at the last index. This will NOT give a number identical to the encoder counts/rev except at very low speeds, however. Any time the encoder is turning above one count per servo period, it can come up short or long. So, you would have to exceed an error margin before declaring a fault. On an axis, particularly, whenever the encoder reverses direction, you would get a difference count that was approximately zero, because the second index pulse is returning to the same axis position as the last index. So, this sort of thing is non-trivial, and you have to cover all the cases to avoid false trips. I could see having that functionality as a compilable/loadable diagnostic test so that it would not have to run all the time (ie saving CPU cycles). I like the proposed functionality. EBo -- -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Encoder Diagnostics
EBo wrote: I could see having that functionality as a compilable/loadable diagnostic test so that it would not have to run all the time (ie saving CPU cycles). I like the proposed functionality. I actually have this test in some of my diagnostics. They set up the encoder counter to reset on index (that's how home to index and threading work) and display the count. You can turn slowly and see the largest number in each direction before it resets to zero. Jon -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
