Back
[08:47:20] <cradek> argh I can't just search for a ref on github (I'm sure it's in one or more repos)
[11:22:18] <seb_kuzminsky> cradek: that seems like a silly oversight on their part, i wonder what they'd say if you opened an issue on it
[11:23:44] <jepler> hi seb_kuzminsky
[11:23:50] <seb_kuzminsky> hola
[11:24:15] <cradek> how was your trip?
[11:24:31] <seb_kuzminsky> it was great
[11:24:50] <seb_kuzminsky> a week of camping and hiking in the high country, in unseasonably warm weather
[11:25:16] <seb_kuzminsky> what'd i miss down here? you guys have been busy it looks like
[11:28:20] <jepler> bpuk_ has sure been diving in, it's exciting
[11:29:06] <jepler> we got terkaa's g74/g84 in master
[11:30:11] <jepler> I got a 3d printer that works well enough with next to zero tinkering, so I've been printing on it for about 2/3 of my leisure hours this past week or so
[11:30:32] <seb_kuzminsky> wow three good news all in a row!
[11:31:46] <jepler> I probably missed something else that happened
[11:31:48] <seb_kuzminsky> which printer?
[11:32:01] <jepler> Monoprice Select Mini, the $200 one
[11:32:57] <jepler> it prints great in PLA, but so far is worthless for ABS
[11:33:35] <jepler> I think there's also some luck of the draw as to whether your printer was assembled well or poorly at the factory
[11:33:38] <seb_kuzminsky> d'awww cute
[11:34:14] <cradek> I always figure it's just me when I find the github website unusable
[11:34:29] <cradek> it's so popular but I usually can't fathom why
[11:34:44] <cradek> https://github.com/dspinellis/unix-history-repo
[11:34:50] <cradek> but there's this cool thing!
[11:35:19] <jepler> cradek: fwiw you can form a link to a commit in the semi-obvious way manually
http://stackoverflow.com/questions/12214746/find-a-commit-on-github-given-the-commit-hash but you have to guess the owner/project where the commit might be
[11:36:45] <cradek> it's in machinekit, and I couldn't even figure out how to find machinekit
[11:36:46] <jepler> cradek: I think the thing is, github the service improves sharing code enough vs self-hosted git that the failings in github's web ui are worth overlooking. we couldn't self-host a service that would let all these people make pull requests...
[11:37:00] <cradek> I mean I searched for machinekit, but none of the results looked like the right one
[11:37:07] <jepler> hah it's
https://github.com/machinekit/machinekit/
[11:37:37] <cradek> I tried sorting by "best match" and "most forks"...
[11:37:54] <cradek> "recently updated"...
[11:38:03] * cradek waves his arms
[11:38:29] <cradek> fwiw, searching for linuxcnc gives the correct result at the top with default search settings
[11:38:33] <jepler> interesting
[11:39:28] <cradek> jepler: I'm not saying we're wrong to use it! I'm just always surprised by all the ways it seems to suck.
[11:40:33] <jepler> cradek: have you *USED* unix ?
[11:40:41] <jepler> my god to complain about a website
[11:40:58] <cradek> wellll
[11:41:05] <archivist> I have :)
[11:41:46] <skunkworks> they all suck in different ways... Or.. they all have good aspects...
[12:25:06] <cradek> darn, I don't think I'm in unix-history-repo
[12:25:44] <cradek> I thought I might have some freebsd patches from super long ago
[14:14:29] <andypugh> Oh my.
[14:14:38] <andypugh> Forum users can be so literal.
[14:15:11] <andypugh> “if you had loadrt and2 count=100 you would have and.0, and2.1 … and2.99”
[14:15:38] <andypugh> “I tried loadrt and2 count=100 and LinuxCNC crashed”
[14:15:59] <bpuk_> wait, it crashed?
[14:16:41] <andypugh> and2 can only have 32 (I think) instances. So it fails to start. (which is described as a crash by users, typically)
[14:16:54] <cradek> "the system went down"
[14:17:33] <mozmck> no wonder they call it a crash either - you get a box with with pages of kernel gobbedly-gook messages!
[14:18:29] <bpuk_> wierd, just tried it here, 100 instances
[14:19:50] <bpuk_> but yes, literal user :D
[14:20:09] <jepler> glancing at how comp generates things currently, names= is limited to 16 names but count= doesn't have a direct limit imposed
[14:20:25] <jepler> I tried "loadrt and2 count=100 and LinuxCNC crashed" and LinuxCNC crashed
[14:20:39] <andypugh> But most components used a fixed-size arfray don’t they?
[14:21:00] <pcw_mesa> 100 works for me (at least the loadrt)
[14:21:39] <jepler> andypugh: yes and anything taking loadrt arrays (like names=) *has* to specify a maximum number
[14:21:49] <andypugh> He decided to load 100 “near” components too.
[14:23:00] <bpuk_> just be glad you didn't say 'loadrt and2 count=n would give and2.0, and2.1, ... and2.n-1'
[14:23:35] <pcw_mesa> I can load 366 before it runs out of mem
[14:27:19] <andypugh> bpuk_: I have been thinking more about G71. I am adding cardinal points to arcs to make it easier to spot their extents. By adding more extra points at frontangle and backangle positions it is probably fairly easy to detect couging.
[14:27:23] <andypugh> (gouging)
[14:27:49] <andypugh> I don’t think a straight line can ever gouge without the end-points gouging.
[14:28:15] <cradek> wonder if when you detect gouging, you should cut what you can (turn part of the arc into a line), or error
[14:29:02] <andypugh> Both?
[14:29:09] <bpuk_> depends on the type of gouging
[14:29:45] <bpuk_> I'm pretty sure I can come up with an example where type1 will gouge, nevermind type 2
[14:30:08] <bpuk_> any anti-gouging code is a good start, but with type2 it's ultimately the operators responsibility
[14:41:20] <seb_kuzminsky> if we annotate arcs with their cardinal points, it'll be easy to fix issue 80:
https://github.com/LinuxCNC/linuxcnc/issues/80
[14:43:03] <jepler> easier anyway
[14:43:31] <cradek> fwiw I think all pre-checks have been removed from master, so this same problem might now happen with any move; I haven't tested.
[14:47:49] <bpuk_> hmm. how many axes can arcs be defined in?
[14:48:29] <bpuk_> all 9?
[14:48:41] <cradek> we do not have uv, vw, wu arcs
[14:48:46] <cradek> we have xy, yz, zx
[14:48:54] <Tom_L> 17 18 19 are typically the planar axis
[14:49:06] <bpuk_> ok, so we don't have say... ax arcs either?
[14:49:08] <Tom_L> others are rotary
[14:49:09] <cradek> and of course they are all helixes (xy with z, yz with x, etc)
[14:49:18] <cradek> no, that makes no sense
[14:49:27] <Tom_L> so it may not be an arc at that point
[14:49:44] <cradek> wellll you can have an XY arc and also move A during it
[14:49:52] <bpuk_> true - axz - thinking about how to describe what I'm thinking of. an arc on a rotary surface
[14:50:12] <Tom_L> still a G17 arc iirc
[14:50:25] <bpuk_> ok, that does simplify the problem somewhat ;)
[14:50:33] <Tom_L> err maybe 18, i'd have to look
[14:50:37] <cradek> > If a line of code makes an arc and includes rotary axis motion, the rotary axes turn at a constant rate so that the rotary motion starts and finishes when the XYZ motion starts and finishes. Lines of this sort are hardly ever programmed.
[14:50:57] <bpuk_> err... they aren't? oops
[14:51:00] <cradek> http://www.linuxcnc.org/docs/html/gcode/g-code.html#gcode:g2-g3
[14:51:22] <bpuk_> must remember not to use arcs on the 4th axis
[14:53:17] <archivist> hmm geometric patterns on balls
[14:53:29] <bpuk_> so because an arc is defined in a plane - the cardinal points are obvious. ok. was thinking this was more complicated than it is
[14:54:04] <cradek> I'm sorry to let you know that nonplanar arcs are allowed
[14:54:09] <cradek> the motion controller supports them just fine
[15:36:25] <andypugh> The cardinal points might need to be twisted if an axis rotation is in effect
[15:37:24] <andypugh> If we have arc to arc blending now there may not be any penalty in splitting all the arcs into a sequence of smaller arcs, and letting end-point detectin handle the limit violations.
[16:17:03] <andypugh> My candle machining video didn’t make it into the Showcase then?
[16:21:38] <jepler> andypugh: I thought someone else had taken charge for the next Showcase but nothing ever happened and I don't remember if mozmck or jthornton was the one who said he was going to do it..
[16:22:23] <jepler> If anyone asked for help with getting the wlo "build" process going, I missed it
[16:22:45] <jepler> It's not that your project was deemd unworthy but just that nobody had the tuits I think
[16:23:10] <jepler> me, I was just really hoping to get some co-conspirators when it came to making showcase entries but that failed
[16:25:04] <andypugh> I think it was KimK actually
[16:26:03] <jepler> oh that may be the case
[17:05:22] <andypugh> bpuk_: What does G71 do with diameters that don’t correspond to a depth?
[17:06:06] <andypugh> Does it leave excess material, or back out from the current depth of cut to cut them at size + U?
[17:06:42] <stustev> If you program an arc and then rotate the coordinate system do you get a helix?
[17:07:34] <skunkworks> you can only rotate in the x/y plane
[17:07:42] <jepler> hi stustev thanks again for hosting fest last month or whenever that was
[17:08:08] <stustev> jepler: you are welcome - it was a fun time
[17:08:26] <stustev> Why can you only rotate in the xy plane?
[17:09:23] <skunkworks> that was the only implimentation
[17:10:06] <stustev> ok - then a little more implementation would allow other plane rotation.
[17:10:47] <stustev> It would not be the ultimate (easy) way to allow helix motion but would work.
[17:11:04] <stustev> If you could rotate two planes then any vector would be possible.
[17:12:16] <stustev> It would take thought to code in the gcode program but would allow any possible helix.
[17:13:18] <stustev> In the Fanuc 15M control G68 rotates a plane. G69 cancels the rotations.
[17:14:25] <stustev> You can rotate one plane on one line. The next line allows rotation of a second plane and combines the rotations.
[17:15:56] <bpuk_> andypugh: do you mean diameters greater than the start point?
[17:16:52] <andypugh> No, diameters that don’t correspond to a depth increment
[17:18:50] <bpuk_> so a change in diameter smaller than the depth of cut? in that case, leave excess material on type1, size+U on type2
[17:19:07] <bpuk_> since type2 does a partial prefinish at the end of each pass
[17:19:47] <bpuk_> if that's not what you meant, I'm really confused
[17:20:12] <stustev> helical motion (milling threads) is another matter entirely
[17:21:13] <Tom_shop> https://www.youtube.com/watch?v=MmQwKSrFPhM
[17:21:30] <Tom_L> G68
[17:26:33] <stustev> Tom: thanks - I had not seen that video.
[17:26:41] <Tom_L> wouldn't you mill threads with G33.1?
[17:27:17] <Tom_L> err maybe not with a single point cutter..
[17:27:40] <stustev> on the 5 axis BC head bridge mill at mpm you could rotate planes and position your program at any angle
[17:27:56] <Tom_L> got any cool machines at your new shop?
[17:28:13] <Tom_L> retrofits etc
[17:28:42] <stustev> not any cool machines running linuxcnc - there are a few projects in the works but nothing finished
[17:30:53] <Tom_L> haas says you must use a G17 18 or 19 before using the G68 to establish the axis plane
[17:31:13] <Tom_shop> http://gcodes.net/haas-g68-rotation/
[17:32:26] <Tom_shop> http://gcodes.net/
[17:32:29] <stustev> Tom_L: that is probable correct - it has been a few years since I used it (more than 10).
[17:32:32] <Tom_L> interesting site
[17:32:48] <Tom_L> lists linuxcnc as well
[17:43:41] <andypugh> Three times, in fact. As LinuxCNC, EMC, and RS274ngc
[17:53:30] <kirk_wallace> andypugh, I have been playing with Vismach and your write up in the docs helped a lot:
http://linuxcnc.org/docs/html/gui/vismach.html
[17:54:46] <andypugh> I think I wrote that at the right point, while I barely understood it myself, and so knew what was confusing and difficult ;-)
[19:23:55] <skunkworks> I don't think linuxcnc uses G68.. It uses an R in the g10 coordinate systems
[19:24:01] <skunkworks> iiirc
[19:29:51] <skunkworks> the mach yahoo groups and forum traffic sure seems to have slowed way down...
[19:35:23] <skunkworks> maybe that just means everything is working great
[19:37:17] <andypugh> Everybody has moved to Mach4 (or, Kflop and Flashcut)
[20:04:25] <Tom_L> i used an old old flashcut but moved to linuxcnc
[20:54:41] <pcw_home> EdingCNC, UCCNC, GRBL also
[20:56:10] <Tom_L> is grbl a subset of lcnc?
[20:57:01] <Tom_L> or derived from the original project..
[21:06:56] <jepler> I think grbl is original. their interpreter is not NIST's.
[21:07:15] <jepler> but you'd probably get more accurate information by asking someone affiliated with that project
[21:14:11] <Tom_L> more a curiosity really
[21:14:28] <Tom_L> know a guy using it
[21:14:40] <Tom_L> trying to get him to switch to lcnc
[21:15:20] <Tom_L> he's afraid the parport won't get him much without getting more hardware
[22:03:43] <jepler> I think that's probably true.
[22:04:24] <jepler> in terms of stuff like I/O counts, step generation rates, etc
[22:05:18] <jepler> the mp select mini 3d printer has a version of marlin, which is derived in part from grbl, and step rates are adequate, you have more I/Os, and you get analog which is of course important for 3d printing
[22:05:53] <jepler> but there's no HAL, and the gcode dialect doesn't have lots of nice linuxcnc stuff like looping, variables, math, cutter comp, etc..
[22:29:14] <skunkworks> and the grbl that I tested on my uno didn't have really good trajectory control. it was an exact stop planner with some spookyness to blend corners
[22:32:17] <skunkworks> http://www.cnczone.com/forums/opensource-software/271966-grbl-logging-linuxcnc.html