EMC: 03cradek 07master * r4cd54b3e7c45 10/src/emc/usr_intf/touchy/touchy.py: I'm usually against this, but in this case...
count, position, and index-enable all clear on the same servo cycle
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
new image at the same url
you can see a full-scale pid output for one servo cycle (no wonder it thumps)
but why? I don't understand it.
servo thread order is hm2 read, motion-command-handler, motion-controller, pid, ..., hm2 write, ..., scope.sample
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-11-15.txt
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.
may be a question more for jmkasunich though - I don't see a hm2 problem - count resets at the right time.
it's done it since day 1, I've just tried to ignore it
what's purple channel 4 in that plot?
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
position/pid rings for a while and then settles and it's fine, but for this one period it's nasty
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
nah - part of the job of this machine is to flush out bugs
i thought it was to turn out parts ;-)
I wonder if it's pid FF1 freaking out
*(pid->cmd_d) = (*(pid->command) - pid->prev_cmd) * periodrecip
output = ... + *(pid->cmd_d) * *(pid->ff1gain) + ...
yeah I think servo_sim thumps too
seems like when motion steps motor-pos-cmd, pid needs to step pid->prev_cmd the same amount to avoid the problem
micges1 is now known as micges
think about what it'll do when there's a step change!
screenshots from servo-sim: http://emergent.unpy.net/files/sandbox/homing-index-ff1.png http://emergent.unpy.net/files/sandbox/homing-index-noff1.png
jepler: same conclusion I came to - but what's the fix?
cradek: oh yeah, now that I read the whole screen I see that
cradek: teach PID a heuristic to detect step changes?
how bad's the tuning without FF1?
switch to ff1 tuning after homing?
jepler: I think it would not be possible to tune otherwise - it's velocity mode
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.
I guess ff2 is also going to be wrong, and that's going to polluted for the next period too
I am not using FF2
my tuning for Z is P=20 D=0.1 FF1=1
maybe I will try making (something like) that change
index search is slow and I bet it's a fair assumption that velocity is not changing when the index is found
EMC: 03jepler 07master * r99bc40cde201 10/configs/sim/servo_sim.hal: Revert "hook up high-resolution probe signals"
EMC: 03jepler 07master * rfed2a416dfe0 10/src/hal/utils/scope_disp.c: try several ways to position the trace label so it is visible
EMC: 03jepler 07master * rbc96fafe6163 10/src/hal/utils/scope_disp.c: account for height of label when deciding placement
EMC: 03jepler 07master * r592686365c5b 10/src/hal/utils/scope_disp.c: don't draw labels when drawing for selection
EMC: 03jepler 07master * r1938a7399c92 10/src/hal/utils/scope_disp.c: try to place trace labels so they do not overlap
wow those changes look great
I hope they're right
if they lead to a very subtle crash, dgarr will find it for me eventually
high resolution probing on hold?
yeah, there was a problem that faliled to solve
cradek: you can use maxcmdD to limit the contribution of FF1 to the normal operating range
cradek: We do what you suggested for FF1 and D with SoftDMC (use last values for sample after home detect)
and it seems to work (sails by home with no thump) maybe not the most elegant solution
but works ok
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
is there a PID-hold input (not disable, which I would guess zeroes out the accumulators)
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
when I try and run the config
I've did a make clean several times...
I'm missing something :/
it's failing to unload the kernel modules from the previous run
it will only unload a name that corresponds to a module it can find in a specific directory
do I need to reboot
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
a reboot will unload the module, so would a sudo rmmod.
but you also want to make sure the "component xxx;" declaration matches the name of the .comp file
so that you don't just get the error again on the next reboot
that was my first error
I changed the name of a component but forgot to change the component... on the first line