Back
[00:09:51] <jepler> andypugh: well heck -- I thought I understood the problem
[00:09:53] <jepler> evidently not
[00:10:04] <andypugh> atan is good, no problem there.
[00:10:58] <andypugh> is it possible that the compiler is still (for some reason) using the math.h definition?
[00:12:12] <andypugh> Do you have the kins/hal/ini files?
[00:13:04] <cradek> using something from math.h isn't the problem - the problem (if we understand it) will happen when you call a function that returns double, but you don't have a prototype in scope
[00:16:46] <jepler> how the *heck* can I get a preprocessed (by cpp) file from the kernel build?
[00:16:49] <jepler> grgrngrgn
[00:17:24] <andypugh> The thing is that atan raises a compiler error without the patch, but tan just compiles (but forces a much bigger recompile). I don't know what that means, but it might mean something.
[00:17:57] <jepler> there may be two problems
[00:18:37] <andypugh> It is entirely possible that the "tan" being called is actually a sunbed driver that is accidentally in scope, I don't know how you tell what actual code, where, is being called.
[00:19:29] <jepler> aha, I may have just spotted the second bug -- and it's my fault again
[00:19:33] <jepler> * jepler looks for a place to hide
[00:20:21] <andypugh> is it as much fun?
[00:21:03] <andypugh> (And thanks for the technical description, it was fascinating and enlightening)
[00:23:13] <jepler> it looks like I provided a totally bogus implementation of atan in rtapi_math_i386.h
[00:24:02] <jepler> This expands to a definition of a function that uses the one-input x87 instruction 'fsin' to implement the one-argument function 'sin': MATHOP(sin, "fsin")
[00:24:11] <jepler> and here's the one for tan: MATHOP(tan, "fptan")
[00:24:26] <jepler> but fptan is actually a two-input x87 instruction that is more closely related to atan2 (two inputs)
[00:24:42] <cradek> ook
[00:24:59] <jepler> so it's the reverse problem: when you call tan() it's trying to use more arguments than are there .. so if it's part of a complex expression, it returns with fewer items on the stack than expected
[00:25:04] <jepler> as well as giving the wrong result, of course
[00:25:11] <andypugh> That's strange, as the atan function is the one that works fine now. (though I have not checked the actual results). tan is still putting bogus values into the stepgen feedback and giving NaN - based f-errors.
[00:26:01] <jepler> err, keep holding on
[00:26:18] <jepler> now I got fpatan and fptan confused
[00:26:25] <jepler> * jepler looks for some documentation
[00:28:21] <jepler> [fptan computes] the tangent of the source operand in register ST(0), stores the result in ST(0), and pushes a 1.0 onto the FPU register stack.
[00:28:27] <jepler> well that's a bit odd
[00:29:29] <andypugh> Certainly seems unexpected, though is it linked to the 1.0-as-second-operand that makes atan2 into atan?
[00:31:44] <jepler> it probably is
[00:32:18] <andypugh> Aram is talking about $30k CAM packages. Seems an odd fit to his machine.
[00:37:05] <jepler> try this, cumulative with the last one:
http://emergent.unpy.net/files/sandbox/0001-fix-implementation-of-tan-provide-implementation-of-.patch
[00:37:31] <jepler> I tested with this:
http://emergent.unpy.net/files/sandbox/trig.comp
[00:38:55] <andypugh> Did that little comp show wierdness without the patch? I ask only out of curiosity
[00:39:29] <jepler> and here's a sesson of it (with all my patches):
http://pastebin.ca/1890130
[00:39:35] <jepler> let me go back in time to before my changes and see...
[00:40:32] <jepler> let's see .. I get this warning (only): /home/jepler/trig.comp:26: warning: implicit declaration of function `atan'
[00:43:31] <cradek> c
[00:43:32] <jepler> I get wrong numbers for atan-y-over-x and tan-theta
[00:46:59] <andypugh> It is hard to see how to test it, I guess adding a stepgen and watching it not drift would fall into the category of "absence of evidence is not evidence of absence)
[00:47:54] <jepler> were tan and atan the two trouble functions, or was there another?
[00:48:06] <jepler> because trig.comp shows problems with them without my changes, and the problems are fixed with my changes
[00:49:00] <andypugh> tan was the only real problem one. atan announced its non-existence so was easily rectified. tan silently compiled then screwd up the system.
[00:49:57] <andypugh> However, with both patches I am now using tan and atan with no apparent wierdness. (the accuracy of the maths I can't vouch for, but looks plausible). The main thing is that nothing utterly bizarre it happeing.
[00:51:04] <andypugh> jepler: The "wrong numbers" was pre-patch?
[00:51:23] <jepler> andypugh: yes, once I reverted to before *both* my patches I had problems wtih *both* atan and tan
[00:51:41] <jepler> I didn't check with the in-between state, but I'm pretty confident tan was wrong then
[00:51:54] <andypugh> And _with_ both I have no problems at all. Award yourself a pay rise :-)
[00:55:08] <jepler> you quickly forget I'm the one who wrote all your problems
[01:00:10] <CIA-2> EMC: 03jepler 07v2.4_branch * rba43d1b468b0 10/src/rtapi/rtapi_math.h: provide a prototype for tan, atan in kernel
[01:00:12] <CIA-2> EMC: 03jepler 07v2.4_branch * rc918d08cb738 10/src/rtapi/rtapi_math_i386.h: fix tan; provide atan
[01:00:48] <andypugh> I can't find the strip, but there is a Dilbert where the software company saleseman is charging 20k for the bugfix patch, and ends up ringing the head office (in Dilbert's presence) and saying "quick, introduce more bugs, I am making a killing here" It is on a coleague's desk and rings too true to be properly funny with our ECU firmware supplier. They charge is for the scheduled software drops, then charge us again to
[01:00:49] <andypugh> industrialise the bugfixes on those. (And it is us who find and fix the bugs)
[01:01:39] <CIA-2> EMC: 03jepler 07master * r5179344ef89c 10/src/hal/drivers/mesa-hostmot2/hm2_pci.c: hostmot2: Fix firmware loading on 5i23 et al
[01:01:40] <CIA-2> EMC: 03jepler 07master * rf079f78c5acd 10/configs/smithy/ (1240.hal 6130.hal 622leadshine.hal): Fix misassigned gpio pins in 1240.hal and 622leadshine.hal. Fix incorrect direction hold time and step pulse polarity in 6130.hal.
[01:01:41] <CIA-2> EMC: 03jepler 07master * r167ec44a7a9c 10/tcl/bin/pickconfig.tcl: make desktop files executable to placate lucid
[01:01:43] <CIA-2> EMC: 03jepler 07master * r3e89a25a2819 10/scripts/emcmkdesktop.in: Make icon appear
[01:01:44] <CIA-2> EMC: 03jepler 07master * r46ce3d2b908e 10/src/emc/usr_intf/axis/scripts/axis.py: Show a prompt when a user re-homes.
[01:01:46] <CIA-2> EMC: 03jepler 07master * r8a00e9b8a867 10/tcl/bin/pickconfig.tcl: Don't present an option that doesn't work
[01:01:50] <CIA-2> EMC: 03jepler 07master * r551940c2f7c7 10/src/hal/drivers/mesa-hostmot2/stepgen.c: fix a bug in stepgen mode setting
[01:01:53] <CIA-2> EMC: 03jepler 07master * r02c2e884b5ea 10/src/hal/drivers/mesa-hostmot2/stepgen.c: fix a stepgen bug
[01:01:53] <CIA-2> EMC: 03jepler 07master * rdb82a1814fb2 10/src/hal/drivers/mesa-hostmot2/hostmot2.c: Removed deprecated part of error message.
[01:01:54] <CIA-2> EMC: 03jepler 07master * r23533197ffae 10/src/hal/drivers/mesa-hostmot2/hm2_7i43.c: Fix load failure on -200s with parport_pc loaded
[01:01:55] <CIA-2> EMC: 03jepler 07master * rba43d1b468b0 10/src/rtapi/rtapi_math.h: provide a prototype for tan, atan in kernel
[01:01:56] <CIA-2> EMC: 03jepler 07master * r1fd5c420f2ec 10/ (10 files in 5 dirs): Merge remote branch 'origin/v2.4_branch'
[01:01:57] <CIA-2> EMC: 03jepler 07master * rc918d08cb738 10/src/rtapi/rtapi_math_i386.h: fix tan; provide atan
[01:02:01] <jepler> andypugh: this is the one I always think of:
http://joeindie.com/blog/?p=50
[01:02:44] <andypugh> :-)
[01:03:17] <jepler> unfortunately when you double my salary for working on emc, it's still zero .. and when I clock 8 hours of overtime on it, it's still zero.
[01:03:54] <andypugh> Talking about Mesa Hostmot: After doing the patch and recompile for tan, I got a warning I have never seen before :
[01:04:13] <jepler> oh no, what now?
[01:04:26] <andypugh> &&/home/andypugh/emc2.5-dev/src/hal/drivers/mesa-hostmot2/bitfile.c: In function ‘bitfile_do_small_chunk’:
[01:04:26] <andypugh> &&/home/andypugh/emc2.5-dev/src/hal/drivers/mesa-hostmot2/bitfile.c:55: warning: assignment discards qualifiers from pointer target type
[01:04:26] <andypugh> &&/home/andypugh/emc2.5-dev/src/hal/drivers/mesa-hostmot2/bitfile.c: In function ‘bitfile_do_big_chunk’:
[01:04:26] <andypugh> &&/home/andypugh/emc2.5-dev/src/hal/drivers/mesa-hostmot2/bitfile.c:84: warning: assignment discards qualifiers from pointer target type
[01:04:37] <jepler> that's not new
[01:04:47] <jepler> I think it's harmless but I haven't looked closely
[01:05:30] <andypugh> I think if it mattered I would have noticed by now. But it's odd I have not seen it previously.
[01:11:15] <jepler> it is a warning that didn't exist on older kernels
[01:12:44] <andypugh> How old? Mine is hardly youthful. (2.6.29.4)
[01:13:18] <jepler> 2.6.24 -- i.e., hardy
[01:13:25] <jepler> * jepler <-- generally hates upgrades
[01:13:45] <jepler> there are a bunch of warnings that appear on 10.04 that weren't on 8.04; most of them are right in some sense, but none of them I've noticed indicate serious bugs
[01:14:16] <andypugh> Indeed. If clay tablets and cuneiform was good enough for the Babylonians it good enough for me.
[01:14:49] <andypugh> Anyway, time to log off.
[01:15:09] <jepler> see you
[01:15:10] <andypugh> Thanks for the fixes. Way out of my league that stuff.
[01:15:23] <jepler> I'm sorry it didn't come sooner.
[01:15:31] <jepler> but you're welcome
[01:16:03] <andypugh> Yes, you took a whole day from when I identified the function at fault...
[01:16:13] <andypugh> I count that as pretty qick.
[01:16:50] <andypugh> And it was the wierdest bug I have ever seen.
[03:15:16] <SteveStallings> SteveStallings is now known as steves_logging
[05:30:39] <CIA-2> EMC: 03cmorley 07v2.4_branch * re51fe4b5d0d8 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): remove base thread from config
[05:31:38] <CIA-2> EMC: 03cmorley 07v2.4_branch * rc315f19ee857 10/src/emc/usr_intf/pncconf/pncconf.py: hide mesa I/O tabs if not needed / configured
[06:15:25] <morfic> <jepler> there are a bunch of warnings that appear on 10.04 that weren't on 8.04; most of them are right in some sense, but none of them I've noticed indicate serious bugs <-- you must have hated gcc3.4 :>
[10:36:46] <alex_joni> =]l;=ll
[10:52:36] <micges> alex_joni: hi
[11:59:01] <CIA-2> EMC: 03jthornton 07v2.4_branch * r91bade193779 10/docs/src/gcode/main.lyx: clean up G53 description
[15:37:19] <alex_joni> micges: hi, sorry.. that wasn't me ;)
[15:37:53] <micges> heh ok
[15:37:55] <micges> cat?
[15:57:44] <alex_joni> micges: nope, my son
[15:59:44] <Jymmm> alex_joni: Youve only been married 6mnths
[16:51:40] <alex_joni> Jymmm: heh
[18:34:01] <CIA-2> EMC: 03jepler 07v2.4_branch * ra6e74cd838c0 10/src/hal/classicladder/protocol_modbus_master.c: classicladder: modbus: fix response size calculation
[18:34:05] <CIA-2> EMC: 03jepler 07v2.4_branch * r1a3307ed32f0 10/src/hal/classicladder/ (serial_common.h serial_linux.c socket_modbus_master.c): classicladder: modbus: Use correct response timeout
[18:34:05] <CIA-2> EMC: 03jepler 07v2.4_branch * r9b89272a526f 10/src/hal/classicladder/serial_linux.c: classicladder: modbus: always transmit before trying to receive
[18:34:06] <CIA-2> EMC: 03jepler 07v2.4_branch * r935bb14285bd 10/src/hal/classicladder/serial_linux.c: classicladder: modbus: use blocking reads
[18:34:07] <CIA-2> EMC: 03jepler 07v2.4_branch * rb20cc187f9e9 10/src/hal/classicladder/serial_linux.c: classicladder: modbus: inter-byte delays are short
[18:34:10] <CIA-2> EMC: 03jepler 07v2.4_branch * ra8d5a0041489 10/src/hal/classicladder/protocol_modbus_master.c: classicladder: modbus: Fix crash if LgtResponse==1
[18:34:14] <CIA-2> EMC: 03jepler 07v2.4_branch * r848d50ef926b 10/src/hal/classicladder/serial_linux.c: classicladder: modbus: fix 300 baud
[19:13:55] <dgarr>
[19:14:15] <dgarr> an odd problem and possible solution occuring with m66:
http://www.panix.com/~dgarrett/stuff/m66problem.txt
[19:18:59] <micges> dgarr: interesting
[19:20:57] <dgarr> a perfect storm of subroutines/repeats/inversetime/m66/roundoff:-(
[19:42:20] <jepler> huh, what a surprise - the Interp::synch call after m66 changes current_x
[19:48:38] <jepler> cradek: any concerns about incorporating dgarr's patch? you're the closest we have to an expert on the interpreter..
[19:50:07] <micges> jepler: I'd say that whole emccanon.cc should be also fixed for floating point compares
[19:50:36] <CIA-2> EMC: 03micges 07master * ra0e9a4c90f30 10/src/hal/components/watchdog.c: hal: fixed some minor bugs in watchdog component
[19:51:27] <jepler> micges: I'm talking in the context of a bugfix for v2.4.
[19:51:37] <jepler> changing thousands of lines in the interpreter -> not a bug fix suitable for v2.4.
[19:52:30] <micges> jepler: I know that
[19:54:43] <alex_joni> the bugfix looks ok to me
[19:55:50] <alex_joni> jepler: did you add the 'classicladder: modbus:" to the commit message?
[19:56:07] <jepler> alex_joni: yes
[19:56:26] <micges> imo best solution is to enable -Wfloat-equal compiler flag in master and try to remove all warnings it will caused
[19:57:43] <alex_joni> jepler: ah, thought it's something automatic :)
[19:57:57] <alex_joni> but I like it either way, saw micges picked it up
[20:21:24] <micges> it would be cool if we use it as a rule of commit messages
[20:44:18] <skunkworks> this is what gets spewed out sometimes during an estop
[20:44:19] <skunkworks> http://pastebin.ca/1890688
[20:45:26] <skunkworks> then after a bunch it says.. 'maximum number of errors to print exceeded'
[20:45:45] <skunkworks> Kim says hi ;)
[20:46:40] <skunkworks> a tool change has to be called before the estop happens it seems. (it finises and tool prepear is false at that point.)
[20:47:02] <skunkworks> finishes
[20:47:15] <skunkworks> prepare
[21:00:52] <skunkworks> bbl
[23:28:35] <skunkworks_> just to clarify what I am seeing. I have an estop loop that works like the third rung example in the hal documents. 4th rung
http://wiki.linuxcnc.org/uploads/display_all.png http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Sample_HAL_And_ClassicLadder What I have seen is the estop on axis never exibits the problem - the external extop does. What happens is if you call a tool prepare in mdi (I have not tried it
[23:29:43] <skunkworks_> now when the estop is pressed - the axis onscreen estop button takes a good 20 seconds to go in. (normally it will go in instantly) the command line spits out this
http://pastebin.ca/1890688
[23:30:17] <skunkworks_> then when you pull the axis estop back out again - it takes anywhere from 10 to 30 seconds to come back out.
[23:30:39] <skunkworks_> *sorry - it is the 4th rung on the sample
