Back
[06:55:18] <alex_jon1> alex_jon1 is now known as alex_joni
[07:32:23] <micges_work> alex_joni: do you know any bad thing that can be on servo system(pid + pwm + mesa, 1Khz servo-thread) if I have huge (>1000%) "realtime delay" ?
[07:32:48] <micges_work> i can think only about some small ferror on that time, nothing more
[07:50:16] <alex_joni> hmm.. maybe it'll start to oscilate
[07:52:30] <micges_work> I'm masking all rt error, but I had osscilation that often I didn't know from where they from..
[07:52:55] <micges_work> rt realtime delay errors
[07:53:54] <alex_joni> I would expect PID running at non-periodic times to cause oscillations
[07:57:17] <micges_work> I will check time and tmax of PID on ossciloscope, then it should show some ticks
[08:11:48] <alex_joni> maybe set a pin high on each servo thread
[08:12:02] <alex_joni> add a watchdog component to the servo thread
[08:12:14] <alex_joni> and use a real oscilloscope, and see how the pulses look
[08:13:24] <micges_work> oh cool idea, thanks
[13:31:24] <CIA-41> EMC: 03micges 07joints_axes3 * r7702eabcbcd6 10/src/emc/usr_intf/axis/scripts/axis.py: Read proper homed joints values in Axis preview
[13:50:37] <CIA-41> EMC: 03micges 07joints_axes3 * r211c1ed3c0ef 10/src/emc/usr_intf/axis/scripts/axis.py: get proper joints count and fix Machine->Homing and Unhoming menu
[14:53:06] <cradek> F (output) -overflow -will be true when the count rolls over from 9999 to 0.
[14:53:18] <cradek> I can't help but wonder why CL counters only count to 9999
[15:05:30] <skunkworks823> heh - because who would need to count over 9999? ;)
[15:05:38] <skunkworks823> what are you keeping track of?
[15:06:33] <cradek> carousel position
[15:08:21] <skunkworks823> sounds like you are almost there. :)
[15:08:40] <cradek> if not for throwing the tool, it would be done
[15:09:03] <jepler> maybe you thought of this already, but the testing will be a lot less expensive if you don't actually put a tool in the holder until it's right..
[15:09:16] <cradek> jepler: heh, yeah, I thought of that
[15:09:24] <cradek> it's actually a holder thrower, not a tool thrower
[15:09:34] <cradek> (and the holders cost more than the tools...)
[15:15:58] <skunkworks823> umm - what happened? The thrower actually threw the tool?
[15:32:49] <skunkworks823> logger_dev: bookmark
[15:32:49] <skunkworks823> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-08-10.txt
[16:04:41] <micges> jepler: you didn't mind if I create axis_cleanup branch to make simmilar work that task_cleanup for ja3?
[16:05:15] <micges> (for Axis gui)
[16:05:59] <jepler> what are you planning to do/change?
[16:08:38] <micges> axis configuration cleanup and refactoring things while doing ja3 (you must admit that it is mess out there)
[16:10:40] <jepler> you can put what you like on a branch, but let's talk before merging that branch to master
[16:11:31] <cradek> also, if it's not part of ja work, don't put it on ja3
[16:11:39] <micges> sure
[16:11:47] <micges> that why I'm asking
[16:19:00] <micges> cradek: cleanup like refactoring existing implementation
[16:23:18] <micges> cradek: why you asking?
[16:23:28] <cradek> curious
[16:24:56] <cradek> my feelings are this: it badly needs a cleanup, but it is currently working, but cleanups introduce bugs and make merges not work, but wouldn't it be nice if it was cleaner?
[16:25:14] <cradek> so I'm conflicted, as you can see :-)
[16:26:02] <jepler> (I think I missed a line or two during the netsplit)
[16:26:23] <cradek> micges> cradek: cleanup like refactoring existing implementation
[16:27:10] <jepler> as I see it, you should refactor code if you want to immediately fix a bug or add a new feature that is made easier by the earlier refactoring
[16:27:32] <jepler> and you should be careful not to get "write different code that I prefer" for actual refactoring, which has a specific meaning
[16:32:59] <micges> I have idea to make diffenrent tool changers implement in M6.py that can be called, but framework to define M codes < 100 must be written => canon<->interp interface must be rething to not rewrite once again on adding definable G codes
[16:37:10] <micges> I have few ideas like this that require some refactoring of code
[16:38:54] <micges> bbl
[16:40:38] <jepler> then implement your idea as a series of refactors followed by the implementation (i.e., multiple commits), then we can talk about the thing as a whole.
http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_topic_branches
[16:40:55] <jepler> particularly when we can see the new thing that is more easily built on the reorganized code, we can understand whether the reorganization is worth it
[16:41:01] <jepler> otherwise it's just change for the sake of change
[16:44:18] <jepler> (oh cool -- hardy *does* have a prepackaged python gtk opengl widget)
[16:46:14] <CIA-41> EMC: 03jepler 07master * rfbea86011924 10/src/ (hal/hal.h hal/hal_priv.h rtapi/rtapi.h): this formulation is nicer than repeated #ifs at the beginning and end of the header
[16:46:15] <CIA-41> EMC: 03jepler 07master * r206fe158bb3a 10/src/rtapi/rtapi.h: improve documentation
[16:46:18] <CIA-41> EMC: 03jepler 07master * rd26eb9508bf4 10/src/hal/hal_lib.c: clarify error message
[16:46:30] <jepler> speaking of change for its own sake :-/
[18:04:08] <jepler> cradek: hm, despite what I said, hal_manualtoolchange is sort-of level triggered
[18:04:31] <jepler> it's triggered on the high state of 'change' but only when its 'changed' output is not asserted
[18:08:14] <cradek> I bet the problem here is it almost always works fine to do it totally wrong
[18:11:44] <BJT-Work> cradek: I gotta remember that one.
[18:12:54] <cradek> I think in this case it's very true
[18:13:18] <cradek> I wasn't trying to be silly at all
[18:13:42] <BJT-Work> I don't think it is silly
[19:17:51] <cradek> hi!
[19:20:02] <mozmck> hi! just got back in. I'll try and sort some stuff out and send you some pictures in a little while.
[19:20:14] <cradek> ok, cool