Back
[10:26:15] <mozmck> cradek: I was able to duplicate the large tool display in axis.
[10:27:38] <seb_kuzm1nsky> meeting time?
[10:27:53] <mozmck> It appears to be caused by probe moves. The file has a lot of G38.2 followed by G92 Z0. When I strip those out, the tool is still rather large, but not quite as excessive.
[10:28:14] <mozmck> oh, I forgot about that!
[10:28:50] <mozmck> That is in one hour right?
[10:29:58] <seb_kuzm1nsky> mozmck: you're right, i'm jumping the gun
[10:30:26] <seb_kuzm1nsky> i'm just so excited to have a meeting! it'll be just like at my dayjob!
[10:31:11] <archivist> I had to re learn my bot!
[10:34:55] <mozmck> Hopefully it will be a lot more useful than $dayjob meetings!
[10:36:24] <mozmck> Although our little company is small enough our meetings are not bad.
[10:37:52] <mozmck> seb_kuzm1nsky: did you see this?
http://pasteboard.co/1VB2KIKw.png
[10:38:34] <mozmck> The text and tool display are disproportionately large there.
[10:39:49] <mozmck> It looks like the code for that is in glcanon.py, but I haven't figured it out yet.
[10:42:16] <seb_kuzm1nsky> that looks all kinds of goofy
[10:42:23] <mozmck> heh
[10:42:56] <seb_kuzminsky> i messed up and thought the meeting was at 15:00 UTC, but really it's at 16:00 UTC, so i wont be able to make it
[10:43:16] <mozmck> well bummer!
[10:43:26] <seb_kuzminsky> i see some of you are lurking in #linuxcnc-meet right now, so i'm going to preemptively cast my votes, count them if you like or ignore them if you like
[10:43:42] <mozmck> heh, I bet they will be counted ;-)
[10:46:01] <mozmck> The file that shows that display is here if anyone has an interest in looking at it and giving any tips on fixing it.
http://www.mcknight-instruments.com/files/Large_test_probe.ngc
[10:46:15] <seb_kuzminsky> as far as i can tell there's not much opposition to ja any more, thanks to all of dgarr's hard word
[10:46:27] <jepler> seb_kuzminsky: yeah that is the impression the mailing list discussion gives too
[10:46:29] <mozmck> hard words?
[10:46:34] <jepler> work
[10:46:38] <mozmck> :-)
[10:46:38] <seb_kuzminsky> *work
[10:46:45] <seb_kuzminsky> d'urr
[10:47:56] <mozmck> Yes, seems like a number of people are using it already.
[10:48:22] <seb_kuzminsky> i should have probably said something in email, but one thing i've learned from all the ja word^Wwork is that we should really try to keep feature branches small, because big ones are hard to merge
[10:48:41] <seb_kuzminsky> maybe the changes of JA are of the kind that *can't* be small
[10:48:57] <mozmck> I was about to ask how you would keep something like that small
[10:49:09] <seb_kuzminsky> or maybe we could have done the work piece-meal over many smaller merges
[10:49:34] <jepler> mozmck: I think there's a detail you left out that will turn out to be relevant
[10:49:36] <seb_kuzminsky> mozmck: i admit i don't understand the ja changes well enough to say whether that would have been possible or not
[10:49:43] <jepler> mozmck: the Z extent of your program is ~840 inches
[10:50:50] <mozmck> jepler: that is true, but I did not know that until I looked at the preview in axis in the P view.
[10:50:52] <jepler> compare the preview of
https://emergent.unpythonic.net/files/sandbox/bigflat.ngc and
https://emergent.unpythonic.net/files/sandbox/bigdiag.ngc
[10:51:35] <mozmck> Actually, it is the preview's handling of probe moves that makes the Z extent look that large.
[10:52:25] <mozmck> I'm still not sure that the tool should be that large when the part gets that large.
[10:52:46] <jepler> anyway, yes, the logic is making the extents and tool look reasonable in the "P" view, but that makes the "Z" aka "XY" aka "top down" view look bad
[10:54:54] <mozmck> Well - somewhat reasonable in P view IMO. I don't think the tool should look as large as the X extent of the part when it is 48" in any case.
[10:57:00] <jepler> https://emergent.unpythonic.net/files/sandbox/preview1.png https://emergent.unpythonic.net/files/sandbox/preview2.png
[10:57:33] <jepler> the screen size of the cone and the dimensions in "p" view are about the same in these two previews of radically different size
[10:57:50] <mozmck> yeah
[10:58:04] <jepler> the magic scaling should maybe consider what view it's in, I dunno
[10:58:24] <jepler> or maybe the real problem is with the preview plot that results from the probing moves you do
[10:58:57] <mozmck> heh, that might be part of it, but it will still do that same thing if you actually have a 900" tall part :-)
[10:59:42] <jepler> or in general, when you have a part that is 10-20x as tall as wide
[11:00:59] <jepler> so yeah it looks like opening files is thoroughly broken in master branch :-/ I thought we'd fixed that.
[11:01:51] <archivist> as I tend to make tiny stuff the cones has always been overly large
[11:08:01] <mozmck> Yeah, I have not done any large parts yet, but we have people running 4' x 8' and large plasma tables, and cutting lots of parts out of full sheets of metal.
[11:09:47] <jepler> I'll review any patches you propose. I think you should consider trying to define a way for preview to do better with the probing moves you report, possibly via magic comment
[11:10:28] <jepler> for instance, if the preview plot would always assume a probe move completes at a particular machine Z coordinate that might be a better preview
[11:12:31] <jepler> or maybe you should change your probing code so that it is always covering the same range of machine Z coordinates, for instance by beginning each one with a move to a constant machine Z or making the end point constant in machine Z
[11:12:43] <mozmck> magic comment?
[11:13:07] <jepler> yeah you'd just put a turd in all your files (AXIS,HEY,PROBE MOVES SHOULD ALL STOP AT MACHINE Z=-1 MKAY)
[11:13:12] <jepler> or maybe it's an inifile option
[11:13:20] <mozmck> ah, I see.
[11:13:39] <mozmck> I had thought about making probes assume they always move back to zero
[11:14:16] <archivist> I dont think you would want that in general purpose probing
[11:14:26] <mozmck> Which is what actually happens for plasma touchoff at least.
[11:15:05] <mozmck> Yeah, it might should be an option. This is only for preview too. I doubt preview shows general purpose probing much better?
[11:15:45] <archivist> I am thinking a head to a cmm :)
[11:15:47] <jepler> consider smartprobe.ngc, it doesn't trail down to negative infinity even though it has many many probing moves
[11:16:52] <jepler> it works by consistently returning to Z#7 when it's ready to step over to the next location, and it never changes coordinate systems
[11:18:47] <mozmck> jepler, the problem is that with plasma, you don't know if the metal has moved, so you start from an assumed safe height (maybe .5") and probe down to find where the metal is now.
[11:19:38] <mozmck> For thinner material the metal can warp as you cut.
[11:19:53] <jepler> and by .5" you mean .5" different from where you probed the last time
[11:20:30] <mozmck> .5" is in reference to the last probe - yes. Each probe is followed by a G92 Z0 (essentially)
[11:20:41] <jepler> move .5" up then probe 1" down, so the preview steps down 1" each time
[11:20:47] <jepler> er .5" down each time
[11:21:31] <mozmck> Well, the problem with that is that the metal might be lower than the last probe.
[11:22:07] <mozmck> I have seen 14 guage steel warp so that one touchoff is an inch higher than the next.
[11:22:14] <jepler> if you went up to a fixed machine Z coordinate and then down by a fixed length, the Z coordinates in the preview wouldn't act like that
[11:22:47] <jepler> g53 g0 z0 / g38.2 z-1
[11:22:58] <jepler> or something like that
[11:23:42] <mozmck> Oh, so you are saying to use absolute coordinates for the probe move? I had not thought of that.
[11:23:56] <jepler> g38.2 doesn't accept g53 right now
[11:24:03] <jepler> but the previous "move to safe Z" G0 move can
[11:26:03] <jepler> or just cancel your G92 Z offset prior to moving to a fixed safety height in what would be the unaltered G54 (or whatever) coordinate system
[11:26:04] <mozmck> It sounds like fixing the probing preview would be best in any case, and I think also the tool size in relation to the part.
[11:40:55] <cradek> so excited
[11:42:09] <mozmck> I suspect more people will address issues in JA after it's merged as well
[11:42:55] <cradek> yes I think it'll see more use and get more attention
[11:44:38] <andypugh> We will have to learn how to educate users on being specific whether they mean a joint or an axis now.
[11:49:38] <andypugh> So, now to vote about So, about LinuxCNC joining the EU...?
[11:50:59] <jepler> not sure what to say about that. I think you will live in interesting times...
[11:52:08] <cradek> I hope it doesn't lead to suffering
[11:52:28] <andypugh> Yes. I think everyone is a bit taken aback by the result. Many of those voting to leave probably only did so because they knew there was no way that it would actually happen.
[11:53:12] <andypugh> I think this is the second time that opinion polls may have materially affected the outcome.
[11:53:47] <andypugh> Heck _I_ voted out just to make the result a bit tighter.
[11:54:00] <archivist> I voted out too
[11:54:47] <andypugh> Something I hadn't considered was Northern Ireland. Now they do have something to fight over :-(
[11:55:47] <cradek> guess people get bored with not warring over borders after a while
[11:56:19] <archivist> and now we have a petition to do it all again
http://www.bbc.co.uk/news/uk-politics-eu-referendum-36629324
[11:57:13] <andypugh> It is quite common in other parts of the world to repeat elections until the voters come up with the right result, isn't it?
[11:57:17] <cradek> funny
[11:57:48] <cradek> I don't know... I'm sure it's common to just fix it in the first place
[11:58:12] <archivist> the elite did need a bloody nose
[12:01:19] <andypugh> archivist: So, you are saying that the way to deal with the out-of-touch political class in Whitehall is to leave the Eu and give the political class in Whitehall all their powers back? :-)
[12:02:12] <andypugh> (In the same way that the SNP are demanding their independence from the UK because we forced them into independence from the EU)
[12:02:15] <archivist> this has set the cat amongst the pigeons there and over the channel :)
[12:02:46] <andypugh> I reckon it will probaly all work out OK, and potentially better.
[12:04:28] <andypugh> So, to really make the world an interesting place, we need Putin to stay on, La Penn to get France, Trump in the US and either of Corbyn or Johnson in the UK.
[12:06:01] <archivist> is that Shakespeare? Comedy of Errors
[12:06:33] <andypugh> It would only be Comic if you could watch from outside, not inside.
[12:08:18] <archivist> revised url for the log, I had the wrong ID at the start command
http://meetlog.archivist.info/meeting.php?id=201606
[12:10:11] <KGB-wlo> push to master branch:
http://linuxcnc.org/
[12:10:20] -linuxcnc-github:#linuxcnc-devel- [13wlo] 15jepler pushed 1 new commit to 06master: 02
https://github.com/LinuxCNC/wlo/commit/9ea8625f68eb91ae16066af447cb4d10c3443900
[12:10:20] -linuxcnc-github:#linuxcnc-devel- 13wlo/06master 149ea8625 15Jeff Epler: showcase: "tome"'s captive nut
[12:12:36] <jepler> who wants to pick and write up the next showcase? I figure we should try to make a new one live every week or so..
[12:35:51] <archivist> fixed all my logging misttoks , bot had collected the topic, just I forgot to put the meeting id in the topic as well
http://meetlog.archivist.info/meeting.php?id=201606
[14:31:13] <andypugh> jepler: Theres a fancy toolchanger on "Show your stuff" at the moment.
[15:09:59] <jepler> andypugh: that's a possibility.
[15:13:19] <JT-Shop> Yea JA + Master = 2.7... if I had not missed the meeting I would have voted yes yes yes
[15:25:21] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #82: @gmoccapy if you will not be able to change it so that the user's umask is respected (by using a different API than tempfile.mkstemp to create the temporary file), then 0664 is probably not the worst choice. 02
https://github.com/LinuxCNC/linuxcnc/issues/82#issuecomment-228567730
[15:43:05] <andypugh> jepler: That may be a slightly too nuanced use of English when talking to a German(?)
[18:41:39] <jepler> possibly :-/
[18:42:18] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #82: In other words, that's fine. 02
https://github.com/LinuxCNC/linuxcnc/issues/82#issuecomment-228575272
[18:47:48] <seb_kuzminsky> pretty good compression ratio on that tldr
[19:00:53] <JT-Shop> hmm stepconf puts EDITOR = gedit but the LiveCD does not have gedit...
[19:04:58] <seb_kuzminsky> JT-Shop: oops
[19:05:26] <JT-Shop> yep, just deduced that from a forum post
[19:06:14] <JT-Shop> I assume the sample configurations and pncconf are the same way
[23:17:07] <seb_kuzminsky> i guess that means we should Recommend gedit in 2.6 and later
[23:17:16] <seb_kuzminsky> which feels a little weird
[23:25:00] <KGB-linuxcnc> 03Jon Elson 052.6 1fed0a2 06linuxcnc 10configs/by_interface/pico/univpwmv/univpwm.tbl update format of tool table * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1fed0a2
[23:29:28] <KGB-linuxcnc> 03Jon Elson 052.6 b1b66a9 06linuxcnc 10configs/by_interface/pico/univpwmv/univpwm_load.hal add explanation of port address and timestamp command line parameters * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b1b66a9
[23:32:50] <KGB-linuxcnc> 03Jon Elson 052.6 43015ff 06linuxcnc 10configs/by_interface/pico/ppmc/ppmc_load.hal explain how to set the parallel port address * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=43015ff
[23:37:03] <KGB-linuxcnc> 03Jon Elson 052.6 d30bf61 06linuxcnc 10configs/by_interface/pico/ppmc_vel/ppmc_load.hal explain parallel port address setting and timestamp command line parameters * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d30bf61
[23:39:46] <KGB-linuxcnc> 03Jon Elson 052.6 d0f52e6 06linuxcnc 10configs/by_interface/pico/univpwm/univpwm_load.hal explain how to set the parallel port address * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d0f52e6
[23:43:15] <KGB-linuxcnc> 03Jon Elson 052.6 45c3256 06linuxcnc 10configs/by_interface/pico/univstep/univstep_load.hal explain how to set the parallel port address * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=45c3256
[23:45:36] <KGB-linuxcnc> 03Jon Elson 052.6 78df7e3 06linuxcnc 10configs/by_interface/pico/USC_encod/univstep_load.hal explain how to set the parallel port address * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=78df7e3
