Back
[00:24:00] <CIA-40> EMC: 03cradek 07master * r4cd54b3e7c45 10/src/emc/usr_intf/touchy/touchy.py: I'm usually against this, but in this case...
[03:06:17] <cradek> count, position, and index-enable all clear on the same servo cycle
[03:06:30] <cradek> ?
[03:06:47] <cradek> jepler: ^ I finally plotted the Z homing thump, but it all looks fine to me
[03:07:09] <cradek> http://timeguy.com/cradek-files/emc/z-homing-thump.png
[03:12:44] <cradek> new image at the same url
[03:12:58] <cradek> you can see a full-scale pid output for one servo cycle (no wonder it thumps)
[03:13:05] <cradek> but why? I don't understand it.
[03:15:23] <cradek> servo thread order is hm2 read, motion-command-handler, motion-controller, pid, ..., hm2 write, ..., scope.sample
[05:14:46] <cradek> logger_dev: bookmark
[05:14:46] <cradek> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-11-15.txt
[05:16:07] <cradek> seb_kuzminsky: ^^ right before you showed up, I was talking about another oddity on my machine: it bangs at index reset time. Z is by far the worst, but I'm pretty sure all three do it. You can see it in the halscope plot.
[05:17:11] <cradek> may be a question more for jmkasunich though - I don't see a hm2 problem - count resets at the right time.
[05:17:25] <seb_kuzminsky> thump, eh?
[05:17:34] <cradek> yeah quite
[05:17:49] <cradek> it's done it since day 1, I've just tried to ignore it
[05:18:06] <seb_kuzminsky> what's purple channel 4 in that plot?
[05:18:13] <seb_kuzminsky> position?
[05:18:29] <cradek> yes
[05:19:10] <seb_kuzminsky> hm, the hm2 signals look ok as far as i understand what they're supposed to do, but i've been wrong about that before
[05:19:16] <cradek> position/pid rings for a while and then settles and it's fine, but for this one period it's nasty
[05:20:06] <cradek> I'm pretty sure the hm2 stuff looks right. I think my thread is ordered correctly too - if both are true, there must be a bug elsewhere
[05:20:45] <seb_kuzminsky> bummer
[05:21:04] <cradek> nah - part of the job of this machine is to flush out bugs
[05:21:33] <seb_kuzminsky> heh
[05:21:42] <seb_kuzminsky> i thought it was to turn out parts ;-)
[05:25:10] <cradek> I wonder if it's pid FF1 freaking out
[05:25:26] <cradek> *(pid->cmd_d) = (*(pid->command) - pid->prev_cmd) * periodrecip
[05:26:04] <cradek> output = ... + *(pid->cmd_d) * *(pid->ff1gain) + ...
[05:33:09] <cradek> yeah I think servo_sim thumps too
[05:34:44] <cradek> seems like when motion steps motor-pos-cmd, pid needs to step pid->prev_cmd the same amount to avoid the problem
[09:05:04] <micges1> micges1 is now known as micges
[14:16:09] <jepler> cradek: FF1.
[14:16:28] <jepler> think about what it'll do when there's a step change!
[14:20:11] <jepler> screenshots from servo-sim:
http://emergent.unpy.net/files/sandbox/homing-index-ff1.png http://emergent.unpy.net/files/sandbox/homing-index-noff1.png
[15:23:12] <cradek> jepler: same conclusion I came to - but what's the fix?
[15:32:53] <jepler> cradek: oh yeah, now that I read the whole screen I see that
[15:32:58] <jepler> cradek: teach PID a heuristic to detect step changes?
[15:33:15] <jepler> how bad's the tuning without FF1?
[15:37:15] <alex_joni> switch to ff1 tuning after homing?
[15:47:24] <cradek> jepler: I think it would not be possible to tune otherwise - it's velocity mode
[15:48:41] <cradek> if index-enable also hooked to pid, pid would know on falling edge that ff1 is going to be wrong. maybe it could just use last period's value for that period.
[15:49:04] <cradek> I guess ff2 is also going to be wrong, and that's going to polluted for the next period too
[15:49:33] <cradek> I am not using FF2
[15:50:04] <cradek> my tuning for Z is P=20 D=0.1 FF1=1
[15:52:16] <cradek> maybe I will try making (something like) that change
[15:53:00] <cradek> index search is slow and I bet it's a fair assumption that velocity is not changing when the index is found
[16:03:40] <CIA-40> EMC: 03jepler 07master * r99bc40cde201 10/configs/sim/servo_sim.hal: Revert "hook up high-resolution probe signals"
[16:03:42] <CIA-40> EMC: 03jepler 07master * rfed2a416dfe0 10/src/hal/utils/scope_disp.c: try several ways to position the trace label so it is visible
[16:03:42] <CIA-40> EMC: 03jepler 07master * rbc96fafe6163 10/src/hal/utils/scope_disp.c: account for height of label when deciding placement
[16:03:43] <CIA-40> EMC: 03jepler 07master * r592686365c5b 10/src/hal/utils/scope_disp.c: don't draw labels when drawing for selection
[16:03:45] <CIA-40> EMC: 03jepler 07master * r1938a7399c92 10/src/hal/utils/scope_disp.c: try to place trace labels so they do not overlap
[16:05:20] <cradek> wow those changes look great
[16:06:33] <cradek> bbl
[16:07:09] <jepler> I hope they're right
[16:07:22] <jepler> if they lead to a very subtle crash, dgarr will find it for me eventually
[16:25:23] <skunkworks> high resolution probing on hold?
[16:29:56] <jepler> yeah, there was a problem that faliled to solve
[17:09:06] <jepler> cradek: you can use maxcmdD to limit the contribution of FF1 to the normal operating range
[17:34:42] <pcw_home> cradek: We do what you suggested for FF1 and D with SoftDMC (use last values for sample after home detect)
[17:34:44] <pcw_home> and it seems to work (sails by home with no thump) maybe not the most elegant solution
[17:34:45] <pcw_home> but works ok
[22:23:21] <cradek> I can think of two solutions: feeding pid index-enable so it can watch for falling edge, or feeding pid joint-vel-cmd for it to use to make D, FF* instead of using internal ddt
[22:25:39] <SWPadnos> is there a PID-hold input (not disable, which I would guess zeroes out the accumulators)
[23:53:35] <jt-plasma> I've made some changes to thc and can't find my error
http://pastebin.ca/1672770 it keeps saying something about thc_ud which I don't even have anymore
[23:53:48] <jt-plasma> when I try and run the config
[23:54:16] <jt-plasma> I've did a make clean several times...
[23:54:38] <jt-plasma> I'm missing something :/
[23:55:53] <jepler> it's failing to unload the kernel modules from the previous run
[23:56:02] <jepler> it will only unload a name that corresponds to a module it can find in a specific directory
[23:56:08] <jt-plasma> do I need to reboot
[23:56:23] <jepler> if you had a problem like a component that had a name that didn't match its kernel module name, then it might do that
[23:56:40] <jepler> a reboot will unload the module, so would a sudo rmmod.
[23:56:48] <jt-plasma> ok thanks
[23:56:50] <jepler> but you also want to make sure the "component xxx;" declaration matches the name of the .comp file
[23:56:59] <jepler> so that you don't just get the error again on the next reboot
[23:57:03] <jt-plasma> that was my first error
[23:57:47] <jt-plasma> I changed the name of a component but forgot to change the component... on the first line
