#linuxcnc-devel | Logs for 2016-11-21

Back
[00:48:12] -!- pfoetchen has quit [Ping timeout: 256 seconds]
[01:07:17] -!- remstw has quit [Ping timeout: 246 seconds]
[01:37:08] -!- andypugh has quit [Quit: andypugh]
[01:43:50] -!- stustev has quit [Ping timeout: 244 seconds]
[01:56:15] -!- stustev [stustev!~stustev@helixmachine.com] has joined #linuxcnc-devel
[02:57:34] -!- alex4nder has quit [Ping timeout: 250 seconds]
[02:59:24] -!- alex4nder [alex4nder!~alexander@ec2-52-33-60-95.us-west-2.compute.amazonaws.com] has joined #linuxcnc-devel
[03:50:28] -!- Guest59080 [Guest59080!~Kitteh@198.211.102.17] has joined #linuxcnc-devel
[04:01:23] -!- Roguish has quit [Remote host closed the connection]
[04:19:33] -!- Guest59080 has quit [Remote host closed the connection]
[04:24:25] -!- zeeshan has quit [Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/ - 64bit Windows version by http://kvirc.d00p.de/]
[04:25:38] -!- andre`` [andre``!~Kitteh@198.211.102.17] has joined #linuxcnc-devel
[04:29:51] -!- andre`` has quit [Remote host closed the connection]
[04:58:13] -!- kingarmadillo has quit [Ping timeout: 256 seconds]
[05:13:25] -!- kwallace_ofcb [kwallace_ofcb!~kwallace@162.222.30.253] has parted #linuxcnc-devel
[06:58:19] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[07:43:12] -!- ve7it has quit [Remote host closed the connection]
[08:48:23] -!- remstw has quit [Ping timeout: 245 seconds]
[08:49:09] -!- KGB-linuxcnc has quit [Ping timeout: 260 seconds]
[08:55:59] -!- KGB-linuxcnc [KGB-linuxcnc!~kgb-linux@git.linuxcnc.org] has joined #linuxcnc-devel
[08:58:37] -!- kingarmadillo has quit [Ping timeout: 240 seconds]
[09:20:04] -!- kingarmadillo has quit [Ping timeout: 258 seconds]
[09:48:49] -!- remstw has quit [Ping timeout: 252 seconds]
[10:45:16] -!- sel [sel!~sel@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[10:46:05] -!- sel has quit [Client Quit]
[10:59:45] -!- skunkworks has quit [Ping timeout: 256 seconds]
[12:30:06] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:02:00] -!- kalxas has quit [Changing host]
[13:08:23] -!- kingarmadillo has quit [Ping timeout: 245 seconds]
[13:13:04] -!- kingarma1illo has quit [Ping timeout: 250 seconds]
[13:13:28] -!- skunkworks has quit [Ping timeout: 260 seconds]
[13:19:38] -!- kingarmadillo has quit [Client Quit]
[13:36:04] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:40:55] -!- skunkworks has quit [Ping timeout: 252 seconds]
[13:41:59] -!- b_b has quit [Changing host]
[13:47:46] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:51:39] <skunkworks> zlog
[13:51:40] <zlog> skunkworks: Log stored at http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-11-21.html
[13:52:14] <skunkworks> Hmm - me typing zlog creates the log.. If a tree falls in the forest....
[13:58:08] -!- skunkworks_ [skunkworks_!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[14:22:01] <JT-Shop> skunkworks: I'm working on a different format for the logs http://gnipsel.com/logs/%23linuxcnc/index.html
[14:36:30] <skunkworks> cool!
[14:51:33] -!- racicot has quit [Quit: Z-Pulley - Later]
[14:55:29] -!- unknownids has quit [Ping timeout: 258 seconds]
[15:29:46] -!- kwallace_ofcb [kwallace_ofcb!~kwallace@162.222.30.253] has joined #linuxcnc-devel
[15:43:32] -!- maurris has quit [Ping timeout: 256 seconds]
[15:57:33] -!- ronaldinho_07 [ronaldinho_07!2a778d96@gateway/web/freenode/ip.42.119.141.150] has joined #linuxcnc-devel
[16:04:53] -!- ronaldinho_07 has quit [Quit: Page closed]
[16:34:31] -!- terkaa [terkaa!~terkaa@a91-155-72-157.elisa-laajakaista.fi] has joined #linuxcnc-devel
[16:35:23] <terkaa> hi
[17:10:17] -!- GJdan_ has quit [Quit: WeeChat 1.7-dev]
[18:00:29] -!- terkaa has quit [Ping timeout: 268 seconds]
[18:13:48] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[18:23:17] -!- GJdan has quit [Quit: WeeChat 1.7-dev]
[19:04:05] -!- Connor has quit [Ping timeout: 248 seconds]
[19:04:40] -!- Connor [Connor!~Connor@71.203.255.220] has joined #linuxcnc-devel
[19:18:23] -!- stustev has quit [Ping timeout: 245 seconds]
[19:37:37] -!- skunkworks_ has quit [Ping timeout: 258 seconds]
[19:45:25] -!- terkaa [terkaa!~terkaa@a91-155-72-157.elisa-laajakaista.fi] has joined #linuxcnc-devel
[19:47:59] <terkaa> Hmmm... this looks cool
[19:48:00] <terkaa> https://www.youtube.com/watch?v=fT1gLX-XbGQ
[20:03:38] -!- kingarmadillo has quit [Ping timeout: 256 seconds]
[20:14:28] <jepler> hm as fast as that arm seems to move I guess that's a sped up video
[20:15:31] <jepler> given that you need multiple mountings anyway, I wonder if it's actually a time saver to mount that adapter
[20:15:45] <jepler> might also have limitations of Z working distance that it helps with
[20:17:01] <skunkworks> the fixture plate uner is impressive.. Look at all the holes!
[20:19:08] <cradek> these bed mills don't have knees, so you're hard pressed to drill into the edge of something big
[20:19:27] <bpuk> if you don't have the clearance height you kind have to do it that way
[20:19:31] <cradek> but doesn't everyone have a 6' tall drill press?
[20:19:45] <skunkworks> yes?!
[20:19:52] <bpuk> that said, I've used 90 degree adaptors (on MDF). They're handy, but rigid isn't the term I'd use
[20:20:40] <skunkworks> or a horizontal mill that you can just hang stuff off the table...
[20:20:57] <bpuk> that tooling plate does look nice though
[20:21:25] <bpuk> and nice demo of using pins to locate the part
[20:23:19] <bpuk> aaand I've just looked at the price of that plate
[20:27:22] -!- stustev [stustev!~stustev@helixmachine.com] has joined #linuxcnc-devel
[20:30:12] <terkaa> That can be used with ATC
[20:30:56] <terkaa> Also it might not be useful for parts that small but it is good for big parts
[20:33:28] <terkaa> Like here
[20:33:30] <terkaa> https://www.youtube.com/watch?v=T-xy9Fnrmlc
[20:34:28] -!- pragmaticus has quit [Ping timeout: 250 seconds]
[20:34:44] <terkaa> And these can also be rigid https://www.youtube.com/watch?v=83h0WNy6pMA
[20:34:52] <terkaa> But very expensive
[20:35:29] <terkaa> New ones from 3000 up
[20:35:36] <bpuk> The ones I used were on a C axis around the spindle, so you could drill/mill all 4 sides of the part
[20:35:58] <terkaa> bpuk: Those were built in=
[20:36:00] <terkaa> ?
[20:36:38] <bpuk> C axis built into the machine, pin in the angle head goes into the c-axis, can turn to any angle
[20:37:26] <terkaa> Oh ok. That would be really good
[20:37:52] <terkaa> This one is also good: https://www.youtube.com/watch?v=cKoTfRxAD78&t=259s
[20:37:59] <bpuk> but you're still sticking the tool another 6"-18" out from the spindle
[20:38:42] <terkaa> bpuk: Yes but on these bigger machines it has to.
[20:39:48] <bpuk> https://www.youtube.com/watch?v=gzyvsEVZkq8
[20:40:30] <terkaa> Or our machine wont have any kind of "reach" with angle head: https://www.youtube.com/watch?v=U7TwyWRrVas
[20:41:09] <bpuk> heh, with a 4" quill travel on my home mill - I think it's safe to say I'm not going to be using one soon
[20:42:40] <bpuk> yup, for a horizontal you'd want stickout
[20:42:45] <terkaa> Yep these wont fit on that one.
[20:43:20] <terkaa> Yes we need that especially because we do not have "zoom boom" on this one
[20:44:27] <terkaa> I have been considering this one: http://www.ebay.com/itm/222298625473?ul_noapp=true
[20:44:57] <bpuk> I'm trying to get a sense of scale from that video - but I suspect I could fit my BP onto the table of your miller
[20:45:52] <terkaa> It has 2500X1250mm XY
[20:46:18] <bpuk> yeah, my mill would fit on the table, you'd probably get the surface grinder on at the same time
[20:47:10] <terkaa> Yes we need this one for some operator cabin base plates milling
[20:47:30] <terkaa> Those plates are used in underground mining equipment
[20:49:00] <terkaa> But to get to point. I have never used this kind of angle heads. If I can get hold on one, how do I program it?
[20:49:34] <bpuk> do you use CAM?
[20:49:46] <bpuk> if not, carefully
[20:50:13] <terkaa> Yes. But I still need to know it in G-code level
[20:50:28] <terkaa> Basically Y-axis becomes Z
[20:50:36] <terkaa> and Z-becomes Y
[20:51:38] <terkaa> Do we need to change to XZ-plane?
[20:52:04] <bpuk> that's one way, the other way is to consider it a rotation through 90 degrees in the A axis.
[20:53:05] <terkaa> Ok, which one would be simpler, regarding using correct tool length offset? (in this case Y-axis movement)
[20:55:00] -!- skunkworks has quit [Ping timeout: 250 seconds]
[20:55:51] <terkaa> I believe application will be drilling, or simple straight milling. Not contours
[20:56:32] <bpuk> if it's fairly simple (drillling/slotting) I'd probably do it by hand. Wondering about flipping the axes, so that you'd program it as a vertical
[20:58:41] <terkaa> Would it be G18 with ie G55 coordinates
[20:59:17] <terkaa> Would tool lenght offset then work with G0 G43 Z10 Hx
[21:01:56] <bpuk> really not sure without testing
[21:02:53] <terkaa> Ok I will test if we find used angle heads
[21:05:00] <bpuk> should be able to test without an angle head - weld two bars together at 90 degrees, stick them in a toolholder, and don't start the spindle
[21:05:26] <terkaa> Hmmm... that is true
[21:05:27] <bpuk> (or cable tie a sharpie to a tool at 90 degrees)
[21:05:53] <terkaa> we have some scrap tools that can be welded
[21:08:13] <terkaa> I can try that tomorrow to see if it is that simple to program
[21:14:24] <bpuk> I'm building up a certain amount of amusement from reading the comments in rs274ngc core
[21:14:54] <bpuk> 'This version does not use any additional memory as it runs. No memory is allocated by the source code'.... #include <set>
[21:15:16] <cradek> bet there are lots of funny stories in there
[21:15:49] <bpuk> 'seems to work ok! FIXME mah is this needed?'
[21:16:10] <bpuk> '// paranoia.'
[21:17:02] <bpuk> all very reassuring comments during a complex set of control flow :D
[21:19:09] <bpuk> out of curiosity - who wrote the o-word code? I know mah did the remap
[21:19:30] <cradek> ken lerman did most of it
[21:20:03] <cradek> I think that was when the interp first malloced
[21:20:29] <bpuk> guessing no longer involved?
[21:21:14] <cradek> ?
[21:21:37] <bpuk> Sorry, I'm guessing Ken Lerman isn't actively involved in linuxcnc these days?
[21:22:00] <cradek> he posts on the lists sometimes
[21:23:51] <bpuk> ok, so if I really can't figure out the control flow he might be able to help
[21:24:09] <cradek> possibly!
[21:24:13] <bpuk> good to know - I'm using A2 paper to graph the basics out - and I'm on my third sheet :D
[21:24:38] <cradek> yikes
[21:24:56] -!- terkaa has quit [Quit: Leaving]
[21:26:21] <bpuk> hmm... does git go back to before remap was implemented?
[21:26:54] <cradek> pretty sure
[21:27:01] <cradek> I think everything mah did was way post-git
[21:27:25] <bpuk> that might make it easier - if I can at least split the python stuff out it'll simplify this a lot
[21:27:26] <cradek> O-words are probably pre-git (we used cvs) but all that history was imported into git
[21:27:59] <cradek> I don't think anyone understands remap :-/
[21:28:05] <cradek> you will be our expert!
[21:28:15] <bpuk> I'm hoping to not touch it at all
[21:28:21] -!- b_b has quit [Remote host closed the connection]
[21:28:58] <cradek> it ain't just you
[21:29:05] <cradek> :-)
[21:29:08] -!- pcw_mesa has quit [Remote host closed the connection]
[21:29:11] <bpuk> whoo! branch v2_0_branch does not have the word 'python' in rs274_ngc_pre.cc
[21:29:13] <bpuk> hehe
[21:29:41] <bpuk> interestingly there is a comment in the header - 'This version of the interpreter not saving input lines. A list of all lines will be needed in future versions to implement loops, and probably for other purposes.'
[21:30:02] <cradek> huh
[21:30:26] <cradek> you can sometimes see the future, but usually not perfectly clearly...
[21:30:32] <bpuk> yup, and yet... loops, and other purposes were implemented without saving input lines ;)
[21:30:51] <mozmck> If you're fixing stuff in o-words, make it so "if" statements don't need another O words ;-)
[21:31:11] <bpuk> oh, I'm fixing nothing! it's terrifying in here
[21:31:38] <jepler> (out of all O-words only "sub" should actually need an ID attached)
[21:32:14] <jepler> I think the interpreter was never not terrible, but it's the interpreter we have
[21:32:15] <bpuk> mozmck - if you want me to take a look I'll need at least two g-code files before I'll even consider diving into this pit of nightmares
[21:32:38] <mozmck> bpuk: I was mostly kidding - I bet it's not a trivial fix.
[21:32:40] <bpuk> I'd need one which works using the current syntax, and one that shows how you expect it should work
[21:32:53] <bpuk> probably not, but while I'm digging *shrug*
[21:32:58] <cradek> noooo
[21:33:24] <cradek> we don't want to break all existing gcode programs, and we don't want to support two dialects
[21:33:40] <cradek> it's too late
[21:34:02] <bpuk> which is why we don't have the interpreter we deserve, but instead the interpreter we have
[21:34:41] <bpuk> cradek: which is the exact reason I don't want to push G71 to emc-users until the syntax is locked in
[21:35:09] <cradek> I think you're being smart
[21:35:27] <mozmck> Yeah, so right now you have to have a unique o## for an if statement: o11 if ... o11 endif
[21:36:34] <mozmck> It would be great if the requirement for the unique o## was removed for if statements (and anything else except the "sub" as jepler said).
[21:36:53] <bpuk> but it would throw up the dialect issue
[21:37:11] <mozmck> Yeah - not sure why that would be a problem though.
[21:37:29] <cradek> maybe there's an implementation that would allow o if ... with no number after the o
[21:37:35] <cradek> would have to think it through
[21:37:50] <bpuk> breaking old gcode
[21:37:51] <cradek> o endif would hook back to the latest (unnumbered?) one
[21:38:02] <bpuk> what about nested if's?
[21:38:07] <bpuk> nvm
[21:38:11] <cradek> maybe it's possible to allow but not require the number
[21:38:33] <cradek> bpuk: I don't know. an if stack or something.
[21:38:51] <cradek> bpuk: but roughing! don't get distracted!
[21:39:06] <bpuk> hehe
[21:39:30] <bpuk> I did get distracted at work today - looked at awallins openvoroni
[21:39:50] <bpuk> and went 'this would work perfectly with arbritrary profiles'
[21:42:34] <bpuk> but that's a year or so off
[21:46:27] <bpuk> and more to the point - would that be of interest long term?
[21:48:20] <jepler> OpenVoronoi is under the GPLv3 so unfortunately it can't be incorporated in LinuxCNC, which has some portions (like the interpreter) that are licensed GPLv2 only.
[21:48:57] <bpuk> darn
[21:49:25] <jepler> it's an unfortunate license situation in LinuxCNC that we have to live with.
[21:49:36] <bpuk> would an equivalent implementation be of interest (2.5D CAM with offset profile, trochoidal machining - within the lcnc core)
[21:53:42] <jepler> I don't feel like I know how widely it would be used
[21:54:12] <jepler> if it scratches an itch for you, you should work on it.
[21:55:11] <bpuk> it's more - it affects how I do the profile reading code
[21:56:09] <jepler> you concluded that the type of offsetting done by cutter comp doesn't fit the needs well enough?
[21:57:07] <bpuk> for milling machines - not to the best of my knowledge
[21:57:09] <jepler> (it seems like the type of algorithm you're considering might also replace the current cutter comp algorithm)
[21:57:33] <bpuk> oh no - cutter comp would remain as is - it's toolpath generation
[21:58:39] <jepler> OK, it's clear I've gotten out of my depth on this subject.
[21:59:16] <bpuk> ok - I needed to cut a large pocket at work - we have no CAM software. Writing the toolpath (which is crude) took me about an hour and a half
[22:00:10] <bpuk> the machine control has a G-code to cut an arbritrary pocket, with the profile defined by a subprogram. But it's the stupidist toolpath you could possibly use to make the pocket
[22:00:46] <bpuk> so my brain asked: why can't a sensible toolpath be generated by the control given that program
[22:02:45] <jepler> isn't computing an offset path an important subproblem of this problem?
[22:02:57] <bpuk> the two logical toolpaths (which any CAM package today would generate) would be a centre starting offset toolpath (with or without a finishing pass), or a HSM trochoidal clearing path, followed by a finishing pass)
[22:03:19] <bpuk> yes, it is. but it's not a single offset, it's 'how many passes do we need'
[22:04:43] <bpuk> tbh I'm mostly asking myself 'what features would the perfect machine control have for me'
[22:04:53] <jepler> that's all most of us do
[22:08:38] <bpuk> I think making a cuppa tea should be a feature
[22:11:37] -!- persina has quit [Quit: Page closed]
[22:13:48] -!- pcw_mesa [pcw_mesa!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[22:17:50] <bpuk> ok. I _think_ I've found the correct entry point
[22:18:02] <bpuk> should G71 be able to be called from within a osub?
[22:19:04] <bpuk> i.e. O100 call -> O100 sub G71 O199 <blah> O0100 endsub
[22:19:26] <jepler> bpuk: seems like that would be desirable
[22:20:28] <jepler> afk
[22:21:30] -!- Tom_L has quit []
[22:21:48] -!- Tom_itx [Tom_itx!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[22:21:55] Tom_itx is now known as Tom_L
[22:23:59] -!- skunkworks_ [skunkworks_!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[22:28:14] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[22:34:17] -!- JT-Shop has quit [Remote host closed the connection]
[22:35:42] -!- JT-Shop [JT-Shop!~john@198.45.191.246] has joined #linuxcnc-devel
[22:50:10] <pcw_mesa> I guess I need sterner warning about wring wrong bitfiles to our FPGA cards
[22:50:12] <pcw_mesa> (1 5I25 bitfile --> 7I92 and one 7I92 bitfile --> 5i25 in the last 2 months)
[22:52:09] <andypugh> Is it a permanent problem?
[22:52:25] <andypugh> Or is the problem that they were sent out like that?
[22:53:53] <jepler> I think the 7i92 needs JTAG to recover from that, not sure about 5i25
[22:56:12] <pcw_mesa> Yep both need JTAG
[22:57:00] <pcw_mesa> customers not finding the desired bitfile so using one for another card
[23:04:15] <andypugh> Can Mesaflesh be made to refuse?
[23:08:40] <pcw_mesa> it already refuses wrong FPGA type but this is the same FPGA type
[23:08:52] <pcw_mesa> (but different pinout)
[23:09:48] <pcw_mesa> all the current flashable bitfiles have the card name in the file so mesaflash could refuse if the file name is not right
[23:11:29] -!- kalxas has quit [Quit: Goodbye]
[23:45:53] -!- kingarmadillo has quit [Ping timeout: 256 seconds]