Back
[00:07:31] -!- teepee has quit [Ping timeout: 244 seconds]
[00:13:43] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[00:16:34] -!- skunkworks has quit [Remote host closed the connection]
[00:19:59] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[00:41:44] <andypugh> skunkworks: Which branch is the Matsu running?
[00:53:46] -!- Miner_48er has quit [Quit: Leaving]
[00:53:48] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[00:56:51] -!- tobias47n9e_ has quit [Ping timeout: 276 seconds]
[00:58:43] -!- andypugh has quit [Quit: andypugh]
[01:03:05] -!- kalxas has quit [Quit: Goodbye]
[01:06:34] <skunkworks> 2.7.4 I think
[01:07:41] <skunkworks> the current 2.7. release
[01:11:05] <seb_kuzminsky> i'm glad 2.7 is being useful
[01:25:36] <skunkworks> they have all been very useful
[01:33:00] -!- Miner_48er has quit [Read error: Connection reset by peer]
[01:37:39] <seb_kuzminsky> glo is very slow for me
[01:37:53] <seb_kuzminsky> i can connect to it, but the ssh server is not real snappy like
[01:54:13] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[02:20:37] -!- skunksleep has quit [Ping timeout: 252 seconds]
[02:45:51] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:54:43] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[03:13:53] -!- pcw_home [pcw_home!~chatzilla@c-50-143-148-115.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[03:24:57] -!- skunksleep has quit [Ping timeout: 250 seconds]
[03:34:13] -!- andypugh [andypugh!~andypugh@12.1.118.71] has joined #linuxcnc-devel
[03:43:12] <KGB-linuxcnc> 03andypugh 05master 6b46650 06linuxcnc 10configs/sim/axis/vismach/VMC_toolchange/toolchange_gray.hal 10configs/sim/axis/vismach/VMC_toolchange/toolchange_index.hal 10src/hal/components/carousel.comp carousel.comp: Add pins to enable jogging of the carousel. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6b46650
[03:43:31] <andypugh> skunkworks: ^
[03:48:06] -!- andypugh has quit [Quit: andypugh]
[04:16:36] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[04:53:52] -!- sel [sel!~sel@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[04:54:21] -!- sel has quit [Client Quit]
[05:03:49] -!- JT-JA14- [JT-JA14-!~john@198.45.191.246] has joined #linuxcnc-devel
[05:04:06] -!- PCW_ [PCW_!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[05:06:08] -!- mal``` [mal```!~mal``@68.ip-149-56-14.net] has joined #linuxcnc-devel
[05:08:47] -!- alex_jon1 [alex_jon1!~alex_joni@81.196.65.201] has joined #linuxcnc-devel
[05:12:54] -!- mal`` has quit [Ping timeout: 246 seconds]
[05:12:55] -!- radish has quit [Ping timeout: 246 seconds]
[05:12:55] -!- PCW has quit [Ping timeout: 246 seconds]
[05:12:56] -!- JT-JA14 has quit [Ping timeout: 246 seconds]
[05:12:56] -!- alex_joni has quit [Ping timeout: 246 seconds]
[05:12:57] -!- racicot has quit [Ping timeout: 246 seconds]
[05:12:57] -!- pcw_home has quit [Ping timeout: 246 seconds]
[05:12:58] -!- ve7it has quit [Ping timeout: 246 seconds]
[05:12:58] racicot_ is now known as racicot
[05:13:00] radish_ is now known as radish
[05:13:30] -!- pcw_home [pcw_home!~chatzilla@c-50-143-148-115.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[05:14:41] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[05:20:23] -!- radish has quit [Changing host]
[06:02:15] -!- Mathnerd314 has quit [Ping timeout: 250 seconds]
[06:04:42] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[06:09:03] -!- skunksleep has quit [Ping timeout: 240 seconds]
[06:16:54] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[06:29:20] -!- kwallace1 [kwallace1!~kwallace@162.222.28.6] has parted #linuxcnc-devel
[06:31:49] -!- ve7it has quit [Remote host closed the connection]
[06:34:54] -!- Connor has quit [Quit: Leaving.]
[07:09:30] -!- skunksleep has quit [Ping timeout: 276 seconds]
[07:11:47] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[07:12:46] -!- teepee has quit [Ping timeout: 272 seconds]
[07:12:46] teepee_ is now known as teepee
[07:23:04] -!- persina has quit [Ping timeout: 250 seconds]
[07:28:32] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 29b9ebe 06linuxcnc 10src/rtapi/rtapi_parport.h rtapi_parport.h: make all inline functions static * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=29b9ebe
[07:55:01] -!- kingarmadillo has quit [Ping timeout: 252 seconds]
[07:57:51] -!- gaute_ has quit [Quit: Page closed]
[08:15:02] <linuxcnc-build> build #1910 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/1910 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[08:15:09] -!- Komzzpa has quit [Ping timeout: 276 seconds]
[08:43:42] -!- GJdan has quit [Ping timeout: 244 seconds]
[08:43:48] -!- awallin___ [awallin___!awallin@lakka.kapsi.fi] has joined #linuxcnc-devel
[08:45:16] -!- alex_joni [alex_joni!~alex_joni@emc/board-of-directors/alexjoni] has joined #linuxcnc-devel
[08:45:16] -!- mode/#linuxcnc-devel [+v alex_joni] by ChanServ
[08:45:40] -!- Tom_itx has quit [Ping timeout: 250 seconds]
[08:45:43] -!- AphelionZ has quit [Ping timeout: 250 seconds]
[08:45:44] -!- alex_jon1 has quit [Ping timeout: 250 seconds]
[08:45:44] -!- amiri has quit [Ping timeout: 250 seconds]
[08:45:45] -!- sttts has quit [Ping timeout: 250 seconds]
[08:45:45] schimmi is now known as sttts
[08:45:45] -!- ivansanchez has quit [Ping timeout: 250 seconds]
[08:45:46] -!- awallin_ has quit [Ping timeout: 250 seconds]
[08:45:47] -!- Khetzal has quit [Ping timeout: 250 seconds]
[08:45:47] -!- ybon has quit [Ping timeout: 250 seconds]
[08:45:59] -!- Khetzal [Khetzal!~khetzal@sierra.khetzal.info] has joined #linuxcnc-devel
[08:49:37] -!- agoddard has quit [Ping timeout: 276 seconds]
[08:50:54] -!- ybon1 has quit [Ping timeout: 276 seconds]
[08:56:53] AphelionZ_ is now known as AphelionZ
[09:03:30] -!- Miner_48er has quit [Quit: Leaving]
[09:10:03] ybon1 is now known as ybon
[09:26:02] -!- b_b has quit [Changing host]
[09:48:56] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[09:59:19] -!- Daerist has quit [Quit: Leaving]
[10:38:55] -!- Tom_itx [Tom_itx!~Tl@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[10:52:24] <skunkworks> Oh - Thank you andy!
[11:05:49] emc_ is now known as emc
[11:10:16] -!- skunksleep has quit [Ping timeout: 252 seconds]
[11:10:50] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[11:11:40] <skunksleep> Forum is down
[11:32:13] -!- realivansanchez has quit [Remote host closed the connection]
[12:27:51] <jepler> May 18 06:13:43 forum kernel: [167092.802930] apache2 invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0
[12:28:01] <jepler> something made it run out of memory
[12:28:38] <jepler> [Wed May 18 06:13:39.351145 2016] [mpm_prefork:error] [pid 1263] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
[12:29:54] <jepler> that's eastern time zone apparently
[12:32:50] <jepler> at that time, some system in the ukraine was spidering flo very agressivley
[12:32:54] <jepler> aggressively
[12:33:46] <jepler> anyway, it's back up; a reboot was the simplest thing to do
[12:33:56] <skunkworks> yay - thanks!
[12:36:02] <jepler> hm excuse me while I reboot it again because of fat fingers
[12:40:15] <jepler> anyway I can't easily increase the amount of RAM so I tripled the swapfile; maybe it'll survive the next jerkface who thinks it'd be a good idea to download all the posts
[12:41:24] <archivist> bing is a common culprit
[12:46:06] -!- md-2 has quit [Quit: Leaving...]
[12:48:04] -!- skunksleep has quit [Ping timeout: 240 seconds]
[12:48:12] <jepler> this was not a standard robot, it didn't identify itself in the user agent string.
[13:12:28] <cradek> apache needs mod_jerkface
[13:12:44] <cradek> oh I suppose they already have it, but they mistakenly called it ratelimit
[13:57:26] -!- kwallace [kwallace!~kwallace@162.222.28.6] has joined #linuxcnc-devel
[14:32:07] -!- skunkworks has quit [Ping timeout: 252 seconds]
[15:16:40] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[15:18:55] <seb_kuzminsky> Ed's project writeups always make me chuckle:
https://softsolder.com/2016/05/18/blender-bearing-repair-round-three/
[16:19:46] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 5e1badd 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: switch from using rxudp count to confirm_write_cnt * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5e1badd
[16:19:46] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 298464d 06linuxcnc 10docs/man/man9/hm2_eth.9 hm2_eth: improve docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=298464d
[16:19:46] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 1befc75 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/tram.c hostmot2: Treat -EAGAIN from hm2_finish_read specially * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1befc75
[16:19:49] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss ca9e4ca 06linuxcnc 10src/hal/drivers/mesa-hostmot2/tram.c hostmot2: fix trivial typo in diagnostic message * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ca9e4ca
[16:19:53] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 089c64b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: don't keep resetting instance * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=089c64b
[16:19:57] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 8321aaf 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: avoid glitches when starting to run * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8321aaf
[16:20:01] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss a183e6e 06linuxcnc 10src/hal/drivers/mesa-hostmot2/sserial.c hostmot2: sserial: avoid long wait after lost packet * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a183e6e
[16:20:11] <jepler> PCW_: .run initial state should be fixed, but I didn't test before pushing because it's inconvenient :-P
[16:20:40] -!- realivansanchez has quit []
[16:57:31] -!- kalxas has quit [Changing host]
[16:58:59] <mozmck> I have an o subroutine with an M66 P1 L1 Q.5 When doing a run-from-line, this delay is executed waiting for something which of course doesn't happen. Would it not be better if it ignored those delays?
[16:59:42] * seb_kuzminsky hands mozmck a block-skip character
[16:59:56] <mozmck> and what is that?
[17:00:32] <seb_kuzminsky> http://linuxcnc.org/docs/html/gcode/overview.html#_block_delete
[17:00:52] <seb_kuzminsky> it lets you skip lines of gcode in some situations
[17:01:09] <seb_kuzminsky> (i was being a little flippant, i'm not sure if it's the right answer to your problem)
[17:01:48] <jepler> the right answer is for some moth to devote a moth-man-year to really making RFL work
[17:02:14] <seb_kuzminsky> moth?
[17:02:21] <jepler> yeah I think it's a job for the moths
[17:02:25] <mozmck> Yeah, that's what I was thinking.
[17:02:27] <jepler> the human-mans haven't taken care of the problem.
[17:03:05] <mozmck> I'm starting to work on a simple rfl that will not run through the code, but simply start where you tell it to.
[17:03:17] <seb_kuzminsky> http://ia.media-imdb.com/images/M/MV5BNDcyMjIyOTk1N15BMl5BanBnXkFtZTgwMzI0MDkwMzE@._V1_UX182_CR0,0,182,268_AL_.jpg
[17:03:43] <jepler> I bet mothra is one of those 10x moth-velopers we hear so much about these days
[17:04:08] <seb_kuzminsky> heh
[17:04:48] <seb_kuzminsky> am i the only one around here who's freaked out by metamorphosis? that's some god-level biotechnology right there
[17:05:25] <mozmck> I could either make it an INI setting, and rfl would work in the "simple" manner if the ini setting is TRUE. Or, possibly make simple rfl a new mode so they could both be used?
[17:05:53] <seb_kuzminsky> i'm generally opposed to INI settings
[17:05:56] <mozmck> it is god-level - same as the rest of creation!
[17:06:05] <seb_kuzminsky> heh yeah
[17:06:33] <seb_kuzminsky> what we do now is walk through the program, setting interpreter variables but not issuing motion commands, until we get to the line? then start running from there?
[17:06:44] <mozmck> I believe so - brokenly
[17:06:55] <seb_kuzminsky> and what you want instead is to accept whatever interpreter state you happen to be in, and just start executing from the selected line?
[17:07:10] <mozmck> Maybe we should also make a list of what is broken while I'm at it.
[17:07:10] <seb_kuzminsky> what do we currently do with modal gcodes?
[17:07:23] <seb_kuzminsky> that'd be a good place to start
[17:07:41] <mozmck> Yes, I want to just start from the selected line.
[17:07:48] <seb_kuzminsky> maybe write down the current behavior as you figure it out into the Code Notes document?
[17:08:07] <mozmck> Yeah, that would be good.
[17:08:29] <mozmck> Right now, I know that probe moves in an O subroutine are badly broken in RFL
[17:08:51] <mozmck> M66 IMO should not delay waiting for the signal.
[17:08:56] <seb_kuzminsky> the code on (and after) the line you Run From surely expects some specific interp state (modal gcodes, named & numbered parameters, etc?)
[17:09:21] <mozmck> Well, that would be one of the possible drawbacks to a simple RFL
[17:09:22] <seb_kuzminsky> i can imagine situations where waiting is the right answer
[17:09:40] <mozmck> how is that?
[17:10:07] <mozmck> You are not wanting to run any of the code, simply set state I think.
[17:10:40] <seb_kuzminsky> what if the input it's waiting on is the door close switch?
[17:11:01] <mozmck> For a simple RFL, you just have to be careful where you start. That is pretty common from what I hear.
[17:11:29] <mozmck> I would think that would be more in an e-stop chain or similar.
[17:11:56] <seb_kuzminsky> oh wait, are you saying this: "in the current RFL, as the interpreter advances up to the line the user asked for it should not perform the M66 wait or the probe moves"?
[17:12:17] <mozmck> exactly! thanks for wording it better.
[17:12:45] <mozmck> The probe moves work properly if they are not in O subroutines.
[17:13:00] <mozmck> If they are in O subroutines it does *really* nasty stuff.
[17:13:29] <seb_kuzminsky> when advancing past non-O-sub probe moves, do they act as if the probe move happened but didn't detect a probe trip?
[17:13:55] <mozmck> Seems like when it starts running at the line requested, it does the move as a probe move.
[17:14:18] <seb_kuzminsky> mozmck: yuck, bug
[17:15:25] <mozmck> So if it is a G2 arc for instance, it runs it at the probing speed - and will eventually say the probe move ended without making contact etc I believe depending on the move.
[17:15:46] <seb_kuzminsky> that's just bonkers
[17:16:50] <mozmck> For a simple RFL, you make sure you start at a sane place, and it works great.
[17:17:24] <mozmck> I think I'll look into making simple RFL a different command. Now I have to figure out how normal RFL is commanded.
[17:18:00] <seb_kuzminsky> good place to start
[17:21:32] -!- sel [sel!~sel@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[17:21:50] -!- sel has quit [Client Quit]
[17:25:08] -!- md-2 has quit [Remote host closed the connection]
[17:27:14] <pcw_home> jepler: sserial run state is fixed
[17:28:31] -!- GJdan has quit [Remote host closed the connection]
[17:33:57] -!- Komzzpa has quit [Ping timeout: 276 seconds]
[17:43:03] -!- erve has quit [Ping timeout: 276 seconds]
[18:00:42] <jepler> pcw_home: thank you for doing my testing
[18:13:33] <cradek> I'm pretty sure I believe in the simple-rfl algorithm you're talking about
[18:14:04] <cradek> it's important that invoking it doesn't affect any machine state, like spindle settings or coolant
[18:14:32] <cradek> then you can set things how you want them, and then simple-rfl
[18:14:50] <cradek> very papertapey
[18:15:11] <mozmck> Yes, that is my plan.
[18:16:07] <mozmck> And if both methods are available at the same time, then conceivably a GUI could have a way to use both and the user could choose the best one for each case even.
[18:16:18] <cradek> seems like you won't be able to (for instance) start in a sub, because when it gets to endsub you'll just get an error
[18:16:42] <cradek> ... which is fine by me
[18:16:49] <cradek> if nothing else it's sure predictable
[18:17:08] <mozmck> Yes
[18:22:15] <jepler> it might run some of the sub, at least until readahead reaches the endsub
[18:22:51] <jepler> https://en.wikipedia.org/wiki/Document_Structuring_Conventions
[18:23:07] <jepler> my own biases make me think a real working RFL has to add metadata not present in gcode, just like DSC adds to postscript
[18:24:15] <jepler> in particular, you'd have a prolog(ue) section, G20 G64 ... would go there, as would subroutine definitions
[18:25:09] <jepler> and then you'd have annotations at each spot where you can sensibly resume
[18:26:06] <cradek> touchy (barely barely) does this; it assumes sensible resume points are the ones that have N words
[18:26:25] <cradek> I wonder if that's even documented
[18:26:46] <cradek> I would put them before tool changes and at other sensible places
[18:27:21] <cradek> listing sensible resume places somehow would also be very smart for simple-rfl
[18:27:35] -!- Komzzpa has quit [Ping timeout: 250 seconds]
[18:28:18] <cradek> at those places you could carefully set all machine state, making it safe to resume without any special care
[18:28:24] <mozmck> I talked to one man who mentioned controllers he has worked on had special codes for places you could resume from.
[18:28:58] <cradek> you could just use sharpie on the paper tape
[18:29:26] <mozmck> They also had a button on the gui, and the code would automatically go to the previous resume point iirc
[18:29:39] <cradek> mozmck: touchy does exactly that
[18:29:47] <cradek> previous/next resume point
[18:30:00] <mozmck> what is an N word?
[18:30:12] <jepler> mozmck: N012345
[18:30:15] <cradek> N1234 type line number at the beginning of the line
[18:30:23] <jepler> it's like good old basic line numbers
[18:30:37] <cradek> y'know, "N" for restart poiNt
[18:30:48] <mozmck> Oh, ok. I don't even use those now.
[18:31:16] <mozmck> Code that I've seen with them has an N number on every line - so I don't know how useful that would be.
[18:31:19] <cradek> other than touchy's thing, they do nothing except make some humans more comfortable
[18:31:36] <cradek> yes that's the typical usage
[18:31:48] <mozmck> I don't really like them because if you add code you have to change them all - etc.
[18:31:56] <cradek> not in linuxcnc - they do nothing
[18:32:06] <jepler> oh linuxcnc doesn't check if they're in order or not repeated or anything like that
[18:32:09] <cradek> leave 'em out, out of order, whatever
[18:32:31] <mozmck> No, but become meaningless :-)
[18:32:40] -!- teepee has quit [Ping timeout: 244 seconds]
[18:32:46] <cradek> although, hilariously, I think it will error if the number is too big
[18:32:52] <mozmck> or confusing.
[18:32:56] <cradek> I remember us increasing it
[18:33:01] <mozmck> what is "too big"?
[18:33:24] <cradek> I sure don't know without looking at the source
[18:33:31] <cradek> or maybe it's in the docs
[18:33:31] <mozmck> ok
[18:33:41] -!- teepee [teepee!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[18:33:59] <jepler> hmph the n-number can't be the result of a [calculation]
[18:34:04] <cradek> http://www.linuxcnc.org/docs/html/gcode/overview.html#_line_number
[18:34:23] <cradek> or negative (according to the docs)
[18:34:34] <jepler> n10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[18:34:38] <jepler> is accepted though
[18:34:47] <jepler> as is n1.1
[18:35:27] <mozmck> I would think a special code for resume points might be good - if we implement that.
[18:35:31] <cradek> ... CHKS((value > 99999), NCE_LINE_NUMBER_GREATER_THAN_99999); */
[18:35:44] <cradek> it's commented out and the comment has an explamation point
[18:36:03] <jepler> /*! ... */ is special to doxygen I think
[18:38:52] -!- skunkworks [skunkworks!~skunkwork@174-124-59-31.dyn.centurytel.net] has joined #linuxcnc-devel
[18:44:21] -!- kingarmadillo has quit [Ping timeout: 246 seconds]
[19:16:34] -!- Komzpa has quit [Ping timeout: 240 seconds]
[19:19:59] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[19:23:08] -!- b_b has quit [Remote host closed the connection]
[19:24:10] -!- sel [sel!~sel@net77-43-27-64.mclink.it] has joined #linuxcnc-devel
[19:24:24] -!- sel has quit [Remote host closed the connection]
[19:34:05] -!- JT-Shop has quit [Remote host closed the connection]
[19:35:07] -!- JT-Shop [JT-Shop!~john@198.45.191.246] has joined #linuxcnc-devel
[19:46:04] -!- zeeshan-shop has quit [Ping timeout: 240 seconds]
[19:46:10] -!- zeeshan has quit [Ping timeout: 252 seconds]
[20:02:00] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[20:46:32] <skunkworks> http://www.practicalmachinist.com/vb/cnc-machining/hmc-retrofit-320332/
[20:47:46] <skunkworks> seems most people on practical machinist are purists.. A machine control needs to be fanuc, centroid or any of the other really expensive controls
[20:48:47] <cradek> > At this moment I would like to know what is the best option.
[20:48:59] <cradek> me too, my friend, always
[20:50:49] <cradek> (haha, linuxcnc on it in 2 weeks)
[20:51:19] <cradek> maybe if done by a couple experienced folks that would be possible, but the machine is unknown and has been stripped
[20:52:55] <PCW_> interfacing Fanuc drives is not easy currently
[20:53:30] <PCW_> ( with non Fanuc hardware I mean)
[20:53:53] <cradek> > Basically all of that is incorrect.
[20:53:55] <cradek> haha
[20:54:55] <PCW_> assuming these are digital (PWM) or worse FSSB drives
[20:56:07] <cradek> "I looked at it about 8 years ago therefore I'm an expert"
[20:56:19] -!- maurris has quit []
[20:57:35] <skunkworks> sorry ;)
[20:58:18] <cradek> aside from being your fault, it's not your fault
[20:58:20] <cradek> :-)
[21:03:20] <skunkworks> of all of that - the only thing anyone got right was that linuxcnc doesn't have a lathe roughing, finishing cycle
[21:04:46] <cradek> true! but it's not a lathe is it?
[21:06:53] -!- chillly has quit []
[21:10:29] -!- emcPT [emcPT!529acfa8@gateway/web/cgi-irc/kiwiirc.com/ip.82.154.207.168] has joined #linuxcnc-devel
[21:12:04] <skunkworks> details ;0
[21:54:47] -!- emcPT has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
[22:24:51] -!- skunkworks has quit [Ping timeout: 246 seconds]
[22:51:00] -!- md-2 has quit [Client Quit]
[22:53:18] -!- remstw has quit [Ping timeout: 276 seconds]
[23:13:24] -!- skunkworks [skunkworks!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[23:14:22] -!- zeeshan [zeeshan!~kvirc64@CPE84948c379051-CM84948c379050.cpe.net.cable.rogers.com] has joined #linuxcnc-devel
[23:15:29] <skunkworks> zlog
[23:15:29] <zlog> skunkworks: Log stored at
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-05-18.html
[23:17:43] <JT-Shop> anyone have an absolute encoder?
[23:22:40] <cradek> I have at least one unknown parallel-interface-of-some-kind model
[23:22:59] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:81c4:5084:f657:1efe] has joined #linuxcnc-devel
[23:23:08] <cradek> it has, I think, a DB25, and it's marked with a pinout
[23:23:38] <JT-Shop> dewey is looking for someone to test the absolute dgarr/ja14-abshome branch
[23:24:31] <cradek> I'd send it to him if it'd help him
[23:24:56] <cradek> but someone who has one with a known already-working interface might sure be better
[23:25:30] <cradek> oh hey, could he use a resolver on a 7iwhatever?
[23:25:43] <JT-Shop> I don't think he has much hardware
[23:25:47] <cradek> I think that's already known to work
[23:26:34] <JT-Shop> hmm
[23:27:07] <cradek> I have a spare HNC resolver *somewhere* that I could loan, but I'd want back eventually
[23:27:34] <JT-Shop> let me fish some more :)
[23:27:40] <cradek> ok :-)
[23:27:49] <cradek> sounds like I'm probably not the best one to help
[23:28:06] <JT-Shop> I can get one from aliexpress cheap
[23:28:30] <seb_kuzminsky> is there something about absolute-encoder homing that requires ja?
[23:28:51] <JT-Shop> good question for dewey
[23:29:05] <kwallace> I also have some HNC resolvers on the shelf somewhere.
[23:29:11] <JT-Shop> I think he made a branch to home them properly
[23:31:09] * JT-Shop heads inside to veg
[23:31:16] <skunkworks> I think he just added absolute homing - what ever that means. I wasn't part of the conversation
[23:48:19] <PCW_> I can send you a Fanuc absolute encoder (it needs a battery to retain its position info)
[23:53:51] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:81c4:5084:f657:1efe] has parted #linuxcnc-devel
