Back
[09:32:05] <cradek> on github I'm looking at
https://github.com/LinuxCNC/linuxcnc/commit/0da9a50f30bb575d557b6617fa0fb0b228216f43
[09:32:20] <cradek> I wanted to add a comment, so I clicked the square plus sign
[09:33:00] <cradek> it let me type my comment but then said "You can't perform this operation at this time"
[09:33:53] <cradek> oh wait, it worked the second time
[10:28:00] <terkaa> hi
[13:40:54] <cradek> for(it++; it < settings->g71_blocks.end(); it++) {
[13:41:13] <cradek> wouldn't this skip the first thing?
[13:41:31] <jepler> if it = g71_blocks.begin() just before, yes.
[13:42:18] <cradek> oh, prev_motion = ...
[13:42:20] <cradek> it's on purpose
[13:42:29] <cradek> treats them pairwise
[13:42:42] <cradek> rtfc
[14:10:25] <terkaa> seb_kuzminsky: Did you find time to check my attempt of coding?
[14:10:34] <terkaa> Was it absolutely horrifying?
[14:10:37] <jepler> terkaa: seb_kuzminsky is away for a week
[14:10:55] <terkaa> Oh ok.
[14:11:18] <jepler> Looking at my logs I don't think he mentioned having a chance to look at your code.
[14:11:35] <jepler> I think all he said was
[14:11:36] <jepler> 08:41:58 <seb_kuzminsky> terkaa: yeah that's on the right track
[14:12:21] <terkaa> Yes that was comment for my git learning
[14:15:22] <jepler> + block->p_number == -1.0 ? settings->cycle_p : block->p_number;
[14:16:05] <jepler> for almost all letters, there is a _flag variable. New code is better checking block->p_flag rather than (block->p_number == -1.0)
[14:16:26] <jepler> you have done a good job of following the style of nearby code, I appreciate that.
[14:18:01] <jepler> lots of changed/added lines have extra whitespace at the end, I don't like that as much. "git rebase --whitespace=fix" can automatically fix this for you.
[14:18:45] <terkaa> Basically that is mostly Michael Haberlers old work(from 2013). I just modified it to work with current master and added Disable/enable speed/feed overrides
[14:18:50] <jepler> Without understanding what the new functionality *DOES* I think it all looks pretty reasonable.
[14:19:14] <terkaa> thank you for whitespace stripping tip
[14:19:42] <terkaa> It adds G84/G74 floating tapping cycles
[14:20:09] <terkaa> and possibility to enable/disable wait for spindle_at_speed before doing feed move
[14:20:47] <jepler> formerly it always waited?
[14:20:54] <terkaa> yes
[14:21:39] <terkaa> and that does not work with floating tapping. Because at the bottom when reversing spindle dir we need to start feed right away
[14:21:49] <jepler> cradek: do you want to have an opinion about this? It's
https://github.com/terkaa/linuxcnc master branch
[14:22:32] <jepler> terkaa: you've run the cycle on a real machine and it works, correct?
[14:22:34] <cradek> terkaa already fixed the problems I spotted regarding overrides
[14:22:56] <jepler> cradek: great to hear!
[14:23:05] <terkaa> jepler: Yes we have run it many days :)
[14:23:37] <cradek> terkaa: does your machine have a spindle-at-speed hooked up?
[14:23:53] <terkaa> cradek: Yes it does.
[14:23:56] <cradek> the part I worry about the most is breaking that and not noticing (because we have no test coverage)
[14:24:06] <cradek> great - the waiting still works as expected?
[14:24:57] <terkaa> Yes if I remove that wire physically feeds wont start
[14:25:13] <cradek> great
[14:25:15] <jepler> that's a good test, hard to put in the autmatic testsuite though
[14:25:25] <cradek> yeah - I'm glad you tried it
[14:25:27] <jepler> terkaa: are you comfortable enough with git to do the rebase to fix the whitespace?
[14:25:46] <terkaa> jepler: I can try my best
[14:26:04] <jepler> terkaa: OK, please do, and then create a pull request
[14:26:15] <terkaa> jepler: ok
[14:26:16] <jepler> let us know if you run into any trouble.
[14:27:55] <jepler> and thank you for your work!
[14:29:21] <terkaa> That is no problem. We need this on our machine and once it is in master, I can follow latest updates
[14:29:32] <terkaa> I got:Current branch master is up to date, rebase forced.
[14:29:32] <terkaa> First, rewinding head to replay your work on top of it...
[14:29:32] <terkaa> Fast-forwarded master to refs/remotes/origin/master.
[14:29:47] <terkaa> does that sound correct?
[14:31:35] <jepler> not quite
[14:31:57] <terkaa> hmmm....
[14:32:10] <jepler> do you have the linuxcnc github as the "upstream" remote?
[14:32:20] <jepler> or do you just have "origin" remote, which is your own github fork?
[14:32:54] <jepler> ("git remote" will list all the remotes you have)
[14:33:29] <jepler> (if you don't feel like learning that much git / github right this second, it's fine, I can do this "rebase" myself that I am requesting)
[14:33:40] <terkaa> [core]
[14:33:40] <terkaa> repositoryformatversion = 0
[14:33:40] <terkaa> filemode = true
[14:33:40] <terkaa> bare = false
[14:33:40] <terkaa> logallrefupdates = true
[14:33:40] <terkaa> [remote "origin"]
[14:33:44] <terkaa> url =
https://github.com/terkaa/linuxcnc.git
[14:33:46] <terkaa> fetch = +refs/heads/*:refs/remotes/origin/*
[14:33:48] <terkaa> [branch "master"]
[14:33:50] <terkaa> remote = origin
[14:33:52] <terkaa> merge = refs/heads/master
[14:33:54] <terkaa> [remote "upstream"]
[14:33:56] <terkaa> url = git://git.linuxcnc.org/git/linuxcnc.git
[14:33:58] <terkaa> fetch = +refs/heads/*:refs/remotes/upstream/*
[14:34:22] <jepler> OK, so you do have "upstream", that's good
[14:34:33] <jepler> try this as your rebase commandline: git rebase --whitespace=fix upstream/master
[14:34:57] <jepler> you should see:
[14:34:58] <jepler> First, rewinding head to replay your work on top of it...
[14:34:58] <jepler> Applying: G84/G74 canned cycles tests
[14:34:58] <jepler> Applying: Add G74/G84 floating tap cycles;
[14:35:10] <terkaa> First, rewinding head to replay your work on top of it...
[14:35:10] <terkaa> Applying: G84/G74 canned cycles tests
[14:35:10] <terkaa> Applying: Add G74/G84 floating tap cycles;
[14:35:17] <terkaa> yep it is same now
[14:36:26] <jepler> OK, now you can push with "git push -f". You have to say "-f" (force), because in this case you are modifying changes that you had already published with "git push".
[14:37:30] <jepler> looks like you did so already?
[14:37:41] <terkaa> Yes
[14:38:24] <jepler> at
https://github.com/terkaa/linuxcnc you can click "create pull request" and it should guide you through the process
[14:38:45] <jepler> first it will show you a page where you are "comparing changes", if that looks right then you "create pull request" a *second* time
[14:39:07] <jepler> then you fill in the title and description, and click "Create pull request" a *third* time. That's the last time.
[14:41:15] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15terkaa opened pull request #210: Adds G84/G74 Floating Tapping Cycles and Possibility to ignore Spindle_at_speed before feed move (06master...06master) 02
https://github.com/LinuxCNC/linuxcnc/pull/210
[14:42:50] <jepler> assuming the checks on travis-ci pass, cradek or I will merge it soon.
[14:43:13] <terkaa> Ok.
[14:45:07] <terkaa> jthornton?
[14:50:39] <andypugh> cradek: I think you are right that Type1 requires arcs <=90 degrees. But I am more interested in the fun parts of Type2
[14:51:54] <cradek> yeah, the geometry gets interesting
[14:52:10] <cradek> and gouge prevention
[14:52:17] <jepler> *** /home/travis/build/LinuxCNC/linuxcnc/tests/interp/g81/g19/g99: FAIL: result differed from expected
[14:52:30] <cradek> oops
[14:52:41] <jepler> terkaa: ^^ I think these changes in other tests are harmless but I'm not sure
[14:52:51] <andypugh> Is there a good reason not to merge the patch as-is? As long as it is undocumented people can’t complain if it doesn’t work :-)
[14:52:53] <jepler> many places there are two new canon calls to ENABLE_FEED_OVERRIDE and ENABLE_SPEED_OVERRIDE
[14:53:17] <terkaa> jepler: Yes I saw that...
[14:53:43] <cradek> hmm that smells suspicious, unless they were wrong before
[14:54:15] <jepler> cradek: I *think* it's OK...
[14:54:26] <jepler> now all(?) canned cycles save and restore the feed and speed override flags
[14:54:36] <terkaa> Yes
[14:54:37] <jepler> just like they all saved and restored the motion control mode before
[14:55:00] <cradek> aha
[14:55:24] <jepler> several sites, such as in Interp::convert_cycle_xy
[14:55:25] <cradek> wait, why?
[14:55:47] <terkaa> I tried also to pass previous state to G84/G74 function only.
[14:55:47] <cradek> most cycles should obey and not mess with those, right?
[14:56:00] <jepler> because Interp::convert_cycle_g74_g84 does
[14:56:16] <terkaa> But I got warnings about variable defined but never used
[14:56:39] <jepler> this save/restore could be moved into Interp::convert_cycle_g74_g84 couldn't it?
[14:57:28] <terkaa> GET_EXTERNAL_FEED_OVERRIDE_ENABLE() function did not work from
[14:57:34] <terkaa> Interp::convert_cycle_g74_g84
[14:57:44] <terkaa> It always returned 1
[14:59:07] <terkaa> I could not figure out why
[15:00:12] <jepler> that's very curious
[15:01:29] <terkaa> Then I tried passing states to of overrides to that function. But compiler reported warnings about variable defined but never used... So I ended up with this solution. But it seems that it needs some more work
[15:02:14] <terkaa> Because it messes up tests of another canned cycles
[15:03:11] <jepler> we could choose to accept the changes to the other tests, I don't think they're *wrong* they are just different than before
[15:03:39] <cradek> how do I see the difference?
[15:04:01] <jepler> no actually it *is* wrong
[15:04:06] <jepler> let me double check ...
[15:04:43] <jepler> here's what I get that I think is wrong:
http://paste.ubuntu.com/23487236/
[15:05:13] <jepler> 27/28 shouldn't enable the overrides
[15:05:16] <cradek> I agree that is wrong
[15:05:54] <jepler> this is a case that was not checked by the tests, in part because before now a canned cycle never changed these flags
[15:05:55] <terkaa> That is true
[15:06:35] <jepler> hmm double hmm
[15:06:45] <jepler> that could be a bug in the "rs274" program's saicanon though
[15:06:49] <jepler> src/emc/sai/saicanon.cc:800:int GET_EXTERNAL_FEED_OVERRIDE_ENABLE() {return 1;}
[15:06:57] <jepler> that implementation of GET_FEED_OVERRIDE_ENABLE is not very good
[15:07:03] <cradek> doh
[15:10:22] <jepler> does GET_EXTERNAL_SPINDLE_OVERRIDE_ENABLE really correspond with DISABLE_SPEED_OVERRIDE ?
[15:10:42] <jepler> unfortunate naming choice if so
[15:10:59] <terkaa> yes it does and it is confusing
[15:12:07] <terkaa> same with GET_EXTERNAL_FEED_OVERRIDE / ENABLE_FEED_OVERRIDE
[15:13:12] <jepler> the implementation of GET_EXTERNAL_FEED_OVERRIDE_ENABLE and GET_EXTERNAL_SPINDLE_OVERRIDE_ENABLE for task (emccanon.cc) looks right
[15:13:35] <jepler> so if your testing found that you were always getting 1/true for these GET_EXTERNALs, it is explained if you were using the rs274 standalone interpreter
[15:15:26] <terkaa> I tried using simulation with Axis. I had same code:
[15:15:27] <terkaa> save_feed_override_enable = GET_EXTERNAL_FEED_OVERRIDE_ENABLE();
[15:15:27] <terkaa> save_spindle_override_enable = GET_EXTERNAL_SPINDLE_OVERRIDE_ENABLE();
[15:15:39] <jepler> yeah AXIS has a bad implementation too
[15:15:42] <cradek> so we could fix sai and put it before terkaa's commit and it'll fix the tests?
[15:16:07] <jepler> cradek: no, the tests will still still fail due to differences
[15:16:53] <cradek> but you wouldn't get lines 27/28 when you do that thing
[15:17:13] <jepler> yeah *that* is fixed
[15:17:54] <terkaa> I can try to modify code so that these are inside Interp::convert_cycle_g74_g84 function
[15:18:12] <jepler> https://github.com/LinuxCNC/linuxcnc/commit/b624266abc220ef55b32bfe86a2cc4191077d879 https://github.com/LinuxCNC/linuxcnc/commit/d34932b97b2812d1246d67cccae44ccb66a2f73e
[15:18:18] <terkaa> But I am afraid it always enables speed/feed overrides
[15:18:59] <jepler> the first commit fixes GET_EXTERNAL_FEED_OVERRIDE_ENABLE() and GET_EXTERNAL_SPINDLE_OVERRIDE_ENABLE() for rs274 sai
[15:19:10] <cradek> yay, thank you
[15:19:11] <jepler> so test results will better match what will actually happen in task
[15:19:34] <jepler> then
https://github.com/LinuxCNC/linuxcnc/commit/d34932b97b2812d1246d67cccae44ccb66a2f73e which I didn't test very thoroughly moves the save/restore of the overrides into Interp::convert_cycle_g74_g84
[15:20:21] <jepler> it changes the order of the SET_MOTION_CONTROL_MODE in the g74/g84 tests but it makes it so all the other tests pass without changing their expected results
[15:21:00] <jepler> but now it makes me wonder if we should make sure and run the canned cycle tests (at least g74/g84) with both m48 and m49 settings
[15:22:19] <jepler> READ => m49
[15:22:19] <jepler> 26 N..... DISABLE_FEED_OVERRIDE()
[15:22:20] <jepler> 27 N..... DISABLE_SPEED_OVERRIDE()
[15:22:20] <jepler> READ => g84 x1 y1 z-1 r1
[15:22:20] <jepler> ...
[15:22:23] <jepler> 41 N..... DISABLE_FEED_OVERRIDE()
[15:22:23] <jepler> 42 N..... DISABLE_SPEED_OVERRIDE()
[15:22:37] <jepler> that looks good testing by hand
[15:25:09] <bpuk> andypugh: which of the g71 patches did you fixup from the 2012 thread?
[15:25:48] <andypugh> Whichever one the link in the first message was to
[15:26:14] <terkaa> jepler: This is how I tried it first. I cannot understand why it did not work. What happens with m48?
[15:26:28] <andypugh> bpuk: So,
http://www.bpuk.org/linuxcnc/g71-patch-1-initial-feedback-mod.diff
[15:26:56] <bpuk> andypugh: it's been 4 years, and I can't remember what I changed between mods - but the latest was
http://bpuk.org/linuxcnc/g71-patch-2-initial-feedback-mod2.diff
[15:27:14] <andypugh> Hmm, OK
[15:27:51] <jepler> terkaa: discovering the implementation of GET_EXTERNAL_FEED_OVERRIDE and GET_EXTERNAL_SPINDLE_OVERRIDE_ENABLE in rs274 sai was bad explains that though
[15:28:04] <andypugh> Is that a diff from patch1 or a diff from master?
[15:28:22] <bpuk> looks like a diff from master at the time
[15:28:22] <jepler> doesn't it?
[15:28:55] <andypugh> It might take someone better at git than me to merge them
[15:29:01] <terkaa> jepler: Yes. Also I had restoring of states in incorrect place
[15:29:38] <bpuk> I'm comparing the diffs by hand at the moment to see if there were any major changes - so far it's all error messages
[15:29:48] <terkaa> inside Case: Plane XX
[15:30:30] <terkaa> But now it is like it should be IMHO
[15:30:49] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #210: I suggest moving the restores of the override state into the g74/g84-specific code:... 02
https://github.com/LinuxCNC/linuxcnc/pull/210#issuecomment-261070529
[15:30:55] <jepler> terkaa: OK, my change makes sense to you then?
[15:31:08] <terkaa> jepler: Absolutely
[15:32:16] <skunkworks> bpuk, good to see you!
[15:34:04] <jepler> hm now I'm surprised by something else..
[15:34:27] <jepler> https://github.com/LinuxCNC/linuxcnc/commit/d34932b97b2812d1246d67cccae44ccb66a2f73e#diff-3900a70bfb5b0db5691f293c4b5c7539R74
[15:34:46] <jepler> it adds some speed/feed override enables where they didn't exist before!
[15:35:33] <jepler> and removes some from where they were before
https://github.com/LinuxCNC/linuxcnc/commit/d34932b97b2812d1246d67cccae44ccb66a2f73e#diff-eb388368c7bcfe43d093b05fcd618dfaR17
[15:35:47] <jepler> afk
[15:36:33] <bpuk> thanks skunkworks
[15:37:34] <bpuk> ok, it looks like there were a few important changes between the two patches mentioned - daft things like checking the spindle is started, and a bit of a refactor moving towards having an arbitrary profile that can be used for any canned cycle (at least that was the idea)
[15:38:19] <bpuk> and a possible fix for the odd retract too
[15:43:35] <terkaa> This is not correct test
[15:44:28] <terkaa> this is G81 drilling cycle test
[15:45:15] <terkaa> there is no spindle counterclockwise, no dwell and there is traverse movement that should be feed
[15:46:08] <terkaa> Should be like this:
[15:46:09] <terkaa> N..... STRAIGHT_TRAVERSE(1.0000, 1.0000, 1.0000, 0.0000, 0.0000, 0.0000)
[15:46:09] <terkaa> N..... DISABLE_FEED_OVERRIDE()
[15:46:10] <terkaa> N..... DISABLE_SPEED_OVERRIDE()
[15:46:10] <terkaa> N..... STRAIGHT_FEED(1.0000, 1.0000, -1.0000, 0.0000, 0.0000, 0.0000)
[15:46:10] <terkaa> N..... STOP_SPINDLE_TURNING()
[15:46:10] <terkaa> N..... START_SPINDLE_COUNTERCLOCKWISE()
[15:46:12] <terkaa> N..... DWELL(0.0000)
[15:46:14] <terkaa> N..... STRAIGHT_FEED(1.0000, 1.0000, 2.0000, 0.0000, 0.0000, 0.0000)
[15:46:16] <terkaa> N..... STOP_SPINDLE_TURNING()
[15:46:20] <terkaa> N..... START_SPINDLE_CLOCKWISE()
[15:46:55] <terkaa> that is for g84/g17/g98
[15:47:54] <cradek> bpuk: thanks for coming back and still being interested in this :-)
[15:48:22] <bpuk> thank andy - he poked me ;)
[15:49:14] <bpuk> I have to admit - I'm looking at some of the code and asking myself 'what was I thinking'
[15:49:50] <andypugh> bpuk: Did you see cradek’s comments here? (Not a very convenient format to read comments in)
https://github.com/LinuxCNC/linuxcnc/commit/0da9a50f30bb575d557b6617fa0fb0b228216f43#commitcomment-19846413
[15:50:13] <cradek> there's also a new mailing list thread
[15:50:17] <cradek> in -devel
[15:51:41] <bpuk> andypugh: I did - which was why I asked which patch you'd started from
[15:51:50] <jepler> terkaa: well for now what I'm going to do is put the saicanon.cc change on our master branch.
[15:52:07] <bpuk> cradek: Yup, I've caught up on that thread
[15:52:44] <bpuk> I think I'll pull that branch, and create a new diff to bring it up to my latest patch if that's ok?
[15:52:48] <terkaa> jepler: ok
[15:53:03] <jepler> terkaa: write us a note on the pull request after you've updated your master branch in a way that allows all tests to pass. Remember that you can "git fetch upstream; git rebase upstream/master" to have my fix to rs274 saicanon in your branch..
[15:53:50] <cradek> bpuk: that's great, you could even make a pull request on it directly
[15:54:12] <jepler> terkaa: makes sense?
[15:54:19] <andypugh> bpuk: Yes, that seems like the best way.
[15:54:32] <terkaa> jepler: yes it does
[15:55:40] <andypugh> bpuk: I am actually working on a version using remap. But _not_ because I don’t think it belongs in the C++ code, because I am interested in the logic of a type-2 version.
[15:56:06] <andypugh> And it’s just easier and quicker to fiddle with Python than C++
[15:57:00] <bpuk> andypugh: If you speak python, that's probably the best way.
[15:57:20] <andypugh> Well, I speak C better than Python, but C++ hardly at all.
[15:57:55] <jepler> C++ is just C with an accent it likes to think of as posh.
[15:58:18] <bpuk> heh. I'm more comfortable with C, or assembler - I've never got my head around the more modern languages properly
[15:58:27] <andypugh> Yes, I can read it, but not write it. Like I can understand posh English, but not speak it.
[15:58:38] <pcw_mesa> andypugh not sure if you got my irc response: the -M encoder flag works fine
[15:58:49] <andypugh> pcw_mesa: Great
[15:59:35] <pcw_mesa> I can now unplug my 24 bit SSI encder and plug it back in again and end up in the same place :-)
[16:00:03] <jepler> pcw_mesa: that's super neat
[16:00:43] <pcw_mesa> Yeah you dont always want wrapping enabled
[16:01:17] <pcw_mesa> I did uncover terkaa's DPLL bug
[16:02:31] <KGB-linuxcnc> 03Andy Pugh 05master 73e6860 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=73e6860
[16:02:51] <jepler> pcw_mesa: is it in the FPGA or in the hal component?
[16:03:09] <pcw_mesa> hal
[16:03:28] <andypugh> The DPLL bug?
[16:03:37] <andypugh> Oh, I assumed it was in the firmware
[16:03:50] <pcw_mesa> timer setting doesn't work right
[16:03:53] <jepler> pcw_mesa: in that case tell us more
[16:04:16] <KGB-linuxcnc> 03Jeff Epler 05master 2b678aa 06linuxcnc 10src/emc/sai/saicanon.cc rs274 sai: Properly implement two GET_EXTERNALs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2b678aa
[16:04:44] <pcw_mesa> well it works right in all my example files but mr terkas did some oddball stuff that exposed a bug
[16:05:24] <bpuk> bah, need to reboot
[16:05:32] <jepler> that's better than a bug that affects all or default configs at least
[16:05:50] <pcw_mesa> if you set timer 1 it works
[16:05:52] <pcw_mesa> if you set timer 2 but never set timer 1 timer 2 is never updated
[16:06:04] <pcw_mesa> same for 3,4
[16:07:47] <pcw_mesa> the default timer values (+100 usec) are not written correctly ether
[16:08:14] <jepler> OK, I'll open a github issue with that info so it doesn't get forgotten
[16:08:30] <pcw_mesa> timer 1,2 share a 32 bit register as do 3,4
[16:08:36] <jepler> yeah I see that in the source already
[16:08:51] <jepler> buff = (rtapi_u32)((-*hm2->dpll.pins->time2_us / period_us) * 0x10000) << 16
[16:08:54] <jepler> | (rtapi_u32)((-*hm2->dpll.pins->time1_us / period_us) * 0x10000);
[16:08:57] <jepler> if (buff != hm2->dpll.timer_12_written){
[16:09:03] <jepler> but I still didn't spot the bug yet
[16:09:16] <pcw_mesa> they probably should use a shadow register and always write all
[16:09:58] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened issue #211: hm2 dpll: reportedly, setting even-numbered timers doesn't work 02
https://github.com/LinuxCNC/linuxcnc/issues/211
[16:10:40] <pcw_mesa> used raw-read to see what was going on
[16:11:08] <jepler> afk again. I hope to get at least one solid day during the holiday weekend to work on hostmot2 though.
[16:11:11] <pcw_mesa> quite weird
[16:11:30] <jepler> pcw_mesa: so if you set 1 and 2, it does raw-read back as expected?
[16:11:40] <pcw_mesa> yes
[16:11:44] <jepler> (by setps before starting hal threads I imagine)
[16:12:10] <pcw_mesa> naturally all my test code either just used timer 1 or setp all timers
[16:12:40] <pcw_mesa> and those both work fine
[16:25:23] <terkaa> jeppler: Made corrections as suggested
[16:40:42] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15terkaa commented on issue #210: Issues should be fixed now 02
https://github.com/LinuxCNC/linuxcnc/pull/210#issuecomment-261088929
[16:45:37] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15terkaa commented on issue #210: It seems I still have some work with Expected test...... 02
https://github.com/LinuxCNC/linuxcnc/pull/210#issuecomment-261090138
[16:57:48] <bpuk> I always forget how many dependencies there are to compile linuxcnc
[17:43:50] <andypugh> bpuk: Do you know the checkbuilddeps way to get the list?
[17:44:43] <andypugh> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Installing_LinuxCNC#Resolving_outstanding_build_dependencies
[17:52:30] <bpuk> yup, got it checked out and built - will start patching tomorrow
[17:52:45] <bpuk> and try to think of evil gcode that will break it
[18:05:28] <andypugh> cradek (I think) listed some things. Arcs > 180 seem like one thing to check.
[18:27:56] <skunkworks> zlog
[18:55:23] <cradek> wonder if dragon/todd and bpuk have talked...
[18:57:48] <skunkworks> Probably not - I wonder if dragon would get on irc
[21:37:41] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15robEllenberg commented on issue #134: This sounds like a potential issue for end users too. It would be useful to have a g-code command to change the blending mode without changing tolerance values. If we had that, then the state restore could use it. Another possibility is to store the tolerance as part of the tag (then restore it). That way, it would work even if the user changed tolerances during the program. 02 http