Back
[00:25:17] <CIA-15> EMC: 03alex_joni 07TRUNK * 10emc2/src/hal/drivers/mesa7i43-firmware/.cvsignore: silence on autogenerated headers
[01:30:13] <CIA-15> EMC: 03alex_joni 07v2_2_branch * 10emc2/src/emc/task/emctaskmain.cc: attempt to fix #1853953 - M66 fails to respond to hardware inputs
[01:30:43] <cradek> uh attempt?
[01:31:08] <alex_joni> cradek: no testing?
[01:31:39] <cradek> oh I see it's simple, sorry
[01:31:46] <cradek> but you misspelled if(boolean)
[01:32:11] <alex_joni> ?
[01:32:49] <jmkasunich> the != 0 is redundant
[01:32:49] <alex_joni> you mean the "!= 0" part ?
[01:32:58] <alex_joni> I read it easier like that
[01:32:59] <jmkasunich> if (emcStatus->motion.synch_di[emcAuxInputWaitIndex]) {
[01:33:30] <cradek> right
[01:34:00] <alex_joni> anyone got a TRUNK with parport and a spare input?
[01:34:01] <cradek> * cradek points vigorously at style guides etc etc
[01:34:10] <jmkasunich> so - is bigjohn running from CVS?
[01:34:17] <alex_joni> nope, 2.2.2
[01:34:35] <jmkasunich> well, how are we gonna get the fix to him?
[01:34:41] <cradek> 2.2.3
[01:34:49] <jmkasunich> (IMO it is sufficiently simple that he can be the only tester we need)
[01:35:28] <jmkasunich> oh - I just thought of a workaround that might work for him in the meantime
[01:35:34] <jmkasunich> lemme check something first
[01:35:45] <cradek> I'm very bothered by one of ==0 and !=0 working. it's a booby trap encouraging someone to write the wrong one
[01:36:09] <jmkasunich> huh?
[01:36:09] <cradek> IMO the only correct way is if(boolean) vs if(!boolean)
[01:36:19] <alex_joni> juve@taurus:~/emc2.TRUNK/src$ less CodingStyle | grep -e "!= 0"
[01:36:19] <alex_joni> e.g. if (spindle_speed != 0) NOT if (spindle_speed)
[01:36:41] <cradek> but that's a float
[01:36:56] <jmkasunich> alex_joni: in that case, the variable isn't a boolean - it is an int (or float) and the coder is being clever/lazy
[01:37:01] <alex_joni> dang, though you wouldn't notice
[01:37:14] <alex_joni> thought even
[01:37:17] <cradek> heh
[01:37:26] <cradek> we're pretty sharp (sometimes)
[01:37:29] <jmkasunich> I just found another bool bug
[01:37:48] <jmkasunich> from and2.comp: FUNCTION(_) { out = in0 && in1; }
[01:37:59] <jmkasunich> bzzzzt!
[01:38:10] <jmkasunich> oh, no, thats fine
[01:38:10] <cradek> but ... that's right
[01:38:13] <jmkasunich> its &&, not &
[01:38:14] <alex_joni> it's &&
[01:38:22] <jmkasunich> ok, so my workaround will work
[01:38:41] <jmkasunich> run the parport signal thru an and gate on the way to motion, to "normalize" it
[01:38:59] <cradek> yes it will
[01:39:27] <alex_joni> debounce would have worked too
[01:39:35] <alex_joni> I think
[01:39:44] <cradek> or not not
[01:39:45] <jmkasunich> much more complex tho
[01:39:55] <cradek> and or or is the best
[01:39:56] <jmkasunich> yeah, not not was my 2nd choice
[01:40:11] <jmkasunich> or and and?
[01:40:16] <cradek> did you check or?
[01:40:19] <cradek> for ||
[01:40:23] <jmkasunich> yeah, it uses ||
[01:40:33] <cradek> bb
[01:40:35] <cradek> l
[01:40:40] <alex_joni> and or or? or or and and?
[01:43:47] <CIA-15> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: attempt to fix #1853953 - M66 fails to respond to hardware inputs
[01:47:04] <CIA-15> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: add RISE and FALL wait modes as suggested bby JMK. for rise it first waits for low, then high
[01:48:16] <alex_joni> good night all
[01:48:33] <jmkasunich> goodnight alex
[01:48:48] <alex_joni> jmkasunich: thanks for spotting that one
[01:49:06] <jmkasunich> you're welcome
[01:49:15] <alex_joni> I'll hook up something to a parport these days and confirm the fix
[01:50:03] <alex_joni> that reminds me.. I had some experience with a Cardbus parport lately
[01:50:13] <jmkasunich> cardbus?
[01:50:20] <alex_joni> newer PCMCIA
[01:50:28] <alex_joni> but not the PCI-Express types
[01:50:30] <jmkasunich> laptop parports?
[01:50:36] <alex_joni> jmkasunich: plugs into a laptop
[01:51:24] <alex_joni> seems loading the linux driver sets up all needed bits
[01:51:32] <alex_joni> then the port addy is in /proc/ioports
[01:51:47] <alex_joni> and simply setting it in the hal_parport cfg=.. made it work
[01:52:56] <alex_joni> same should work for pci cards like the netmos (using parport_pc)
[03:17:05] <cradek> http://mathworld.wolfram.com/Right-HandedCoordinateSystem.html
[03:17:09] <cradek> man what a useless diagram
[03:17:48] <cradek> I was hoping I could link to a decent description of what a RHCS is instead of explaining it
[03:18:51] <jmkasunich> http://www.povray.org/documentation/view/3.6.1/15/
[03:19:08] <jmkasunich> unfortunately it is left handed, but maybe you could use gimp to mirror the image?
[03:19:44] <cradek> maybe
http://en.wikipedia.org/wiki/Right-hand_rule
[03:20:13] <jmkasunich> maybe
[03:20:35] <jmkasunich> did you see the pic at the bottom of the povray page? and the block of text between the two pics?
[03:21:09] <cradek> yes
[03:21:30] <cradek> strange that nobody else does what I do to determine handedness
[03:22:03] <cradek> I end up with my thumb along Z
[03:22:30] <jmkasunich> imdex = x, middle = y?
[03:22:31] <cradek> fingers "sweep" from X to Y when I close my hand
[03:23:00] <cradek> start making a salute and point fingers along X, then bend fingers to Y
[03:23:13] <cradek> if you can do this, thumb points Z
[03:23:30] <cradek> I think it's how I learned to figure the cross product direction
[03:24:12] <cradek> (I'm trying to answer the lathe arc direction question correctly and succinctly)
[03:24:19] <jmkasunich> ah
[03:24:23] <cradek> not easy since I like to "hear myself type"
[03:24:30] <jmkasunich> is that the "G2 goes the wrong way" question?
[03:24:53] <cradek> yes
[05:37:36] <SWPadnos____> SWPadnos____ is now known as SWPadnos
[14:13:23] <jepler> alex_joni: back when I was floating the idea of 2.2.3, you wanted me to wait until you'd looked at a particular bug. was that one of the issues that was "fixed" by the initialization of joint_pos?
[14:13:40] <alex_joni> one of them yes
[14:13:51] <jepler> but there's still one more you want to investigate?
[14:13:54] <alex_joni> the other one was the M66 - which is also fixed (but not verified)
[14:14:22] <jepler> ah ok
[14:14:26] <alex_joni> and the last thing I have in mind is the number of IO's exported by motion
[14:14:43] <jepler> did you fix that on TRUNK already?
[14:14:46] <alex_joni> yes
[14:15:02] <alex_joni> but I was a bit worried about backporting without asking you
[14:16:07] <jepler> I am glad you were :-P
[14:16:59] <jepler> one question -- where is the index number for an input checked for being valid?
[14:17:03] <jepler> I don't see that in the patch
[14:17:19] <alex_joni> can you be more specific?
[14:18:12] <jepler> suppose I M66 P999, or M66 P-2 -- where does it deal with the fact that the input number is out of range?
[14:18:20] <jepler> (and the same for M66 E-)
[14:18:29] <alex_joni> in the interp
[14:20:47] <jepler> Issuing EMC_TASK_PLAN_EXECUTE -- (+509,+268, +87,m66p99999999,)
[14:20:55] <jepler> now task seems to be hung ?
[14:21:07] <alex_joni> you broke it
[14:21:09] <jepler> when I exited axis, it printed
[14:21:09] <jepler> /usr/local/jepler/src/emc2/scripts/emc: line 594: 8673 Segmentation fault $EMCTASK -ini $INIFILE
[14:21:16] <alex_joni> ewww
[14:21:19] <jepler> so I guess that crashes task
[14:21:26] <alex_joni> * alex_joni hides
[14:22:33] <jepler> this is before updating
[14:22:42] <alex_joni> I dont think that changes
[14:22:43] <jepler> I don't think it's new behavior
[14:22:47] <alex_joni> nope
[14:24:25] <alex_joni> good catch.. I ll fix it later
[14:25:32] <jepler> OK
[14:28:04] <jepler> oh duh -- it's from the printf() which happens before the input number is validated!
[14:28:21] <alex_joni> and which should be removed
[14:28:33] <jepler> well *that* is a fix to feel good about
[14:28:33] <alex_joni> although it was helpful yesterday
[14:28:55] <jepler> then move it down below the "valid index" check
[14:29:57] <alex_joni> I'll see what I'll do..
[14:30:08] <alex_joni> but I also think bad things will happen to task
[14:30:17] <alex_joni> the WAIT() canon call doesn't check for index limits
[14:30:27] <jepler> no I was just noticing that too
[14:30:38] <alex_joni> and checking against EMC_MAX_DIO is also not a "real" solution
[14:30:51] <alex_joni> it needs to be reported by emcmot .. how many there actually are there
[14:31:44] <jepler> m66p9999999l3Q1 crashes at emctaskmain.cc:2326
[14:32:58] <alex_joni> that's one of the emcStatus->motion.synch_di[emcAuxInputWaitIndex] .. right?
[14:33:02] <jepler> alex_joni: yes
[14:33:09] <jepler> sorry I guess we have different versions of that file
[14:33:17] <jepler> if (emcStatus->motion.synch_di[emcAuxInputWaitIndex] == 1) {
[14:33:21] <jepler> ...
[14:33:40] <alex_joni> jepler: yeah, I'm at work.. don't have a real file editor handy
[14:33:40] <jepler> even if motion is configured for fewer inputs, there will be EMC_MAX_DIO in motion.synch_di[]
[14:34:06] <alex_joni> right..
[14:34:16] <alex_joni> but EMC_MAX_DIO is not the same as EMCMOT_MAX_DIO
[14:34:24] <alex_joni> and I don't know how to fix that
[14:34:43] <alex_joni> (where to define it so it's ok for both locations: RT code motion, and task/canon)
[14:37:22] <jepler> bad things happen if you include emcmotcfg.h in emcglb.h?
[14:37:48] <jepler> that's what I'd be tempted to do
[14:40:12] <alex_joni> think I tried the other way around.. but bad things happened
[14:41:18] <jepler> it still compiles
[14:41:51] <jepler> http://pastebin.ca/869768
[14:42:58] <alex_joni> seems good enough for commit.. if it still runs :)
[14:43:18] <jepler> hm I didn't know the inputs could be monitored in the stat buffer
[14:43:36] <alex_joni> thats recent.. it might be nice to see them from emctop
[14:45:53] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/emc/nml_intf/emcglb.h: define some EMC_MAX in terms of EMCMOT_MAX, saves changing definitions in two places
[15:27:55] <lerneaen_hydra> lo, anyone here?
[15:28:25] <lerneaen_hydra> oops
[15:37:08] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/docs/src/config/ (11 files): set dpi of these screenshots to 100 so that they fit on the pdf page
[15:37:57] <skunkworks> Thanks :)
[15:38:19] <skunkworks> iirc - the documents get built every so often?
[15:39:09] <jepler> yes the online version is updated within about an hour of any change
[15:43:28] <CIA-15> EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/config/ (11 files): from TRUNK: make images fit on pdf page
[15:52:42] <skunkworks> jepler: looks great
[15:52:48] <skunkworks> thanks again
[15:54:12] <jepler> skunkworks: thanks for checking it!
[15:54:25] <jepler> too bad you already printed it :-P
[15:55:16] <skunkworks> no problem - just have to reprint 19-26
[15:55:41] <jepler> it didn't affect the page numbering?
[15:55:47] <jepler> (I didn't check)
[15:56:23] <skunkworks> a little - but that is why I am re-printing the whole section
[15:56:48] <jepler> you weird people with your printed documentation.
[15:56:51] <jepler> I don't get it
[15:57:17] <skunkworks> heh - weird isn't it.
[16:09:13] <cradek_> cradek_ is now known as cradek
[16:12:09] <skunkworks> it actually prints different than the preview. Odd. but worked great
[20:45:13] <CIA-15> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/halui.cc: remove unneeded include (emcmotcfg is included by emcglb nowadays)
[21:04:53] <cradek> a P3 700 is great for running EMC. For compiling EMC, not so great
[21:05:09] <SWPadnos> heh
[21:05:09] <alex_joni> tell me about it
[21:05:13] <SWPadnos> I found similar results with a celeron 500
[21:05:17] <alex_joni> * alex_joni already plans for a new PC
[21:05:32] <alex_joni> don't want to build new kernels on this athlon XP 1600+
[21:06:01] <cradek> yeah, if you could get it right in one try, it would be ok - but nobody can do that
[21:06:26] <cradek> you use ccache when doing kernels right??
[21:06:39] <alex_joni> I probably will
[21:06:54] <alex_joni> I crashed 1-2 HDDs since last time I did it
[21:07:02] <alex_joni> so I'll start with apt-get :P
[21:07:36] <cradek> getting ready for april?
[21:07:43] <alex_joni> slowly
[21:07:49] <alex_joni> they have alpha3 out
[21:08:07] <alex_joni> and the kernel is at rc8 iirc
[21:08:31] <alex_joni> there is an ADEOS patch for one of the rc's already
[21:08:38] <SWPadnos> cool
[21:08:48] <alex_joni> SWPadnos: in the xeno svn
[21:08:56] <SWPadnos> ok
[21:13:36] <skunkworks> is april the next lts release?
[21:15:00] <SWPadnos> yep - 04/2008 = 8.04
[21:15:23] <skunkworks> cool
[21:15:24] <SWPadnos> (6.04 was delayed by 2 months, so it became 6.06)
[21:15:25] <alex_joni> horny hardon 8.04
[21:15:34] <skunkworks> hehe
[21:15:35] <alex_joni> err.. hardy heron
[21:15:39] <alex_joni> :P
[21:32:09] <alex_joni> heh
http://ubuntu-women.org/
[21:33:50] <cradek> Membership is open to _all_.
[21:34:45] <cradek> "We hope to increase the diversity ratio by creating an atmosphere for women to communicate openly and ask technical questions without any fear of being flamed or ridiculed for asking so-called silly questions."
[21:35:08] <cradek> they hope to teach people to not flame women when they ask a question that would get men flamed?
[21:35:24] <cradek> that actually seems condescending to me
[21:35:59] <skunkworks> 'take it like a man' ;)
[21:36:16] <alex_joni> err.. person
[21:36:29] <cradek> oops, my "know when to stop talking" didn't kick in at the right time
[21:37:05] <skunkworks> This is a mens club anyways - no worries.
[21:37:29] <cradek> well I like women
[21:37:43] <SWPadnos> * SWPadnos too
[21:38:01] <skunkworks> cradek: that should be in the wiki quotes ;)
[21:38:02] <cradek> but that part of their mission statement seems stupid
[21:40:32] <alex_joni> jepler: ping
[21:42:07] <CIA-15> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/canon.hh: check for out-of-boundness for M66 inputs (2.2 backport candidate?)
[21:42:09] <CIA-15> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/rs274ngc/ (4 files): check for out-of-boundness for M66 inputs (2.2 backport candidate?)
[21:42:09] <CIA-15> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/task/emccanon.cc: check for out-of-boundness for M66 inputs (2.2 backport candidate?)
[21:42:10] <CIA-15> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/sai/saicanon.cc: check for out-of-boundness for M66 inputs (2.2 backport candidate?)
[21:45:40] <jepler> alex_joni: it's unfortunate to change the canon interface during a stable release cycle.
[21:46:02] <alex_joni> I know..
[21:46:12] <alex_joni> and adding interp errors, etc
[21:46:33] <jepler> alex_joni: as a separate issue, we should stop defining new numbered error codes now that they can be strings (the CHKS and CHKF macros)
[21:46:38] <alex_joni> I'd rather accompany the 2.2.x branch with a don't do that message, or a crappier fixing
[21:47:04] <alex_joni> jepler: I considered that, but didn't know how it affects locale stuff
[21:47:09] <jepler> yeah if "just don't crash" is less invasive, I'd prefer that in 2.2 to changing more stuff
[21:47:35] <alex_joni> I thought the interp_error is handled by msgmerge somehow automatically
[21:47:39] <alex_joni> (without looking)
[21:49:23] <CIA-15> EMC: 03alex_joni 07TRUNK * 10emc2/debian/changelog: note M66 additional check
[21:50:07] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/po/Submakefile: find translation strings in all files in librs274
[21:50:07] <jepler> they were missing, but it was an oversight
[21:51:02] <alex_joni> so what's the plan?
[21:51:23] <alex_joni> to remove all CHK, and put CHKS's in place? or just for future errors?
[21:51:41] <jepler> if somebody wants to get rid of all the numbered errors in 2.3 that would be great.
[21:53:15] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Alex_Joni
[21:58:10] <CIA-15> EMC: 03alex_joni 07v2_2_branch * 10emc2/src/emc/task/emccanon.cc: hackish fix to prevent segfaults with bad M66 index numbers. the real fix is in r1.126
[22:02:06] <CIA-15> EMC: 03alex_joni 07v2_2_branch * 10emc2/debian/changelog: note 2 x M66 fixes, run-from-line ferror fix
[22:02:21] <alex_joni> jepler: hope that's ok like that
[22:06:06] <jepler> looks much less invasive, thanks
[22:06:30] <alex_joni> it will fail more silently though
[22:09:14] <jepler> I know
[22:25:48] <alex_joni> cradek: still there?
[22:26:16] <alex_joni> is this too ugly?
[22:26:20] <alex_joni> - return emcStatus->motion.synch_di[index];
[22:26:20] <alex_joni> + return (emcStatus->motion.synch_di[index] != 0) ? 1 : 0 ;
[22:27:27] <alex_joni> otherwise I would get 64 in #5399 for parport.0.pin-10-in
[22:34:42] <CIA-15> EMC: 03alex_joni 07v2_2_branch * 10emc2/src/emc/task/emccanon.cc: last bit of fixing SF #1853953 - this makes 5399 hold only -1, 0 or 1 for digital inputs
[22:36:43] <CIA-15> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/task/emccanon.cc: last bit of fixing SF #1853953 - this makes var #5399 hold only -1, 0 or 1 for digital inputs
[22:56:47] <CIA-15> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/ (stepconf.glade stepconf.py): add spindle-on as requested by #1849499
[23:35:12] <CIA-15> EMC: 03cradek 07v2_2_branch * 10emc2/src/emc/kinematics/tp.c: backport 1.87: "battle with tiny moves" to fix SF#1877433
[23:53:36] <jepler> alex_joni: you probably fucked something up adding spindle on
[23:53:43] <jepler> oh wait, on trunk it might be OK
[23:53:46] <jepler> excuse my hasty words
[23:54:03] <jepler> it's just that with the way it's put together in 2.2 you really can't add new signals without breaking existing configs
[23:58:24] <CIA-15> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: fix 'spindle brake' output
[23:59:51] <SWPadnos____> SWPadnos____ is now known as SWPadnos