Back
[00:03:18] -!- exitcode1 has quit [Quit: quit]
[00:14:31] -!- Thomaxo_ has quit [Remote host closed the connection]
[00:17:06] <cradek> Tom_itx: the .001 brass shim stock worked
[00:17:45] <cradek> wrapped around, it was tight in the collet without drawing it shut, just like a real tool is
[00:20:16] <Tom_itx> nice
[00:20:28] <Tom_itx> just make sure it doesn't overlap or it won't run true
[00:22:44] -!- Loetmichel has quit [Ping timeout: 256 seconds]
[00:24:50] <jepler> seb_kuzminsky: yes, it emits an "mfence" instruction on x86_64 and i386 with recent -march= selected; and a lock-prefixed memory-accessing NOP for i386 without -march= selected (pre-sse2)
[00:25:08] <jepler> seb_kuzminsky: in a loop whose body is just mfence, it takes ~50 cycles per loop on an intel i7
[00:25:46] <jepler> so the penalty is probably 40-50 cycles per use if my test harness is right
[00:26:23] <jepler> "lock orl $0, (%esp)"
[00:28:02] -!- anth0ny_ has quit [Quit: anth0ny_]
[00:28:06] <jepler> hmmm
[00:28:15] <jepler> the *other* reason the fence is needed is the clever compiler
[00:28:16] <jepler> void f(struct T *t) {
[00:28:16] <jepler> while(t->a == 0) /* NOTHING */;
[00:28:16] <jepler> printf("%d\n", t->b);
[00:28:16] <jepler> }
[00:28:38] <jepler> there's nothing in the abstract machine that allows t->b to change during this function, so there's no reason the read can't be moved above the while-loop
[00:30:00] <jepler> hm my attempted changes to task/motion just totally broke it
[00:30:03] amnesic_away is now known as amnesic
[00:30:38] <jepler> usrmotReadEmcmotStatus: COMM_SPLIT_READ_TIMEOUT
[00:35:13] -!- Akex_ has quit [Quit: Connection closed for inactivity]
[00:37:16] <cradek> the whole serial number system is broken without syncs too, right?
[00:37:56] <cradek> or do we have queues now
[00:39:05] -!- per_sonne has quit [Ping timeout: 264 seconds]
[00:39:45] <cradek> tool change handshaking?
[00:42:10] -!- zeitue has quit [Ping timeout: 240 seconds]
[00:43:04] <jepler> cradek: it looks like anything going through libnml is already safe, because they use operating system mutexes.
[00:43:25] <cradek> oh ok
[00:44:00] <jepler> "Primitives such as mutexes and semaphores are provided to synchronize access to resources from parallel threads of execution. These primitives are usually implemented with the memory barriers required to provide the expected memory visibility semantics. In such environments explicit use of memory barriers is not generally necessary." -- wikipedia
[00:44:21] <cradek> ok so it's generally usually ok
[00:44:22] <jepler> I *think* tool-change / tool-changed is OK
[00:44:48] <cradek> I was thinking about how it sets a request number and then a bit to say you should read it
[00:45:04] <jepler> oh, hm.
[00:45:04] <cradek> doesn't iotask twiddle those hal bits directly?
[00:45:06] <jepler> you're right
[00:45:42] <jepler> so the thing I was trying to formulate about index-enable & position-fb would apply here too
[00:46:26] <cradek> I think no, because motion and hal drivers are all realtime
[00:46:28] <jepler> except that in the case of index, the reader and writer are typically both in the same realtime thread, so they don't have a problem
[00:46:35] <cradek> yeah that
[00:46:50] <jepler> software stepgen & encoder need attention where they exchange data from the fast thread to the slow one
[00:47:03] <cradek> er no, they can be in different realtime threads, but that's still ok, because one cpu
[00:47:15] <cradek> ?
[00:47:33] <jepler> if we want to further codify that all the RT stuff runs on one CU
[00:47:34] <cradek> I thought if both reader and writer are realtime it's ok
[00:47:34] <jepler> CPU
[00:47:51] <cradek> above my pay grade
[00:48:22] <jepler> right now we provide rate monotonic scheduling, but we haven't ever formally promised it. RMS implies that all RT threads run on one CPU thread
[00:48:24] <cradek> I think seb is right that probing is a trouble spot
[00:48:25] -!- DenSchub has quit [Remote host closed the connection]
[00:49:39] -!- Camaban has quit [Quit: Leaving]
[00:50:23] <cradek> we DO promise it:
http://linuxcnc.org/docs/html/man/man3/hal_create_thread.3hal.html
[00:50:27] <jepler> yeah, same thing with the same "probably usually OK because usually in the same thread"
[00:51:05] <cradek> I think no, because probing communicates with task so the results can make it into the interpreter
[00:51:35] <jepler> It's RT which takes care of all the latching, right?
[00:51:45] <jepler> one patch (not in the series I posted so far) fixes up the shared memory between task and motion
[00:52:00] <jepler> fixing the existing "head == tail" checks to actually work
[00:52:23] <cradek> oh yeah, the latching is surely in motion
[00:56:14] amnesic is now known as amnesic_away
[00:58:46] <jepler> seems like with home switches and probe inputs it doesn't matter much; the consequence there is having the position be different by 1 servo cycle
[00:58:56] <jepler> it's not "read as zero", it's "read as stable"
[00:59:02] <jepler> er "read as stale"
[01:00:31] -!- tinkerer has quit [Remote host closed the connection]
[01:00:39] <cradek> but with index, if not for all-one-cpu, you can maybe get the not-yet-reset value
[01:00:47] <cradek> for one servo cycle
[01:01:28] <jepler> right
[01:01:49] -!- zeitue has quit [Max SendQ exceeded]
[01:02:10] <jepler> I am very tempted to say it's broken to update position-fb and index-enable not from the same thread as motion
[01:02:18] <jepler> I mean, it's OK if that's broken
[01:03:07] <cradek> software encoder updates those things in the slow half?
[01:03:24] <jepler> yes, I believe so
[01:04:55] <jepler> how the heck do you get barriers in the right place in a classicladder toolchanger
[01:06:18] <cradek> doesn't ladder read all inputs, then run all the program, then write all outputs? seems like it would be fine.
[01:07:10] <jepler> barriers are required on the reading side, because otherwise reads can occur in a different order than program order implies
[01:07:58] <jepler> so for the same reason that iocontrol needs a barrier between setting the tool number and asserting tool-prepare, ladder needs to (A) read tool number before tool-prepare in program order and (B) have a barrier between them so that program order and actual order are the same
[01:08:00] <cradek> I don't understand
[01:08:13] <cradek> processing
[01:08:47] <jepler> today, who knows if (A) is true anyway
[01:09:02] <jepler> probably bits are read in a fixed order with respect to numbers
[01:09:23] <jepler> while (f == 0);
[01:09:24] <jepler> // Memory fence required here
[01:09:24] <jepler> print x;
[01:09:39] <cradek> ok I'm with you now
[01:09:40] <jepler> same if it's: if(f == 0) print x; which is more like the ladder situation
[01:09:43] <jepler> https://en.wikipedia.org/wiki/Memory_barrier
[01:09:58] <jepler> the load of x from memory could be before the load of f from memory, in this kind of computer
[01:10:04] <cradek> because ladder_rt is hooked to iocontrol
[01:10:34] <jepler> right, via hal
[01:10:38] <cradek> it seems like you can't fix this in the general case of having arbitrary hal programmability
[01:10:42] <jepler> yes
[01:10:54] <cradek> that's ... bad
[01:11:12] <jepler> a bunch of dumb things in shared memory is a great idea if your background is microcontrollers and x86 doesn't dash any of those hopes too hard
[01:11:32] <jepler> except now I'm concerned for all machines about part A of the classicladder toolchainger story
[01:11:37] <jepler> changer
[01:11:52] <cradek> yeah
[01:12:16] <cradek> doesn't even require this arm thing to screw that up
[01:12:19] <jepler> right
[01:16:04] <jepler> hm do we have general "copy input to output" components?
[01:16:15] <jepler> if so you just need to add a "execute a barrier instruction" component
[01:16:57] <jepler> so then you'd put this component in classicladder's thread, copy(tool-prepare); barrier; copy(tool-number) in imperative speak
[01:17:42] <cradek> I'm taking your word for this
[01:18:34] <jepler> ah, actually a better idea
[01:18:48] <jepler> use classicladder to delay the tool-prepare signal by one cycle so that tool-number is stable
[01:19:21] <jepler> .. or, in iocontrol, sleep(any nonzero amount) after setting tool number and before asserting the prepare signal
[01:19:46] <jepler> it's almost like making linuxcnc work on arm is a waste of time
[01:19:56] <jepler> literally, if we insert sleep(1)
[01:20:47] Loetmichel2 is now known as Loetmichel
[01:21:06] -!- phantoneD has quit [Ping timeout: 256 seconds]
[01:22:16] <cradek> I wonder how many wrong tool changes our users will get, with it all as is, before the sun burns out
[01:22:53] <jepler> seems like a lot of toolchanger designs might do OK if they initially get the wrong tool number but it becomes right 1ms later
[01:23:19] <jepler> turn the wrong way for 1ms, or go around an extra time, or suchlike
[01:23:55] <cradek> it sure depends
[01:24:04] <jepler> and just once in a very blue moon
[01:24:48] <jepler> (And I feel one comin' on soon)
[01:25:08] <cradek> stop by and I'll buy you a beer
[01:25:52] <jepler> hm I didn't know it was a cover when Ms. Parton recorded it.
[01:26:50] <cradek> wouldn't surprise me if that was an old song
[01:26:51] <jepler> (in fact the first I recall of the song was when the band I was listening to announced from the stage that their next number was a cover *of* Dolly Parton)
[01:26:54] <jepler> https://en.wikipedia.org/wiki/Once_in_a_Very_Blue_Moon
[01:27:23] <jepler> which gives the songwriting credit to (Patrick Alger, Eugene Levine)
[01:27:35] <cradek> oh maybe I don't know that song
[01:27:49] <cradek> I was thinking of: blue moon, you saw me standing alone, without a something something ...
[01:27:53] <jepler> [Alger] later teamed up with Nanci Griffith and co-wrote Griffith's hit songs "Once In A Very Blue Moon" ( with Eugene Levine) and "Lone Star State of Mind."(with Eugene Levine and Fred Koller)
[01:28:35] <jepler> https://www.youtube.com/watch?v=ykKKCqy3gKM
[01:29:58] -!- tjtr33 has quit [Quit: Leaving]
[01:30:10] <cradek> never heard it before
[01:32:52] <jepler> (she should have changed that stupid lock, and also her address)
[01:33:45] <cradek> ugh, she murders roseville fair because she's so scared someone will say GAYYYYYYY if she sings it right
[01:33:49] <cradek> I hate when people do that
[01:35:45] <Tom_itx> i doubt tool changers react that quick anyway
[01:36:09] <cradek> Tom_itx: but it's easy to imagine a ladder that latches the value
[01:36:11] <Tom_itx> all the ones i've seen were rather slow or did a prefetch
[01:37:06] <cradek> latch the request on a rising edge has got to be a typical ladder behavior
[01:37:22] <Tom_itx> i've not messed with classic ladder yet
[01:38:39] <jepler> cradek: if the choice was to gender-flip it or tell it in the third person, which is the lesser violence to the song? (yes, I know that's a false dichotomy)
[01:39:15] -!- per_sonne has quit [Ping timeout: 246 seconds]
[01:40:44] <jepler> cradek: and more importantly, how serious were you with that beer invitation?
[01:40:49] <cradek> the basic flip would be hard, because you'd end up with "gentle flower of a small town boy" "... my joy(?)"
[01:40:55] <cradek> totally serious
[01:41:13] <jepler> I think I'll drop by then
[01:41:24] <cradek> ok, I'll make sure something's cold
[01:41:49] <jepler> OK, how about "I was dressed in blue and I looked so lovely"
[01:42:09] <cradek> bleh
[02:07:59] -!- Thomaxo has quit [Remote host closed the connection]
[02:20:06] -!- X2FreakBuilder has quit [Ping timeout: 246 seconds]
[02:33:15] -!- kwallace_shiz [kwallace_shiz!~kwallace@142.147.85.210] has joined #linuxcnc-devel
[02:35:50] -!- tjtr33 has quit [Quit: Leaving]
[02:40:42] -!- per_sonne has quit [Ping timeout: 250 seconds]
[03:05:35] -!- gene_ has quit [Remote host closed the connection]
[03:24:15] -!- sumpfralle has quit [Ping timeout: 246 seconds]
[03:24:19] -!- arekm has quit [Read error: Connection reset by peer]
[03:29:04] postaL_offline is now known as postaL
[03:34:03] -!- pcw_home_ [pcw_home_!~chatzilla@c-50-143-148-115.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[03:35:53] <seb_kuzminsky> jepler/hm2-eth-multiple (2a83a1) seems fine on my bp, it homed at least, ship it!
[03:36:14] -!- pcw_home has quit [Ping timeout: 248 seconds]
[03:36:28] pcw_home_ is now known as pcw_home
[03:41:47] -!- per_sonne has quit [Ping timeout: 244 seconds]
[04:02:39] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[04:04:36] -!- Crom has quit [Ping timeout: 264 seconds]
[04:20:14] -!- maximilian_h [maximilian_h!~bonsai@dslb-092-074-052-008.092.074.pools.vodafone-ip.de] has joined #linuxcnc-devel
[04:20:15] -!- AR_ has quit [Ping timeout: 246 seconds]
[04:21:33] -!- maximilian_h1 has quit [Ping timeout: 255 seconds]
[04:36:04] -!- furrywolf has quit [Ping timeout: 246 seconds]
[04:42:54] -!- per_sonne has quit [Ping timeout: 250 seconds]
[04:53:53] -!- bobo_ has quit [Quit: Page closed]
[04:57:45] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[05:30:24] -!- DenSchub has quit [Read error: Connection reset by peer]
[05:31:45] -!- ve7it has quit [Remote host closed the connection]
[05:37:18] -!- jdqx has quit [Ping timeout: 248 seconds]
[05:38:01] -!- FinboySlick has quit [Quit: Leaving.]
[05:44:02] -!- per_sonne has quit [Ping timeout: 256 seconds]
[05:54:31] -!- jubjub has quit [Remote host closed the connection]
[05:58:22] -!- kwallace [kwallace!~kwallace@142.147.85.210] has parted #linuxcnc-devel
[06:01:11] <cmorley> seb_kuzminsky: ok when I hear from you and John - I will push (or fix and push) :)
[06:01:29] -!- erve has quit [Remote host closed the connection]
[06:04:54] -!- CaptHindsight has quit [Ping timeout: 246 seconds]
[06:17:07] -!- CaptHindsight [CaptHindsight!~2020@adsl-75-57-145-130.dsl.emhril.sbcglobal.net] has joined #linuxcnc-devel
[06:17:07] -!- CaptHindsight has quit [Changing host]
[06:17:07] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[06:30:42] -!- i_tarzan_ has quit [Ping timeout: 255 seconds]
[06:35:24] -!- anth0ny_ has quit [Quit: anth0ny_]
[06:43:16] -!- anth0ny_ has quit [Client Quit]
[06:45:43] -!- per_sonne has quit [Ping timeout: 244 seconds]
[07:03:30] -!- bkboggy has quit [Quit: Leaving]
[07:32:28] -!- mozmck has quit [Read error: Connection reset by peer]
[07:48:01] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[07:55:18] -!- per_sonne has quit [Ping timeout: 264 seconds]
[08:13:17] -!- furrywolf has quit [Ping timeout: 240 seconds]
[08:23:25] -!- HardWall has quit [Read error: Connection reset by peer]
[08:31:06] -!- X2FreakBuilder has quit [Ping timeout: 246 seconds]
[08:38:23] -!- LikeVinyl has quit [Remote host closed the connection]
[08:56:07] -!- per_sonne has quit [Ping timeout: 252 seconds]
[08:56:11] -!- rob_h [rob_h!~robh@90.204.236.205] has joined #linuxcnc-devel
[08:56:49] -!- arekm has quit [Ping timeout: 256 seconds]
[09:48:17] -!- nofxx has quit [Ping timeout: 240 seconds]
[09:57:29] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[09:57:38] <KGB-linuxcnc> 03andypugh 05andypugh/carousel_demo 954363b 06linuxcnc 10(20 files in 2 dirs) Add a Vismach config to demonstrate the carousel component. This config might also be useful for trialling alternative toolchanger systems. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=954363b
[09:58:18] -!- per_sonne has quit [Ping timeout: 264 seconds]
[10:05:02] -!- arrowbook has quit [Ping timeout: 248 seconds]
[10:08:30] -!- erve has quit [Ping timeout: 264 seconds]
[10:08:35] -!- andypugh [andypugh!~andypugh@50.Red-79-158-169.dynamicIP.rima-tde.net] has joined #linuxcnc-devel
[10:09:54] -!- amiri has quit [Ping timeout: 246 seconds]
[10:09:57] <andypugh> seb_kuzminsky: I just pushed a feature branch with the carousel comp, Vismach gui, G-code toolchange remap and spindle orient demos.
[10:25:56] -!- andypugh has quit [Quit: andypugh]
[10:39:34] -!- andypugh [andypugh!~andypugh@50.Red-79-158-169.dynamicIP.rima-tde.net] has joined #linuxcnc-devel
[10:39:47] -!- andypugh has quit [Client Quit]
[10:46:20] -!- arrowbook [arrowbook!~qicruser@119.176.48.183] has joined #linuxcnc-devel
[10:58:46] -!- per_sonne has quit [Ping timeout: 260 seconds]
[11:18:17] -!- tofu_ [tofu_!~sean@66-118-151-70.static.sagonet.net] has joined #linuxcnc-devel
[11:18:41] -!- brlcad has quit [Read error: Connection reset by peer]
[12:00:12] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[12:00:21] -!- teepee has quit [Ping timeout: 258 seconds]
[12:00:21] teepee_ is now known as teepee
[12:00:47] -!- per_sonne has quit [Ping timeout: 240 seconds]
[12:11:48] -!- sumpfralle has quit [Ping timeout: 255 seconds]
[12:14:06] -!- Dimroy has quit [Remote host closed the connection]
[12:26:54] -!- erve has quit [Ping timeout: 248 seconds]
[12:32:49] -!- alex_joni has quit [Ping timeout: 252 seconds]
[12:36:35] -!- Tecan has quit [Changing host]
[12:37:41] -!- alex_joni [alex_joni!~alex_joni@81.196.65.201] has joined #linuxcnc-devel
[13:02:10] -!- per_sonne has quit [Ping timeout: 240 seconds]
[13:02:15] -!- b_b has quit [Changing host]
[13:08:39] -!- lucashodge has quit [Client Quit]
[13:21:58] <jepler> andypugh: neat!
[13:22:35] -!- b_b has quit [Remote host closed the connection]
[13:39:46] <jepler> wow, go 1.4's garbage collector would pause all threads for seconds on real workloads. go 1.5 brings it down by a factor of 1000, though (reading between the lines on the graphs, which should have been log scale but weren't) >10ms GC times are still in the cards. don't write your realtime motion control software in go yet.
[13:39:51] <jepler> https://talks.golang.org/2015/go-gc.pdf
[13:41:10] <jepler> SF seems to indicate mailing lists are 2nd priority after project web service, but restoration is slow because they seem not to trust their data very much.
http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration/ latest news
[13:41:39] <jepler> > We’ll be bringing services back online as the validation of backing data is completed, and anticipate bringing additional services online through mid-week .. We’re prioritizing the project web service (used by many projects using custom vhosts), mailing lists, and the ability to upload data to our download service
[13:45:57] <jepler> it seems like they had *way* too many eggs in a single basket, that they could lose everything (slashdot and all sourceforge services) due to a single block device corruption event
[13:48:36] <archivist> there was a GC cartoon linked yesterday, gc looks at the webcam to see if you are looking at the screen, you look away and it runs :)
[13:56:28] tofu_ is now known as brlcad
[14:00:06] -!- erve has quit []
[14:02:15] -!- Mr_Sheesh has quit [Remote host closed the connection]
[14:04:18] -!- per_sonne has quit [Ping timeout: 264 seconds]
[14:07:33] <cradek> > We're holding SCM service restoration for last
[14:08:08] <cradek> > related to filesystem corruption on our storage platform. This incident impacted all block devices on our Ceph cluster
[14:08:25] <cradek> I don't understand what this means
[14:09:13] <cradek> they have one big filesystem, and the filesystem got nuked?
[14:11:18] -!- Mr_Sheesh has quit [Remote host closed the connection]
[14:16:46] -!- kwallace [kwallace!~kwallace@142.147.85.210] has joined #linuxcnc-devel
[14:17:17] -!- b_b has quit [Changing host]
[14:20:22] <jepler> seems like
[14:20:46] <jepler> archivist: yeah that was a slide in this presentation I was looking ta
[14:32:29] -!- Thomaxo has quit [Read error: Connection reset by peer]
[14:35:13] -!- Akex_ has quit [Quit: Connection closed for inactivity]
[14:43:41] -!- Mr_Sheesh has quit [Remote host closed the connection]
[14:45:38] -!- Mr_Sheesh has quit [Excess Flood]
[14:50:52] -!- Thomaxo__ has quit [Read error: Connection reset by peer]
[15:06:10] -!- per_sonne has quit [Ping timeout: 256 seconds]
[15:18:33] -!- micges has quit [Ping timeout: 255 seconds]
[15:23:06] -!- Tecan has quit [Quit: Live Long And Phosphor!]
[15:30:30] -!- Thomaxo_ has quit [Remote host closed the connection]
[15:34:02] -!- brianmorel99 [brianmorel99!~brianmore@h75-100-180-199.mgtnmi.dsl.dynamic.tds.net] has joined #linuxcnc-devel
[15:35:26] <brianmorel99> My 7i92 is going to be here this week, is there any issues with putting a usb wifi adapter, or another nic card in the same computer to have internet access on?
[15:39:45] <pcw_home> Either should be fine but I do know to avoid Broadcom on WIFI adpaters
[15:41:56] <brianmorel99> pc_home: Great, thanks for getting the 7i92 out Friday!
[16:01:05] -!- anth0ny_ has quit [Client Quit]
[16:01:50] -!- anth0ny_ has quit [Client Quit]
[16:05:56] -!- brianmorel99 has quit [Quit: brianmorel99]
[16:07:54] -!- per_sonne has quit [Ping timeout: 264 seconds]
[16:15:39] <seb_kuzminsky> cmorley: i looked at stepconf-mach-import, looks sane enough, though i dont have a mach config to test it with
[16:15:58] -!- GJdan has quit [Remote host closed the connection]
[16:17:17] <seb_kuzminsky> my only comment is that the docs should be updated to match
[16:18:03] <seb_kuzminsky> here:
http://linuxcnc.org/docs/2.7/html/getting-started/index.html#_stepper_configuration_wizard
[16:18:24] <seb_kuzminsky> and here:
http://linuxcnc.org/docs/2.7/html/config/stepper.html
[16:22:39] -!- Servos4ever has quit [Quit: ChatZilla 0.9.91.1 [SeaMonkey 2.26.1/20140612173529]]
[16:23:44] <seb_kuzminsky> andypugh: the carousel manpage has a cut-n-paste error in the synopsis (it thinks it's called toolchange)
[16:24:42] -!- _longines has quit [Ping timeout: 264 seconds]
[16:25:03] <seb_kuzminsky> the sample config failed to start for me
[16:25:27] <seb_kuzminsky> this seems to be the root of the problem: conv_float_s32: already exists
[16:25:40] <seb_kuzminsky> ./toolchange_gray.hal:2: waitpid failed /home/seb/linuxcnc-dev/bin/rtapi_app conv_float_s32
[16:25:43] <seb_kuzminsky> ./toolchange_gray.hal:2: /home/seb/linuxcnc-dev/bin/rtapi_app exited without becoming ready
[16:25:46] <seb_kuzminsky> ./toolchange_gray.hal:2: insmod for conv_float_s32 failed, returned -1
[16:25:48] <seb_kuzminsky> Shutting down and cleaning up LinuxCNC...
[16:26:18] <seb_kuzminsky> the index sample config starts
[16:26:25] <seb_kuzminsky> with lots of errors:
[16:27:47] <seb_kuzminsky> http://paste.ubuntu.com/11904738/
[16:32:11] <seb_kuzminsky> but despite that it shows a vismach machine with a carousel that moves when i T... M6
[16:32:30] <seb_kuzminsky> so that's cool
[16:33:18] <seb_kuzminsky> i really like vismach, it's glitzy and helpful to understand what's going on, and i'm excited to see more stuff use it
[16:34:07] <archivist> I dream of material being cut in vismach as well :)
[16:35:24] <seb_kuzminsky> i think anders wallin did some cut simulation work
[16:36:09] <archivist> and somebody else in emc2 waaaay back
[16:36:27] <archivist> I did play with it
[16:36:59] <seb_kuzminsky> it's relatively easy to do the first 80% of awesome new features...
[16:37:06] <archivist> damned if I can remember where I last had it and on which box
[16:38:59] <seb_kuzminsky> bbl
[16:59:01] -!- b_b has quit [Remote host closed the connection]
[17:08:47] -!- per_sonne has quit [Ping timeout: 240 seconds]
[17:11:19] -!- skunksleep [skunksleep!~AndChat14@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[17:13:35] <KGB-linuxcnc> 03Dewey Garrett 05andypugh/carousel_demo 0b35f09 06linuxcnc 10configs/sim/axis/vismach/VMC_toolchange/vmc_graycode.ini 10configs/sim/axis/vismach/VMC_toolchange/vmc_index.ini VMC_toolchange: fix paths for RIP only systems * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0b35f09
[17:13:35] <KGB-linuxcnc> 03andypugh 05andypugh/carousel_demo 3a6ab37 06linuxcnc 10configs/sim/axis/vismach/VMC_toolchange/toolchange_gray.hal Fix a problem with dual declaration of a conversion function * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3a6ab37
[17:23:50] -!- Dimroy has quit [Ping timeout: 240 seconds]
[17:32:30] -!- Dimroy has quit [Ping timeout: 264 seconds]
[17:37:28] <jepler> seb_kuzminsky: I need you to tell me that it is the wrong time to think about merging branch jepler/hal-streams to 2.7. (the branch that makes a C API for streamer/sampler-type functionality)
[17:37:55] <jepler> seb_kuzminsky: I also would like your opinion about how much, if any, memory-order stuff you think we should try to address in 2.7, since our best understanding is that the problems are all ARM-only.
[17:38:32] <jepler> seb_kuzminsky: .. these questions are tied together, because the fix for the streamer/sampler problems is half as big with branch jepler/hal-streams, because the libifying reduced code duplication
[17:38:51] <jepler> but it's not *that* much more difficult, it's just 4 sites for a barrier call instead of just 2
[17:39:33] <jepler> afk
[17:41:48] -!- delinquentme has quit [Read error: Connection reset by peer]
[17:47:56] <jepler> seb_kuzminsky: oh and thanks for testing the hm2 stuff on real iron
[17:51:06] <KGB-linuxcnc> 03Jeff Epler 052.7 4249427 06linuxcnc Merge branch 'jepler/hm2-eth-multiple' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4249427
[18:06:41] -!- syyl has quit [Ping timeout: 244 seconds]
[18:11:12] -!- per_sonne has quit [Ping timeout: 264 seconds]
[18:16:14] -!- PetefromTn_ [PetefromTn_!~IceChat9@97-81-58-82.dhcp.kgpt.tn.charter.com] has joined #linuxcnc-devel
[18:52:33] -!- chinchill has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
[18:55:54] -!- SpeedEvil has quit [Ping timeout: 255 seconds]
[19:08:26] -!- malcom2073 has quit [Quit: No Ping reply in 180 seconds.]
[19:12:42] -!- per_sonne has quit [Ping timeout: 264 seconds]
[19:12:49] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[19:14:56] -!- AGR has quit [Ping timeout: 256 seconds]
[19:21:39] -!- micges [micges!~micges@aez134.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[19:40:12] -!- kyle__ has quit [Ping timeout: 244 seconds]
[19:40:18] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[19:44:02] -!- AGR has quit []
[19:48:38] <cmorley> seb_kuzinsky: thanks for review. I will address docs before pushing anything
[19:54:49] -!- AGR has quit [Ping timeout: 246 seconds]
[19:55:06] -!- mhaberler has quit [Ping timeout: 246 seconds]
[19:58:26] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[20:14:26] -!- per_sonne has quit [Ping timeout: 256 seconds]
[20:42:38] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[21:01:55] -!- maximilian_h [maximilian_h!~bonsai@dslb-092-074-052-008.092.074.pools.vodafone-ip.de] has parted #linuxcnc-devel
[21:03:06] -!- Deejay has quit [Quit: bye]
[21:08:19] <Tom_itx> reviewing the G33.1 docs, i'm not getting the specified results. if i specify G33.1 with an X Y Z move it doesn't rapid to XY before moving z as the docs indicate, rather a synchronized move of all at once
[21:09:34] <Tom_itx> i fixed my cam to put x y on a separate line for now
[21:13:00] <Tom_itx> test code starting at N21
http://tom-itx.no-ip.biz:81/~webpage/cnc/temp/relaymount.txt
[21:14:02] -!- tinkerer has quit [Remote host closed the connection]
[21:14:54] <Tom_itx> maybe that's what the Warning in the G33.1 docs means
[21:15:04] <Tom_itx> it could be clearer
[21:16:00] -!- per_sonne has quit [Ping timeout: 264 seconds]
[21:21:47] <pcw_home> I think it does what the docs say, but if you dont do a XY move first you will likely be unhappy
[21:24:12] <jepler> we are talking about
http://linuxcnc.org/docs/html/gcode/gcode.html#sec:G33_1-Rigid-Tapping ?
[21:25:01] <pcw_home> yes
[21:25:07] <pcw_home> "A move to the specified coordinate, synchronized with the spindle at the given ratio and starting with a spindle index pulse. "
[21:25:09] <pcw_home> that says XYZ to me
[21:27:33] <Tom_itx> the example shows an X Y move on a separate line
[21:28:09] <pcw_home> for good reason (unless you like tapping sideways)
[21:28:26] <Tom_itx> i'm looking at the 2.7 docs
[21:28:30] <Tom_itx> probably the same
[21:29:09] <Tom_itx> the warning makes it seem that it will rapid to XY then do the sync Z move
[21:30:06] <jepler> yeah the warning is either wrong or misleading vs the implementation
[21:31:38] <Tom_itx> i got it working here but someone else mentioned it today in the main channel
[21:31:51] <pcw_home> maybe that should be a error (can it ever make sense? )
[21:33:37] <jepler> yes, think 5-axis (though I don't think 5/6 axis rigid tapping is supported,
http://webcache.googleusercontent.com/search?q=cache:immsswc0J3YJ:sourceforge.net/p/emc/feature-requests/75/&strip=1 )
[21:34:55] <jepler> hmph, abcuvw words are accepted but ignored in g33.1.
[21:35:49] <jepler> so, anyway, if the tool is not pointing along Z, a rigid tapping motion that is not along Z is desireable
[21:36:27] -!- KimK has quit [Ping timeout: 244 seconds]
[21:36:38] -!- mhaberler has quit [Quit: mhaberler]
[21:36:42] <jepler> G33.1 is not a canned cycle; a rigid tapping canned cycle G8?.? X- Y- Z- *would* be expected to move to X Y and then tap in Z (assuming plane G17 = XY)
[21:36:53] <pcw_home> So G33.1 can do spindle synchronized motion in any direction (but of course will break things iy the direction is not parallel to the spindle axis)
[21:37:42] <Tom_itx> seems so
[21:38:19] <jepler> so maybe it should say something more like that
[21:38:20] <jepler> > Warning | G33.1 is not a "canned cycle"; if X- or Y- are specified and not equal to the current coordinate, the tapping move will be in a direction not purely in the Z axis.
[21:38:40] -!- KimK [KimK!~Kim__@ip68-102-188-176.ks.ok.cox.net] has joined #linuxcnc-devel
[21:38:59] <Tom_itx> it would make sense to add it to G84 and have the XY move rapid first then do the sync Z move
[21:39:24] <jepler> .. Instead, program G0 X- Y- / G33.1 Z- T- to rapid to the correct location and then perform the tapping move along the Z axis.
[21:39:39] <pcw_home> yeah
[21:39:58] -!- Servos4ever has quit [Quit: ChatZilla 0.9.91.1 [SeaMonkey 2.26.1/20140612173529]]
[21:40:17] <jepler> I don't know if there's any specific reason that there is no G84 canned cycle in linuxcnc.
[21:40:20] <jepler> afk
[21:47:35] -!- XyzB07 has quit [K-Lined]
[21:50:31] -!- Loetmichel has quit [Ping timeout: 240 seconds]
[21:51:11] <JT-Shop> seems to be a lot of code for G84 in interp_cycles.cc
[21:54:21] -!- andypugh [andypugh!~andypugh@50.Red-79-158-169.dynamicIP.rima-tde.net] has joined #linuxcnc-devel
[21:58:34] -!- Loetmichel2 has quit [Ping timeout: 250 seconds]
[22:00:53] jdqx- is now known as jdqx
[22:02:22] -!- AGR has quit [Ping timeout: 260 seconds]
[22:04:47] -!- andypugh has quit [Quit: andypugh]
[22:14:49] -!- jdqx has quit [Remote host closed the connection]
[22:15:09] <jepler> looks like g84 is accepted but doesn't do anything like a rigid tapping canned cycle.
http://paste.ubuntu.com/11906388/
[22:17:16] -!- per_sonne has quit [Ping timeout: 246 seconds]
[22:23:59] -!- HardWall has quit [Ping timeout: 244 seconds]
[22:47:38] -!- arrowbook has quit [Ping timeout: 260 seconds]
[22:59:06] -!- Camaban has quit [Quit: Leaving]
[23:00:51] -!- Tom_L [Tom_L!~Tom@unaffiliated/toml/x-013812] has joined #linuxcnc-devel
[23:02:49] -!- Tom_L has quit [Client Quit]
[23:08:33] -!- remstw has quit [Quit: brb]
[23:19:36] -!- per_sonne has quit [Ping timeout: 264 seconds]
[23:20:44] -!- theorbtwo has quit [Read error: No route to host]
[23:24:31] -!- RealityVoid has quit [Read error: Connection reset by peer]
[23:28:08] -!- gonzo_nb has quit [Read error: Connection reset by peer]
[23:40:31] <KGB-linuxcnc> 03Chris Morley 05stepconf-mach-import ee698b2 06linuxcnc 10src/emc/usr_intf/stepconf/stepconf.py stepconf -add error highlighting to axis page * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ee698b2
[23:40:32] <KGB-linuxcnc> 03Chris Morley 05stepconf-mach-import 4a851a5 06linuxcnc 10docs/src/getting-started/images/stepconf-config.png 10docs/src/getting-started/stepconf.txt docs -update stepconf docs to include 'import mach' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4a851a5
[23:40:32] <KGB-linuxcnc> 03Chris Morley 05stepconf-mach-import 6eb283b 06linuxcnc 10src/emc/usr_intf/stepconf/import_mach.py stepconf -fix up some errors in 'import_mach' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6eb283b
[23:44:45] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.91.1 [Firefox 34.0.5/20141126041045]]
[23:59:49] -!- Thomaxo_ has quit [Remote host closed the connection]