Back
[07:38:15] <terkaa> hi all
[09:23:22] <jepler> I need to work on uspace+rtai and see what's up. iirc the threads.0 test failed sometimes, indicating possible violation of the rate monotonic scheduling promise.
[09:26:34] <jepler> also I need to work on rtai packaging so that there is an "rtai-dev" package that linuxcnc can depend on at build time
[09:31:06] <jepler> difficulty: we don't really have an rtai kernel on debian jessie that we're confident of, let alone for amd64 which is all I use anymore
[09:55:54] <mozmck> I think this commit fixes issue #177
https://github.com/mozmck/linuxcnc-mirror/commit/9c4432163274d0c978cd3bbb041e91b2459a88d7
[09:56:19] <mozmck> I tested with G64, but not with G61
[10:19:33] <jepler> hm
[10:19:47] <jepler> side thought, does state tags explicitly restore the P- Q- values when G64 is in effect?
[10:22:39] <cradek> looks like not currently
[10:26:16] <jepler> second hmmm: does it restore modifications to the coordinate systems (via g10 for example)
[10:26:21] <cradek> see Interp::gen_g_codes() case 11
[10:26:46] <cradek> no, just which one is active
[10:26:58] <jepler> ok
[10:27:19] <cradek> pretty much what you see in the active gcodes readout is what's saved and restored
[10:28:04] <jepler> fair enough
[10:28:30] <jepler> part programs that modify coordinate systems are probably relatively few
[10:28:43] <jepler> similarly, ones that change G64 P- Q- values during the run
[10:28:59] <jepler> hmmm
[10:29:08] <jepler> programming G64 on its own nullifies previous P- and Q- settings?
[10:29:33] <cradek> PQ might get lost, if you do G64 PQ, (abort here) ... G61 (readahead to here)
[10:29:43] <cradek> yeah I was just thinking along those lines
[10:30:15] <jepler> origin/statetags is the latest / merge candidate branch right?
[10:30:19] <cradek> yes
[10:31:06] <mozmck> So would it not be better if abort did not reset G64? Only reset it when explicitly told to?
[10:31:41] <mozmck> That's what my patch for 2.7 does (unless I missed something).
[10:32:16] <jepler> cradek: but doesn't state tags generate bare G64 regardless of whether G61 or G64 is active?
[10:32:23] <jepler> afk
[10:32:35] <cradek> no, it only generates the reset commands that are needed
[10:32:42] <cradek> (if I understand it right)
[10:33:25] <cradek> fwiw, the conversation we have is this:
https://github.com/LinuxCNC/linuxcnc/issues/134
[10:35:00] <cradek> mozmck: maybe we need to save the PQ with the g[11] (control mode) tag, and restore them
[10:35:12] <cradek> talking about statetags now
[10:35:33] <cradek> I think your change to just not mess with it is right for 2.7
[10:35:49] <mozmck> yeah, I guess that is in the case that someone changes G64 settings in mid program?
[10:36:08] <cradek> yes
[10:36:37] <cradek> you might not be aware that the motion mode does get changed implicitly sometimes - at least canned cycles do it
[10:36:48] <cradek> and g76 might, not sure
[10:37:12] <mozmck> I guess changing G64 mid-program could be interesting as a gag :-) Part program looks one way and the actually cutout wildly different.
[10:37:14] <cradek> and the new floating tap cycles that [forget his name] is working on
[10:38:04] <mozmck> G64 is a motion mode? - no I was not aware it got changed implicitly.
[10:53:15] <skunkworks> drilling cycles change to g61 iirc (that is how i found out my tuning wasn'
[10:53:19] <skunkworks> t the greatest
[10:53:28] <skunkworks> ' is too close to the enter key
[11:30:54] <jepler> zlog: ?
[11:32:28] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #134: I have a concern about G64—it looks like programming G64 alone resets the P- and Q- values, and that state tags will do exactly this. I'm not entirely sure how to test this given that #177 is also affecting whether P- and Q- are retained. See IRC conversation:
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-11-15.html 02
https://github.com/LinuxCNC/linuxcnc/issues/
[11:43:56] <mozmck> micges did test the other night and verified that Q was retained - only P was reset.
[11:44:28] <cradek> in statetags?
[11:47:36] <mozmck> no, we were only looking at 2.7
[11:48:06] <mozmck> So that might not be relevant to statetags
[12:53:30] <andypugh> Does anyone know who “dragon” the G71 guy is?
[12:55:28] <cradek> yes, he was at fest
[12:55:42] <andypugh> Is he a Todd we know, or a new Todd?
[12:55:56] <andypugh> (Todd Zuercher, for example)
[12:56:09] <cradek> he's not that one
[12:56:24] <andypugh> I am not clear how far he has got with G71, ie if he has code already
[12:56:54] <cradek> I don't know either
[12:57:20] <cradek> there are sure some starting points he might have
[12:57:34] <cradek> many people have worked on this
[12:57:39] <cradek> bbl, lunch
[13:08:35] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15tseufl opened pull request #208: docs: 2.8 and later, new/actual images (06master...06docs-2.8-new-images-(en)) 02
https://github.com/LinuxCNC/linuxcnc/pull/208
[13:10:45] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15tseufl opened pull request #209: docs: 2.8 and later, new templates for svg-images (06master...06docs-2.8.new-images-(tmpl)) 02
https://github.com/LinuxCNC/linuxcnc/pull/209
[13:26:18] <andypugh> I had a look through a thread about a previous attempt:
[13:26:19] <andypugh> https://sourceforge.net/p/emc/mailman/emc-users/thread/000601cd831d%24bc81b600%2435852200%24%40org/#msg29723177
[13:27:10] <andypugh> And it went the way of many such things, I suspect. Somebody says “here is a cool new think I have spent months of my life on” and The Usual Suspects say “Oh, no you have done that all wrong, that isn’t how it should be”
[13:32:19] <cradek> one sentiment dragon expressed was trepidation about mh's response
[13:33:01] <cradek> someone else used remap and ended up having to require use of G0.1 G1.1 G2.1 etc to program the shape
[13:33:22] <cradek> so, using remap gave a worse solution for the user
[13:33:27] <jepler> meanwhile I still have trepdiation about remap at all, and yet it's in linuxcnc.
[13:33:43] <cradek> sure
[13:40:13] <cradek> I think the part where you can use a gcode sub for tool change is great
[13:40:29] <andypugh> Well, luckily, nowadays we are perfectly at liberty to ignore mh
[13:40:31] <cradek> but the whole python thing is bordering on crazy
[13:40:41] <jepler> the design of the python part is really bad.
[13:40:53] <cradek> andypugh: as you might imagine, several of us told dragon that quite clearly
[13:41:13] <jepler> I continue to work on being less a naysayer myself, but please speak up if I start doing it.
[13:41:23] <jepler> like I'm doing right now :-/
[13:41:54] <andypugh> I just tried applying the Ben Potter patch, and it didn’t take.
[13:42:04] <andypugh> (though wasn’t far off)
[13:42:36] <cradek> I don't remember seeing ben's patch
[13:42:50] <cradek> that might be a good starting point for todd
[13:43:05] <cradek> or maybe they could work together
[13:43:05] <andypugh> https://sourceforge.net/p/emc/mailman/emc-users/thread/000601cd831d%24bc81b600%2435852200%24%40org/#msg29723177
[13:43:25] <cradek> yeah I'm looking at it now, thanks
[13:44:17] <andypugh> I think I have a reasonable algorithm in my head, but feel that it would be much easier to debug in Python.
[13:46:20] <cradek> _setup.g71_blocks.push_back(*eblock);
[13:47:04] <cradek> interesting, he saves the blocks, not the moves (interp_queue.cc) as I would have done
[13:48:11] <cradek> I would have used an O sub to describe the profile, and he says: + /* stuff for lathe canned cycles (g70/g71) control - TODO: See if this should/can be merged in with o word control */
[13:48:22] <cradek> so he was thinking along those lines too
[13:48:36] <cradek> I see nothing crazy about this patch as a starting point
[13:48:55] <andypugh> I was definitey going to save the end points, arc centres and motion type
[13:49:00] <andypugh> in a list
[13:49:33] <andypugh> He seems to have done all the hard integration work
[13:49:46] <cradek> yeah
[13:50:20] <andypugh> But he thinks the algorithm is not so robust, and it only handles monotonic profiles
[13:50:24] <cradek> I would have used the interp_queue that cutter comp uses, so as to not invent another queue type
[13:50:47] <cradek> my understand is that only handling monotonic profiles (and giving good errors otherwise) is perfectly fine and expected
[13:50:51] <cradek> understanding
[13:51:06] <cradek> the commercial users call this "type 1" roughing cycles and it is what's common on controls
[13:51:15] <andypugh> There are versions (Type II G71) that handle “pockets"
[13:51:36] <cradek> yes but I understand it's both rare and unneeded
[13:51:39] <andypugh> And that seems like a reasonable ambition.
[13:51:56] <andypugh> And would _finally_ allow us to make use of frontabgle and backangle :-)
[13:52:02] <cradek> heh
[13:52:25] <cradek> I wonder if ben's implementation allows you to still use cutter comp
[13:52:32] <cradek> that's critical
[13:52:51] <andypugh> Maybe not as critical as you think.
[13:53:29] <andypugh> The (G70?) finishing pass just needs to call the O-sub as a normal sub with cutter comp on
[13:53:55] * cradek squints
[13:55:06] <cradek> are you sure ccomp would always make you cut more on a monotonic profile?
[13:55:25] <andypugh> I have hardly ever felt the need to use cutter-comp on the lathe. I guess it would matter when doing a taper to a shoulder when both needed to contact. But otherwise in most lathe work as long as length and sdiamter are OK you are not _very_ concerned about the radii being exact.
[13:56:02] <cradek> but tapers or arcs end up in the wrong places and the wrong sizes
[13:57:01] <cradek> I guess maybe people mostly use the cycle to cut a square shoulder
[13:57:06] <cradek> then it sure wouldn't matter
[13:57:44] <andypugh> Well, a sequence of diameters conected by _a_ radius, I would guess
[13:58:05] <cradek> ?
[13:58:08] <andypugh> But I doubt that most folk even measure their radiuses in lathe work.
[13:58:21] <andypugh> But that is not an excuse to do the job wrongly.
[13:58:45] <cradek> a roughing cycle that can't use ccomp is better than no roughing cycle
[13:58:56] <cradek> but it is very inferior to one that can
[13:59:45] <cradek> so if your design doesn't allow it, you have probably chosen a wrong design
[14:00:05] <cradek> I bet we're not disagreeing :-)
[14:00:45] <jepler> cradek: doesn't this line of argument make you conclude you do have to have a separate queue for the lathe cycles than for cutter comp?
[14:01:24] <cradek> yes
[14:01:58] <cradek> ben's patch has that; my idea of using the interp_queue would also (you just make a second one)
[14:02:22] <jepler> ah true, you can have two things of the same kind in a C++ program
[14:02:39] <cradek> heh
[14:03:34] <cradek> I guess you'd have to change qc() so you can new it or something like that
[14:03:37] * cradek waves his hands
[14:05:36] <cradek> Maybe we can agree on a standard syntax on it in RS274 space. I mean you can intersperse ';py,<some python statement>' into the LinuxCNC dialect now
[14:05:46] <cradek> srsly?
[14:06:40] <jepler> I sure did not know that
[14:08:05] <cradek> oh look:
https://sourceforge.net/p/emc/mailman/message/29729806/
[14:08:10] <cradek> I guess past-me was there
[14:08:20] <cradek> and I was approximately the same as I am now
[14:45:54] <andypugh> OK, the Ben Potter patch compiles.
[14:48:20] <jepler> they colored it like a "fischer-price my first 3d printer"
https://www.amazon.com/dp/B01EWGJAS0
[14:48:54] <andypugh> Hmm, perfect christmas present
[14:49:21] <andypugh> non-heated print bed for child safety
[14:49:30] <andypugh> Way to make a bug into a feature!
[14:49:34] <jepler> heh
[14:53:46] <andypugh> Not only does the patch compile, it works:
https://imagebin.ca/v/326KODteOwbz
[14:54:13] <andypugh> We could probably have had this for years.
[14:55:41] <cradek> looks correctly comped
[14:56:32] <andypugh> It’s not 100%, the retract X before the retract Z is in the wrong direction
[14:57:12] <cradek> so, only the hard parts are done?
[15:02:04] <KGB-linuxcnc> 03andypugh 05BenPotter/G71 0da9a50 06linuxcnc 10(10 files in 3 dirs) G71: Ben Potter patch (very) slightly re-worked for 2.8 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0da9a50
[15:04:00] <terkaa> hello
[15:04:09] <andypugh> I still think using an O-sub block rather than line numbers is neater, if only because it maks it possible to not run the actual profile.
[15:05:33] <cradek> yes I would like to see that change to his patch too
[15:05:58] <andypugh> Pity that someone on the LinuxCNC sourceforce page gave it a 1-star “I loved this” rating
[15:23:57] <andypugh> I am tempted to try it on metal…
[15:31:49] <skunkworks_> andypugh, video...
[15:31:49] <skunkworks_> andypugh,
http://bbs.homeshopmachinist.net/threads/71954-John-stepper-motor-gear-hobber
[15:37:54] <andypugh> I didn’t know that JS had succumbed to LinuxCNC :-)
[16:44:58] <skunkworks> zlog
[16:45:24] <skunkworks> only for hobbing... ;)
[16:45:59] <jepler> make a machine for both gear hobbing and knob knurling. call it the "hob knob".
[17:22:51] <skunkworks> Heh