Back
[03:32:05] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15propcoder opened issue #178: No way to correctly display back tool lathe in axis 02
https://github.com/LinuxCNC/linuxcnc/issues/178
[11:00:07] <cradek> don't resolvers often have several/many full electrical cycles per physical turn?
[11:03:34] <pcw_home> they often do for higher resolution and also ones used to commutate 4-8 pole AC servos
[11:05:14] <cradek> that could sure give you more indexes than you expect, if the converter works like the pico ones I have
[11:08:20] <jepler> some days I wonder if we should kill the use of index
[11:08:25] <jepler> for threading
[11:08:25] <pcw_home> Yeah, though the offsets would be noticeably quantized if you checked
[11:08:27] <pcw_home> it looks like Marius's problem is that index is just not seen sometimes, but its hard to tell
[11:08:54] <jepler> it was very important before double-precision hal floats, because you could easily get into the range where spindle positions were very quantized
[11:12:04] <pcw_home> index on threading is needed for "A" only threading (as JMK reminded me)
[11:12:05] <pcw_home> and of course the thread start is volatile without a physical index (probably not important)
[11:22:05] <seb_kuzminsky> not important right now, but will/would be for peck tapping
[11:22:50] <seb_kuzminsky> http://www.helmancnc.com/fanuc-g84-rigid-peck-tapping-cycle/
[11:24:25] <skunkworks> I think it certainly be an option - but allowing threading without an index would be a nice addition..
[11:25:26] <jepler> you might still find the index once ('spindle homing' a la andypugh's idea) but after that you can just use a modulo operation to know the spindle angle
[11:28:01] <cradek> I assume we'd keep spindle-revs as is (increases by 1.0 for each full turn in M3 direction)
[11:28:22] <cradek> you'd code in the assumption that you could start a threading pass at any xxx.0 position
[11:29:01] <cradek> if your encoder works perfectly AND you home it yourself by setting index-enable, that would give the same behavior as today
[11:29:47] <jepler> yes that's essentially what I'm saying
[11:30:16] <jepler> and if you have 4 index pulses per spindle rev, or 3.5, or 100/25.4, you can do better than you can today at threading
[11:30:30] <jepler> because it involves just setting your scale right, not changing you hardware until you have one index-pulse per revolution
[11:30:33] <cradek> yes that's true
[11:30:51] <jepler> granted, you'll have 4, or 7, or ??? different possible thread starting points *over power cycles* / spindle homing cycles..
[11:31:26] <cradek> I think that is rarely important
[11:31:39] <cradek> if it was important to you, you could just fix your hardware
[11:32:11] <skunkworks> if you setup spindle homing like an axis - you could have a switch then that could find the next index
[11:33:05] <skunkworks> *like homing to index - you would then find the 'right' index each time
[11:33:20] <skunkworks> ie a prox sensor that would get you close
[11:35:08] <jepler> of course in my scheme, you have a scale that is not a "nice" number (that you are likely to write as an exact decimal) then that inaccuracy is compounded as the spindle turns increase
[11:40:09] <jepler> (for instance, if you have 1000/3 CPR and set position-scale to 333.33, then you accumulate an error of 1 revolution every 100,000 revolutions)
[11:40:21] <jepler> that accumulating error also gets cleared out by using the index pulse
[11:40:43] <jepler> except for how it would be tricky to make the index pulse come exactly once every 1000/3 cycles
[11:41:20] <jepler> .. put the AB encoder on the motor and the Z (only) on the spindle? crazy.
[11:50:21] <pcw_home> If you have an index its going to be more robust,
[11:50:23] <pcw_home> but it does seem a simulated index in the encoder comp
[11:50:24] <pcw_home> would simplify hardware on a fair number of systems
[16:22:04] <seb_kuzminsky> mozmck: if you're into it, i'd be happy to help get linuxcnc 3.0~pre1 released at the hackfest
[21:00:56] <seb_kuzminsky> ~.
[21:02:17] <jepler> >
[21:02:18] <jepler> The Debian project can be accused of many things, but jumping too quickly on leading-edge technology is not one of them
[21:02:50] <jepler> https://lwn.net/SubscriberLink/703001/ba030656510a5314/ (Supporting UEFI secure boot in Debian)
[21:59:05] <cradek> but I don't want *any* of those features on my machines
[22:00:30] <skunksleep> zlog
[22:01:25] <cradek> but I never had the choice of when to close the barn door, never mind the status of the horses