Back
[01:24:03] <cmorley> seb_kuzminsky: ok when I hear from you and John - I will push (or fix and push) :)
[05:20:29] <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
[05:32:49] <andypugh> seb_kuzminsky: I just pushed a feature branch with the carousel comp, Vismach gui, G-code toolchange remap and spindle orient demos.
[08:44:50] <jepler> andypugh: neat!
[09:02:37] <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.
[09:02:42] <jepler> https://talks.golang.org/2015/go-gc.pdf
[09:04:01] <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
[09:04:31] <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
[09:08:48] <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
[09:11:27] <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 :)
[09:30:25] <cradek> > We're holding SCM service restoration for last
[09:31:00] <cradek> > related to filesystem corruption on our storage platform. This incident impacted all block devices on our Ceph cluster
[09:31:16] <cradek> I don't understand what this means
[09:32:05] <cradek> they have one big filesystem, and the filesystem got nuked?
[09:43:14] <jepler> seems like
[09:43:37] <jepler> archivist: yeah that was a slide in this presentation I was looking ta
[10:58:17] <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?
[11:02:37] <pcw_home> Either should be fine but I do know to avoid Broadcom on WIFI adpaters
[11:04:47] <brianmorel99> pc_home: Great, thanks for getting the 7i92 out Friday!
[11:38:30] <seb_kuzminsky> cmorley: i looked at stepconf-mach-import, looks sane enough, though i dont have a mach config to test it with
[11:40:08] <seb_kuzminsky> my only comment is that the docs should be updated to match
[11:40:55] <seb_kuzminsky> here:
http://linuxcnc.org/docs/2.7/html/getting-started/index.html#_stepper_configuration_wizard
[11:41:16] <seb_kuzminsky> and here:
http://linuxcnc.org/docs/2.7/html/config/stepper.html
[11:46:36] <seb_kuzminsky> andypugh: the carousel manpage has a cut-n-paste error in the synopsis (it thinks it's called toolchange)
[11:47:55] <seb_kuzminsky> the sample config failed to start for me
[11:48:19] <seb_kuzminsky> this seems to be the root of the problem: conv_float_s32: already exists
[11:48:32] <seb_kuzminsky> ./toolchange_gray.hal:2: waitpid failed /home/seb/linuxcnc-dev/bin/rtapi_app conv_float_s32
[11:48:34] <seb_kuzminsky> ./toolchange_gray.hal:2: /home/seb/linuxcnc-dev/bin/rtapi_app exited without becoming ready
[11:48:37] <seb_kuzminsky> ./toolchange_gray.hal:2: insmod for conv_float_s32 failed, returned -1
[11:48:40] <seb_kuzminsky> Shutting down and cleaning up LinuxCNC...
[11:49:10] <seb_kuzminsky> the index sample config starts
[11:49:17] <seb_kuzminsky> with lots of errors:
[11:50:39] <seb_kuzminsky> http://paste.ubuntu.com/11904738/
[11:55:03] <seb_kuzminsky> but despite that it shows a vismach machine with a carousel that moves when i T... M6
[11:55:22] <seb_kuzminsky> so that's cool
[11:56:10] <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
[11:56:58] <archivist> I dream of material being cut in vismach as well :)
[11:58:15] <seb_kuzminsky> i think anders wallin did some cut simulation work
[11:59:01] <archivist> and somebody else in emc2 waaaay back
[11:59:19] <archivist> I did play with it
[11:59:50] <seb_kuzminsky> it's relatively easy to do the first 80% of awesome new features...
[11:59:58] <archivist> damned if I can remember where I last had it and on which box
[12:01:50] <seb_kuzminsky> bbl
[12:36:27] <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
[12:36:27] <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
[13:00:19] <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)
[13:00:47] <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.
[13:01:23] <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
[13:01:43] <jepler> but it's not *that* much more difficult, it's just 4 sites for a barrier call instead of just 2
[13:02:25] <jepler> afk
[13:10:48] <jepler> seb_kuzminsky: oh and thanks for testing the hm2 stuff on real iron
[13:13:57] <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
[15:11:29] <cmorley> seb_kuzinsky: thanks for review. I will address docs before pushing anything
[16:31:11] <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
[16:32:26] <Tom_itx> i fixed my cam to put x y on a separate line for now
[16:35:52] <Tom_itx> test code starting at N21
http://tom-itx.no-ip.biz:81/~webpage/cnc/temp/relaymount.txt
[16:37:46] <Tom_itx> maybe that's what the Warning in the G33.1 docs means
[16:37:56] <Tom_itx> it could be clearer
[16:44:38] <pcw_home> I think it does what the docs say, but if you dont do a XY move first you will likely be unhappy
[16:47:03] <jepler> we are talking about
http://linuxcnc.org/docs/html/gcode/gcode.html#sec:G33_1-Rigid-Tapping ?
[16:47:53] <pcw_home> yes
[16:47:59] <pcw_home> "A move to the specified coordinate, synchronized with the spindle at the given ratio and starting with a spindle index pulse. "
[16:48:00] <pcw_home> that says XYZ to me
[16:50:25] <Tom_itx> the example shows an X Y move on a separate line
[16:51:01] <pcw_home> for good reason (unless you like tapping sideways)
[16:51:18] <Tom_itx> i'm looking at the 2.7 docs
[16:51:22] <Tom_itx> probably the same
[16:52:01] <Tom_itx> the warning makes it seem that it will rapid to XY then do the sync Z move
[16:52:58] <jepler> yeah the warning is either wrong or misleading vs the implementation
[16:54:30] <Tom_itx> i got it working here but someone else mentioned it today in the main channel
[16:54:43] <pcw_home> maybe that should be a error (can it ever make sense? )
[16:56:29] <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 )
[16:57:47] <jepler> hmph, abcuvw words are accepted but ignored in g33.1.
[16:58:41] <jepler> so, anyway, if the tool is not pointing along Z, a rigid tapping motion that is not along Z is desireable
[16:59:33] <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)
[16:59:44] <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)
[17:00:33] <Tom_itx> seems so
[17:01:11] <jepler> so maybe it should say something more like that
[17:01:11] <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.
[17:01:50] <Tom_itx> it would make sense to add it to G84 and have the XY move rapid first then do the sync Z move
[17:02:16] <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.
[17:02:31] <pcw_home> yeah
[17:03:09] <jepler> I don't know if there's any specific reason that there is no G84 canned cycle in linuxcnc.
[17:03:12] <jepler> afk
[17:14:03] <JT-Shop> seems to be a lot of code for G84 in interp_cycles.cc
[17:38:01] <jepler> looks like g84 is accepted but doesn't do anything like a rigid tapping canned cycle.
http://paste.ubuntu.com/11906388/
[19:03:23] <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
[19:03:23] <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
[19:03:23] <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
[20:36:24] <seb_kuzminsky> http://sliptonic.com/dogfooding-with-freecad-path/
[20:42:21] <seb_kuzminsky> cmorley: that looks great
[20:42:41] <seb_kuzminsky> i still dont have a mach config, so i can't try converting it
[20:43:28] <seb_kuzminsky> i'm happy that there's docs now, so if someone tells me they successfully converted a working mach config to a working linuxcnc config i'll go all salt'n'peppa
[20:44:28] <seb_kuzminsky> http://i.ytimg.com/vi/UKUKU1LXVHg/hqdefault.jpg
[21:40:45] <jepler> I've got an idea, let's put each stepper on its own wifi connection and hope for the best.
http://www.adafruit.com/products/2653
[22:18:37] <cradek> omg!
[22:45:50] <mozmck> Interesting:
http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/ I knew I liked keyboards and mice, buckling spring ;)
[22:50:11] <cradek> So here's a Vision Of The Future that's popular right now: [ This plugin is vulnerable and should be updated. ]
