Back
[00:09:04] -!- Patang [Patang!~freenode@cm-84.208.100.218.getinternet.no] has joined #linuxcnc-devel
[00:13:06] <pcw_mesa> Yay! Found the DPLL bug
[00:50:08] -!- Patang has quit [Ping timeout: 260 seconds]
[01:14:19] -!- Patang [Patang!~freenode@cm-84.208.100.218.getinternet.no] has joined #linuxcnc-devel
[01:24:24] -!- marshmn has quit [Ping timeout: 258 seconds]
[02:02:00] -!- tchaddad has quit [Ping timeout: 260 seconds]
[02:29:20] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:589:8201:bbc0:34b7:f862:221:49b1] has joined #linuxcnc-devel
[02:29:34] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:589:8201:bbc0:34b7:f862:221:49b1] has parted #linuxcnc-devel
[02:30:56] -!- Roguish [Roguish!~chatzilla@c-50-143-183-159.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[02:38:45] -!- kingarmadillo has quit [Quit: Lost terminal]
[02:44:06] -!- GJdan has quit [Quit: WeeChat 1.7-dev]
[02:53:17] -!- tchaddad has quit [Remote host closed the connection]
[03:19:45] -!- BeachBumPete [BeachBumPete!~BeachBumP@2607:fb90:404a:389c:e2c6:f195:85a8:3100] has joined #linuxcnc-devel
[03:19:49] -!- BeachBumPete has quit [Client Quit]
[03:20:12] -!- BeachBumPete [BeachBumPete!~BeachBumP@2601:589:8201:bbc0:3c3f:5997:ec64:dc15] has joined #linuxcnc-devel
[03:20:12] -!- BeachBumPete has quit [Client Quit]
[03:20:27] -!- BeachBumPete [BeachBumPete!~BeachBumP@2601:589:8201:bbc0:3c3f:5997:ec64:dc15] has joined #linuxcnc-devel
[03:20:57] -!- BeachBumPete [BeachBumPete!~BeachBumP@2601:589:8201:bbc0:3c3f:5997:ec64:dc15] has parted #linuxcnc-devel
[04:15:44] -!- Roguish has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
[04:17:02] -!- tchaddad has quit [Read error: Connection reset by peer]
[04:29:59] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[04:33:25] -!- ktchk [ktchk!~eddie6929@n219079250092.netvigator.com] has joined #linuxcnc-devel
[04:33:52] -!- ktchk has quit [Read error: Connection reset by peer]
[04:34:16] -!- ktchk [ktchk!~eddie6929@n219079250092.netvigator.com] has joined #linuxcnc-devel
[04:44:00] -!- KimK has quit [Ping timeout: 260 seconds]
[04:54:43] -!- ktchk [ktchk!~eddie6929@n219079250092.netvigator.com] has parted #linuxcnc-devel
[04:57:08] -!- KimK [KimK!~Kim__@2600:8803:7a85:6d00:dc5d:93c3:d65b:19b2] has joined #linuxcnc-devel
[05:06:07] -!- tchaddad has quit [Remote host closed the connection]
[05:25:32] -!- ve7it has quit [Remote host closed the connection]
[05:31:38] -!- kingarmadillo has quit [Ping timeout: 265 seconds]
[05:43:35] -!- kwallace_ofcb [kwallace_ofcb!~kwallace@162.222.30.253] has parted #linuxcnc-devel
[05:52:25] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[06:04:39] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[06:25:16] -!- tchaddad has quit [Read error: Connection reset by peer]
[07:04:30] -!- marshmn has quit [Ping timeout: 250 seconds]
[07:16:04] -!- tchaddad has quit [Remote host closed the connection]
[07:21:57] -!- tchaddad has quit [Ping timeout: 240 seconds]
[07:49:57] -!- steves_logging has quit [Ping timeout: 240 seconds]
[08:05:49] -!- kingarmadillo has quit [Ping timeout: 265 seconds]
[09:03:18] -!- marshmn has quit [Ping timeout: 244 seconds]
[09:25:40] -!- ktchk [ktchk!~eddie6929@n219079250092.netvigator.com] has joined #linuxcnc-devel
[09:37:14] -!- kalxas has quit [Changing host]
[09:58:27] -!- b_b has quit [Changing host]
[10:06:45] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[12:05:33] -!- ktchk has quit [Ping timeout: 265 seconds]
[12:07:09] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[12:36:59] -!- sheppard has quit [Remote host closed the connection]
[13:05:28] -!- marshmn has quit [Ping timeout: 256 seconds]
[13:09:31] -!- terkaa [terkaa!~terkaa@dsl-olubrasgw1-50dcad-121.dhcp.inet.fi] has joined #linuxcnc-devel
[13:09:49] <terkaa> hi all
[13:11:42] -!- kingarmadillo has quit [Ping timeout: 256 seconds]
[13:32:17] -!- kingarmadillo has quit [Ping timeout: 240 seconds]
[13:54:22] -!- terkaa has quit [Remote host closed the connection]
[14:44:04] -!- steves_logging [steves_logging!~Steve@wsip-70-182-2-252.dc.dc.cox.net] has joined #linuxcnc-devel
[14:52:51] -!- agnitio_ has quit [Ping timeout: 246 seconds]
[14:53:11] -!- agnitio has quit [Ping timeout: 246 seconds]
[14:54:56] <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.
[14:58:07] <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
[15:02:40] <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
[15:03:01] -!- kingarmadillo has quit [Ping timeout: 248 seconds]
[15:07:18] -!- tchaddad has quit [Remote host closed the connection]
[15:07:57] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[15:15:54] -!- agnitio has quit [Read error: Connection reset by peer]
[15:27:28] <mozmck> I think this commit fixes issue #177
https://github.com/mozmck/linuxcnc-mirror/commit/9c4432163274d0c978cd3bbb041e91b2459a88d7
[15:27:53] <mozmck> I tested with G64, but not with G61
[15:42:43] -!- kwallace_ofcb [kwallace_ofcb!~kwallace@162.222.30.253] has joined #linuxcnc-devel
[15:51:06] <jepler> hm
[15:51:21] <jepler> side thought, does state tags explicitly restore the P- Q- values when G64 is in effect?
[15:54:12] <cradek> looks like not currently
[15:57:50] <jepler> second hmmm: does it restore modifications to the coordinate systems (via g10 for example)
[15:57:54] <cradek> see Interp::gen_g_codes() case 11
[15:58:19] <cradek> no, just which one is active
[15:58:32] <jepler> ok
[15:58:52] <cradek> pretty much what you see in the active gcodes readout is what's saved and restored
[15:59:38] <jepler> fair enough
[16:00:03] <jepler> part programs that modify coordinate systems are probably relatively few
[16:00:17] <jepler> similarly, ones that change G64 P- Q- values during the run
[16:00:33] <jepler> hmmm
[16:00:41] <jepler> programming G64 on its own nullifies previous P- and Q- settings?
[16:01:07] <cradek> PQ might get lost, if you do G64 PQ, (abort here) ... G61 (readahead to here)
[16:01:16] <cradek> yeah I was just thinking along those lines
[16:01:48] <jepler> origin/statetags is the latest / merge candidate branch right?
[16:01:53] <cradek> yes
[16:02:39] <mozmck> So would it not be better if abort did not reset G64? Only reset it when explicitly told to?
[16:03:15] <mozmck> That's what my patch for 2.7 does (unless I missed something).
[16:03:49] <jepler> cradek: but doesn't state tags generate bare G64 regardless of whether G61 or G64 is active?
[16:03:57] <jepler> afk
[16:04:08] <cradek> no, it only generates the reset commands that are needed
[16:04:16] <cradek> (if I understand it right)
[16:04:58] <cradek> fwiw, the conversation we have is this:
https://github.com/LinuxCNC/linuxcnc/issues/134
[16:06:34] <cradek> mozmck: maybe we need to save the PQ with the g[11] (control mode) tag, and restore them
[16:06:46] <cradek> talking about statetags now
[16:07:06] <cradek> I think your change to just not mess with it is right for 2.7
[16:07:22] <mozmck> yeah, I guess that is in the case that someone changes G64 settings in mid program?
[16:07:41] <cradek> yes
[16:08:10] <cradek> you might not be aware that the motion mode does get changed implicitly sometimes - at least canned cycles do it
[16:08:22] <cradek> and g76 might, not sure
[16:08:46] <mozmck> I guess changing G64 mid-program could be interesting as a gag :-) Part program looks one way and the actually cutout wildly different.
[16:08:47] <cradek> and the new floating tap cycles that [forget his name] is working on
[16:09:37] <mozmck> G64 is a motion mode? - no I was not aware it got changed implicitly.
[16:24:48] <skunkworks> drilling cycles change to g61 iirc (that is how i found out my tuning wasn'
[16:24:52] <skunkworks> t the greatest
[16:25:02] <skunkworks> ' is too close to the enter key
[17:02:27] <jepler> zlog: ?
[17:02:27] <zlog> jepler: Log stored at
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-11-15.html
[17:04:01] -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/
[17:15:29] <mozmck> micges did test the other night and verified that Q was retained - only P was reset.
[17:16:01] <cradek> in statetags?
[17:19:09] <mozmck> no, we were only looking at 2.7
[17:19:40] <mozmck> So that might not be relevant to statetags
[17:33:03] -!- jthornton has quit [Read error: Connection reset by peer]
[17:33:03] -!- JT-Shop has quit [Read error: Connection reset by peer]
[17:33:26] -!- JT-Shop [JT-Shop!~john@198.45.191.246] has joined #linuxcnc-devel
[17:33:29] -!- jthornton [jthornton!~john@198.45.191.246] has joined #linuxcnc-devel
[18:05:29] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[18:08:51] -!- skunkworks has quit [Ping timeout: 246 seconds]
[18:25:04] <andypugh> Does anyone know who “dragon” the G71 guy is?
[18:27:02] <cradek> yes, he was at fest
[18:27:16] <andypugh> Is he a Todd we know, or a new Todd?
[18:27:29] <andypugh> (Todd Zuercher, for example)
[18:27:42] <cradek> he's not that one
[18:27:57] <andypugh> I am not clear how far he has got with G71, ie if he has code already
[18:28:27] <cradek> I don't know either
[18:28:53] <cradek> there are sure some starting points he might have
[18:29:07] <cradek> many people have worked on this
[18:29:12] <cradek> bbl, lunch
[18:32:26] -!- marshmn has quit [Ping timeout: 256 seconds]
[18:40:08] -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
[18:42:18] -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
[18:43:01] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[18:57:51] <andypugh> I had a look through a thread about a previous attempt:
[18:57:52] <andypugh> https://sourceforge.net/p/emc/mailman/emc-users/thread/000601cd831d%24bc81b600%2435852200%24%40org/#msg29723177
[18:58:43] <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”
[19:01:58] Tom_itx is now known as Tom_L
[19:03:53] <cradek> one sentiment dragon expressed was trepidation about mh's response
[19:04:34] <cradek> someone else used remap and ended up having to require use of G0.1 G1.1 G2.1 etc to program the shape
[19:04:55] <cradek> so, using remap gave a worse solution for the user
[19:05:01] <jepler> meanwhile I still have trepdiation about remap at all, and yet it's in linuxcnc.
[19:05:17] <cradek> sure
[19:11:46] <cradek> I think the part where you can use a gcode sub for tool change is great
[19:12:02] <andypugh> Well, luckily, nowadays we are perfectly at liberty to ignore mh
[19:12:05] <cradek> but the whole python thing is bordering on crazy
[19:12:15] <jepler> the design of the python part is really bad.
[19:12:27] <cradek> andypugh: as you might imagine, several of us told dragon that quite clearly
[19:12:46] <jepler> I continue to work on being less a naysayer myself, but please speak up if I start doing it.
[19:12:57] <jepler> like I'm doing right now :-/
[19:13:27] <andypugh> I just tried applying the Ben Potter patch, and it didn’t take.
[19:13:38] <andypugh> (though wasn’t far off)
[19:14:10] <cradek> I don't remember seeing ben's patch
[19:14:24] <cradek> that might be a good starting point for todd
[19:14:38] <cradek> or maybe they could work together
[19:14:38] <andypugh> https://sourceforge.net/p/emc/mailman/emc-users/thread/000601cd831d%24bc81b600%2435852200%24%40org/#msg29723177
[19:14:58] <cradek> yeah I'm looking at it now, thanks
[19:15:50] <andypugh> I think I have a reasonable algorithm in my head, but feel that it would be much easier to debug in Python.
[19:17:50] -!- md-2 has quit [Quit: Leaving...]
[19:17:53] <cradek> _setup.g71_blocks.push_back(*eblock);
[19:18:38] <cradek> interesting, he saves the blocks, not the moves (interp_queue.cc) as I would have done
[19:19:44] <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 */
[19:19:55] <cradek> so he was thinking along those lines too
[19:20:10] <cradek> I see nothing crazy about this patch as a starting point
[19:20:28] <andypugh> I was definitey going to save the end points, arc centres and motion type
[19:20:33] <andypugh> in a list
[19:21:07] <andypugh> He seems to have done all the hard integration work
[19:21:19] <cradek> yeah
[19:21:54] <andypugh> But he thinks the algorithm is not so robust, and it only handles monotonic profiles
[19:21:58] <cradek> I would have used the interp_queue that cutter comp uses, so as to not invent another queue type
[19:22:20] <cradek> my understand is that only handling monotonic profiles (and giving good errors otherwise) is perfectly fine and expected
[19:22:24] <cradek> understanding
[19:22:39] <cradek> the commercial users call this "type 1" roughing cycles and it is what's common on controls
[19:22:48] <andypugh> There are versions (Type II G71) that handle “pockets"
[19:23:09] <cradek> yes but I understand it's both rare and unneeded
[19:23:12] <andypugh> And that seems like a reasonable ambition.
[19:23:30] <andypugh> And would _finally_ allow us to make use of frontabgle and backangle :-)
[19:23:35] <cradek> heh
[19:23:58] <cradek> I wonder if ben's implementation allows you to still use cutter comp
[19:24:05] <cradek> that's critical
[19:24:24] <andypugh> Maybe not as critical as you think.
[19:25:02] <andypugh> The (G70?) finishing pass just needs to call the O-sub as a normal sub with cutter comp on
[19:25:28] * cradek squints
[19:26:39] <cradek> are you sure ccomp would always make you cut more on a monotonic profile?
[19:26:59] <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.
[19:27:35] <cradek> but tapers or arcs end up in the wrong places and the wrong sizes
[19:28:35] <cradek> I guess maybe people mostly use the cycle to cut a square shoulder
[19:28:39] <cradek> then it sure wouldn't matter
[19:28:53] -!- pragmaticus has quit [Remote host closed the connection]
[19:29:17] <andypugh> Well, a sequence of diameters conected by _a_ radius, I would guess
[19:29:38] <cradek> ?
[19:29:41] <andypugh> But I doubt that most folk even measure their radiuses in lathe work.
[19:29:55] <andypugh> But that is not an excuse to do the job wrongly.
[19:30:18] <cradek> a roughing cycle that can't use ccomp is better than no roughing cycle
[19:30:30] <cradek> but it is very inferior to one that can
[19:31:18] <cradek> so if your design doesn't allow it, you have probably chosen a wrong design
[19:31:38] <cradek> I bet we're not disagreeing :-)
[19:32:18] <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?
[19:32:57] <cradek> yes
[19:33:31] <cradek> ben's patch has that; my idea of using the interp_queue would also (you just make a second one)
[19:33:55] <jepler> ah true, you can have two things of the same kind in a C++ program
[19:34:12] <cradek> heh
[19:35:08] <cradek> I guess you'd have to change qc() so you can new it or something like that
[19:35:11] * cradek waves his hands
[19:37:09] <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
[19:37:19] <cradek> srsly?
[19:38:14] <jepler> I sure did not know that
[19:39:38] <cradek> oh look:
https://sourceforge.net/p/emc/mailman/message/29729806/
[19:39:44] <cradek> I guess past-me was there
[19:39:53] <cradek> and I was approximately the same as I am now
[19:44:12] -!- racicot has quit [Changing host]
[20:17:27] <andypugh> OK, the Ben Potter patch compiles.
[20:19:53] <jepler> they colored it like a "fischer-price my first 3d printer"
https://www.amazon.com/dp/B01EWGJAS0
[20:20:27] <andypugh> Hmm, perfect christmas present
[20:20:54] <andypugh> non-heated print bed for child safety
[20:21:04] <andypugh> Way to make a bug into a feature!
[20:21:07] <jepler> heh
[20:25:19] <andypugh> Not only does the patch compile, it works:
https://imagebin.ca/v/326KODteOwbz
[20:25:46] <andypugh> We could probably have had this for years.
[20:27:14] <cradek> looks correctly comped
[20:28:05] <andypugh> It’s not 100%, the retract X before the retract Z is in the wrong direction
[20:28:45] <cradek> so, only the hard parts are done?
[20:33:38] <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
[20:35:22] -!- terkaa [terkaa!~terkaa@a91-155-72-157.elisa-laajakaista.fi] has joined #linuxcnc-devel
[20:35:33] <terkaa> hello
[20:35:42] <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.
[20:37:07] <cradek> yes I would like to see that change to his patch too
[20:37:32] <andypugh> Pity that someone on the LinuxCNC sourceforce page gave it a 1-star “I loved this” rating
[20:55:31] <andypugh> I am tempted to try it on metal…
[21:00:27] -!- terkaa has quit [Quit: Leaving]
[21:03:22] <skunkworks_> andypugh, video...
[21:03:22] <skunkworks_> andypugh,
http://bbs.homeshopmachinist.net/threads/71954-John-stepper-motor-gear-hobber
[21:03:23] -!- skunkworks_ has quit [Read error: Connection reset by peer]
[21:09:28] <andypugh> I didn’t know that JS had succumbed to LinuxCNC :-)
[21:59:26] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[22:10:16] -!- tchaddad has quit [Remote host closed the connection]
[22:13:34] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:589:8201:bbc0:34b7:f862:221:49b1] has joined #linuxcnc-devel
[22:13:50] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:589:8201:bbc0:34b7:f862:221:49b1] has parted #linuxcnc-devel
[22:15:37] -!- tchaddad has quit [Read error: Connection reset by peer]
[22:16:31] <skunkworks> zlog
[22:16:32] <zlog> skunkworks: Log stored at
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-11-15.html
[22:16:58] <skunkworks> only for hobbing... ;)
[22:17:33] <jepler> make a machine for both gear hobbing and knob knurling. call it the "hob knob".
[22:54:25] <skunkworks> Heh
[23:45:09] -!- marshmn has quit [Ping timeout: 248 seconds]
[23:58:30] -!- andypugh has quit [Quit: andypugh]