Back
[06:09:28] <alex_joni> hey jthornton
[06:09:31] <alex_joni> all well on the forum?
[06:09:41] <jthornton> yes
[06:09:46] <alex_joni> good..
[06:09:53] <jthornton> how are you doing? any snow yet
[06:10:12] <alex_joni> nah.. 20C here
[06:10:35] <alex_joni> 68F in your silly units ;)
[06:10:43] <jthornton> lol
[06:19:43] <alex_joni> so still warm
[06:19:48] <alex_joni> how's your end?
[06:26:04] <skunkworks> alex_joni, did you see
http://electronicsam.com/images/house/stellabee3.JPG
[06:27:46] <jthornton> we had a cold spell but it is warm and wet now
[06:31:23] <skunkworks> cooling off here.. last sunday though it was 65f
[07:11:47] <alex_joni> skunkworks: poor defenseless kids
[07:12:00] <alex_joni> j/k .. very cute ;)
[07:14:00] <skunkworks> :)
[09:46:54] <jepler> anybody around who can test linuxcnc on lucid using a rtai package rebuilt with this patch?
http://emergent.unpythonic.net/files/sandbox/rtai-dfsg.patch (background:
http://mid.gmane.org/20131101024943.GA31516%40unpythonic.net )
[09:47:10] <jepler> I have only been able to compile-test it
[11:37:54] <cradek> unfortunately my test rtai machine has croaked (hardware)
[12:21:27] <seb_kuzminsky> jepler: do you want latency numbers or just "it boots & runs linuxcnc or it doesnt" testing? if it's the latter, would a VM work?
[12:56:42] <jepler> seb_kuzminsky: a vm would work
[12:57:05] <jepler> nothing about the change should pertain to latency, it's about whether some rtapi or hal component uses the deleted APIs and escaped my greps
[12:57:39] <seb_kuzminsky> i bet our test suite doesn't cover all of the rtai api :-(
[12:58:06] <cradek> wouldn't the build fail?
[12:59:08] <seb_kuzminsky> if the declaration was still in the header but the definition was no longer in any C file, you'd get a successful compile and a runtime failure
[13:00:29] <cradek> oh because they aren't really linked
[13:39:19] <jepler> well, there's the kernel module build's link checking which should report undefined symbols
[13:39:55] <jepler> I am slightly worried by mah's assertion that each file he copied was necessary to supply some symbol
[13:40:14] <jepler> because if that's accurate, then my assessment that most of the files are nops is wrong, but it looked quite clear cut to me
[14:56:44] <andypugh> Any thoughts about whether G85 should be changed?
[14:57:35] <andypugh> Our implemntation does not match what one would want, nor the way that Fanuc do it.
[15:02:34] <seb_kuzminsky> do you think we should rapid up from R to old_Z? are there any other issues with it?
[15:03:08] <andypugh> I don't know of any other issues, but I do think that one would anticipate a rapid to retract_height
[15:03:52] <seb_kuzminsky> i think so too, probably, but i'm not a real machinist
[15:04:16] <andypugh> I realise that we may have more users than Fanuc, so shouldn't be subject to their whims, but this is what theirs does:
http://www.helmancnc.com/fanuc-g85-boring-cycle-cnc-mill-programming/
[15:05:14] <seb_kuzminsky> haha
[15:05:39] <andypugh> Having tried to use G85 with a boring head, it is genuinely annoying that it wants to return all the way from R to old_Z at feed speed.
[15:05:58] <seb_kuzminsky> yeah, who's got that kind of time
[15:06:18] <seb_kuzminsky> that's a really nice diagram in the helman docs
[15:06:22] <seb_kuzminsky> very clear
[15:07:08] <andypugh> It's almost tempting to make our own versions for the canned cycles.
[15:08:38] <seb_kuzminsky> we have some words that try to say the same thing as those pictures:
http://www.linuxcnc.org/docs/2.5/html/gcode/gcode.html#sec:G80-G89
[15:08:56] <seb_kuzminsky> our words dont mention what should happen at the end if you're in g99 mode
[15:10:08] <andypugh> I think the only reason that G85 is different is that the other cycles all rapid-out from the bottom.
[15:10:10] <seb_kuzminsky> err, i mean if we're in g98 mode (retract to old z mode)
[15:10:23] <andypugh> (Other than G87, which exists but we deny exists)
[15:10:30] <seb_kuzminsky> heh
[15:11:21] <andypugh> This might be because a working version of spindle orient is new.
[15:11:47] <seb_kuzminsky> does g87 require spindle orient?
[15:11:54] <seb_kuzminsky> i dont think it should
[15:12:24] <andypugh> You think it could make the "unhook" move on the basis of actual spindle orientation?
[15:12:59] <seb_kuzminsky> maybe i'm misunderstanding g87
[15:13:20] <andypugh> I was going by the comments in convert_cycle
[15:17:00] <seb_kuzminsky> opened bug #337 to track this:
https://sourceforge.net/p/emc/bugs/337/
[15:21:18] <andypugh> I was just going to fix it :-)
[15:22:12] <seb_kuzminsky> dont let me stop you! :-)
[15:22:31] <seb_kuzminsky> i know i'd forget about it if i don't write it down
[15:43:40] <andypugh> fun to test, I don't have anything that bores in the UV plane...
[15:50:55] <seb_kuzminsky> axis sim 9axis?
[15:51:07] <andypugh> booting as we speak
[15:51:45] <andypugh> Hmm. No option 'grid_size' in section: 'DEFAULT'
[15:52:33] <cradek> if you touch it -- be careful to test switching between g98 and g99, and also switching between different cycles and whether the retract plane gets reset (or not) at the right times
[15:52:51] <cradek> I'll be sure to look at your patch :-)
[15:52:56] <cradek> thanks for working on it
[15:53:29] <andypugh> I wish I knew what the "right times" were
[15:53:41] <cradek> I think the docs say...?
[15:54:09] <andypugh> But it looks like a very small change, as all the calculations about what to do if old_z is below r etc are done elsewhere
[15:54:39] <cradek> > The initial (G98) plane is reset any time cycle motion mode is abandoned, whether explicitly (G80) or implicitly (any motion code that is not a cycle). Switching among cycle modes (say G81 to G83) does NOT reset the initial plane.
[15:54:52] <cradek> I meant initial plane, not retract plane
[15:55:13] <cradek> the retract plane is the explicit one, initial is the implicit
[15:55:42] <cradek> > G98 - retract to the position that axis was in just before this series of one or more contiguous canned cycles was started.
[15:56:58] <cradek> but yeah maybe you're not even touching those things, ignore me then
[15:57:34] <andypugh> Do you know why the code is duplicated for each plane?
[15:58:11] <cradek> I imagine it's only because that's the way someone managed to code it
[15:58:22] <andypugh> (At a guess, because of a limitation in how values are passed in C++)
[15:58:24] <cradek> iirc it's hairy code
[15:58:47] <andypugh> 6 almost-identical switch statments
[15:58:57] <cradek> that code's not C++ish iirc
[16:00:56] <andypugh> I think I see why, because there is no "variable" way to pick block->v_number or x_number etc etc (unless you got horrid)
[16:02:12] <cradek> I'm sure the right person could make that less duplicated-looking, but sometimes the cure is worse than the disease
[16:02:46] <cradek> hold your nose and do your one-liner fix and it will all continue to work perfectly and nobody will need to touch it until ~ 2020
[16:03:13] <jepler> Yeah, before making those kinds of changes you would want to make sure you had an extensive testsuite that would find your mistakes
[16:03:13] <andypugh> Yeah, but I had to change the one line 6 times :-)
[16:03:20] <cradek> at which point we'll both be retired and living in luxury
[16:04:05] <cradek> I think jepler is right, and also maybe was being serious
[16:05:14] <andypugh> I was hoping he was talking about refactoring all the duplicates, rather than changing the G85 behaviour?
[16:05:25] <cradek> I hope so
[16:05:58] <cradek> if you only change one (six) thing(s) I bet you can test it manually and be confidentish
[16:06:41] <andypugh> I think so. And as nobody except me and the guy on the forum have ever noticed....
[16:07:25] <seb_kuzminsky> tests/interp/g76 looks like it'd be a good starting place for writing g85 tests
[16:09:02] <andypugh> I would look, but then would I be expected to do the same for all canned cycles? And what to test for?
[16:09:48] <seb_kuzminsky> doing work does not obligate you to do more work later
[16:10:55] <cradek> these are the easiest tests - you write some gcode and look at it in the AXIS preview, and if it looks sane, you call sai's output right.
[16:11:09] <seb_kuzminsky> i would start by writing the test as a way to verify my understanding of the current behavior
[16:11:20] <cradek> but yes I agree you're certainly not obliged
[16:11:22] <seb_kuzminsky> then modify the test to describe the new behavior, and make it pass again
[16:11:28] <andypugh> I was going to test on my actual machine..
[16:11:58] <seb_kuzminsky> crazy talk
[16:13:06] <andypugh> <giggle> I am in user space. I have no idea how to print a debug clue :-)
[16:13:53] <andypugh> <closes the kernel log tail -f>
[16:16:34] <andypugh> In other news: Do we know if drogge and co are confident in their tooltable patch? They seem likely to put out the lathe with it, but actual machinists at Superior Roll and Turning keep getting tool table corruption
[16:18:52] * seb_kuzminsky shrugs
[16:19:24] <andypugh> Also, would it make sense to have a sub-tree in "sample configs" of "vendor configs" and put Smithy, CoolTool, Mesa in them?
[16:20:21] <andypugh> Unless anyone gets really insistent I have no expectation of having my tool table stuff ready for 2.6
[16:23:00] <cradek> solely taking my data from the forum (I have never built or run that patch) it seems broken in at least one assbitey way
[16:23:41] <cradek> but I am sure they have that information just like I do
[16:24:45] <andypugh> Yeah. I am a bit concerned that many folk seem to think it is an option to be cnsidered to be up to the standards we aspire to.
[16:25:37] <andypugh> (Some of us are aspiring further than others)
[16:29:32] <seb_kuzminsky> andypugh: don't rush your tooltable work, i'd really rather not add too many new features to 2.6 at this point
[16:30:01] <seb_kuzminsky> we have plenty of work cut out for us to get joints_axes and rtos/ub/etc reviewed & merged
[16:30:25] <andypugh> I havent done more than think about it (and get my machine understanding tools better) since the fest, to be honest.
[16:30:48] <andypugh> Indeed, I think the new tool table is 2.6.1
[16:30:53] <seb_kuzminsky> i hope to get 2.6 released sooner rather than later, but 'soon' is going to be long from now because of the huge amount of work piled up already
[16:31:31] <andypugh> Actually, it is probably 2.7, after a lot of testing as the new "master"
[16:31:37] <seb_kuzminsky> after 2.6 goes out, i'd like to advocate making 2.7 a smaller, quicker release, and if the tooltable work is ready i'd love to consider it at that time
[16:32:09] <seb_kuzminsky> yeah, no new features should go into point releases like 2.6.1 (except *maybe* new drivers that can't break anything else)
[16:33:04] <andypugh> So, if I am at Z2 and I do G98 G85 F10 R3 Z0 what should I expect? (note that current Z is below R)
[16:33:18] <seb_kuzminsky> the new tool table, the new trajectory planner, etc, are all fine candidates to merge into master shortly after the 2.6 branch is made, stabilized, and released as 2.7 a few months or so later
[16:34:39] <andypugh> Yes, they both need a lot of testing, they both stand a very good chance of breaking stuff. The other 2.6 stuff is a huge amount of "if it compiles, and it works at all, it's good" and "folk have run this side branch for years"
[16:37:06] <seb_kuzminsky> i think you should expect a rapid to Z=3 (R), then a feed to Z=0, then a feed to Z=3 (because g98 and R > initial_z)
[16:37:34] <seb_kuzminsky> this is my reading of the Canned Cycles section of the gcode docs
[16:37:52] <andypugh> Great. That's what I expected and what I got
[16:37:58] <seb_kuzminsky> oh good :-)
[16:39:30] <andypugh> Unfortunately, changing plane (without a G80) has sent me to Y=2 without me ever typing a Y2 command
[16:39:41] <andypugh> But I don't think that is me....
[16:40:01] <andypugh> <opens a normal VM>
[16:40:43] <seb_kuzminsky> wow, that sounds wrong!
[16:42:34] <andypugh> with sim axis-9axis
[16:42:48] <andypugh> start, home, etc
[16:43:27] <andypugh> G0 Z2 // G98 G85 F10 R1 Z0 // G18 // G98 G85 F10 R1 X0
[16:43:37] <andypugh> You end up at Y2
[16:44:25] <andypugh> Without a Y2 command
[16:44:42] <andypugh> We need to document that. (fixing it is harder) :-)
[17:08:11] <seb_kuzminsky> open a bug ticket pls
[17:09:35] <seb_kuzminsky> is it because the clear_z of the first g85 gets used as "clear_y" on the second one?
[17:10:11] <seb_kuzminsky> shouldn't g18 reset the clear_z plane, according to cradek's prognostication above?
[17:36:32] <andypugh> It's called clear_cc (third generic axis)
[17:37:22] <andypugh> And I am not sure how you "reset" it. Perhaps the answer is to force an implicit G80 on plane-change?
[17:49:57] <andypugh> G19.1 / / G98 G85 F10 R1 U0 raises a "U-value unspecified in VW plane canned cycle"
[17:50:10] <andypugh> That's not my bug, I suspect.
[17:52:24] <andypugh> Indeed not, interp_cycles.cc line 1390. Should I fix that now, or as part of a separate commit?
[17:54:58] <andypugh> It's a proper bug, should probably be pushed to 2.5...
[17:55:11] <seb_kuzminsky> without knowing what you're talking about, i'd think do it as a separate commit for that specific bug
[17:55:38] <andypugh> CHKS((!block->x_flag), _readers[(int)'u']? NCE_U_VALUE_UNSPECIFIED
[17:55:49] <seb_kuzminsky> lol
[17:56:00] <seb_kuzminsky> the blind copypasta strikes again!
[17:56:07] <seb_kuzminsky> andypugh is on a roll tonight
[17:57:52] <andypugh> Which branch should I fix that in?
[17:57:56] <seb_kuzminsky> convert_cycle_vw has the same problem
[17:58:39] <andypugh> That is VW
[17:58:47] <seb_kuzminsky> err, oh
[17:58:52] <andypugh> The rest all seem to work
[17:58:52] <seb_kuzminsky> i think 2.5, but that's cradek's call
[17:59:27] <seb_kuzminsky> you're right, it's just _vw that's wrong
[18:00:22] <andypugh> It's almost depressing, you do allthis work, and quite clearly no-body has ever done a VW canned cycle...
[18:00:59] <seb_kuzminsky> yeah :-/
[18:01:18] <seb_kuzminsky> all the common code paths have been thoroughly exercised and debugged, but all the corner cases still have lurking bugs
[18:01:46] <seb_kuzminsky> i bet 99% or more of our users use boring 2- or 3-axis machines
[18:02:53] <seb_kuzminsky> this is partially why i'm excited about this robot arm that i bought for our local hackspace:
http://highlab.com/~seb/linuxcnc/scorbot-er-3/1024131507a.jpg
[18:03:35] <seb_kuzminsky> to test joints_axes, and high-axis-count gcode
[18:04:00] <seb_kuzminsky> so make sure you get all the bug out before i get the robot hooked up
[18:05:20] <andypugh> U may be the least popular extra axis to do a canned cycle in. W is used a little bit, I reckon
[18:12:56] <andypugh> cradek?
[18:17:47] <seb_kuzminsky> bbl
[18:17:59] <seb_kuzminsky> thanks for all your debugging today andypugh
[18:22:27] <KGB-linuxcnc> 03andy 05v2.5_branch 6724bda 06linuxcnc 10src/emc/rs274ngc/interp_cycles.cc
[18:22:27] <KGB-linuxcnc> Fix a copy-paste error that gave an annoyingly wrong error message in VW plane canned cycles
[20:08:48] <KGB-linuxcnc> 03andy 05master 0a2f75e 06linuxcnc 10src/emc/ 10rs274ngc/interp_cycles.cc 10rs274ngc/rs274ngc_interp.hh * Make the behaviour of G85 more as-expected
[20:09:01] <jepler> so on BBB with the "machinekit" image, glxinfo says: OpenGL renderer string: Software Rasterizer
[20:09:17] <jepler> so it's rasterizing axis's plot on the slow cpu and then shipping bitmaps over the network
[20:09:58] <andypugh> That sounds suboptimal
[20:14:42] <jepler> I believe it is
[20:20:11] <jepler> this makes it use the glx wire protocol instead: sudo chmod 000 /usr/lib/arm-linux-gnueabihf/dri/swrast_dri.so
[20:20:14] <jepler> it's somewhat better performing
[20:20:28] <jepler> (still other than great, however)
[20:22:06] <jepler> next thing it would be nice to understand is why milltask takes 20%CPU when it's idle
[20:23:08] <andypugh> Maybe it checks to see if it is really idle more assidiously than necessary?
[20:29:54] <jepler> changing the task timeout to 10ms instead of 1ms knocks milltask way down
[20:30:24] <jepler> ssh encryption takes 30% CPU
[20:43:05] <jepler> this seems to be a bit lighter on the CPU: ssh -X -o "Ciphers=arcfour" linuxcnc@192.168.7.2
[20:45:51] <jepler> and changing the hardcoded time for backplot polling seems to help too
[20:45:52] <jepler> - o.after_idle(lambda: thread.start_new_thread(self.logger.start, (.01,)))
[20:45:55] <jepler> + o.after_idle(lambda: thread.start_new_thread(self.logger.start, (.05,)))
[20:47:30] <jepler> well that's all I've got for now. I suppose I should e-mail charles my findings.
[21:03:39] <skunkworks> logger[mah]:
[21:03:39] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-11-02.html
