Back
[00:01:05] <psha> in gladevcp gremlin load will be called not from realize but from periodic handler so it have with_context
[00:04:33] <psha> sleep time here, bbl :)
[09:23:18] <Bonny> Hello... Need help to compile GIT patch..
[13:51:50] <CIA-41> EMC: 03jepler 07master * rcfbc31234dd9 10/configs/motenc/motenc_motion.hal: motenc: hook up pid.#.index-enables
[14:20:11] <CIA-41> EMC: 03jepler 07master * re01c51ad4b88 10/ (lib/python/glnav.py src/emc/usr_intf/axis/scripts/axis.py): axis: Move setup code for set_view_x to GlNavBase
[14:20:21] <CIA-41> EMC: 03jepler 07master * rdeb85138e319 10/ (lib/python/glnav.py src/emc/usr_intf/axis/scripts/axis.py): Merge remote branch 'psha/gremlin-fix'
[14:54:16] <jepler> For some reason I found myself reading an appnote on a PID implementation for AVR.
http://www.atmel.com/dyn/resources/prod_documents/doc2558.pdf
[14:54:25] <jepler> on page 7 they do something weird
[14:54:45] <jepler> "To avoid that changes in the desired process value makes any unwanted rapid changes in the control output, the controller is improved by basing the derivative term on the process value only"
[14:55:20] <jepler> that is, the Dgain is multiplied not by the derivative of error, but by the derivative of feedback only
[14:55:40] <cradek> huh - that's really not the same thing at all
[14:56:04] <jepler> it seems a bit like the opposite of FF1
[14:57:20] <jepler> their only graphs are of "step" commands, so derivative of error will have nasty glitches in it at every step change
[14:57:53] <SWPadnos> every command (in emc) is a step change, since we evaluate in discrete time
[14:58:00] <jepler> well, sure
[14:58:36] <SWPadnos> it makes some sense to base D on feedback only, since you might want to damp more or less based on slew rate
[14:59:18] <jepler> but if your command is conceptually always a step (not just because it's discrete PID) then using derivative-of-feedback for the "D" term makes sense
[14:59:27] <jepler> it masks out the glitch that happens at each step
[14:59:33] <jepler> and is the same as the derivative of error at other times
[15:00:53] <SWPadnos> likely with opposite sign
[15:01:07] <SWPadnos> err, maybe not. time for more coffee
[19:01:51] <andypugh> Has anyone been bored enough to ponder why I can't make the docs for the gearchange comp?
[19:08:56] <CIA-41> EMC: 03jepler 07master * r0e92bb4f4cd7 10/src/hal/utils/comp.g: comp: fix failure to build documentation
[19:09:10] <jepler> andypugh: I missed hearing about the problem, but I think that ^^ fixes it
[19:10:01] <andypugh> Ah, not something wrong in my code then? That might explain why I can't see a culprit.
[19:13:13] <andypugh> Having read the patch, I am even more puzzled, as I had deleted all +1 parts as I thought that looked like an obvious suspect (and matched the error message, a bit). Or is it a generic problem with any personality in parameters?
[19:13:23] <jepler> yes, I believe so
[19:13:53] <andypugh> (I guess I should just checkout master, pull and rebase to see rather than speculating?)
[19:14:15] <jepler> I didn't actually try your gearchange.comp after my fix..
[19:40:14] <psha> jepler: it was late yesterday so i had to go
[19:40:38] <psha> i've not added with_context to load function since in current gremlin it's useless (and maybe harmful)
[19:40:57] <psha> also i think that time.sleep(0.02) is not good for idle function
[19:41:44] <jepler> probably not
[19:42:49] <psha> i've played a bit with async timeout add in idle but surely i need to read glib docs about idle more :0
[19:42:52] <psha> :)
[20:26:01] <andypugh> jepler: That patch does seem to overcome my problem.
[20:53:09] <CIA-41> EMC: 03cradek 07master * r155171ceadcb 10/ (6 files in 5 dirs): Added command LOGAPPEND to append to log file
[20:54:40] <psha> cradek: congrats to bonny :) he's last version was not bad :)
[22:10:30] <micges> anyone remember what I must change to get more verbose output from emcmot?
[22:11:04] <micges> there is somewhere system file that holds rtpai print log level
[22:11:20] <cradek> somewhere in /proc
[22:16:05] <andypugh> Is there now?
[22:17:10] <SWPadnos> /proc/rtapi and /proc/hal should both exist, I think
[22:17:19] <micges> weird:
http://pastebin.com/BpwrJ1e1
[22:17:21] <SWPadnos> (as long as EMC is running)
[22:18:18] <micges> to increase debug level you must: 'echo 4 > /proc/rtapi/debug'
[22:18:20] <andypugh> micges: Ah, the much lover vector 14
[22:18:49] <micges> yep
[22:19:07] <jepler> if the hal kernel modules are still loaded, you may be able to find the source line number of the fault. see docs/rtfaults.txt.
[22:22:21] <micges> jepler: thanks
[22:43:12] <micges> jepler: if addr2line returns '??:0' it means that no debug symbols was added?
[22:45:10] <jepler> micges: yes.
[22:45:19] <jepler> so unfortunately you'll have to rebuild with debugging and then recreate the problem :(
[22:45:31] <micges> I've done that twice
[22:45:59] <micges> both places that I could add the -g flag seems doesn't work
[22:46:18] <jepler> need to make clean as well
[22:46:25] <jepler> not sure what else might be necessary, I've only done this a tiny bit myself
[22:46:45] <micges> I've done that too
[22:47:09] <micges> thanks anyway, I'll be trying
[22:47:21] <jepler> ubuntu 10.04 or other system?
[22:47:45] <micges> 10.04
[22:47:56] <jepler> that's what I tested on..
[22:48:33] <micges> it's quite late here, so I'll redone test again
[22:50:02] <jepler> if the offset is big it could mean you guessed the wrong component, I think addr2line will give ?? for that too
[22:50:20] <jepler> anyway, goodnight
[22:50:44] <micges> not yet :)
[22:53:14] <micges> ok it works
[22:59:20] <jepler> :qa
[22:59:23] <jepler> argh you are not vi
[23:02:44] <micges> bug seems to be in locking rotary code :|
[23:05:23] <micges> yep
[23:07:47] <cradek> uh-oh
[23:11:01] <micges> vector 14 shows up on line 281 on command.c
[23:12:39] <micges> I've added debug above and it seems that somewhere it tried to set joint 0 pin , even if there are only pins on joints 3 to 5
[23:12:48] <micges> (more less)
[23:13:20] <cradek> line 281 is SET_JOINT_HOMED_FLAG(...) - how is that related to locking rotary?
[23:13:51] <cradek> or do you have a different line 281
[23:16:14] <micges> joints_axes3 branch
[23:16:35] <cradek> ah
[23:20:07] <jepler> void emcmotSetRotaryUnlock(int axis, int unlock) {
[23:20:07] <jepler> *(emcmot_hal_data->joint[axis].unlock) = unlock;
[23:20:09] <jepler> }
[23:20:19] <jepler> for me the middle line is line 281
[23:20:42] <micges> yep
[23:23:42] <jepler> unfortunately you don't know what the caller of that function is, there seem to be some in homing and in tp
[23:23:47] <jepler> but the action you were doing should tell you which it is
[23:24:15] <micges> tp
[23:24:40] <micges> [16852.030874] 69847: CMD 154, code 17 SET_LINE
[23:27:42] <jepler> unless you have a locking rotary on purpose, I guess you need to try to determine why tc->indexrotary is not -1
[23:28:00] <micges> jepler: seems to me that rotary code is not prepared to ja3 changes in emcmot
[23:32:56] <micges> jepler: thanks for pointer, I think I've got it
[23:35:40] <ries_> ries_ is now known as ries
[23:37:30] <jepler> micges: excellent
[23:37:35] <jepler> and I'll say goodnight again..
[23:38:09] <micges> good night