Re: [Emc-users] Homing to index ends at different positions

2016-10-12 Thread Kirk Wallace
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

2016-10-12 Thread Peter C. Wallace
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

2016-10-12 Thread andy pugh
On 12 October 2016 at 10:13, Marius Alksnys  wrote:
> 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

2016-10-12 Thread Peter C. Wallace
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