Back
[13:10:14] <Roguish> good morning. What is the status of linuxcnc and debian Jessie? is there documentation on straightforward installation of Linuxcnc on Jessie?
[13:11:51] <cradek> http://www.linuxcnc.org/docs/html/getting-started/getting-linuxcnc.html#_alternate_install_methods
[13:12:08] <cradek> the docs say amd64 & i386, simulation only
[13:12:57] <cradek> I don't think anyone has managed to get a realtime kernel on jessie that is reliable on a variety of hardware
[13:25:36] <Roguish> what about this:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
[13:25:49] <Roguish> sort of implies it's ok
[13:31:16] <cradek> do you intend to control machinery or use simulation?
[13:31:31] <CaptHindsight> is there a tool for Jessie that builds kernel packages?
[13:31:52] <CaptHindsight> I guess that debianizes it
[13:32:09] <Roguish> real machine. but primarily just curious. wheezy is working ok.
[13:32:15] <cradek> there obviously must be such a tool
[13:32:29] <cradek> if you apt-get source the kernel, you should be able to see how it's done
[13:32:48] <cradek> in the distant past I know it was called make-kpkg; I'm sure it has been reinvented by now
[13:33:47] <cradek> Roguish: then I heartily recommend not messing with it
[13:34:36] <Roguish> ok. no problem. like I said. just curious. thanks. yeah, i'm not into kernel building......
[13:50:38] <pcw_mesa> In my exp Preempt-RT/LinuxCNC is ok on Ubuntu 12.04 14.04 16.04, Mint 17,18, Wheezy,Jessie
[13:50:39] <pcw_mesa> but if you have new hardware you may need to build the RT kernel yourself
[13:51:14] <pcw_mesa> (or if no std RT kernel is available for the dist)
[13:53:18] <jepler> for debian jessie you can install 4.1, 4.4, or 4.6 realtime kernels from snapshot.debian.org --
https://emergent.unpythonic.net/01466682649
[13:53:56] <jepler> preempt-rt that is
[14:09:57] <bpuk> skunkworks: changing L to floating point is fairly easy, needs a recompile though
[14:10:29] <skunkworks> sounds like something that needs to be pushed to master :)
[14:13:15] <bpuk> I'll change it in my branch, should be ready to do another reasonable sized push over the weekend
[14:47:38] <skunkworks> to have it cut along the x axis instead of z - is that a different gcode?
[15:26:23] <bpuk> g72?
[15:42:11] <skunkworks> yes - I think you are rigth
[15:42:12] <skunkworks> right
[16:04:15] <bpuk> I think G73 has been used in linuxcnc?
[16:04:50] <bpuk> yeah, darn. for a drilling cycle
[16:05:31] <bpuk> ok. wierd thought - can we use the same code to do two different things depending on if LATHE = 1 is set?
[16:06:53] <cradek> so far we've managed to use the exact same interpreter for lathe and mill
[16:07:03] <cradek> so there's no precedent for that
[16:08:22] <bpuk> hmm. doing G71.1 instead of G73 might be the answer then
[16:08:24] <cradek> (I'm not saying it's a bad idea)
[16:08:45] <cradek> if that's not a crazy answer, then yeah it's easier
[16:08:57] <bpuk> I'm trying to visualise what would happen if you called G71/G72 on a mill.
[16:09:07] <cradek> but if that's crazy maybe it's time to consider having different interpreters, or at least different behaviors, for lathe and mill
[16:10:51] <bpuk> worth thinking about. Not sure if that ini VAR is passed to interp
[16:11:06] <cradek> no I'm sure it's not currently
[16:13:58] <bpuk> <-- finally got a break from dull paperwork at work, and back onto new designs. so my brain is thinking in the right mode again
[16:14:44] <bpuk> don't think different interpreters is the right answer, there would be too much shared code
[16:15:28] <bpuk> different behaviours would make more sense - especially since a lot of the internal checks are more or less in that direction
[16:15:46] <bpuk> (you're in the G19 plane, but this code doesn't make any sense! Begone!'
[17:25:13] <Tom_L> you mention lathe and mill. what about "other" ?
[17:25:52] <Tom_L> i suppose the G code wouldn't apply to all
[17:26:14] <bpuk> lathe and mill are the traditional - they're the ones that tend to have special g-codes and canned cycles
[17:26:33] <Tom_L> agreed
[17:26:40] <bpuk> I suppose 3D printer could also have useful canned cycles
[17:26:49] <bpuk> but other than that? examples? :D
[17:26:52] <Tom_L> what about EDM?
[17:27:05] <Tom_L> laser maybe
[17:27:33] <Tom_L> i'd say there are more of those using linuxcnc than 3d printers presently
[17:28:21] <bpuk> plasma?
[17:28:40] <Tom_L> there are quite a few of those
[17:28:44] <bpuk> EDM is very much a special case, and plunge and wire both could do with thier own behaviours
[17:28:49] <Tom_L> JT has one i know
[17:45:02] <bpuk> laser rastering could use a custom G-code - other than that, everything should be doable using remap.
[17:45:23] <bpuk> EDM does appear to be the special case, and I'm not convinced interp is the place to handle those cases
[18:07:38] <KimK_laptop> Re two behaviors, mill and lathe, just a quick question from a kibitzer (who should be on the road already anyway): don't we already have something in the ini file that says LATHE=TRUE/FALSE or some such? What is that doing?
[18:08:01] <cradek> right now, just the GUIs respond to that
[18:09:19] <KimK_laptop> OK, thanks, just checking. And thanks for deleting those ancient pages. Sorry it was just those few, maybe more someday.
[18:10:05] <bpuk> ideally, the UI should work out from the interpreter which mode it's in
[18:10:30] <bpuk> the current codebase works... but I'm not convinced it's ideal
[19:50:22] <bpuk> evenin' andy
[20:00:21] <andypugh> Evening.
[20:00:34] <andypugh> Beeen out with work colleagues, just got bacl
[20:00:37] <andypugh> (back)
[20:01:09] <andypugh> Did you see the latest G71 Type II style?
[20:02:26] <bpuk> I did - it's looking pretty much bob on
[20:03:08] <cradek> are you guys going to stir your work together and take us directly to type 2 in the interpreter?
[20:03:23] <andypugh> It’s not perfect on a new pocket, but I don’t know if it is bad enough to worry about
[20:03:53] <andypugh> I think straight to Type II is the plan.
[20:04:09] <bpuk> Philosophical decision - I've seen the argument a couple of times on the mailing list that we'd be better off moving _all_ cycles to python
[20:04:35] <cradek> why?
[20:04:39] <andypugh> It’s trivial to make G71.1 and G72.1 force Type I behaviour
[20:04:54] <bpuk> on the other hand, I'm going to keep working on a native interpreter - once I get the o-code stuff out of the way I'll start converting andy's algorithm
[20:05:58] <bpuk> cradek: as far as I understand it - keeps the interpreter code simple, and allows machine integrators access to the cycle code in a 'easy to use' format
[20:06:20] <bpuk> I'm not convinced. but if people want to argue that, I'll listen
[20:06:37] <andypugh> Doing it in Python means re-creating lines and arcs and offsets in Python. Doing it natively allows you to re-use the existing code, that is known to work.
[20:06:43] <cradek> I'm also not convinced but would read an argument
[20:07:20] <cradek> it sounds destabilizing for no useful reason, and I think you'd end up with something more complex
[20:07:38] <cradek> stirring several languages together usually doesn't make things simpler
[20:07:53] <andypugh> I think that the one making the arguement has moved on
[20:08:03] <cradek> I do not see a need for an integrator modifying the built-in cycles
[20:08:11] <cradek> oh ok, then let's also move on
[20:08:19] <bpuk> ok :D move on. C it is
[20:08:54] <andypugh> G71 is a (fairly) standard G-code. It belongs with the others
[20:09:24] <bpuk> andypugh: I'd keep with the G<n> X<n> keeps type1, G<n> X<n> Z<n> keeps type2 syntax
[20:09:55] <bpuk> it's cheap, it's standard amongst commercial controls, and it doesn't make life harder in implementation
[20:10:03] <andypugh> I’d rather we didn’t, you know.
[20:10:27] <bpuk> ok? why not?
[20:10:42] <andypugh> I don’t like a deliberate no-move Z code being used as a flag to alter behavouir.
[20:15:15] <bpuk> flags should be defined explicitly? (i.e. using G7<n>.<m>)
[20:15:37] <zeeshan> bpuk: what standard controls use Z as a g71 flag
[20:15:38] <bpuk> and I think it's sleep time for me. G'nite all. Will continue tomorrow
[20:15:41] <zeeshan> :P
[20:15:58] <bpuk> zeeshan: Haas, Fanuc off the top of my head
[20:16:00] <zeeshan> definitely not fanuc
[20:16:02] <zeeshan> or mazak
[20:16:03] <zeeshan> thats for sure
[20:16:20] <zeeshan> http://i.imgur.com/GpupTYb.png
[20:16:45] <bpuk> first line of profile block, not in the G71 command
[20:17:12] <zeeshan> o
[20:17:33] <bpuk> can't speak for mazak, never used one
[20:17:55] <zeeshan> not missing out on much
[20:17:56] <zeeshan> :P
[20:18:18] <andypugh> The way I see it, folk are likely to want Type II nearly every time, so we just give them a simple way to switch that off.
[20:18:26] <andypugh> But I am open to arguments the other way.
[20:19:09] <zeeshan> folks shouldnt be writing g71 by hand!!!!!!!!!
[20:19:27] <zeeshan> we need a linuxcnc features function that automatically generates the code for you using your g71!
[20:19:33] <bpuk> if I was doing a small batch, I'd prefer type 2. On a production batch, I'd prefer a type 1 if possible
[20:19:59] <andypugh> bpuk: Where do you get the profile from? Is it a call to interp_convert_arc (etc) or the next level up? And is the profile you get back diameter-compensated?
[20:20:16] <cradek> I'm sure I'll always write it by hand...
[20:20:22] <andypugh> bpuk: Why prefer Type 1 for production?
[20:20:26] <cradek> for me, that's the point
[20:20:34] <zeeshan> cradek: nerd!
[20:20:49] <andypugh> Yeah, a CAM sysrtem can do a better job than G71 can. It knows more.
[20:20:57] <zeeshan> noo
[20:21:01] <zeeshan> im talking something like mazatrol
[20:21:04] <andypugh> G71 is a way to avoid CAM
[20:21:11] <zeeshan> in mazatrol you define your shape
[20:21:16] <cradek> doesn't matter how good a cam system I don't have is
[20:21:20] <bpuk> andypugh: currently it's actually in convert_straight, with a comment to move it to the correct place
[20:21:20] <zeeshan> and it generates the tool path for you
[20:21:35] <zeeshan> for lathe, cam is kinda not quick.
[20:21:40] <zeeshan> unless you get into complex geometry
[20:21:43] <bpuk> andypugh: marginally faster, with a pre-finish path the stepped finish doesn't matter
[20:21:53] <cradek> but this is a tangent and I'll let you guys work on the cycles
[20:22:26] <bpuk> also, the current code doesn't compensate at all, adding the compensation isn't difficult but I wanted to concentrate on the algorithm first
[20:22:54] <andypugh> bpuk: It is only faster by root(2) - 1 of the plunge depth.
[20:23:06] <andypugh> It’s a tiny difference.
[20:23:56] <andypugh> With no pockets it really is likely to be almost identical, and might give better tool-life or allow a faster feed on the finish.
[20:24:25] <bpuk> cradek: cam for lathes is meh, it doesn't give a huge boost over g71. I've also never found a cam system I can't beat by hand-coding, or hand-tweaking
[20:24:52] <bpuk> andypugh: yup, we're talking fractions of a second. scarily, that's enough to matter
[20:26:00] <bpuk> andypugh: but a lot depends on the industry and machine. for a lot of the parts I run, it doesn't matter at all, I just need a perfect part.
[20:26:19] <bpuk> For the few production parts I run, a fraction of a second is important
[20:26:25] <zeeshan> bpuk: lets have a cam vs manual programming race
[20:26:27] <zeeshan> :D
[20:26:33] <andypugh> G71.1 to force Type1 behaviour is my preference, but it’s not somethng I will argue hard about.
[20:26:38] <Tom_L> bpuk what industry are you in?
[20:27:05] <bpuk> I make drinks dispense equipment - 80% of my machining time is toolmaking. the rest is production
[20:27:42] <Tom_L> yeah probably not real high production
[20:27:48] <bpuk> exactly
[20:28:03] <bpuk> a 'big' batch for us is 25k
[20:28:25] <bpuk> but the difference between 6 seconds a part and 5.5 seconds a part is noticable
[20:29:10] <Tom_L> probably alot of stainless?
[20:29:56] <bpuk> acetal and stainless are the two most common
[20:30:05] <bpuk> followed by brass
[20:30:17] <bpuk> almost no mild steel or aluminium
[20:30:30] <Tom_L> i ran alot of brass roundbar in years past
[20:30:44] <Tom_L> then a mix of steel and aluminum
[20:30:46] <bpuk> I like running brass, it just doesn't happen much ;)
[20:31:11] <Tom_L> i could chew thru 6 bars in ~20 min
[20:31:18] <Tom_L> 1"
[20:31:29] <bpuk> P20 or Toolox 33 is the most common material for non-production
[20:31:53] <bpuk> and every time I run it, I go a bit faster, and I'm probably still not running as fast as I can
[20:32:51] <bpuk> I tend to dive for cover - especially on the finish passes after hardening
[20:33:18] <bpuk> lovely stuff, just scary :D
[20:45:23] <andypugh> We used to use P20 a lot in a previous job, but I have never used it on my own projects.
[20:46:17] <andypugh> I tend to use EN1A when I don’t care or EN24 when I do, to be honest
[20:46:37] <andypugh> (And I know those specs were obsoleted before I was born)
[21:44:02] <cradek> ooh the docs links, including the quickref, for 2.5 on linuxcnc.org work
[22:29:26] <skunkworks> did they not?
[22:29:36] <skunkworks> zlog
[22:29:50] <cradek> I was just pleasantly surprised
[22:29:53] <cradek> that's pretty old stuff
[22:30:06] <cradek> 1.108256 -0.000032 -0.000027 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
[22:30:30] <cradek> interesting - the stuff written to the probe log is the feedback position
[22:30:40] <cradek> (I guess that's what you'd want)
[22:31:58] <cradek> linuxcnc is awesome, even v2.5.0
[22:33:18] <pcw_home> Yeah, don't want to add the following error to the probe measurements
[23:08:52] <cradek> heh I think I remember writing or fixing that...
[23:13:10] <cradek> Author: Chris Radek <chris@timeguy.com>
[23:13:10] <cradek> Date: Thu Oct 15 15:09:55 2009 -0500
[23:13:17] <cradek> Probing needs the cartesian feedback position ...
[23:26:40] <Tom_L> trying to compile master, python version too old. lucid 10.04
[23:28:34] <cradek> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
[23:28:57] <cradek> it's not you - master no longer builds on ubuntu10
[23:29:13] <Tom_L> i kinda figured that but tried anyway
[23:29:17] <cradek> but 2.7 does
[23:29:19] <Tom_L> since it's not supported anymore
[23:29:24] <Tom_L> oh?
[23:29:27] <Tom_L> 2.7.8?
[23:29:33] <cradek> from this page, looks like
[23:29:37] <cradek> sure
[23:30:04] <Tom_L> so i do a git checkout 2.7 instead of master?
[23:30:09] <cradek> yes
[23:30:10] <Tom_L> i don't do git much :)
[23:30:36] <Tom_L> i don't need it, just messin
[23:31:20] <Tom_L> so i should use precise or wheezy i suppose..
[23:31:34] <cradek> use wheezy if you want it trouble-free
[23:31:49] <Tom_L> is it flakey on 12.04?
[23:32:13] <cradek> I've never used ubuntu12, but it's 4+ years old and I know there's no live cd
[23:32:23] <cradek> I mean no linuxcnc cd
[23:32:25] <Tom_L> ok
[23:33:01] <Tom_L> i've got wheezy on a hdd here somewhere
[23:36:00] <cradek> the shape I digitized tonight:
http://timeguy.com/cradek-files/emc/lensoutline.png
[23:36:41] <Tom_L> looks like eyeglasses lens
[23:36:45] <cradek> ding ding
[23:38:24] <cradek> which reminds me, I probably shouldn't leave it in the acetone all night
[23:38:34] <Tom_L> no probably not
[23:38:50] <Tom_L> did you digitize it with a probe and lcnc?
[23:44:29] <cradek> yep
[23:45:26] <cradek> oops, it melted either the "lens" or some coating on it
[23:45:41] <cradek> it was just the demo lens that came in the (new) frame
[23:46:45] <Tom_L> why was it soaking to begin with?
[23:46:54] <Tom_L> had you been cutting on it?
[23:46:56] <cradek> I superglued it to probe it
[23:47:06] <Tom_L> oh
[23:48:34] * Tom_L powers down and goes into sleep mode
[23:50:17] <cradek> http://timeguy.com/cradek-files/emc/lensprobe.jpg
