Back
[01:43:45] <KGB-linuxcnc> 03Chris Morley 05qtvcp-2.7 40d58ad 06linuxcnc 10(10 files in 4 dirs) qtvcp -introduce basic infrastructure * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=40d58ad
[02:48:06] <linuxcnc-build> build #2273 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/2273 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[12:31:41] <IchGucksLive> hi
[12:31:57] <IchGucksLive> zlog
[12:41:09] <IchGucksLive> is there a info on what changed to the new G71 build
[12:41:43] <IchGucksLive> bpuk: ?
[12:43:41] <bpuk> the G71 build checked in yesterday was an update to get support for profiles into the C++ code. Use O profile->endprofile to define the profile
[12:43:56] <bpuk> only type1 implemented, I'm going through doing some cleanup at the minute
[12:44:33] <IchGucksLive> Thanks
[12:45:41] <bpuk> next stage after this batch of cleanup is to get offsetting the profile correct. it'll take a while to get the C code correct
[12:45:51] <bpuk> I'm not as quick as andy ;)
[12:47:33] <IchGucksLive> doesent matter time is a cxat
[15:29:26] <andypugh> I am fuzzy on frontangle and backangle…
[15:30:39] <andypugh> Having found the correct docs, I am now less fuzzy
[15:31:11] <bpuk> yay. can you explain how they work for a button tool?
[15:31:13] <andypugh> There is misleading info on the Wiki. (what else is new)
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolTable
[15:31:23] <andypugh> bpuk: They don’t?
[15:31:51] <bpuk> I don't know - that's been bugging me for a while
[15:31:58] <andypugh> Hmm, actually, you would use 90 and 90
[15:32:17] <bpuk> something to think about in terms of anti-gouge algorithms
[15:32:53] <bpuk> which bit is misleading?
[15:33:17] <andypugh> http://linuxcnc.org/docs/html/lathe/lathe-user.html#_lathe_tool_orientation_a_id_lathe_tool_orientation_a is quite clear that they are positive angles from a line parallel to the Z axis
[15:33:36] <andypugh> The Wiki shows them as being measured from the X axis
[15:34:25] <andypugh> If you put in orientation 9 you get a button tool in Axis.
[15:35:12] <andypugh> I am thinking that we can choose to ignore negative tool angles, to provide a way for folk to “turn off” gouge detection.
[15:35:16] <bpuk> I'll have to test that with cutter comp - I'm sure it does work, just need to be careful (it's one of the more extreme examples)
[15:35:21] <bpuk> and good spot :)
[15:35:54] <bpuk> I think I've got the start of an offset algorithm that should work for all the sample profiles so far.
[15:37:12] <andypugh> I am moving the gouge-detection earlier, to a point where we can say which line is gougey.
[15:38:33] <bpuk> how early on?
[15:39:28] <andypugh> Too early, it won’t work ;-(
[15:40:06] <bpuk> I was thinking more-or-less during the offset stage
[15:40:51] <andypugh> I was going to do it in the G-code read section, but at that point we don’t know if it is a left-to-right ot right-to-left profile
[15:40:52] <bpuk> do the offset, detect anything that curves beyond the backangle, and clip to that
[15:41:04] <bpuk> ah, yeah, too early ;)
[15:41:37] <andypugh> Currently it is in the plunge and retract section of the linear cuts
[15:42:09] <bpuk> I think that's too late
[15:42:25] <bpuk> but it could work
[15:42:29] <andypugh> (Because my code doesn’t cut the curved profile, at all. As that seemed to be a solved problem in your code already?
[15:43:05] <bpuk> (the pre-finish pass? or the type2 retract?)
[15:43:30] <andypugh> pre-finish pass
[15:43:49] <bpuk> yeah, pre-finish works pretty well on type1
[15:44:07] <bpuk> without comp
[15:44:21] <andypugh> You know, it’s probably worth a run through the list of moves just to check for gouging. I will try that.
[15:45:08] <bpuk> current plan of attack is: couple of minor fixes, get the offset code finished off (this is the long bit), refactor the G71 function to pick type1/type2, use offset profile instead of manually applying offsets
[15:45:20] <andypugh> It’s probably less susceptible to false warnings. (minor gouging of staircases etc probably isn’t an issue as long as the true profile survives)
[15:45:54] <bpuk> I'm more concerned about true gouges - we know the backangle - but does the tool follow that angle all the way?
[15:46:07] <andypugh> I think we should always use TypeII, and offer a G71.1 code to force Type-1
[15:46:18] <bpuk> i.e. I can think of a couple of cheap toolholders which angle back on the cutter, then go 90 degrees the rest of the way.
[15:47:03] <andypugh> In that case you need to modify the angle in the tool table to suit the tool, not the insert.
[15:48:14] <bpuk> which brings us back to measuring angles
[15:48:41] <bpuk> (sorry, my brain is jumping around a bit tonight)
[15:52:45] <bpuk> Gene's idea on the mailing list of randomising each depth by 0.01 or so is quite interesting though - not something to do as standard, but an interesting option
[16:03:12] <andypugh> I missed that. Gene tends to dilute his valuable ideas.
[16:03:46] <cradek> I missed it too
[16:04:02] <bpuk> 'Not 100% true, but at some point along the cutting edge, usually on the left side of the tool since we usually cut right to left, it is cutting thru the oxide film. The damage in most cases will not be at the cutting tip, but back up the left edge by however deep a cut is being taken. And a retrace retraction of enough (0.01") to prevent the tip from rubbing during the retrace for
[16:04:02] <bpuk> the next pass becomes very important. That makes a huge diff in how long a carbide chip lasts on TLM, so I am writing that into my code as I re-use it, or for new code.'
[16:04:58] <bpuk> if I'm reading that right, it's a suggestion to vary the cut depth marginally, to avoid a consistent wear point - which is something I do with milling cutters
[16:05:54] <cradek> do you see that kind of wear on roughing lathe tools in real life?
[16:06:16] <andypugh> Gene is convinced that Aluminium instantly forms a ceramic layer of adamantine hardness. I think he is incorrect.
[16:06:19] <bpuk> I see it on millling tools - lathe tools I tend to shatter before they're showing that kind of wear
[16:07:05] <bpuk> the oxide layer is pretty hard, but not crazily so - if I use generic tips I tend to see tip damage fairly quickly. using aluminium tips - not so much
[16:07:44] <andypugh> And how fast does this oxide layer form? Between one cut and the next?
[16:08:50] <bpuk> not that fast, you'll get _some_ - but the damage is done on the first cut
[16:08:56] <bpuk> aaand that's the answer :D
[16:10:41] <bpuk> allow a different depth for the first cut as an option?
[16:11:19] <cradek> if you want to take a certain cut first, you could ... program it
[16:13:38] <bpuk> that's crazy talk
[16:15:49] <pcw_mesa> another randomization strategy that Ive seen is spindle speed modulation
[16:16:12] <pcw_mesa> (to avoid chattering)
[16:16:14] <jepler> why not digital spread spectrum your step rate while you're at it
[16:17:01] <andypugh> That’s useful for avoiding chatter (PCW’s idea) I do it manually, but I have seen a Youtube video of (I think) a MAZAK that has it as a feature.
[16:17:33] <andypugh> We could add that as an M-code I would have thought.
[16:17:36] <pcw_mesa> might not be a bad idea on the software stepgen to avoid beats causing resonance
[16:17:50] <bpuk> feedback based? or just random?
[16:18:04] <andypugh> bpuk: Not even random
[16:18:10] <pcw_mesa> beats exciting resonance I mean
[16:18:31] <pcw_mesa> sinusoidal maybe
[16:18:54] <andypugh> Actually, it’s HAAS:
https://www.youtube.com/watch?v=dXR2wDDFFm4
[16:19:21] <bpuk> oooh - I might be able to do the trial then!
[16:19:47] <bpuk> I guess it needs fairly good tracking on speed
[16:20:21] <andypugh> I have been known to stand there sliding the slider. Which is a pain with a trackball and Axis :-)
[16:20:32] <bpuk> that could be really handy for some thin stainless cuts
[16:21:31] <bpuk> and yeah, sinusoidal
[16:21:48] <andypugh> Easy to mock-up in HAL with siggen and a sum2
[16:22:21] <bpuk> and it looks like quite a big variation (from the demo)
[16:23:26] <pcw_mesa> Yeah its a power waster, there are a couple of good papers about it floating around
[16:24:21] <bpuk> would work really nicely on servo spindles - less well on inverter/acim (unless they're really well tuned)
[16:24:40] <bpuk> ok. spread spectrum on steprate?
[16:24:47] <andypugh> HAAS use M38. And it’s unused in LinuxCNC
[16:27:52] <andypugh> bpuk: It works for me with a VFD
[16:29:15] <andypugh> I implemented G71.1
https://ibin.co/34i8QHqFXSoC.png
[16:29:44] <andypugh> Though I am not sure if it should also force stair-steps. Seems like it shouldn’t
[16:30:15] <bpuk> I'm trying to think of a situation where stairsteps would be preferred
[16:31:50] <andypugh> I tried nd failed
[16:32:10] <bpuk> very marginal speed improvement is the only case I can think of
[16:32:19] <bpuk> but you're talking milliseconds.
[16:32:43] <bpuk> even on work hardening materials - you're better with type2 retract
[18:04:50] <KGB-linuxcnc> 03andypugh 05andypugh/g71type2remap dca78a4 06linuxcnc 10configs/sim/axis/g71/lathe.ini 10configs/sim/axis/g71/python/remap.py 10nc_files/G71test1.ngc 03nc_files/G71test1_L2R.ngc G71: Add codes G71.1 and G72.1 to force type-1 (no pockets) mode * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dca78a4
[18:05:45] <andypugh> (The truncated section of the comment says that it now does gouge detection in all quadrants. internal/external and R to L and L to R
[18:06:28] <andypugh> Conjecture: If the tool can reach each end of an arc without couging then it can reach all of the arc…
[18:30:06] <linuxcnc-build> build #2804 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2804 blamelist: andypugh <andy@bodgesoc.org>
[18:30:07] <cradek> arcs are already at most a quadrant?
[18:30:43] <andypugh> Yes in this case
[18:31:09] <cradek> that sounds likely to be true then
[18:31:48] <cradek> wellll I can think of a counterexample already
[18:32:10] <cradek> imagine an arc of smaller radius than the tool tip radius
[18:32:58] <cradek> cutter comp will already error on that, but I don't know whether that helps you
[18:33:39] <cradek> you guys have talked about 'offsetting' but I don't think I know for sure what that means
[18:46:06] <archivist> tip radius can be small enough but still fail
http://www.collection.archivist.info/archive/mirror/cnc/curve.jpg
[18:48:24] <cradek> yes! if the tool is more than a quadrant
[18:51:12] <archivist> and tools angle
[18:52:53] <linuxcnc-build> build #4654 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4654 blamelist: andypugh <andy@bodgesoc.org>
[18:54:28] <andypugh> archivist: In that picture, the tool can’t touch the arc-ends (inside) either.
[18:55:13] <andypugh> cradek: G71 takes parameters for the amount of metal to leave in the X and Z directions on the pre-finishing pass.
[18:55:44] <andypugh> But, the numbers can be different, so it’s not congruent with tool diameter comp.
[18:56:14] <archivist> it can touch the arc ends but then cannot go into
[18:56:25] <archivist> http://www.collection.archivist.info/archive/mirror/cnc/curve0002.jpg
[18:56:51] <andypugh> It can’t touch the inside of the arc at the ends.
[18:57:04] <archivist> that is true
[18:58:33] <andypugh> (put another way, the flank angle of the tool is < the tangent angle of the arc ends
[18:59:06] <archivist> yes I was about to say something similar
[18:59:33] <archivist> both flank angles
[23:37:29] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15dhweizel opened issue #217: error at the end of a remapped m6 02
https://github.com/LinuxCNC/linuxcnc/issues/217
