Back
[06:59:49] <KGB-linuxcnc> 03Norbert Schechner 05master b00d54c 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py gmoccapy_2_1_6_1 - added code information * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b00d54c
[08:35:52] <skunkworks> cradek, how did you probe the shape?
[08:36:20] <Tom_L> did you see the last jpg?
[08:40:56] <cradek> skunkworks: excessively, with no smarts: 360 radial probes
[08:42:41] <skunkworks> ah
[08:44:55] <cradek> would be fun to write a smart shape-tracing algorithm, but I didn't do that
[08:45:26] <cradek> it would be a lot like smartprobe
[11:01:31] <KGB-linuxcnc> 03Norbert Schechner 052.6 df19ffe 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_5_6_2_3 - G96 bug solved * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=df19ffe
[11:04:32] <KGB-linuxcnc> 03Norbert Schechner 052.7 332beb8 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=332beb8
[11:32:20] <KGB-linuxcnc> 03Norbert Schechner 05master 5fec8d9 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_2_1_6_2 - better solution for the G96 bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5fec8d9
[11:47:57] <jepler> it's snowing!
[11:48:46] * Tom_L looks outside
[11:48:51] <Tom_L> naw not yet
[11:52:32] <Tom_L> you're in Ne iirc?
[12:10:25] <jepler> yeah
[12:11:20] <jepler> it's not going to amount to much.
[12:16:40] <linuxcnc-build__> build #669 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/669 blamelist: Norbert Schechner <nieson@web.de>
[12:56:52] <linuxcnc-build__> build #83 of 4025.deb-jessie-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4025.deb-jessie-armhf/builds/83 blamelist: Norbert Schechner <nieson@web.de>
[16:07:38] <mozmck> Interesting - it looks like halui pins such as estop-reset and etc are looking for a level change - not a particular level
[17:10:56] <andypugh> bpuk: Did you see the message on the mailing list?
[17:11:52] <andypugh> Should the cycle assume that the profile ends at the furthest Z-point and add cuts with no explicit end?
[18:09:29] <JT-Shop> assuming anything is bad
[18:09:50] <JT-Shop> not enough information is an error
[18:49:25] <bpuk> just read the mailing list message, but I've been out all night
[18:51:21] <bpuk> profile should assume that the X starting point is the stock diameter. Z... Hmm... Last Z position...
[18:51:49] <bpuk> yeah, I'd expect it to cut to the furthest Z, but no deeper than the X diameter at that location
[18:59:18] <bpuk> thinking it through, it's something I noted with the existing code. final Z should cut to stock dia
[18:59:32] <andypugh> The behaviour he saw is certainly wrong, it takes a 20mm initial cut.
[19:00:17] <bpuk> huh? it doesn't start at the furthest out cut? that's what his pictures suggest
[19:00:43] <andypugh> The first picture
[19:00:56] <bpuk> ouch
[19:01:07] <andypugh> It starts at the first cut with a defined end, not the starting X
[19:01:11] <bpuk> that one _shouldn't_ take a cut at all
[19:01:43] <andypugh> Indeed. We either need to make a closing-move mandatory, or assume one
[19:02:19] <andypugh> “No code survives contact with the users”
[19:02:31] <bpuk> heh
[19:03:01] <andypugh> I am tinkering with makin left-to-right profiles work, but it’s getting late
[19:03:27] <bpuk> either the profile is closed loop, or it's open, and the last Z move should be considered to travel to x infinity
[19:04:05] <bpuk> if it's closed loop, the start and end of the profile should be adjusted to meet the starting point
[19:04:16] <bpuk> and yup, late. thinking out loud
[19:04:53] <andypugh> I think that profiles open in the positive-X direction should be allowed.
[19:05:35] <andypugh> So not a fully-closed loop
[19:07:36] <bpuk> ugh, ID turning. if ID turning the final move should tend to X0
[19:42:21] <andypugh> Yes, that is probably cheaper :-)
[19:42:45] <andypugh> I now have left-to-right working.
[19:44:56] <andypugh> Tjough left to right gouge-detection appears hardee than I assumed
[21:02:06] <skunkworks> zlog
[21:13:47] <andypugh> <pedant> 29:36 That isn’t a drill. it’s a vertical lathe.
[21:16:25] <andypugh> Sorry, wrong channel :-)