#emc-devel | Logs for 2010-06-29

Back
[13:23:58] <skunkworks_> logger_dev: bookmark
[13:23:58] <skunkworks_> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-06-29.txt
[13:37:13] <jepler> morning sk
[13:37:14] <jepler> morning skunkworks_
[13:38:07] <skunkworks_> good morning
[13:38:16] <skunkworks_> cought up on sleep?
[13:39:36] <jepler> not quite
[13:41:00] <skunkworks_> heh
[13:48:32] <skunkworks_> ok - I can reproduce it.
[13:50:05] <skunkworks_> in the demo-step-cl
[13:50:44] <skunkworks_> on a different computer
[13:53:39] <jepler> oh -- if it's easy to reproduce maybe it'll get fixed
[13:53:44] <skunkworks_> heh
[13:53:56] <skunkworks_> Let me put the config up somewhere.
[13:54:10] <jepler> modified demo-step-cl, then?
[13:54:16] <skunkworks_> yes
[13:56:48] <skunkworks_> mainly what I did was added a iec timer set at 10 seconds to simulate the tool prepare/prepered loop. I then set the external extop contact to be an internal bit in ladder so I can turn it on and off. (4th estop run active)
[13:57:05] <skunkworks_> *rung
[14:05:34] <skunkworks_> http://www.electronicsam.com/images/KandT/testing/demo_step_cl/
[14:10:04] <skunkworks_> so - This is how it acts. run emc from the command line (2.4.1) in ladder - open the vars (bit status) bit %B3 is the external estop. bring up axis - home all the axis. in mdi - issue a T2. This will take 10 seconds to complete. Once it is complete - activate bit 3 (external estop) you will see stuff spew out of the command line and the estop on axis will not go in for an amount of time - also at that time - tool pre
[14:21:29] <skunkworks_> if that makes any sense
[14:21:41] <jepler> I think you got cut offnear the end "also at that time - tool pre"
[14:22:21] <skunkworks_> so - This is how it acts. run emc from the command line (2.4.1) in ladder - open the vars (bit status) bit %B3 is the external estop. bring up axis - home all the axis. in mdi - issue a T2. This will take 10 seconds to complete. Once it is complete - activate bit 3 (external estop) you will see stuff spew out of the command line and the estop on axis will not go in for an amount of time - also at that time - tool pre
[14:22:40] <skunkworks_> also at that time - tool prepare goes high.
[14:45:40] <jepler> wow, my machine is really unresponsive while running that configuration
[14:45:47] <jepler> it's still unresponsive after I got rid of the base thread
[14:45:55] <jepler> (--enable-simulator so I had to get rid of the parport stuff anyway)
[14:46:15] <cradek> jepler: make your CL window smaller
[14:46:43] <jepler> actually sim/axis is taking 100% CPU with nothing going on!
[14:46:45] <aystarik> guys, what is the state of 10.04 support?
[14:46:54] <jepler> aystarik: it's not done yet.
[14:47:09] <jepler> we had hoped it would be ready by now, but it's not.
[14:47:18] <cradek> there are packages you can test if you want at linuxcnc.org/mozmck
[14:47:40] <aystarik> what is holding?
[14:47:58] <skunkworks_> cradek: did you hear of any issues at the fest - all the classroom computers we setup?
[14:48:05] <jepler> there are still systems on which that kernel doesn't run or doesn't boot 100% reliably and we don't know why
[14:48:07] <cradek> what do you mean issues?
[14:48:26] <cradek> oh with emc not working? no it seemed to be fine
[14:48:26] <skunkworks_> if they had any issues during the class.
[14:48:29] <skunkworks_> good
[14:48:36] <cradek> the machines were all the same, I think
[14:48:46] <jepler> yeah, they were identical or near-identical
[14:48:51] <skunkworks_> yah - probably
[14:49:24] <jepler> I'm aware of two specific problems, but mozmck probably knows more: (1) his 6-core machine boots OK, but emc's realtime code appears to never execute (2) some machines still black screen at boot-up, sometimes
[14:50:24] <skunkworks_> I didn't try to see if you get the tool prep issue in sim
[14:50:59] <aystarik> I've found it is possible to boot without initrd by compiling devfs in. Thus plymouth gets pretty irrelevant
[14:51:39] <aystarik> may be this helps with (2)?
[14:52:23] <jepler> I have not been involved enough to answer that.
[14:53:10] <aystarik> 6-core seems to be quite unusual for EMC, may be we can say that in release notes and move on? :)
[14:57:19] <cradek> aystarik: that's making many leaps of faith, including the one that says since this problem affects one six-core machine it will only affect six-core machines
[14:57:57] <cradek> aystarik: it would be helpful if you'd test the available packages on whatever systems you can
[14:58:31] <aystarik> only dual cores here...
[15:00:37] <cradek> skunkworks_: seems like the problem happens when you Tn and then *not* M6 and then external estop
[15:01:28] <skunkworks_> could be... (I have not been tool changing because it won't work yet)
[15:04:57] <skunkworks_> I just assumes that you are going to do a tool prep and change on the same line?
[15:05:03] <skunkworks_> *it
[15:06:52] <cradek> well I'm not saying it's not broken - I'm saying that's the more specific pattern I see
[15:08:35] <skunkworks_> heh
[15:08:56] <skunkworks_> (I am just glad it isn't noise!) :) :)
[15:11:34] <cradek> beware it may take us a few days to work up the nerve to look in iotask.cc
[15:12:07] <Jymmm> * Jymmm hands cradek the jug of liquid courage
[15:12:40] <skunkworks_> heh - again - I am just glad it wasn't something I was doing.
[15:13:01] <skunkworks_> *wrong
[15:13:46] <Jymmm> skunkworks_: If it was, it would have been an easy fix, but nooooooooooooo you have to find something broken, eeeeeesh ;)
[15:19:58] <micges> skunkworks_: I've reproduced this error too
[15:21:00] <skunkworks_> thank you
[15:28:40] <cradek> ARRRGH MY EYES!!
[15:29:17] <skunkworks_> heh - did you just look in iotask.cc?
[15:29:33] <cradek> yeah... (I had the name wrong: ioControl.cc)
[15:29:43] <skunkworks_> heh
[15:30:20] <micges> cradek: another reason to remove estop control from iocontrol.cc and move it to control.c
[15:30:59] <cradek> I'd be in favor of getting rid of the separate io program, if someone wanted to do the work and test it
[15:31:25] <cradek> we can't do it in 2.4 though, of course, so we still have to fix this with the smallest possible change
[15:32:07] <micges> I've done 3/4 of work in local git, but I don't know how to handle tool changer (too less time)
[15:32:38] <micges> cradek: I understand what can go to 2.4
[15:34:03] <cradek> if you are stuck, perhaps you should push your 3/4 done rewrite to a branch on linuxcnc (maybe someone would have finished it at cnc workshop had they known about it)
[15:34:17] <cradek> I put incomplete stuff on branches all the time :-)
[15:35:55] <micges> it was some time ago
[15:36:54] <micges> it seems that at workshop there wasn't much programming?
[15:37:23] <jepler> I notice that when I turn on RTAPI_MSG_DBG in iocontrol and turn on %B3 it prints EMC_TOOL_PREPARE
[15:37:34] <jepler> then task complains EMC_TOOL_ABORT timed out waiting
[15:37:35] <cradek> I did a lot (mostly right before workshop)
[15:38:33] <micges> and joint axes problems was discussed?
[15:41:09] <jepler> micges: no
[15:41:45] <jepler> why; are you waiting for some kind of decisions or discussion before working further on it?
[15:46:42] <cradek> jepler: also, if you T1M6 then wait for it to finish, then %B3, you get another EMC_TOOL_LOAD
[15:46:53] <cradek> maybe it resends the last message?
[15:47:21] <cradek> if you don't do anything between machine on and %B3, you get another EMC_LUBE_ON
[15:47:53] <jepler> cradek: I've been running task under the debugger, and the message it sends is from emcIoAbort
[15:48:02] <cradek> the extra EMC_LUBE_ON or EMC_TOOL_LOAD are invisible because they are no-op
[15:48:19] <jepler> so it's not clear to me what task is doing wrong, or whether it's a problem in io
[15:52:57] <micges> jepler: yes
[15:53:29] <micges> jepler: it's not clear to me how to change get_acc and get_vel in canon.cc
[15:54:06] <cradek> you mean to do joint constraints?
[15:55:11] <micges> that too
[16:02:33] <jepler> it seems the problem is that something in io (maybe the bit just after the read_hal_inputs() call) is putting a wrong number in echo_serial_number
[16:02:44] <jepler> in a later iteration, that makes the EMC_TOOL_PREPARE message look fresh
[16:02:46] <jepler> type=1104 serial_number=9 echo=8
[16:02:46] <jepler> EMC_TOOL_PREPARE
[16:02:46] <jepler> type=1104 serial_number=9 echo=10
[16:02:46] <jepler> EMC_TOOL_PREPARE
[16:02:48] <jepler> type=1103 serial_number=10 echo=9
[16:02:51] <jepler> EMC_TOOL_ABORT
[16:03:11] <micges> cradek: after achieve full gantry functionality I've don't developed ja3 from faburary
[16:03:13] <jepler> it's the same message (serial number 9) but it looks 'noew' again since echo is 10.
[16:06:09] <jepler> 'new'
[16:06:30] <cradek> emcioStatus.echo_serial_number = emcioCommand->serial_number+1; //need for different serial number, because we are pushing a new message
[16:06:38] <cradek> this screams at me, but I don't know what it's saying
[16:07:04] <jepler> I'm screaming too, as a matter of fact
[16:07:13] <cradek> I can understand that
[16:08:17] <skunkworks_> you guys are cool
[16:08:40] <cradek> yet so ineffective
[16:08:45] <skunkworks_> heh
[16:08:46] <jepler> that line's very old
[16:09:45] <jepler> I think the origin of the +1 is commit 405131d0129fbdaae5a8fde80a2a61265ff9601b
[16:09:48] <jepler> circa 2005
[16:10:21] <jepler> but to complicate things somebody ran indent and dos2unix and unix2dos a few times on the file in between
[16:10:29] <cradek> haha
[16:10:57] <jepler> yabosukz I suspect
[16:11:44] <cradek> I still do not understand the purpose of nose hair. yuck.
[16:14:43] <Jymmm> cradek: http://www.wisegeek.com/what-is-the-purpose-of-nose-hair.htm
[16:15:12] <Jymmm> cradek: http://krisdekker.files.wordpress.com/2009/10/nosehair2.jpg
[16:15:47] <jepler> * jepler resolves to not load an image named "nosehair2.jpg"
[16:16:46] <Jymmm> jepler: (it's not bad)
[16:16:50] <jepler> skunkworks_: let me know what this patch breaks: http://emergent.unpy.net/files/sandbox/0001-fix-TOOL_PREPARE-after-estop.patch
[16:17:08] <jepler> it does appear to get rid of the undesired TOOL_PREPARE action
[16:17:39] <skunkworks_> jepler: thanks - will try it very soon. (have to get git of 2.4.1)
[16:19:50] <cradek> I don't see any problem (at first glance) with that change
[16:20:06] <cradek> it gets rid of the extra messages I was seeing (not just prep)
[16:27:28] <dgarr> were there comments on this? http://www.panix.com/~dgarrett/stuff/m66problem.txt
[16:28:03] <jepler> I tested that the patch avoids the very slow move
[16:29:21] <cradek> the fix is probably fine - I tried to understand the base cause and see if it could be helped, but I didn't get very far
[16:29:46] <dgarr> is there something else you want me to do?
[16:31:09] <cradek> do you understand what causes the position to be changed just a tiny bit?
[16:31:18] <jepler> cradek: the base problem is that there's an interp::synch call in there, and the feedback position doesn't exactly match the old commanded position or something
[16:31:40] <cradek> oh ok
[16:32:35] <cradek> so it isn't a cumulative thing because of all those short moves
[16:32:42] <jepler> I don't think so..
[16:32:44] <CIA-2> EMC: 03jepler 07v2.4_branch * r6b1bc3d4575f 10/src/emc/rs274ngc/interp_find.cc: test for a tiny difference instead of fpoint equality
[16:32:51] <jepler> well, since chris ack'd it I'll put it in
[16:33:04] <jepler> dgarr: as always, thanks
[16:33:09] <cradek> should synch use commanded position instead of feedback?
[16:33:25] <jepler> dgarr: you are both a good troublemaker and troubleshooter
[16:33:31] <skunkworks_> ok - why doesn't git checkout RELEASE_2_4_1 work?
[16:33:34] <cradek> feedback is always quantized more
[16:34:03] <dgarr> jepler: it's because i use emc daily
[16:34:08] <jepler> skunkworks_: the release tags now have the form v2.4.1, not RELEASE_2_4_1
[16:34:20] <skunkworks_> ah - ok. I will update the wiki
[16:34:20] <jepler> skunkworks_: if it's still wrong somewhere please fix it
[16:35:06] <cradek> dgarr: I think you must use parts that others don't use much (for instance I doubt I've ever run a M66 command)
[16:35:55] <jepler> skunkworks_: actually I'll fix it on Installing_EMC2 on the wiki, if that's where you read it..
[16:36:53] <skunkworks_> yes
[16:36:55] <skunkworks_> thanks
[16:37:06] <dgarr> thanks for the commit, on a different subject, i'm not sure if this patch was noticed: http://www.panix.com/~dgarrett/stuff/0001-halshow-add-menu-options-for-load-save-exit.patch
[16:37:55] <cradek> dgarr: neat
[16:38:42] <jepler> it should use msgcat::mc here: + -title "Load a watch list"\
[16:39:11] <jepler> it would be nice if $menubar.file -postcommand would disable "save watch list" when it's inappropriate
[16:39:34] <jepler> besides that, I don't see a reason not to add this to master
[16:49:59] <dgarr> for msgcat: http://www.panix.com/~dgarrett/stuff/0001-halshow-use-msgcat.patch
[16:50:36] <jepler> OK, if you don't think you'll work on the -postcommand soon I'll squash and commit those two
[16:50:37] <dgarr> i will have to study how to disable when inappropriate as you mentioned
[16:54:50] <CIA-2> EMC: 03jepler 07master * r907ad600c519 10/tcl/bin/halshow.tcl: halshow: add menu options for load/save/exit
[16:56:08] <jepler> thanks for the patch
[16:57:05] <jepler> $menubar.file configure -postcommand { if {$::watchlist != ""} { $menubar.file entryconfigure ## -state normal } { $menubar.file entryconfigure ## -state disabled } }
[16:57:20] <jepler> where ## is the integer index of the menu, or [msgcat::mc "Save Watch List"]
[16:57:31] <jepler> probably the latter is better; it's more resilient against change in the menu structure
[16:57:48] <jepler> untested of course, but that's the general idea of using postcommand to make menu items (un)available at the right times
[17:13:06] <skunkworks_> sorry - when I do git checkout v2.4.1 I get a fatal: not a git repository
[17:18:40] <skunkworks_> wait - maybe I should read the directions more closely
[17:35:30] <alex_joni> cradek: that line in iocontrol was mine
[17:35:59] <alex_joni> (if my memory serves me right)
[17:36:14] <alex_joni> the idea is this: ioControl is a subordinate of emctask
[17:36:36] <alex_joni> it should only reply to commands from task (with an ack/nack - whatever those were called)
[17:36:51] <alex_joni> but along with ack/nack it would also send the entire status
[17:37:31] <skunkworks_> alex_joni: ! how is it going?
[17:37:39] <alex_joni> now the problem with ioControl (when HAL stuff was added - it was simIoControl before that) is that when an external thing changes (estop) you need to send a message from ioControl to task
[17:37:58] <alex_joni> that's pushing upstream, and you need a 'fake/bogus/whatnot' number so it gets accepted
[17:40:03] <alex_joni> jepler: ^^
[17:41:08] <Jymmm> alex_joni: If I understand correctly, in essence estop gets added to a queue (of sorts)?
[17:41:33] <alex_joni> I think it was this: http://git.linuxcnc.org/gitweb?p=emc2.git;a=commitdiff;h=405131d0129fbdaae5a8fde80a2a61265ff9601b
[17:42:03] <alex_joni> Jymmm: no, it's just the opposite - if you don't 'push' the message, it'll only get sent on the next query from task
[17:42:23] <Jymmm> ah
[17:42:27] <alex_joni> but either way, this isn't exactly estop.. it's a software gui thingie that displays estop state
[17:42:34] <alex_joni> estop needs to be addressed in hardware :D
[17:43:40] <skunkworks_> exactl!
[17:43:44] <skunkworks_> exactly!
[17:45:23] <dgarr> jepler: thanks for the lesson on entryconfigure: http://www.panix.com/~dgarrett/stuff/0001-halshow-only-show-Save-when-appropriate.patch
[17:58:59] <CIA-2> EMC: 03jepler 07master * rc27d6ca41a96 10/tcl/bin/halshow.tcl: halshow: only show Save when appropriate
[18:10:23] <jepler> yuck, the performance of goocanvas is pretty poor the way I'm using it
[18:10:46] <SWPLinux> with a name fitting goo*, is that a surprise? :)
[18:10:55] <jepler> displaying 3 traces each with 4k samples it's running at about 1fps
[18:11:16] <jepler> (this is in a 'roll'-type mode, so I have to recreate the paths each time)
[18:11:30] <SWPLinux> is there a grid display as well?
[18:11:46] <jepler> no, just the traces
[18:11:52] <skunkworks_> http://emergent.unpy.net/files/sandbox/0001-fix-TOOL_PREPARE-after-estop.patch
[18:11:54] <SWPLinux> (not that it should matter much, since there are 12k trace segments)
[18:11:58] <Skunkemc> thanks
[18:13:04] <jepler> actually I guess it's more like 2Hz, most polls of the captured data are under 500 new samples at 1 per ms
[18:13:16] <SWPLinux> pygoocanvas?
[18:13:18] <jepler> but still .. performance has got to be better than that
[18:13:19] <jepler> SWPLinux: yes
[18:13:44] <jepler> terrrible interface -- format your Path in an svg-like syntax then the internals of goocanvas have to parse all that data back out
[18:13:56] <SWPLinux> ugh
[18:14:09] <SWPLinux> openGL is probably faster
[18:14:36] <SWPLinux> there's a polyline equivalent in OGL, isn't there?
[18:15:15] <jepler> still, the time to generate the path data in Python is a small portion of the total redraw tiem. I can measure that as typically 70ms while the redraw part is taking the remainder of the 400ms+
[18:15:35] <jepler> SWPLinux: yes but in principle using pygoocanvas gets me good performance without opengl and also nice antialiasing
[18:16:05] <SWPLinux> ... if you actually get good performance
[18:16:09] <jepler> right
[18:16:30] <jepler> it seems like 12k segments is not asking very much
[18:16:35] <SWPLinux> no
[18:19:26] <jepler> I don't need the full generality of a Path; I should try Polyline instead
[18:21:50] <SWPLinux> there's a project called xoscope that might be interesting
[18:21:55] <SWPLinux> on sourceforge
[18:23:24] <jepler> MY EYES!
[18:23:28] <jepler> it's way too colorful
[18:24:19] <SWPLinux> heh
[18:24:32] <SWPLinux> I don't know if that's the 2.0 version
[18:24:39] <SWPLinux> it didn't look very gtk-ish to me
[18:27:05] <jepler> this API makes no sense to me: http://library.gnome.org/devel/goocanvas/unstable/GooCanvasPolyline.html#goo-canvas-polyline-new-line
[18:27:30] <jepler> oh, wait, I understand -- ... isn't more points; it's properties
[18:27:33] <jepler> nevermind
[18:29:40] <SWPLinux> do you actually have to pass in all 4000 XY pairs in the polyline call?
[18:31:35] <SWPLinux> oh wait, that makes a polygon - I think it may automagically connect the last point to the first point
[18:34:35] <jepler> polyline gets me 3fps
[18:34:41] <jepler> no, you have a choice of closed or open with polyline
[18:35:01] <SWPLinux> ok
[18:35:18] <SWPLinux> I just noticed that the example of ...polyline_new makes a filled triangle with only 3 points
[18:35:40] <jepler> I want to pass all the points (as opposed to at most one point for each X coordinate on the screen) so that in non-roll mode scrolling and changing time scale do not involve modifying the polyline object, only its transformation
[18:36:29] <jepler> (but that may be doomed to failure too, as anisotropic scaling means you get a brush that is not square, but is rectangular)
[18:37:45] <skunkworks_> jepler: the patch seems to work here for that issue.
[18:38:08] <jepler> skunkworks_: that's good news
[18:38:38] <skunkworks_> cool beans
[18:45:36] <jepler> 'perf report' shows I'm spending just shy of 70% of my time in libcairo, plus whatever is X server time. If that's all the faster cairo is, cairo-based rendering looks like a bust.
[18:46:36] <jepler> 50% is in the Python process and 30% is in the xorg process, so overall that's 80+% in cairo+xorg
[18:56:01] <jepler> with 3*320 samples it's quite responsive
[18:57:19] <jepler> http://emergent.unpy.net/files/sandbox/scopedemo.png
[19:21:56] <mshaver> Looking at http://www.linuxcnc.org/dapper/ I notice that there is no dists directory. Was there ever?
[19:22:53] <jepler> mshaver: breezy and dapper debs were organized differently. http://linuxcnc.org/emc2/
[19:23:07] <jepler> looking for something 'vintage'?
[19:24:00] <mshaver> Ahh, OK! Thanks! No 2.4 for them?
[19:24:05] <jepler> nope.
[19:24:39] <mshaver> I had a call from a guy with an old machine and wanted to upgrade him from 2.1.7 to something better.
[19:25:01] <cradek> dapper folks can update to the latest 2.3.x without a new OS
[19:26:07] <mshaver> That would be a big improvement. He had http://www.linuxcnc.org/dapper in his sources.list file.
[19:26:29] <jepler> I wonder where that came from
[19:26:49] <mshaver> No clue - predates me...
[19:27:16] <mshaver> Or he read it wrong to me over the phone...
[19:27:43] <jepler> well -- you have to modify sources.list to get 2.2.x or 2.3.x (as well as fix up configs)
[19:27:59] <jepler> maybe start here? http://mid.gmane.org/20100303131746.GA19962@unpythonic.net
[19:28:27] <jepler> .. and follow the wiki UpdatingTo2.3 section
[19:28:49] <jepler> and as far as making old configs work again, http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UPDATING sections 2 and 3 are relevant
[19:30:05] <alex_joni> ][
[19:30:20] <mshaver> Actually, we have replacement Hardy equipped hard drives with updated configs we can swap out for these folks. He's out of warranty, but we usually just provide service on a "forever" basis anyway.
[19:30:56] <mshaver> I just have to talk to the boss (Michelle) to see if that's what she wants to do.
[19:36:35] <jepler> I bet we've changed a few things since 2.1.7!
[19:38:52] <micges> just a few
[19:38:53] <alex_joni> heh
[19:39:15] <alex_joni> wonder how many pages of changelog...
[19:39:45] <alex_joni> probably less than a kernel point release
[19:40:53] <mshaver> The thing is, there's got to be some software stepping improvements in there too.
[19:41:39] <micges> surely in mesa stepgens
[19:42:47] <jepler> an upgraded hard drive won't give him a mesa card
[19:44:10] <jepler> src/hal/components/stepgen.c changes since 2.1.7: http://pastebin.ca/1892005
[19:44:39] <jepler> a5b0e07 stepgen reworked - new core step generator with high resolution feedback, and tweaks to the position
[19:44:42] <jepler> 940aadc doubled step rate for software step+direction on parport
[19:44:45] <jepler> ^^^ two of the exciting ones
[19:46:03] <micges> jepler: what git command to see this list ^^ ?
[19:47:05] <jepler> micges: git log --oneline v2.1.7..origin/v2_3_branch -- src/hal/components/stepgen.c
[19:47:32] <micges> thanks
[19:47:44] <jepler> restrict to a range of revisions with 'since..until', and to specified paths with '-- paths'
[19:47:57] <jepler> there's a lot of power in 'git log'!
[19:50:55] <mshaver> This is a software stepping (parallel port) machine, so I should see about getting him up to date, especially as his complaint resolves to "missing steps".
[20:03:06] <jepler> if f(theta)=cos(k*theta) then f'(theta) = k*sin(k*theta) or something like that?
[20:05:29] <cradek> -
[20:05:42] <skunkworks_> jepler: I do see that - if you hit the external estop while the tool prep is high - the axis estop won't go in until it gets the prepared signal.
[20:07:16] <skunkworks_> before - the tool prepare signal would go low during estop
[20:09:08] <skunkworks_> ^ forget the last statement. It did the same thing. the estop will not go in until the tool prepared goes high
[20:11:28] <skunkworks_> but the estop button in axis does set the tool prepare low when hit during the tool prepare cycle.
[20:17:16] <alex_joni> skunkworks_: sure, that direction is easy
[20:17:26] <alex_joni> the problem is with things coming from HAL
[20:18:15] <skunkworks_> sounds like a pain :)
[20:18:27] <micges> jepler: can you comment on this? http://www.pastebin.ca/1892022
[20:19:47] <jepler> I disagree absolutely with changes like this:
[20:19:47] <jepler> #
[20:19:48] <jepler> + ret = fgets(line, LINELEN, stdin);
[20:20:13] <jepler> the goal in making changes should seldom be to simply make the compiler shut up; it should be to make the software better
[20:20:34] <jepler> in the next version of gcc, there are "value assigned is never used" warnings, so you'll just put off the pain of actually solving any bug that might exist on that line to the future
[20:21:23] <cradek> if you want the compiler to just shut up about a certain thing, you can usually do that with -W... cflags
[20:22:24] <jepler> + unsigned char *p, ch = 0;
[20:22:38] <jepler> I am pretty sure the compiler is mistaken about ch being used unitialized. Here's why:
[20:23:10] <jepler> dbuf_get_byte can fail (not assigning to its second argument) in several specific ways: !di, !di->base, and di->offset == di->sz
[20:23:38] <jepler> .. but those exact conditions are checked in dbuf_get_string above the dbuf_get_byte call
[20:25:07] <jepler> is my analysis right or wrong? Well, if it's right, then no change is necesasry. If it's wrong, then you're taking away clues from a future, smarter person that would help find the bug.
[20:26:10] <micges> I just wanted opinion
[20:26:21] <jepler> I just gave you my opinion.
[20:26:55] <micges> I see it, thanks
[20:27:46] <micges> what about: emc/usr_intf/axis/extensions/emcmodule.cc:40:1: warning: "T_BOOL" redefined ?
[20:28:23] <micges> it was added before T_BOOL was defined or simply redefine T_BOOL size?
[20:53:48] <jepler> T_BOOL was added to Python in 2008. I'm not sure what the first version of Python is that has T_BOOL. http://bugs.python.org/issue1720595
[20:56:23] <jepler> the definition and behavior of T_BOOL in Python differs from the one in emcmodule.cc
[20:57:11] <jepler> so maybe the right fix is
[20:57:11] <jepler> +#undef T_BOOL
[20:57:11] <jepler> #define T_BOOL T_UBYTE
[21:02:39] <mshaver> jepler: Any thoughts on what this might mean:
[21:02:42] <mshaver> [15011.718875] axis[8888]: segfault at 00000000 eip b7de14da esp bfd67e88 error 6
[21:03:27] <mshaver> It's in the kernal log after EMC crashed.
[21:03:49] <cradek> what emc version?
[21:04:10] <jepler> it means axis did a NULL pointer dereference. The instruction pointer was b7de14da.
[21:04:25] <mshaver> I'd guess the latest of 2.3, but I can ask for specifics.
[21:05:40] <cradek> any other clues would be helpful too (like if the user can do a particular thing to cause it)
[21:05:55] <cradek> if it's new and/or random behavior, can't hurt to run memtest for a while
[21:07:38] <skunkworks_> matt! how was hgr?
[21:08:20] <mshaver> * mshaver is checking to see if Dave is still at work at Smithy to ask about these things
[21:12:10] <mshaver> skunkworks: Big. Full of stuff. For example, they had machine tools, rubber hose, a couple of safes, piles of circuit boards, etc.
[21:12:37] <skunkworks_> heh
[21:12:45] <skunkworks_> did steve make it out alive?
[21:12:45] <mshaver> 2.3.5
[21:22:59] <mshaver> cradek: 2.3.5 - I'm having Dave run memtest overnight to see how that end of things is doing. If that runs OK, I'll see if he can repeat the problem. He's experienced several crashes over the last few days; once after running a gcode program for 2 hours, this time while jogging.
[21:25:32] <mshaver> skunkworks: Ther was only a few hundred dollars damage done to Steve before he escaped. Nothing too serious. In fact he mostly bought shelving, so that's good!
[21:27:28] <skunkworks_> heh