Re: [Emc-users] Homing to index ends at different positions
On 10/12/2016 04:15 AM, Peter C. Wallace wrote: ... snip > Another diagnostic would be to halscope the index pulse itself assuming you > can move slowly enough to detect it in the servo thread, index pulses are > often 1 encoder pitch wide (1/2048 in your case) so you would have to move > more slowly than 2s seconds per turn to reliably detect it at a 1 KHz servo > thread ... snip I recently had Z axis homing problems on my HNC lathe. I watched the encoder signals with HALscope while turning the screw forward and back by hand. I lost position over a few cycles. It turned out to be a bad capacitor that was causing the encoder voltage regulator to randomly shutdown. I removed the capacitor and function was restored. So, your problem may be like this, where the fault may not be consistent or obvious. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Homing to index ends at different positions
On Wed, 12 Oct 2016, Marius Alksnys wrote: > Date: Wed, 12 Oct 2016 14:59:54 +0300 > From: Marius Alksnys <mar...@robotise.lt> > Reply-To: "Enhanced Machine Controller (EMC)" > <emc-users@lists.sourceforge.net> > To: emc-users@lists.sourceforge.net > Subject: Re: [Emc-users] Homing to index ends at different positions > > Thank you for your suggestions, Peter. > In this case Z assembly weights probably several hundred kilograms. And > I don't have a big wish to remove the servo motor, although possible. > Releasing the electromechanical brake makes it drop really fast. > > By the way, I have never succeeded "setsing" or "setping" an encoder > index-enable signal and waiting for it to go down by rotating the > encoder by hand on other setups. I don't remember the exact behavior > now. I thought it has something to do with less often used IO type of > HAL pin.. But a bit of time passed, I should check that again. > If the latch move is slow enough (so the index signal is capturable by halscope with a servo thread update rate), capturing a halscope trace of index and index-enable might help diagnosis setp-ing the index-enable pin will not work, but sets-ing the signal that carries the index-enable does work and does not require disconnecting hal pins > What is interesting, while not proven, that encoder count (or rawcount) > persists between different LinuxCNC sessions and resets only after 7i77 > 5V power is re-applied. And exactly then I observe different Z position > after homing. > These things are not easy to prove, as they require big number of > different tries. The 7I77 cannot "store" any encoder counts as it only has encoder input signal conditioning on card, though cycling the 7I77 power when LinuxCNC is running will like cause a few stray counts. Note the raw counts are not cleared at linuxcnc start so can be any initial value (encoder counts and position _are_ cleared at linuxcnc startup and encoder position is cleared by index if index enable is true). Is it possible that something on the drive changes with 7I77 power cycles. > > >> I would hand check index detection by "setsing" the appropriate index-enable >> signal and turning the axis by hand and watching for the same index-enable >> signal to be cleared. If this does not work reliably it suggests you have a >> encoder index signal interface problem of some sort (wrong interface mode, >> too short index signal, missing index from resolver-digital converter, 5V >> problem on 7I77, cable issues etc) >> >> The encoder errors also suggest some kind of generic interface issue >> >> Another diagnostic would be to halscope the index pulse itself assuming you >> can move slowly enough to detect it in the servo thread, index pulses are >> often 1 encoder pitch wide (1/2048 in your case) so you would have to move >> more slowly than 2s seconds per turn to reliably detect it at a 1 KHz servo >> thread >> >> >> >> Peter Wallace >> Mesa Electronics >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > 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. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Homing to index ends at different positions
On 12 October 2016 at 10:13, Marius Alksnyswrote: > LinuxCNC 2.7.7, hostmot2, Mesa 5i25 + 7i77, resolver to quadrature > converter integrated into servo drive, 8192 counts per revolution. How does the Resolver to Quadrature converter decide where the index is? It might do it on a fixed part of the cycle (the LinuxCNC 7o49 driver does) or it might just pulse every 8192 counts. The latter method won't work well. Is the error exactly one turn, or is it truly random? -- 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, 1916 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Homing to index ends at different positions
On Wed, 12 Oct 2016, Marius Alksnys wrote: > Date: Wed, 12 Oct 2016 12:13:16 +0300 > From: Marius Alksnys> Reply-To: "Enhanced Machine Controller (EMC)" > > To: emc-users@lists.sourceforge.net > Subject: [Emc-users] Homing to index ends at different positions > > LinuxCNC 2.7.7, hostmot2, Mesa 5i25 + 7i77, resolver to quadrature > converter integrated into servo drive, 8192 counts per revolution. > > I finished integration and one day operator said that Z position was > lost after last machine restart. > > I checked Z homing process and got different final Z positions at > different tries, especially after PC and 7i77 5V re-powering. > > Then I observed that looking for an index sometimes does not actually > stop at the index, but at the next one - after one full turn. Would it > be noise or inverted signal problem it would interpret noises as index > pulse and would stop faster, not further, but this does not happen. > > I played a lot with HOME_LATCH_VEL, making it much smaller, changing its > direction, but could not get reliable results. I checked position of > home switch in relation to index position and moved the flag of home > switch, got around 1200 counts difference between them, but nothing helped. > > And now, as I can recall, homing to index with Mesa boards gave me > problems here and there often. Final workaround was to disable this > feature and rely on imprecise home switches only :( > > in INI file: > = > [HM2] > DRIVER = hm2_pci > FPGA = hm2_5i25.0. > ENC = hm2_5i25.0.encoder. > PWM = hm2_5i25.0.pwmgen.0 > DI = hm2_5i25.0.7i77.0.0.input- > DO = hm2_5i25.0.7i77.0.0.output- > AO = hm2_5i25.0.7i77.0.1. > AI = hm2_5i25.0.7i77.0.0.analogin > CONFIG=" num_encoders=6 sserial_port_0=2XXX " > > # Axis Z > [AXIS_2] > TYPE = LINEAR > FERROR = 1 > MIN_FERROR = 0.2 > MAX_VELOCITY = 325 > MAX_ACCELERATION = 1800 > ... (PID values) > BIAS = 0 > DEADBAND = 0.0004 > MAX_OUTPUT = 10 > INPUT_SCALE = -1259.84251969 > OUTPUT_SCALE = -10 > OUTPUT_MIN_LIMIT = -10 > OUTPUT_MAX_LIMIT = 10 > MIN_LIMIT = -512 > MAX_LIMIT = 0 > HOME = -1 # The position that the joint will go to upon completion of > the homing sequence > HOME_OFFSET = -8 # The axis position of the home switch or index pulse, > in machine units. > HOME_SEARCH_VEL = 60 > HOME_LATCH_VEL = -10 > HOME_FINAL_VEL = 100 > HOME_USE_INDEX = YES > HOME_IGNORE_LIMITS = NO > HOME_SEQUENCE = 0 > > in main HAL file: > = > loadrt trivkins > loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD > num_joints=[TRAJ](AXES) num_dio=7 > loadrt threads name1=slow-thread period1=[EMCMOT]SLOW_PERIOD > loadrt pid names=pid-x,pid-y,pid-z,pid-spin,pid-orient > ... > loadrt debounce cfg=10 > ... > loadrt hostmot2 > loadrt [HM2](DRIVER) config=[HM2](CONFIG) > setp [HM2](FPGA)watchdog.timeout_ns 500 > ... > # --- Z encoder setup --- > setp [HM2](ENC)02.filter 1 > setp [HM2](ENC)02.scale [AXIS_2]INPUT_SCALE > net z-pos-fb [HM2](ENC)02.position => pid-z.feedback axis.2.motor-pos-fb > net z-vel-fb [HM2](ENC)02.velocity => pid-z.feedback-deriv > net z-index-enable axis.2.index-enable <=> [HM2](ENC)02.index-enable > ... > net z-index-enable => pid-z.index-enable > ... > # Home and limit switches > ... > net z-home-noisy [HM2](DI)09 => debounce.0.2.in > net z-home debounce.0.2.out => axis.2.home-sw-in > ... > net z-limit-noisy [HM2](DI)10-not => debounce.0.5.in > ... > # THREADS > addf [HM2](FPGA)read servo-thread > addf debounce.0 servo-thread > ... > > addf motion-command-handler servo-thread > addf motion-controller servo-thread > ... > addf pid-z.do-pid-calcs servo-thread > ... > addf [HM2](FPGA)write servo-thread > ... > addf scale-s-vel slow-thread > ... > > in postgui.hal: > = > ... > net enc-quad-error-en [HM2](ENC)00.quad-error-enable > [HM2](ENC)01.quad-error-enable [HM2](ENC)02.quad-error-enable > [HM2](ENC)05.quad-error-enable > ... > # I put this line at the very end, because I noticed more occasional > quadrature errors otherwise: > sets enc-quad-error-en 1 > lock > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > I would hand check index detection by "setsing" the appropriate index-enable signal and turning the axis by hand and watching for the same index-enable signal to be cleared. If this does not work reliably it suggests you have a encoder index signal interface problem of some sort (wrong interface mode, too short index signal, missing index from resolver-digital converter, 5V problem on 7I77, cable issues etc) The encoder errors also suggest some kind of generic interface issue Another diagnostic