alex_jon1 is now known as alex_joni
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" ?
i can think only about some small ferror on that time, nothing more
hmm.. maybe it'll start to oscilate
I'm masking all rt error, but I had osscilation that often I didn't know from where they from..
rt realtime delay errors
I would expect PID running at non-periodic times to cause oscillations
I will check time and tmax of PID on ossciloscope, then it should show some ticks
maybe set a pin high on each servo thread
add a watchdog component to the servo thread
and use a real oscilloscope, and see how the pulses look
oh cool idea, thanks
EMC: 03micges 07joints_axes3 * r7702eabcbcd6 10/src/emc/usr_intf/axis/scripts/axis.py: Read proper homed joints values in Axis preview
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
F (output) -overflow -will be true when the count rolls over from 9999 to 0.
I can't help but wonder why CL counters only count to 9999
heh - because who would need to count over 9999? ;)
what are you keeping track of?
sounds like you are almost there. :)
if not for throwing the tool, it would be done
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..
jepler: heh, yeah, I thought of that
it's actually a holder thrower, not a tool thrower
(and the holders cost more than the tools...)
umm - what happened? The thrower actually threw the tool?
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-08-10.txt
jepler: you didn't mind if I create axis_cleanup branch to make simmilar work that task_cleanup for ja3?
(for Axis gui)
what are you planning to do/change?
axis configuration cleanup and refactoring things while doing ja3 (you must admit that it is mess out there)
you can put what you like on a branch, but let's talk before merging that branch to master
also, if it's not part of ja work, don't put it on ja3
that why I'm asking
cradek: cleanup like refactoring existing implementation
cradek: why you asking?
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?
so I'm conflicted, as you can see :-)
(I think I missed a line or two during the netsplit)
micges> cradek: cleanup like refactoring existing implementation
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
and you should be careful not to get "write different code that I prefer" for actual refactoring, which has a specific meaning
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
I have few ideas like this that require some refactoring of code
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
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
otherwise it's just change for the sake of change
(oh cool -- hardy *does* have a prepackaged python gtk opengl widget)
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
EMC: 03jepler 07master * r206fe158bb3a 10/src/rtapi/rtapi.h: improve documentation
EMC: 03jepler 07master * rd26eb9508bf4 10/src/hal/hal_lib.c: clarify error message
speaking of change for its own sake :-/
cradek: hm, despite what I said, hal_manualtoolchange is sort-of level triggered
it's triggered on the high state of 'change' but only when its 'changed' output is not asserted
I bet the problem here is it almost always works fine to do it totally wrong
cradek: I gotta remember that one.
I think in this case it's very true
I wasn't trying to be silly at all
I don't think it is silly
hi! just got back in. I'll try and sort some stuff out and send you some pictures in a little while.