Back
[09:24:08] <seb_kuzminsky> the linux kernel just gained a Code of Conduct^W^W^W^Wflict, summarized as "be excellent to each other":
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ddbd2b7ad99a418c60397901a0f3c997d030c65e
[09:28:43] <archivist> I like it, I grabbed something from the brlcad channel, when someone was moaning about his review, started to edit it a bit for generic use
[09:31:18] <cradek> I wonder if that will help
[09:31:26] <cradek> it's all so hard
[09:32:16] <archivist> especially if someone somewhere is translating to his own language
[09:32:56] <cradek> yes even when you share a language it's hard to communicate well about technical things
[09:34:21] <seb_kuzminsky> or about any thing
[09:34:27] <CaptHindsight> ok, that explains why other projects just went anal about conduct
[09:35:14] <CaptHindsight> seb_kuzminsky: just excellent or totally excellent? :)
[09:35:28] <seb_kuzminsky> "be just barely tolerable to each other"
[09:36:42] <skunkworks> I don't see the issue that andrew is seeing.. it almost seems like a setup problem..
[09:37:00] <skunkworks> but he says sim lathe..
[09:37:20] <archivist> I was starting on the stop nagging about your patch
http://www.collection.archivist.info/archive/mirror/linuxcnc/patience.txt
[09:40:01] <seb_kuzminsky> patches do get dropped sometimes (ie, forgotten by the reviewers), and one of the jobs of a patch submitter is to shepherd the patch towards review & merge by preventing droppage
[09:40:50] <seb_kuzminsky> for example, slavko did the right thing imo by: 1. opening a feature request for his patch, and 2. poking the reviewers after a week of silence
[09:44:50] <skunkworks> micges, did the demo person like the new TP?
[09:45:13] <micges> very
[09:48:17] <micges> unfortunately plasma generator is broken so we will cut something in a few hours or tomorrow
[13:32:19] <cradek> skunkworks: so there's really something broken about using mms in the g18 plane?
[13:38:26] <mozmck> c_morley: you around?
[13:38:40] <c_morley> Yes
[13:39:50] <mozmck> I'm looking at Gscreen, and I can resize larger in the X direction, but not smaller
[13:40:33] <mozmck> So I can make the window wider but then I can not make it smaller again.
[13:42:04] <c_morley> This is the default screen? I believe it has to do with Gremlin.
[13:42:21] <mozmck> Yes, default screen, but I think any of the others as well.
[13:42:40] <mozmck> That may be, because it is Gremlin that re-sizes.
[13:43:12] <c_morley> Try Gaxis no plot see if its the same
[13:43:55] <c_morley> That is one thing very difficult with glade...finding that one thing that is screwing up the control
[13:44:02] <mozmck> That one works fine.
[13:44:46] <c_morley> So its probably a option set wrong on one of the dozens of containers.
[13:44:53] <mozmck> Also in the Industrial screen the bottom pane with buttons has a lot of empty space and no way to eliminate that that I can see.
[13:45:06] <mozmck> ok, that could be.
[13:45:21] <mozmck> Gtk+ is a pretty good pain in general
[13:45:30] <c_morley> The only way to find it is to delete things till it work properly then work your way back.
[13:45:46] <c_morley> Blank buttons you mean?
[13:45:51] <mozmck> huh.
[13:45:56] <mozmck> No, no buttons.
[13:46:21] <c_morley> hmmm that seems weird
[13:46:51] <c_morley> looking
[13:47:26] <c_morley> oops i'm in the middle of work so its broken right now sorry
[13:47:38] <mozmck> Looks like this:
http://pbrd.co/1C2rkU2
[13:48:54] <c_morley> that looks like where the keyboard toggle...try toggling the keyboard button. what distribution are you using?
[13:49:38] <c_morley> If debian then Onboard virtual keyboard is not supported.
[13:51:13] <mozmck> I'm using LinuxMint 17.1
[13:52:02] <mozmck> I toggled the Toggle Keyboard button but it did nothing.
[13:52:11] <mozmck> I don't think I have Onboard installed.
[13:52:18] <c_morley> oh cool... I tried to get Mint working with linuxcnc I had mixed results but I think it was an earlier version. I like Mint
[13:53:58] <c_morley> I haven't work on Gscreen for a long while, things may have bit rotted some. Gmoccpy allows some other virtual keyboard that Debian has..I should add that too.
[13:55:04] <mozmck> I just installed Onboard - I'll see if that changes anything.
[13:55:35] <mozmck> I like Mint as well. I run XFCE on my main computer here, and Cinnamon on my laptop.
[13:56:30] <c_morley> The Gscreen samples are really just that samples I developed to exercise the utility of Gscreen. I was hoping someone would make a really nice screen with it. Norbert did but he wanted to work outside of Gscreens philosophy too much :)
[13:56:32] <mozmck> Both are nice, but XFCE is actually a little more configurable and I like Mint's setup of it. I do use Nemo (Nautilus fork without all the features removed) instead of Thunar.
[13:56:41] <mozmck> I see.
[13:56:41] <skunkworks_> cradek: It looks like it.
[13:56:51] <c_morley> I dislike Debian,
[13:57:37] <mozmck> The problem with Debian is that it's a year or two out of date as soon as it's released :)
[13:57:52] <c_morley> Yes Thunar -- I miss tabs
[13:58:13] <c_morley> Oh The problem I find is little paper cuts -- drives me crazy
[13:58:23] <mozmck> Actually, the newest Thunar has tabs - and is getting pretty close to Nemo in functionality.
[13:58:25] <c_morley> Ubuntu was polished
[13:58:36] <c_morley> Oh good !
[13:58:46] <mozmck> I would say Mint is more polished, and more sensible.
[13:59:08] <c_morley> I Agree - mint is the way to go for what we are doing.
[13:59:26] <mozmck> I plan on building a liveCD using Xubuntu 14.04 soon, but I have though of basing it on Mint.
[13:59:37] <c_morley> I vote Mint
[14:00:08] <mozmck> One thing I found out is that either one - or maybe *any* distribution wants you to remove their branding from any custom liveCD based on theirs
[14:00:15] <c_morley> or put Cinnamon on Xubuntu :)
[14:00:41] <mozmck> Well, I plan to use XFCE because it is a bit more stable and a lot faster that cinnamon.
[14:00:43] <c_morley> Yes I can somewhat understand that
[14:01:17] <mozmck> If you look at the XFCE version of Mint though, you might be surprised how similar it looks to the Cinnamon version.
[14:01:43] <c_morley> I am using Xfce now on an underpowered Debian computer
[14:01:45] <mozmck> Yeah, so removing the branding is going to be a little bit of extra pain.
[14:01:58] <c_morley> Guess I have to check it out again :)
[14:02:53] <c_morley> Have you tried the Debian based version of Mint?
[14:02:57] <mozmck> I bet even debian would technically want us to remove their branding from the liveCD.
[14:03:16] <mozmck> No, it was based on the Testing version of Debian,
[14:03:57] <c_morley> It's no different then us not really wanting Tormach's pilotpath or machinekit saying Linuxcnc
[14:04:22] <mozmck> Yes - it does make sense.
[14:04:38] <c_morley> I heard they were going to switch to what we are using now (Debian version) and get away from rolloing release
[14:04:59] <mozmck> Yes, I read something about that, but I don't remember the details
[14:05:29] <c_morley> Are you just playing with Gscreen or interested in custom screens?
[14:05:54] <mozmck> I'm going to build a custom screen, and looking at the various options.
[14:06:24] <mozmck> It's looking like Gscreen may be the best starting point for me.
[14:06:30] <c_morley> I would do what I can to help you use Gscreen
[14:06:48] <cradek> mozmck: have you found something more detailed than
https://wiki.debian.org/Derivatives/Guidelines#De-.2FRe-branding
[14:07:05] <mozmck> We really like the look of the Tormach screen and layout, so it will probably have a similar layout.
[14:07:24] <c_morley> I need to document more about how customs are built. Some of the problem (as usual) is I know how it's supposed to work :)
[14:08:06] <c_morley> Get tormach's GLADE file and it can be exactly the same look :)
[14:08:11] <mozmck> cradek: I didn't look very much for Debian, but I asked the Xubuntu devs and they said definitely.
[14:08:16] <c_morley> or at least layout
[14:08:49] <mozmck> cradek: And LinuxMint has something about it as well, and a liveCD builder out there says the same about any distribution IIRC.
[14:09:35] <cradek> unfortunately none of those sound like particularly good sources. I'll keep digging around on debian.org.
[14:09:51] <mozmck> c_morley: Are they giving that out? It doesn't look like building one from scratch would be hard. We don't want it exactly the same anyhow.
[14:10:13] <skunkworks_> cradek: it seems to run slower on arcs when in mm
[14:10:25] <mozmck> cradek: they may not be for debian, but they are for xubuntu and linux mint.
[14:10:27] <skunkworks_> I sent rob an email. His email must be full now.
[14:10:29] <c_morley> They will only give it to those who own Tormach machines
[14:10:56] <skunkworks_> I don't know if this has always been or not. I would have to dig.
[14:11:00] <cradek> skunkworks_: all arcs or only g18 arcs?
[14:11:38] <skunkworks_> I am about 50% sure it is just G18...
[14:11:43] <skunkworks_> sill playing
[14:13:43] <skunkworks_> the example on the list - the arcs are clamped at 60 mm/m
[14:14:49] <c_morley> mozmck: I wonder if they would give you the files if you promise to not distribute a screen that looks too much like theirs. Tormach has been pretty good to linuxcnc so I wouldn't want to jeopardize the relationship.
[14:15:37] <mozmck> I don't know - I can probably build pretty quickly I would think?
[14:15:51] <mozmck> build a glade file that is...
[14:17:19] <c_morley> Yes the layout isn't too bad once your used to GLADE. Getting the look (theme) right is a lot more effort
[14:17:49] <CaptHindsight> which linuxcnc GUI is the most flexible for customization? I'd like to use it for a single axis setup with a bunch of IO. watch the axis rotate, see synchronized events (on/off) from devices around the rotating parts in the chuck
[14:17:50] <c_morley> I am not sure what technigue they used, but I would bet lots of image files
[14:18:02] <mozmck> Yes, I heard they used bitmaps, but I would like to explore theming instead.
[14:18:19] <c_morley> Gscreen is the most flexeble
[14:18:34] <c_morley> yes bit maps is easier I would say
[14:18:49] <c_morley> some themes use bit maps too
[14:18:50] <cradek> skunkworks_: can you make a gcode file with just one arc (the same arc) in each of the three planes and reproduce it with that? it would be great to see the TASK ISSUE debug output of that.
[14:18:51] <skunkworks_> cradek: well crap - If you bring the program up in sim axismm - it runs at the correct speed. So maybe it is a xz only mm issue
[14:19:38] <mozmck> c_morley: that's interesting. I guess it would make the buttons non-resizeable, so you would need images for each button size?
[14:20:04] <cradek> making a gui unresizable is a terrible mistake and I hope nobody else makes it
[14:20:05] <c_morley> Well one theme uses images that are resizable
[14:21:39] <CaptHindsight> I'd like to start developing something to replace labview to monitor linuxcnc controlled machines that aren't machine tools
[14:21:40] <cradek> skunkworks_: are you saying the xz arc works ok as long as you have a y axis defined?
[14:21:42] <c_morley> Yes Gscreen can use a bit map as a background and then you can just place widgets on it..and thats great and easy but then if you resize it everything moves out of place :(
[14:22:21] <skunkworks_> cradek: so far
[14:22:49] <skunkworks_> unless there is something different between the ini's that I am not seeing
[14:23:05] <c_morley> Mozmck: in industrial that blank area is it filled auto mode?
[14:23:15] <skunkworks_> it is between the axis_mm.ini in sim and the ini that Andrew posted on the list.
[14:23:27] <mozmck> what is auto mode?
[14:23:31] <c_morley> yes
[14:24:00] <mozmck> I don't know what auto mode is.
[14:24:09] <c_morley> oh sorry auto mode is when you are going to run a program - it may be called something different in Industrial..
[14:24:13] <mozmck> I installed Onboard and there is a keyboard there now.
[14:24:31] <c_morley> ahh hit the 'program' button
[14:25:04] <mozmck> I can un-install onboard and check right quick
[14:25:12] <c_morley> then the keyboard area should be replaced with Gcode area
[14:25:20] <c_morley> don't un install
[14:25:54] <c_morley> the screen changes in manual. MDI and auto mode (slightly)
[14:26:50] <mozmck> ok, I see the keyboard in all modes, but it gets a little smaller in Auto to make room for the G-code windoe
[14:26:51] <mozmck> window
[14:27:21] <mozmck> Anyhow, that's fine now that I know what it is.
[14:27:35] <c_morley> If you toggle the keyboard off it will get bigger I think
[14:28:08] <mozmck> Oh, yes that works now. Looks like it doesn't work properly if Onboard is not installed.
[14:29:35] <c_morley> Hopefully I can find some time and improve it...
[14:30:08] <mozmck> ok, I may be able to help as I look at stuff and work on it here.
[14:30:23] <skunkworks_> cradek: if I change axis_mm.ini to lathe (change 2 things only - corrdinates = X Z, Lathe = 1) it seems to run correctly....
[14:31:04] <cradek> maybe next try removing the [AXIS_1] section (ugh)
[14:32:13] <skunkworks_> ugh...
[14:32:18] <skunkworks_> that did it.
[14:34:40] <cradek> skunkworks_: it would be great if you could get that TASK ISSUE debug output for the failure mode
[14:39:08] <c_morley> mozmck: sounds great! ttyl
[14:44:00] <skunkworks_> cradek:
http://pastebin.com/fKF9iMRE
[14:45:55] <skunkworks_> cradek: with axis 1 still in (and running correct velocity)
http://pastebin.com/hKinfu4U
[14:46:23] <cradek> woo
[14:46:37] <cradek> the only difference was removing the [AXIS_1] section?
[14:46:43] <skunkworks_> yes
[14:46:51] <skunkworks_> I put it back in to do the second task list.
[14:47:48] <c_morley> mozmck: Not sure if you knew but if you name the glade file tester.glade and put if in the sim/gscreen folder then you can load it as a linuxcnc screen - should be explained in master's manual or on wiki - k really going now :)
[14:58:22] <KGB-linuxcnc> 03Norbert Schechner 052.6 50c1baa 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_5_2_2 - fixed division by zero error on spindle * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=50c1baa
[14:59:44] <KGB-linuxcnc> 03Norbert Schechner 052.7 386b859 06linuxcnc Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=386b859
[15:00:27] <KGB-linuxcnc> 03Norbert Schechner 05master dde5c45 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dde5c45
[15:00:59] <cradek> skunkworks_: can I have your test ini and gcode?
[15:01:42] <cradek> skunkworks_: I'm not just spotting this one like the other one
[15:06:29] <skunkworks_> http://pastebin.com/K0WYE5h9 ini with [axis_1]
[15:07:10] <skunkworks_> short gcode
[15:07:11] <skunkworks_> http://pastebin.com/ZQ0SRN2f
[15:07:54] <skunkworks_> it runs 140mm/s if [axis_1] is in the ini. - 60mm/m if removed
[15:08:11] <cradek> thanks!
[15:22:37] <cradek> this is totally weird. I think all the constraints on arcs were wrong, if the config's axes didn't all match:
http://pastie.org/10012811
[15:23:19] <cradek> even XY arcs would have been wrong
[15:23:31] <cradek> why didn't we notice?
[15:23:59] <skunkworks> there was a xy issue a while back that was fixed. (it had huge violations..)
[15:24:48] <cradek> would you have noticed if all some various arcs went too slow?
[15:24:52] <cradek> if some
[15:24:59] <skunkworks> hmm - maybe not.
[15:25:41] <skunkworks> is that a fix?
[15:26:15] <cradek> yes but I'm having trouble convincing myself it matches all the facts
[15:27:53] <cradek> if you have a normal mill config with Y maxvel less than both X and Z, and you do some G17 arcs, I think you will see a violation on Y
[15:29:41] <skunkworks> biab
[15:31:42] <cradek> no, it's right for G17
[15:41:49] <cradek> ugh yeah it was totally wrong, but happened to work for G17
[15:42:22] <cradek> you can see an arbitrarily large violation if you set Y's maxvel to be smaller than X,Z and do a G19 arc
[15:47:17] <KGB-linuxcnc> 03Chris Radek 052.7 dbdec6a 06linuxcnc 10src/emc/task/emccanon.cc Fix use of wrong maxvel and maxaccel values on non-G17 arcs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dbdec6a
[16:00:16] <skunkworks> zlog:
[16:07:40] <Tom_itx> skunkworks, can you see that link ok? was having router issues yesterday
[16:09:02] <skunkworks> yep - worked
[16:09:15] <Tom_itx> ok thanks
[16:09:54] <seb_kuzminsky> i'll make another 2.7 pre-release this week with all the TP fixes you guys are making
[16:11:55] <skunkworks> cradek: that seemed to fix the lathe issue. But I thought it might also fix
http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-03-09%2010:14:18.png
[16:12:23] <cradek> what's wrong there?
[16:12:32] <skunkworks> but the G18 arcspiral still runs 200IPM slower..
[16:13:04] <cradek> hm maybe it's deeper
[16:13:37] <cradek> g18 is slower even if all your axis_0,1,2 are the same?
[16:15:50] <skunkworks> yes
[16:16:24] <cradek> yeah that can't be this same bug, sorry :-/
[16:16:42] <cradek> g17 and g19 are the same but g18 is slower?
[16:17:53] <skunksleep> Yes
[16:22:00] <cradek> very funky
[16:22:08] <cradek> that has a bad smell to it
[16:25:31] <skunksleep> I have a cold..
[16:58:00] <cradek> skunkworks: sorry to hear you're sick. everyone is sick lately.
[16:59:12] <AndChat|144384> It has been a sick house for the last month
[17:24:56] <andypugh> A general Python question: Is there any reason to replace a class with a def if you only expect to use one of it?
[17:44:55] <micges> as always in Python it's possible but I don't see any reason to do so
[18:09:02] <andypugh> So, no memory or efficiency advantage?
[18:09:31] <andypugh> It feels like a “sub” rather than a “class” but the example I have is a class.
[18:44:01] <cradek> skunkworks: the NCD only works in G17, but that's not what's going on - they are being issued as real arcs.
[18:44:40] <skunkworks> right - the speed stays up xy and yz - not xz
[18:45:29] <skunkworks> So I agree it isn't related to NCD
[18:46:57] <skunkworks> Can you reproduce what I am seeing?
[18:51:22] <cradek> skunkworks: yeah I can
[19:12:08] <skunkworks> good (sometimes it is just me...)
[19:13:29] <cradek> huh my earlier "fix" is wrong
[19:14:34] <skunkworks> is it wrong if it fixes the issue at hand?
[19:14:36] <cradek> I could've sworn I tested it. is negative % positive undefined?
[19:16:46] <memfrob> hi all, RTAI 4.1 is released
[19:17:02] <memfrob> IPIPE legacy interface in RTAI is finally being dropped!
[19:33:25] <skunkandroid> cradek: like riding a bike?
[19:36:31] <Tom_itx> could someone please post the git addy for the mesaflash utility?
[19:37:35] <atom1> ahh nm... i found it
[19:50:43] <cradek> ohhh my
[19:50:58] <cradek> skunkandroid: you always find something the last place you look
[19:51:40] <skunkandroid> That sounds promising
[19:52:54] <cradek> zoom in and look at the paths
[19:53:27] <atom1> yay! asrock alive!
[19:59:48] <skunkworks> cradek: because the arcs are the wrong way?
[20:00:44] <skunkworks> oops.. sorry..
[20:02:55] <skunkworks> was your fix good then?
[20:03:07] <cradek> nope it was still wrong
[20:03:52] <KGB-linuxcnc> 03Chris Radek 052.7 bc9d94c 06linuxcnc 10src/emc/task/emccanon.cc Fix my previous fix for arc axis constraints * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc9d94c
[20:04:50] <cradek> if I change it to g18 g3 and change nothing else, it runs at full speed because then they're tangent
[20:05:04] <cradek> r format can sure hide problems, can't it
[20:20:47] <skunkworks> ugh. stupid mistake..
[20:21:09] <skunkworks> so - your fix does fix the lathe issue though -right?
[20:21:18] <cradek> yes it better
[20:22:33] <cradek> without breaking all the other planes, even
[20:26:59] <memfrob> Looks like the new RTAI 4.1 release further fixes the isolcpus bug, I'm going to be doing massive clean-up on the 4.1 release and ensure compatibility with LinuxCNC as 4.1 will not work as-is
[20:28:35] <memfrob> I am going to continue to bump all related changes to the core of RTAI, hal, scheduler, kernel, etc upon new RTAI releases so in case LinuxCNC developers want to ship a new CD or new .debs that can without having to use obsolete RTAI trees
[22:23:05] <seb_kuzminsky> memfrob: cool, i hope to look at the new rtai (& rt-preempt) patches along with the GSoC student that expressed interest
[22:46:43] <memfrob> im almost done cleaning up the 4.1 release
[22:52:53] <memfrob> down to the last 10K lines of code, only about a couple hundred lines left I actually need to modify but I have scripts that do most of the work for me
