andypugh: well heck -- I thought I understood the problem
atan is good, no problem there.
is it possible that the compiler is still (for some reason) using the math.h definition?
Do you have the kins/hal/ini files?
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
how the *heck* can I get a preprocessed (by cpp) file from the kernel build?
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.
there may be two problems
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.
aha, I may have just spotted the second bug -- and it's my fault again
* jepler looks for a place to hide
is it as much fun?
(And thanks for the technical description, it was fascinating and enlightening)
it looks like I provided a totally bogus implementation of atan in rtapi_math_i386.h
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")
and here's the one for tan: MATHOP(tan, "fptan")
but fptan is actually a two-input x87 instruction that is more closely related to atan2 (two inputs)
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
as well as giving the wrong result, of course
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.
err, keep holding on
now I got fpatan and fptan confused
* jepler looks for some documentation
[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.
well that's a bit odd
Certainly seems unexpected, though is it linked to the 1.0-as-second-operand that makes atan2 into atan?
it probably is
Aram is talking about $30k CAM packages. Seems an odd fit to his machine.
try this, cumulative with the last one: http://emergent.unpy.net/files/sandbox/0001-fix-implementation-of-tan-provide-implementation-of-.patch
I tested with this: http://emergent.unpy.net/files/sandbox/trig.comp
Did that little comp show wierdness without the patch? I ask only out of curiosity
and here's a sesson of it (with all my patches): http://pastebin.ca/1890130
let me go back in time to before my changes and see...
let's see .. I get this warning (only): /home/jepler/trig.comp:26: warning: implicit declaration of function `atan'
I get wrong numbers for atan-y-over-x and tan-theta
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)
were tan and atan the two trouble functions, or was there another?
because trig.comp shows problems with them without my changes, and the problems are fixed with my changes
tan was the only real problem one. atan announced its non-existence so was easily rectified. tan silently compiled then screwd up the system.
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.
jepler: The "wrong numbers" was pre-patch?
andypugh: yes, once I reverted to before *both* my patches I had problems wtih *both* atan and tan
I didn't check with the in-between state, but I'm pretty confident tan was wrong then
And _with_ both I have no problems at all. Award yourself a pay rise :-)
you quickly forget I'm the one who wrote all your problems
EMC: 03jepler 07v2.4_branch * rba43d1b468b0 10/src/rtapi/rtapi_math.h: provide a prototype for tan, atan in kernel
EMC: 03jepler 07v2.4_branch * rc918d08cb738 10/src/rtapi/rtapi_math_i386.h: fix tan; provide atan
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
industrialise the bugfixes on those. (And it is us who find and fix the bugs)
EMC: 03jepler 07master * r5179344ef89c 10/src/hal/drivers/mesa-hostmot2/hm2_pci.c: hostmot2: Fix firmware loading on 5i23 et al
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.
EMC: 03jepler 07master * r167ec44a7a9c 10/tcl/bin/pickconfig.tcl: make desktop files executable to placate lucid
EMC: 03jepler 07master * r3e89a25a2819 10/scripts/emcmkdesktop.in: Make icon appear
EMC: 03jepler 07master * r46ce3d2b908e 10/src/emc/usr_intf/axis/scripts/axis.py: Show a prompt when a user re-homes.
EMC: 03jepler 07master * r8a00e9b8a867 10/tcl/bin/pickconfig.tcl: Don't present an option that doesn't work
EMC: 03jepler 07master * r551940c2f7c7 10/src/hal/drivers/mesa-hostmot2/stepgen.c: fix a bug in stepgen mode setting
EMC: 03jepler 07master * r02c2e884b5ea 10/src/hal/drivers/mesa-hostmot2/stepgen.c: fix a stepgen bug
EMC: 03jepler 07master * rdb82a1814fb2 10/src/hal/drivers/mesa-hostmot2/hostmot2.c: Removed deprecated part of error message.
EMC: 03jepler 07master * r23533197ffae 10/src/hal/drivers/mesa-hostmot2/hm2_7i43.c: Fix load failure on -200s with parport_pc loaded
EMC: 03jepler 07master * rba43d1b468b0 10/src/rtapi/rtapi_math.h: provide a prototype for tan, atan in kernel
EMC: 03jepler 07master * r1fd5c420f2ec 10/ (10 files in 5 dirs): Merge remote branch 'origin/v2.4_branch'
EMC: 03jepler 07master * rc918d08cb738 10/src/rtapi/rtapi_math_i386.h: fix tan; provide atan
andypugh: this is the one I always think of: http://joeindie.com/blog/?p=50
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.
Talking about Mesa Hostmot: After doing the patch and recompile for tan, I got a warning I have never seen before :
oh no, what now?
&&/home/andypugh/emc2.5-dev/src/hal/drivers/mesa-hostmot2/bitfile.c: In function ‘bitfile_do_small_chunk’:
&&/home/andypugh/emc2.5-dev/src/hal/drivers/mesa-hostmot2/bitfile.c:55: warning: assignment discards qualifiers from pointer target type
&&/home/andypugh/emc2.5-dev/src/hal/drivers/mesa-hostmot2/bitfile.c: In function ‘bitfile_do_big_chunk’:
&&/home/andypugh/emc2.5-dev/src/hal/drivers/mesa-hostmot2/bitfile.c:84: warning: assignment discards qualifiers from pointer target type
that's not new
I think it's harmless but I haven't looked closely
I think if it mattered I would have noticed by now. But it's odd I have not seen it previously.
it is a warning that didn't exist on older kernels
How old? Mine is hardly youthful. (220.127.116.11)
2.6.24 -- i.e., hardy
* jepler <-- generally hates upgrades
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
Indeed. If clay tablets and cuneiform was good enough for the Babylonians it good enough for me.
Anyway, time to log off.
Thanks for the fixes. Way out of my league that stuff.
I'm sorry it didn't come sooner.
but you're welcome
Yes, you took a whole day from when I identified the function at fault...
I count that as pretty qick.
And it was the wierdest bug I have ever seen.
SteveStallings is now known as steves_logging
EMC: 03cmorley 07v2.4_branch * re51fe4b5d0d8 10/src/emc/usr_intf/pncconf/ (pncconf.glade pncconf.py): remove base thread from config
EMC: 03cmorley 07v2.4_branch * rc315f19ee857 10/src/emc/usr_intf/pncconf/pncconf.py: hide mesa I/O tabs if not needed / configured
<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 :>
EMC: 03jthornton 07v2.4_branch * r91bade193779 10/docs/src/gcode/main.lyx: clean up G53 description
micges: hi, sorry.. that wasn't me ;)
micges: nope, my son
alex_joni: Youve only been married 6mnths
EMC: 03jepler 07v2.4_branch * ra6e74cd838c0 10/src/hal/classicladder/protocol_modbus_master.c: classicladder: modbus: fix response size calculation
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
EMC: 03jepler 07v2.4_branch * r9b89272a526f 10/src/hal/classicladder/serial_linux.c: classicladder: modbus: always transmit before trying to receive
EMC: 03jepler 07v2.4_branch * r935bb14285bd 10/src/hal/classicladder/serial_linux.c: classicladder: modbus: use blocking reads
EMC: 03jepler 07v2.4_branch * rb20cc187f9e9 10/src/hal/classicladder/serial_linux.c: classicladder: modbus: inter-byte delays are short
EMC: 03jepler 07v2.4_branch * ra8d5a0041489 10/src/hal/classicladder/protocol_modbus_master.c: classicladder: modbus: Fix crash if LgtResponse==1
EMC: 03jepler 07v2.4_branch * r848d50ef926b 10/src/hal/classicladder/serial_linux.c: classicladder: modbus: fix 300 baud
an odd problem and possible solution occuring with m66: http://www.panix.com/~dgarrett/stuff/m66problem.txt
a perfect storm of subroutines/repeats/inversetime/m66/roundoff:-(
huh, what a surprise - the Interp::synch call after m66 changes current_x
cradek: any concerns about incorporating dgarr's patch? you're the closest we have to an expert on the interpreter..
jepler: I'd say that whole emccanon.cc should be also fixed for floating point compares
EMC: 03micges 07master * ra0e9a4c90f30 10/src/hal/components/watchdog.c: hal: fixed some minor bugs in watchdog component
micges: I'm talking in the context of a bugfix for v2.4.
changing thousands of lines in the interpreter -> not a bug fix suitable for v2.4.
jepler: I know that
the bugfix looks ok to me
jepler: did you add the 'classicladder: modbus:" to the commit message?
imo best solution is to enable -Wfloat-equal compiler flag in master and try to remove all warnings it will caused
jepler: ah, thought it's something automatic :)
but I like it either way, saw micges picked it up
it would be cool if we use it as a rule of commit messages
this is what gets spewed out sometimes during an estop
[20:44:19] <skunkworks> http://pastebin.ca/1890688
then after a bunch it says.. 'maximum number of errors to print exceeded'
Kim says hi ;)
a tool change has to be called before the estop happens it seems. (it finises and tool prepear is false at that point.)
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
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
then when you pull the axis estop back out again - it takes anywhere from 10 to 30 seconds to come back out.
*sorry - it is the 4th rung on the sample