#linuxcnc-devel Logs

Jun 20 2017

03:36 AM pcw_mesa_ is now known as pcw_mesa
08:07 AM KGB-linuxcnc: 03Jeff Epler 05master d2225b8 06linuxcnc Merge branch 'remap-default-modalgroup' of https://github.com/jepler/linuxcnc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d2225b8
08:12 AM KGB-linuxcnc: 03Jeff Epler 05master bea69c3 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/rtapi/uspace_rtapi_app.cc Merge branch 'jepler/setfsuid' of https://github.com/LinuxCNC/linuxcnc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bea69c3
08:20 AM KGB-linuxcnc: 03Jeff Epler 05master 240793b 06linuxcnc Merge branch 'hm2_rpspi' of https://github.com/BsAtHome/linuxcnc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=240793b
09:59 AM jepler: seb_kuzminsky: all well with the forum while I was away?
10:24 AM seb_kuzminsky: no problems
10:24 AM seb_kuzminsky: there were some short timeouts (doesn't respond to http and/or icmp for 30 seconds, then comes back without any human intervention)
10:24 AM seb_kuzminsky: that happens randomly once or twice every day or two, and has all along
10:25 AM seb_kuzminsky: might be my network connection at home, for all i know
12:03 PM IchGucksLive: HI all the cooltool has changed its electronics and so its pinout the mashines redy configt arent running
12:03 PM IchGucksLive: now the 4th or more needed help
12:05 PM archivist: users have to think for them selves and not expect wet nursing
12:05 PM IchGucksLive: but most do
12:06 PM archivist: this one next door seems very lazy
12:06 PM archivist: have to teach them to fish
12:06 PM IchGucksLive: i know but we are most pro here and far from the baseline whee peole see linux for the first time
12:27 PM IchGucksLive: archivist: has the smictl name changed in 16.04
12:28 PM archivist: I have no idea of that name or where it is from
12:33 PM nos__ is now known as nos
01:29 PM KGB-linuxcnc: 03Sebastian Kuzminsky 052.7-hm2-encoder-raw-position 1140fc1 06linuxcnc 10docs/man/man9/hostmot2.9 10src/hal/drivers/mesa-hostmot2/encoder.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h hostmot2: add .raw-position pin to encoder * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1140fc1
02:00 PM jepler: After the index pulse is seen, the position command will have a step discontinuity. the stepper position, as known to hm2_7i43.0.stepgen.XX however *has had no step* so it's going to go running off trying to undo the step change
02:01 PM jepler: I think the config proposed is just broken
02:01 PM jepler: or am I missing where stepgen is able to "follow" the index reset?
02:01 PM jepler: I see now that peter covered this in a subthread I hadn't reached yet..
02:02 PM jepler: oh so I did miss that this motor-pos-cmd vs joint-pos-cmd distinction..
02:03 PM * jepler goes back under his rock
02:11 PM pcw_mesa: isn't there a step in the encoder position at index?
02:12 PM pcw_mesa: and doesn't the command position needs to match this
02:12 PM pcw_mesa: to avoid a large thump/FE at index
02:56 PM seb_kuzminsky: pcw_mesa: the command to the motor has no offsets (no home offset, no screw-comp offset, etc)
02:56 PM seb_kuzminsky: the feedback from the motor needs to match this
02:57 PM seb_kuzminsky: the encoder's ".position" feedback jumps on index-enable && index
02:58 PM seb_kuzminsky: i just added a ".raw-position" feedback from the encoder that ignores index, so it behaves just like (for example) the stepgen's .position-fb
02:58 PM seb_kuzminsky: i think that should fix tom's problem
03:30 PM pcw_mesa: it may have no offsets but id the encoder position has a step, the commanded position must have a matching step or there will be a thump
03:31 PM pcw_mesa: but if
03:36 PM seb_kuzminsky: the interface that motion presents to the motor has three pins relevant to this discussion: axis.*.motor-pos-cmd, .motor-pos-fb, and .index-enable
03:36 PM seb_kuzminsky: .motor-pos-cmd and .motor-pos-fb are both offset-free, continuous values
03:38 PM seb_kuzminsky: this works fine with things like stepgen, where the .position-cmd and .position-fb pins are both free of offsets
03:40 PM seb_kuzminsky: with encoders, the .position and .count values jump when (.index-enable && Index) is true, so it's not suitable for connecting to axis.*.motor-pos-cmd
03:41 PM seb_kuzminsky: i wonder how servos have ever worked
03:41 PM seb_kuzminsky: maybe there's something i'm not thinking of here
03:42 PM jepler: motion has special code for the cycle where the index reset causes a step change in position-fb
03:42 PM jepler: as does pid (it wants to see the index-enable pin's value too, as a reader)
03:42 PM jepler: and you have to get things in the right order
03:44 PM seb_kuzminsky: ah, i knew about the special handling in pid to avoid the THUMP on index, i didn't know Motion had special handling too
03:45 PM pcw_mesa: the special handling is just one servo cycle long so commanded position must jump along with feedback position
03:47 PM pcw_mesa: (actually I think this is all an artifact of simple hardware encoder logic that can only clear the count on index)
03:47 PM pcw_mesa: I woudl be better if no step was visible at the hal level at all
03:47 PM jepler: yeah you're right on both counts
03:47 PM jepler: but one of those early isa encoder-counting cards had only reset, not latch..
03:47 PM jepler: and so here we are, umpteen years later
03:48 PM jepler: (actually maybe pico boards too..)
03:48 PM pcw_mesa: unfortunately this (clearing on index) is quite common
03:49 PM pcw_mesa: Yeah I think this has been discussed years and years ago
03:51 PM pcw_mesa: there's even hm2 firmware that has index capability in the stepgen, also many years old...
03:57 PM cradek: oh I'm sad I gave stupid advice
03:58 PM cradek: stepgen in position mode and encoder+index homing has never been supported
03:58 PM cradek: stepgen in velocity mode with pid works fine
03:58 PM pcw_mesa: yeah its just a velocity mode servo at that point
03:59 PM cradek: doesn't it also work better? I thought we were using velocity mode stepgen + pid in new configs now
04:00 PM pcw_mesa: It does work better (in the respect that its more tolerant of jitter and allows finer tuning of FE)
04:01 PM pcw_mesa: But I think Toms config is quite old, before pncconf changed to PID run stepgesn
04:12 PM seb_kuzminsky: it looks to me like Motion only ignores .motor-pos-fb on the cycle where the encoder clears .index-enable
04:15 PM pcw_mesa: probably needs to do that to avoid a bogus following error
04:46 PM seb_kuzminsky: motor-pos-cmd is computed from joint-pos-cmd by addinging the home & backlash offsets, joint-pos-fb is computed from motor-pos-fb by subtracting the offsets
04:49 PM seb_kuzminsky: so index homing works because it changes the joint-pos-cmd and the homing offset simultaneously, so the joint-pos-fb gets the matching offset and ferror stays small
04:50 PM seb_kuzminsky: so now i'm back to not understanding why tom's machine ferrors on home
04:59 PM pcw_mesa: My guess is that index causes a step in the FB position _and_ commanded position but the stepgen
04:59 PM pcw_mesa: (which is not looking at the FB position) makes a crazy move to accommodate the position step
04:59 PM pcw_mesa: causing a large glitch in the feedback position
04:59 PM pcw_mesa: (the position step needs to be ignored but the stepgen has no way to deal with this)
05:04 PM pcw_mesa: That is, on a normal servo system with encoder feedback, index detection causes a step in encoder position and commanded position
05:04 PM pcw_mesa: but no change in motion is desired so there are patches in PID and motion to cope with the step, but the stepgen has no way of dealing
05:04 PM pcw_mesa: properly with index
05:10 PM seb_kuzminsky: i believe index causes a step in the encoder's .position-fb (it goes to 0) and a step in axis.2.joint-pos-cmd (it goes to [AXIS_2]HOME_OFFSET, which is 0)
05:12 PM seb_kuzminsky: it also updates Motion's internal version of axis.2.motor-offset
05:12 PM seb_kuzminsky: but i believe that index does not cause a step in axis.2.motor-pos-cmd, because .motor-pos-cmd is computef from .joint-pos-cmd by adding that motor/home offset
05:13 PM seb_kuzminsky: i expect that .motor-pos-cmd is continuous (smooth) across all stages of index homing, because Motion makes it so
05:23 PM seb_kuzminsky: but i am forever surprised by the details of linuxcnc's behavior
05:25 PM seb_kuzminsky: the hackspace shopbot has steppers with encoders, but no index channel
05:31 PM jepler: seb_kuzminsky: I'm going to bounce the forum, the last update included a kernel update for security bugs (not remotely relevant)
05:32 PM seb_kuzminsky: ok
05:54 PM jepler: bounce bounce
06:45 PM pcw_mesa: seb_kuzminsky: i dont see how the position command could be continuous, because if it does not match the encoder
06:45 PM pcw_mesa: feedback (which does have a step) , you will have a (up to1 turn) thump
07:03 PM pcw_mesa: actually the thump can be as big as the homing move to index because at startup the encoder is cleared so the encoder count
07:03 PM pcw_mesa: will accumulate during the homing move and then be cleared by index
07:15 PM jepler: (and it doesn't "repeat" during a single session because the next index-reset doesn't change the counts by much if at all)
07:17 PM pcw_mesa: right, it resets the count at '0'
07:29 PM seb_kuzminsky: the motor command doesn't care what the encoder says
07:29 PM seb_kuzminsky: Motion tells the motor where it should go to in smooth "motor coordinates"
07:30 PM seb_kuzminsky: the motor tells Motion where it is (for stepgen this is the position accumulator, for servos it's the encoder, including any index reset)
07:30 PM seb_kuzminsky: inside Motion, there's a layer of abstraction between "motor coordinates" and "joint coordinates"
07:31 PM seb_kuzminsky: Motion thinks in terms of joint coordinates, and converts to motor coordinates at the last possible second
07:31 PM seb_kuzminsky: pcw_mesa: i said some things to you without realizing you weren't here
07:32 PM seb_kuzminsky: pcw_mesa: also inside Motion there are two offsets, that define the difference between motor coordinates and joint coordinates: the home offset and the backlash-compensation offset
07:32 PM seb_kuzminsky: when the machine is unhomed, the home offset is zero and screw comp is not used (because Motion doesn't know where on the screw it is)
07:33 PM seb_kuzminsky: as the machine homes, Motion moves the joint pos cmd in the direction of HOME_SEARCH_VEL, and motor-pos-cmd tracks it with no offset
07:34 PM seb_kuzminsky: when the joint steps on the home homes, Motion learns the home offset, this is the difference between motor coordinates and joint coordinates
07:34 PM seb_kuzminsky: note that joint coordinates are meaningful, they correspond to the machine's work space
07:34 PM seb_kuzminsky: while motor coordinates are relatively meaningless, because they start at 0 when the machine turns on
07:34 PM seb_kuzminsky: so Motion thinks in terms of joint coords
07:35 PM seb_kuzminsky: ferror = joint-pos-cmd - joint-pos-fb
07:35 PM seb_kuzminsky: motor-pos-cmd = joint-pos-cmd - home_offset
07:35 PM seb_kuzminsky: joint-pos-fb = motor-pos-fb + home_offset
07:36 PM seb_kuzminsky: and that's how motor-pos-cmd is smooth: when homing completes, home_offset goes from 0.0 to whatever the motor-pos-cmd was when homing completed, and joint-pos-cmd goes to HOME_OFFSET
07:36 PM seb_kuzminsky: and since home_offset is subtracted from joint-pos-cmd from then on, it washes out
07:36 PM seb_kuzminsky: bbl dinner!
07:36 PM pcw_mesa: right, but if you look at Toms latest (zoomed) plot you can see that both the encoder position and motor position are rest to 0 on index
07:36 PM pcw_mesa: s/rest/reset
07:37 PM pcw_mesa: (the stepgen position command is netted to motor-pos-cmd in hal)
08:08 PM seb_kuzminsky: i see what you mean
08:08 PM seb_kuzminsky: that is surprising to me
08:09 PM seb_kuzminsky: (tangentially, it makes me nervous how the index comes nearly at the same time as the second trip of the home switch)
08:10 PM seb_kuzminsky: notice how, when the home switch trips the first time, the joint-pos-cmd and the motor-offset both jump
08:10 PM seb_kuzminsky: that's the "coarse" home offset, which happens as soon as Motion has any idea at all of where it is
08:11 PM seb_kuzminsky: then it refines the home offset through the (optional) later stages of homing, as shown later in the plot
08:12 PM seb_kuzminsky: it's a little hard to tell, but both joint-pos-cmd and joint-pos-fb jump by the exact same amount as motor-offset
08:12 PM seb_kuzminsky: (motor-offset) is home_offset + screw_comp
08:13 PM seb_kuzminsky: the motor-offset jump must be the difference between where the home switch trips and where the index happens, it returns to its old value when the index reset happens
08:16 PM seb_kuzminsky: i'm going to home my servo bridgeport and see what that looks like
08:16 PM pcw_mesa: yeah there are a lot more details than I expected
08:16 PM pcw_mesa: It has indexed homing?
08:16 PM seb_kuzminsky: yeah
08:17 PM seb_kuzminsky: it looks like Tom's motor-offset changes by 0.003, isn't that about what his ferror max is?
08:19 PM seb_kuzminsky: it's hard to tell what his ferror changes by
08:19 PM pcw_mesa: looks like 0.005
08:19 PM pcw_mesa: ferror limit
08:19 PM seb_kuzminsky: :-(
08:20 PM pcw_mesa: looks like the error spike is 1.2 mills or so
08:23 PM pcw_mesa: min ferror is 0.001 so that could be close to tripping
08:25 PM pcw_mesa: since the index search velocity is probably a small fraction of the rapids velocity
08:28 PM seb_kuzminsky: oh, hah, except my machine doesn't ferror when homing, so i shouldn't trigger on that...
08:30 PM pcw_mesa: Yeah the PID loop doesn't really care if you change its command and feedback simultaneously
08:30 PM pcw_mesa: (except some minor side effects that are patched around)
08:32 PM pcw_mesa: bbl dinner!
08:35 PM seb_kuzminsky: i wish it was easy to tell halscope to allocate more memory for its signal storage
08:41 PM seb_kuzminsky: http://highlab.com/~seb/linuxcnc/rehoming-z.png
08:41 PM seb_kuzminsky: on my machine, motor-pos-cmd goes to pid->pwmgen, and motor-pos-fb comes from the encoder (all through mesa)
08:45 PM seb_kuzminsky: http://highlab.com/~seb/linuxcnc/homing-x-first-time.png
08:46 PM seb_kuzminsky: and that shows that pcw_mesa is right and i'm wrong about continuous motor-pos-cmd
08:49 PM pcw_mesa: I think requiring a step in the commanded position is unavoidable if you clear the position on index
08:54 PM jepler: --no-no-kernel opposite of --no-kernel
08:55 PM seb_kuzminsky: pcw_mesa: isn't that handled by the internal offset? .motor-offset
08:56 PM seb_kuzminsky: .joint-pos-cmd and .joint-pos-fb have to jump to get to the home switch, sure, but .motor-pos-cmd doesn't,
08:56 PM seb_kuzminsky: eh, i'm going crazy here, i'm just going to drill my holes and finish this part
09:39 PM jepler: a good first step: a live image bootable in qemu that gives a preempt kernel https://emergent.unpythonic.net/files/sandbox/stretch-live-rtpreempt.png
09:39 PM jepler: now I have to figure out how to add packages from wlo
09:42 PM jepler: > lwr -t live-task-xfce -e "linux-image-rt-amd64 linux-headers-rt-amd64"
09:49 PM seb_kuzminsky: whaa!!! that's awesome!
10:30 PM jepler: The following packages have unmet dependencies:
10:30 PM jepler: linuxcnc-uspace : Depends: libboost-python1.55.0 but it is not installable
10:31 PM jepler: apparently just blindly installing the jessie debs on a fresh stretch isn't going to fly
10:32 PM jepler: I'm not excited to frankendistro it and pull in jessie packages :-/
10:32 PM jepler: goodnight