Back
[07:44:48] <jthornton> I noticed this in the 2.5 change log "AXIS: dynamic tabs can embed other applications" is there any documentation on how to do that?
[09:11:46] <seb_kuzminsky> jthornton: i'll channel cradek:
[09:11:46] <seb_kuzminsky> < cradek> I'd check the source :-)
[09:16:04] <cradek> well I looked at the AXIS docs and I think the answer is no
[09:18:58] <cradek> also embedding tabs in touchy is not documented
[09:19:59] <cradek> happily, I think the procedure is the same for both:
[09:20:04] <cradek> sim/touchy/touchy.ini:# EMBED_TAB_NAME = Tools
[09:20:04] <cradek> sim/touchy/touchy.ini:# EMBED_TAB_COMMAND = xterm -into {XID} -rv -fn lucidasanstypewriter-bold-14 -e watch -n1 cat simpockets.tbl
[09:20:38] <cradek> (untested)
[09:27:19] <akex2> Hy all
[09:27:49] <seb_kuzminsky> thanks cradek
[09:27:53] <seb_kuzminsky> hi akex2
[09:28:07] <akex2> How disable a anti gouging protection on linux cnc please ?
[09:28:42] <akex2> I hate that :(
[09:28:53] <cradek> that is probably the wrong question. do you understand that it is reporting a problem in your gcode, and what that problem is?
[09:29:32] <JT-Shop> cradek, thanks
[09:29:51] <cradek> JT-Shop: welcome, it's not much to go on, but it's something
[09:29:57] <akex2> Nop i want disable it
[09:30:37] <cradek> do you understand what causes it?
[09:31:18] <akex2> If i want a pocket diam 20mm i can make it whith a tool 12mm ex whith compensation
[09:31:47] <akex2> Yes i understand where is an what is the problem
[09:32:09] <cradek> yes you can make that pocket
[09:32:33] <cradek> ok great, please explain then
[09:32:59] <skunkworks> probably not if the circular pocket is made of very segments....
[09:33:15] <akex2> Sorry i don't speak verry well but i try explain you
[09:33:16] <seb_kuzminsky> much pocket
[09:33:19] <seb_kuzminsky> very segments
[09:33:33] <cradek> akex2: I'm having no trouble understanding you
[09:33:44] <akex2> No is a circular
[09:33:55] <akex2> Ok good cradek ;)
[09:34:45] <skunkworks> heh *probably not if the circular pocket is made of very short segments....
[09:36:25] <akex2> Iinux cnc say : the input motion is less than the radius of the tool
[09:40:28] <skunkworks> akex2, the entry move of cutter comp needs to be atleast the radius of the tool.
[09:40:29] <skunkworks> http://linuxcnc.org/docs/2.6/html/gcode/tool_compensation.html#_overview
[09:44:46] <akex2> Thx skunkworks
[09:45:14] <akex2> My tool is in center on my pocket
[09:45:53] <akex2> My tool diam 12mm and my pocket is 20
[09:46:29] <cradek> you can either enter cutter comp mode before putting the tool in the pocket, or use an arc entry move
[09:48:38] <akex2> Ok i understand cradek
[09:48:46] <akex2> But last one question
[09:50:55] <akex2> When compenstation is activate i can't make a g2 r5,5 with a tool diam 10 it's normaly ?
[09:52:03] <cradek> a tool of radius 5 has no problem inside or outside an arc with radius 5.5
[09:55:44] <akex2> Ok i try make a programe with error and if i can't resolve it, i come back, i am very boring of this error...
[09:56:07] <akex2> Thx cradek and skunkworks lot off!
[09:56:24] <cradek> welcome
[09:56:52] <cradek> entry moves can be hard to get right
[09:59:00] <akex2> You say right !
[10:11:49] <kwallace> akex2, I have also had frustration with cutter compensation. Just after compensation is turned on, the next move has a destination point at the stated point plus an offset. Then a path is determined to get there. The path is the tricky bit and I believe is based on the next point and the one after it. Since this is done behind the scenes, it can be hard to predict. I find having math functions available in g-code often makes it easier to just
[10:12:14] <archivist> cut off
[10:12:29] <kwallace> I find having math functions available in g-code often makes it easier to just leave compensation off and do it in the g-code. The current tool radius can be pulled into the g-code using the proper variable, #5410:
http://linuxcnc.org/docs/html/gcode/overview.html#_numbered_parameters_a_id_sub_numbered_parameters_a
[10:13:14] <kwallace> Oops :(
[10:15:04] <cradek> that's sure true for some simple shapes, but cutter comp will figure out shapes you really don't want to deal with yourself
[10:16:34] <cradek> I recently used it to make a hexagon (-like shape) get rounded corners
[10:16:50] <cradek> it would have been possible but really boring to figure the arcs out myself
[10:17:04] <cradek> wait it was an octagon-like shape
[10:31:21] <kwallace> Here is a sample routine with compensation in g-code:
http://wallacecompany.com/tmp/Screenshot_pocket-1a.png .
[10:33:38] <kwallace> Oops, brain fart, the above uses a Python routine to create the g-code. Never mind.
[10:36:16] <skunkworks_> http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-10-20%2023:08:50.png
[10:36:31] <skunkworks_> linuxcnc cutter comp.. ;)
[10:37:07] <seb_kuzminsky> skunkworks_: all i see is the accel violations ;-)
[10:37:27] <skunkworks_> seb_kuzminsky, see the version?
[10:38:09] <cradek> I smile upon my cutter comp algorithm much more than I smile upon that old planner
[10:38:24] <skunkworks_> cradek, both work very well....
[10:38:35] <cradek> you're too generous
[10:38:47] <seb_kuzminsky> i use cutter comp every chance i get
[10:39:03] <seb_kuzminsky> it's much easier to figure out the entry move than all the path afterwards
[10:39:17] <cradek> heh yeah that's an easy tradeoff
[10:39:29] <seb_kuzminsky> sometimes that means my machine does a little silly dance above the work, to enter cutter comp
[10:39:41] <seb_kuzminsky> but as long as no real machinists see it, i dont mind :-)
[10:40:03] <cradek> sometimes I wonder if the other choice of entry move would be smarter for concave entry (tangent to the following line but ON the nominal path, instead of into the corner)
[10:40:11] <skunkworks_> dxf2gcode does the entry move above the part by default.
[10:40:36] <seb_kuzminsky> anything you do with the tool in air is a forgivable sin
[10:44:42] <skunkworks_> I think we are back down to the sob and the interp/bad runtest failure
[10:46:20] <skunkworks_> cradek, I am sure that screenshot was run at machine maximum..
[10:46:30] <skunkworks_> not normal machining speeds
[10:48:10] <seb_kuzminsky> is the interp test failure due to a change in arc tolerance?
[10:49:29] <skunkworks_> his last comment
[10:49:31] <skunkworks_> > As for the interp tests, we could also just turn down the spiral tolerance.
[10:49:31] <skunkworks_> > I had it cranked way up as a proof of concept, but it doesn't necessarily
[10:49:31] <skunkworks_> > have to be that high.
[10:50:38] <seb_kuzminsky> we had talked about increasing arc tolerance a few weeks or so ago
[10:52:40] <seb_kuzminsky> we decided then to increase the arc radius tolerance to 0.002828 inches in imperial and 0.02828 mm in metric
[10:53:08] <seb_kuzminsky> that makes linuxcnc accept programs where arc centers & endpoints are rounded to 0.001 inch / 0.01 mm
[10:53:26] <seb_kuzminsky> the tp in 2.7.0~pre2 (current 2.7 branch) handles these tolerances just fine
[10:57:00] <akex> cradek are you here ?
[10:57:25] <seb_kuzminsky> akex: ask your question
[10:58:21] <akex> ok thx i want uderstand why linuxcnc won't start my programe
[10:58:34] <akex> http://pastebin.com/CFMvJGme
[10:58:53] <seb_kuzminsky> what error do you get?
[10:59:59] <seb_kuzminsky> i assume your machine is metric? there's no G21
[11:00:29] <akex> yes
[11:00:32] <akex> the tool will interfere with the piece
[11:01:46] <seb_kuzminsky> on the cutter comp entry move still?
[11:03:31] <akex> G3 X10. Y0. I-10. J0.
[11:03:37] <akex> at this line
[11:04:43] <akex> in english my error is that
[11:04:45] <akex> Interference of the tool with a finite part of the piece with the tool radius compensation [2]
[11:04:57] <seb_kuzminsky> ok, i'm trying it here now
[11:05:22] <akex> cradek say me it's possible to make a poket 20 with a tool 12
[11:05:31] <seb_kuzminsky> i agree with that
[11:05:31] <PetefromTn_> does the cutter comp callout have to have the tool callout on the same line?
[11:05:36] <akex> but linuxcnc won't do that
[11:05:45] <seb_kuzminsky> PetefromTn_: no, it should use the currently loaded tool by default
[11:05:56] <seb_kuzminsky> akex: let's figure out what's wrong here...
[11:06:10] <akex> yes my diam tool is 12 mm no forgot that
[11:06:25] <cradek> I said before: you can either enter cutter comp mode before putting the tool in the pocket, or use an arc entry move
[11:07:11] <akex> i just want uderstand my problem
[11:07:26] <akex> i translate your say 2 min please
[11:08:47] <akex> the problem is not entry move
[11:09:16] <akex> linuxcnc won't make a arc with my tool
[11:10:06] <seb_kuzminsky> "Arc move in concave corner cannot be reached by the tool without gouging"
[11:10:13] <seb_kuzminsky> Near line 26
[11:10:20] <akex> yes that it
[11:10:21] <seb_kuzminsky> bbl
[11:10:39] <akex> what is bbl ?
[11:11:23] <archivist> be back later
[11:12:00] <akex> if it's possible disable this protection or other. i have ever make that on other machining and work well
[11:12:13] <cradek> akex:
http://www.linuxcnc.org/docs/html/gcode/tool_compensation.html#sec:cutter-compensation
[11:12:14] <akex> ok archivist thx
[11:12:31] <cradek> look at the images in #3 and #3.1
[11:12:57] <cradek> look at where the tool goes at the end of the entry move when you make a concave corner for entry
[11:13:17] <cradek> see the green path on the #3 image
[11:14:40] <cradek> if you think about the entry move inside the circle you have programmed, you will see that it is impossible for the tool to fit in this corner
[11:16:20] <akex> i can't explain i don t have vocabulari
[11:17:07] <akex> how you "cradek" programe this pocket
[11:17:33] <akex> are you see
http://pastebin.com/CFMvJGme
[11:20:58] <akex2> I just like understand how programing that or disable this shiti protection
[11:21:52] <archivist> it is not "protection"
[11:23:19] <cradek> it's easy to think that removing an error message will make the program do what you want, but this is wrong, because the error message is there to tell you you've made a situation the program does not handle
[11:23:44] <cradek> so you could possibly make this situation work, but you would have to change the entry algorithm
[11:24:12] <cradek> you can understand the entry algorithm, and see why it does not work in the case you give, if you look at those images I linked earlier
[11:25:34] <cradek> useful-subroutines.ngc (in your distribution) does a different kind of entry above the hole, and then cuts the round pocket with helixes - you might want to look at that
[11:26:24] <cradek> I'm sorry it's frustrating but it's simply not a matter of removing error messages
[11:29:08] <akex> there are a french dec of linuxcnc ?
[11:29:27] <akex> because i can't uderstand all you say
[11:29:30] <cradek> http://www.linuxcnc.org/docs/html/index_fr.html
[11:29:49] <akex> dev* sorry
[11:30:20] <akex> cradek thanks for all.
[11:30:39] <seb_kuzminsky> the cutter comp entry move looks reasonable to me
[11:30:41] <cradek> http://www.linuxcnc.org/docs/html/gcode/tool_compensation_fr.html#sec:Compensation-rayon-d-outil
[11:30:45] <akex> but there are a glitch langage and i am frustrate
[11:30:56] <seb_kuzminsky> if i reduce the diameter of the tool to 1 mm it loads fine and displays the expected path
[11:31:12] <cradek> seb_kuzminsky: notice it doesn't cut the full circle
[11:31:27] <seb_kuzminsky> yep, it leaves the first part of the circle un-cut
[11:31:39] <akex> i want cut a full cir
[11:31:46] <seb_kuzminsky> with a larger-diameter tool, shouldn't it just leave more of the beginning of the circle uncut?
[11:32:01] <cradek> seb_kuzminsky: that's because the entry move target is inside the concave corner formed by the circle and the radial line
[11:32:24] <seb_kuzminsky> right
[11:32:47] <cradek> seb_kuzminsky: yes, until the tool doesn't fit inside that corner made up of half the circle
[11:33:10] <seb_kuzminsky> oh!!!
[11:33:31] <seb_kuzminsky> the diameter of the tool is 12 mm, and that's more than the distance between the entry move and the top of the circle
[11:33:34] <seb_kuzminsky> i get it now
[11:33:37] * seb_kuzminsky is a little slow
[11:33:40] <cradek> yes
[11:34:00] <cradek> as you increase the tool you'll see it cut less and less of the circle, until you hit 3/4 of the circle and it will no longer fit
[11:34:32] <cradek> so this is the wrong way to cut inside a circle :-/
[11:35:46] <seb_kuzminsky> yep
[11:36:10] <seb_kuzminsky> did my email to bence kovacs on emc-developers go out? i dont see it in the gmane archive
[11:37:42] <seb_kuzminsky> the sf archive has it, so i guess it got that far at least
[11:39:35] <cradek> http://timeguy.com/cradek-files/emc/blue-algorithm.png
[11:39:43] <cradek> don't laugh at my editing skills
[11:40:19] <cradek> I think this is an alternative entry algorithm that would work in this situation
[11:41:03] <cradek> (a different poison we could pick)
[11:44:19] <cradek> although the corresponding arc cases I'm thinking of make me shiver
[11:46:47] <seb_kuzminsky> the problem akex is having is that a 12mm tool can't both be to the left of the radial entry move and to the left of the (ccw) circle
[11:46:47] <cradek> notice that even in the simple case in my picture, in the right-side compensation mode, the tool will be cutting something to the left of the black line
[11:47:02] <cradek> yes
[11:47:15] <seb_kuzminsky> yes, that's surely worse
[11:48:12] <cradek> well I think I like the current green way better, but the blue way lets akex's pocket work
[11:48:41] <cradek> but I think the blue way has to assume what's going on on the left side, which it can't really know
[11:49:00] <cradek> I suspect some other controls use the blue algorithm for the pocketing reason
[11:49:35] <seb_kuzminsky> the blue way would also cut the whole circle, and not leave those little tufts at entry & exit like it does now
[11:49:40] <cradek> yes
[11:50:19] <seb_kuzminsky> it's maybe arguably not wrong to cut to the left of the entry move
[11:50:27] <cradek> but imagine cutting inside a square pocket (entering ill-advisedly at a corner)
[11:50:34] <seb_kuzminsky> the green algorithm does too, just not as much
[11:50:40] <cradek> green algorithm cuts not quite the whole square, blue gouges past it
[11:51:02] <seb_kuzminsky> yeah, right
[11:51:58] <cradek> sorry - green algorithm does too (what)?
[11:52:31] <seb_kuzminsky> cuts to the left of the entry move (it has to, since it starts out gouging by the tool radius)
[11:52:52] <cradek> well it transitions from halfway over the line, to next to it
[11:52:57] <seb_kuzminsky> tight
[11:52:59] <seb_kuzminsky> *right
[11:53:02] <cradek> by definition you're halfway over it before entry
[11:53:17] <seb_kuzminsky> yeah, unavoidably
[11:53:20] <cradek> I think that's not assuming in any way
[11:54:07] <seb_kuzminsky> i was thinking, since we must start out in that way, thus by definition it's allowed to cut the "wrong" side during the entry move
[11:54:08] <PetefromTn_> it would be above the part at that point usually in that instance right? I am trying to understand Cutter Compensation as well so this is interesting
[11:54:21] <seb_kuzminsky> PetefromTn_: absolutely
[11:54:32] <seb_kuzminsky> if you just do your entry move in the air, all these problems go away
[11:54:49] <cradek> yeah it's best to enter and exit cutter comp NOT touching the work
[11:55:00] <PetefromTn_> do you guys normally like to use a ramp infeed for something like this.
[11:55:10] <seb_kuzminsky> for pocketing?
[11:55:26] <Tom_itx> that or drill a hole for the cutter to plunge into
[11:55:41] <PetefromTn_> well for any cutter comp move so you can get the entry move done safely?
[11:55:43] <seb_kuzminsky> i prefer to ramp for material entry, but sometimes i'm too lazy and plunge because it's easier to write the gcode that way
[11:55:46] <cradek> seb_kuzminsky: blue algorithm is still cutting the left side even at entry's endpoint
[11:56:02] <cradek> seb_kuzminsky: which might not necessarily be worse
[11:56:06] <seb_kuzminsky> yeah, so it's potentially gouging more
[11:56:10] <cradek> I think this is what you're saying
[11:56:27] <seb_kuzminsky> yes, that's what i tried to say :-)
[11:56:35] <cradek> this is hard to talk about over text
[11:56:40] <cradek> even with my brilliant artwork
[11:57:24] <seb_kuzminsky> i wonder if there's a drawing program that lest you share a drawing workspace in a browser yet
[11:57:42] <seb_kuzminsky> eh, i should get back to work
[11:57:42] <cradek> the blue dashed line sure might not be what the part looks like over there, and for some shapes you'll not like what this does
[11:58:06] <seb_kuzminsky> yeah, green at least errs on the side of removing less material
[11:58:33] <seb_kuzminsky> seeyas
[11:58:34] <cradek> bbl
[22:01:32] <skunkworks> well that was unexpected..
[22:15:16] <kwallace1> skunkworks, do you use a rotary axis? I was asked to study the issues with Gremlin's display for a job such as engraving text on a cylinder. I haven't used a A axis so I have no idea what's up. I seem to recall the tool rotates instead of the workpiece.
[22:16:10] <skunkworks> kwallace1: correct.. For some instances it would be nice if the toolpath rotated in the preview instead..
[22:16:31] <skunkworks> (but I don't have a working rotory axis - just a lot of 4+ axis testing)
[22:20:03] <kwallace1> I was told "the paths were a mess". I assume that the text was not legible on the display but cut properly. This may be due to our version of Gremlin. I'm planning on getting a standard LinuxCNC working and play with it in sim but that may take some time.
[22:20:48] <skunkworks> kwallace1: that seems a bit odd.. it would be neat to see examples.
[22:23:17] <kwallace1> I'm just getting started on this, so I need to figure out how to put the g-code together and set up an A axis. I was supposed to have something done by tomorrow morning but I don't think it's going to happen.
[22:24:15] <skunkworks> would kins maybe have to be setup for some geometries for the preview to look correct? (thinking out loud..)
[22:26:14] <kwallace1> I don't know. The part comes out fine so the kins might be okay.
[22:31:16] <skunkworks> kwallace1: if you look at this 5 axis machining video - the preview looks correct in axis for the part it is machining..
[22:31:18] <skunkworks> https://www.youtube.com/watch?v=R1DCXe9t3UE
[22:32:40] <kwallace1> For fun, I put in g0 a 30 and the DRO counted up to 30 but the neither the tool or axes rotated. I suspect the A axis bit in our version of Gremlin is broken, which may be an adequate answer for tomorrow. Thanks for your help.
[22:33:07] <skunkworks> ah
[22:33:08] <skunkworks> ok
[22:36:22] <kwallace1> Hmm, the debug output shows "emcTaskPlanLevel() returned 0
[22:36:22] <kwallace1> Unknown word where unary operation could be
[22:36:23] <kwallace1> Interpreter stack: - int Interp::read_operation_unary(char*, int*, int*) - int Interp::read_unary(char*, int*, double*, double*) - int Interp::read_real_value(char*, int*, double*, double*) - int Interp::read_g(char*, int*, block*, double*) - int Interp::read_one_item(char*, int*, block*, double*)
[22:36:23] <kwallace1> emcTaskPlanExecute(GO A 30) returned 5
[22:36:23] <kwallace1> "
[22:37:20] <kwallace1> It looks like Gremlin and I will have some quality time this week.
[22:38:41] <skunkworks> yeck
[22:39:25] <kwallace1> Oops wrong again, that error is due to typing in GO (gee oh) instead of G0.
