Back
[12:50:32] <skunkworks> andypugh, so the reason my profile doesn't work is because the L needs to be an integer and 1 inch is too much?
[12:50:51] <andypugh> Yes. quite likely
[12:51:48] <andypugh> You could (slightly) alter the Python do divide by 1000 to enter an offset in thousandths.
[12:52:45] <andypugh> Line 166: if 'l' in words: d.Lword = words['l'] / 1000.0
[12:52:53] <skunkworks> andypugh,
http://electronicsam.com/images/KandT/testing/Screenshot-27.png
[12:53:04] <skunkworks> ok - will try
[12:53:20] <andypugh> Try ir with L = 0 first
[12:53:54] <andypugh> Also add a rapid back to the full diameter to the end of the profile
[12:54:42] <skunkworks> ah - better -
http://electronicsam.com/images/KandT/testing/Screenshot-28.png
[12:55:26] <skunkworks> the face is interesting
[12:57:13] <andypugh> That’s your entry G0 move. It will be explained in the docs.
[12:57:36] <skunkworks> awesome
[13:01:40] <pcw_home> looks like Alfred Hitchcock
[13:01:45] <andypugh> Basically the notional cutter comes in from + Infinity (and beyond) and starts cutting at the entry G0 move, stops at the profile, starts if it sees the profile again, and so on.
[13:02:09] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot-29.png
[13:02:25] <andypugh> If the infinite ray doesn’t hit the entry G0 move then it starts when it hits another part of the profile, and that is how pockets happen
[13:08:21] <skunkworks> That is why the right end cut is touching the finished profile? (no L)
[13:10:25] <andypugh> Yes. But it will also always touch a G0 move (this is a feature)
[13:13:43] <skunkworks> andypugh, dividing L by 1000 - and setting it to 10
http://electronicsam.com/images/KandT/testing/Screenshot-30.png
[13:13:46] <skunkworks> looks nice
[13:14:22] <andypugh> Make the final retract a G0 to cut the full length
[13:15:59] <skunkworks> like this?
http://electronicsam.com/images/KandT/testing/Screenshot-31.png
[13:16:18] <andypugh> No
[13:16:30] <andypugh> That’s a G1, it’s white
[13:16:36] <skunkworks> ah
[13:16:40] <skunkworks> duh
[13:17:03] <andypugh> Though, if cutting up to a shoulder you might not want a G0.
[13:17:38] <andypugh> Depends on whether it is part of the finishing cut or not.
[13:18:06] <skunkworks> right
[13:19:07] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot-32.png
[13:28:21] <KGB-linuxcnc> 03Norbert Schechner 05master d2ec405 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_2_1_6_1 - bug in G96 handling * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d2ec405
[13:43:23] <cradek> guys this looks superduper useful
[13:46:13] <jepler> that looks just like raster conversion
[13:46:40] <jepler> I guess it's raster-ish in one of the axes but as fine grained as possible in the other
[13:49:00] <andypugh> simple stairstep reduction
https://ibin.co/33uIFA5x0poy.png
[13:52:20] <andypugh> Too-simple stairstep reduction:
https://ibin.co/33uJEfWgYDby.png
[13:56:23] <linuxcnc-build__> build #2789 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2789 blamelist: Norbert Schechner <nieson@web.de>
[14:03:23] <andypugh> cradek: That “Too simple” is what I descrined in the email. I failed to think hard enough
[14:09:57] <linuxcnc-build__> build #4645 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4645 blamelist: Norbert Schechner <nieson@web.de>
[14:11:46] <jepler> (that buildbot failure is not due to norbert's change, it's yet another flaky test that I haven't managed to figure out yet)
[18:30:19] <skunkworks> is hostdime.com down for others?
[18:31:37] <skunkworks> I assume that is why my website is down.
[18:35:01] <andypugh> seems to be
[18:36:09] <skunkworks> how hard is it to change L to use floating point?
[18:36:24] <andypugh> http://http://downforeveryoneorjustme.com/hostdime.com
[18:36:45] <andypugh> skunkworks: I don’t know, I haven’t even looked at that.
[18:36:58] <andypugh> bpuk: might have more idea what it involved
[18:37:01] <skunkworks> awesome!
[18:37:14] <skunkworks> going to have to remember that site
[18:37:30] <skunkworks> I have been giving it profiles and they look pretty awesome!
[18:37:41] <skunkworks> I guess awesome is the work of the day
[18:41:28] <cradek> you probably just have to change read_l() and maybe add an l_flag throughout
[18:42:31] <andypugh> The values returned by emcstat.tool_offset are a completely different format to the values passed via emccommand.tool_offset.
[18:42:57] <andypugh> If the example at
http://linuxcnc.org/docs/2.6/html/common/python-interface.html#_sending_commands_through_tt_linuxcnc_command_tt is correct
[18:43:24] <andypugh> s.tool_offset returns XYZABCUVW offsets, no diameter or angles
[19:24:44] <andypugh> Did anyone have any thoughts about the extra planes? Does anyone know if any other controllers have the full set? Google made me wonder id anyone else even does UV etc)
[19:50:05] <skunkworks> zlog
[19:57:17] <skunkworks> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/151914
[20:01:22] <skunkworks> they are all brainwashed ;)
[20:38:18] <andypugh> skunkworks:
[20:38:29] <andypugh> https://ibin.co/33wI1TuI5ymS.png
[20:38:51] <andypugh> step-reduction and gouge-detection now work (pretty much)
[20:39:14] <andypugh> Gouge detection just prints to the terminal, no action is taken
[20:41:16] <KGB-linuxcnc> 03andypugh 05andypugh/g71type2remap 6a4c9ac 06linuxcnc 10configs/sim/axis/g71/lathe.tbl 10configs/sim/axis/g71/python/remap.py 10nc_files/G71test1.ngc 10nc_files/lathe_pawn_G71.ngc G71 / G72: Added Type II restracts ( stair-step reduction) and gouge detection * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6a4c9ac
[20:43:39] <skunkworks> wow - aesome!
[22:18:21] <Tom_L> good stuff goin on here
[22:21:41] <skunkworks> magical
