Back
[07:32:06] <jthornton> dgarr if you read back is there a way to set the size to about 80%?
[07:48:43] <jepler> jthornton: yes
[07:48:46] <jepler> after 0 [list wm geometry .__tk_filedialog ${width}x${height}+0+0]
[07:48:55] <jepler> +0+0 gives the offset from the upper left corner of the screen
[07:49:03] <jepler> and width and height give the size
[07:49:13] <jepler> so you could make different computations and use different numbers
[07:50:04] <jepler> for example, you can compute 80% of width by
[07:50:04] <jepler> % set width 1024
[07:50:05] <jepler> 1024
[07:50:05] <jepler> % expr {int($width*.8)}
[07:50:05] <jepler> 819
[07:50:56] <jepler> the problem with dgarr's suggestion is that it is not portable: it depends on details of tk that they might change in any version. (besides not working on mac or windows, which we don't care about)
[07:51:40] <fenn> windows doesn't use the tk file dialog anyway
[07:52:13] <jepler> right
[08:49:36] <seb_kuzminsky> morning
[08:50:43] <seb_kuzminsky> anyone have an opinion on what T-number means "no tool" or "unknown tool"? I feel like it's a somewhat important policy/interface issue that we don't have a clear guideline on: sometimes we use 0 and sometimes -1
[09:19:49] <skunkworks> https://www.youtube.com/watch?v=HO945tdvrzQ
[09:22:32] <skunkworks> he has been working with mach4 to get his 4th axis integrated - ran into some roadblock and decided to see if he could get his device working with linuxcnc/pathpilot
[09:22:50] <skunkworks> He seemed very impressed with linuxcnc
[09:22:59] <mozmck> nice!
[09:24:16] <cradek> ooh it can be a spindle or a rotary? neat.
[09:24:31] <skunkworks> yes
[09:56:32] <skunkworks> Safety glasses anyone?
https://www.youtube.com/watch?v=5p6uLDIF0K8
[09:56:33] <skunkworks> jeeper
[09:57:22] <cradek> yeah they're pretty close to that thing at that height
[09:57:57] <cradek> those adults should know better
[09:58:10] <skunkworks> yes
[09:58:35] <cradek> and isn't that mach on the screen?
[09:59:52] <skunkworks> I don't know... you would think that the guy would know what he is running.. :) it looks a bit like a form of gmoccapy maybe
[10:00:56] <skunkworks> it looks like linux otherwise (some form of gnome)
[10:01:39] <skunkworks> (icons down the left side)
[10:02:25] <cradek> huh
[10:02:30] <cradek> can't tell anymore
[10:07:23] <pcw_home> probably linuxcnc (they buy 6I25s from us)
[10:12:02] <cmorley> If I was selling to the current market I would tend to make the screen look mach-ish, Curious how they did though.
[10:12:41] <cradek> that gets me right in the feels
[10:12:55] <ssi> cradek: :(
[10:15:57] <skunkworks> http://www.machsupport.com/forum/index.php/topic,30949.0.html
[10:16:21] <cmorley> mach-ish or fanuc-ish depending on the market I was trying to reach. machinists tend to be very anal about how things work :)
[10:16:52] <skunkworks> those machinist need to chill out! ;)
[10:18:32] <cmorley> it's easier to sell to people something they are familiar to then convince them something different is better - even if it is better.
[10:18:32] <cradek> skunkworks: oh hey, some software has broken tool offsets? good thing I don't use that software - it sounds unfinished.
[10:18:38] <cmorley> just human nature
[10:18:55] <cradek> cmorley: yeah, glad I'm not selling anything
[10:19:28] <cmorley> well the profits might be nice but not the customer service part :)
[10:19:29] <cradek> cmorley: if I was, I'd probably have to do all sorts of things I don't like or believe in, and that sucks
[10:19:43] <cmorley> tis true i'm afraid
[10:19:50] <cradek> :-/
[10:22:22] <skunkworks> there seems to be growing mach user base that is getting upset that they are paying for software that they have to beta test.
[10:22:47] <cradek> that is a very common model in the commercial software world
[10:22:56] <cradek> very profitable
[10:23:33] <cmorley> cradek:I had a similar problem at work - they want to replace our laser alignment with a different make.
[10:24:13] <cmorley> the new one works fine but id have to learn how to use it, and i already know the nuisances of the old one.
[10:24:54] <cmorley> besides i'm pretty sure the foreman is getting a kickback for buying it, which ticks me off since we don't need it
[10:27:58] <skunkworks> cmorley, good to see you on. Thanks for all the work on gscreen and such
[10:29:15] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 139fb47 06linuxcnc 10tests/toolchanger/m61/test-ui.py tests: add spindle unloading to m61 test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=139fb47
[10:29:16] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 9ed202c 06linuxcnc 10src/emc/iotask/ioControl.cc io: fix HAL pins on "M61 Q0" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9ed202c
[10:29:16] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 3218b21 06linuxcnc 10src/emc/iotask/ioControl.cc io: "no tool" is spelled "0", not "-1" * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3218b21
[10:29:17] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 cc211bf 06linuxcnc 10docs/src/code/Code_Notes.txt docs: update code notes on M61 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cc211bf
[10:29:19] <cmorley> ya i tend to lurk...I have been away working for a month, but now back. Yes i'm happy a few people are trying to use gscreen to make customizations
[10:29:46] <KGB-linuxcnc> 052.6-m61-bug faa5e07 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=faa5e07
[10:30:36] <cradek> cmorley: have you checked out joints_axes8 yet?
[10:30:59] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 21a5373 06linuxcnc 03docs/src/code/code-notes.txt Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=21a5373
[10:32:19] <cmorley> cradek. no i have no use for it, so it does't interest me until it's merged, then i have to fix all my projects :)
[10:33:35] <cradek> well the idea is to make it work right, then merge it
[10:34:00] <cradek> seb & I hope to investigate it a bit on the weekend of the 17th
[10:34:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 9f5b80c 06linuxcnc 10debian/changelog 10docs/src/getting-started/updating-linuxcnc.txt Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9f5b80c
[10:35:02] <skunkworks> cradek, hackerfest?
[10:35:24] <cradek> nothing so organized
[10:35:32] <skunkworks> heh
[10:36:42] <mozmck> I have an interest because I really need to get a working gantry with two home switches.
[10:36:58] <cmorley> Cradek: The thing is I have limited time, so until it's actually merged I probably won't work on it. I'm sorry but it's been 'almost merged' for a very long time.
[10:37:13] <cradek> yes because nobody is working on it :-(
[10:37:27] <cradek> I totally understand limited time
[10:37:32] <cmorley> well i spelled out how I felt about that in an email
[10:37:35] <seb_kuzminsky> mozmck: i've got one of those too! at the boulder hackspace. and i too want it to work right, and i'm willing to put some effort into it
[10:37:47] <mozmck> seb_kuzminsky: great!
[10:38:20] <cmorley> mozmck: did you see the component I fooled with on the forum to do tandem hoing with steppers?
[10:38:21] <mozmck> I've had too many other projects that have been pressing, but I should be able to spend some time on that soon.
[10:38:32] <cradek> but I don't understanding wanting to merge (broken/unfinished) first and disrupt everyone using master. it manufactures a crisis for no reason and I don't believe in that, even though I concede that it might be motivating in some ways
[10:38:49] <mozmck> cmorley: no, I hardly ever look at the forum (it's that "time" thing)
[10:39:27] <cmorley> cradek: its been done before, just not on such a grand scale.
[10:40:06] <cmorley> it's why i suggested pulling out 2.8 first gives time.
[10:40:20] <cmorley> yes it's the motivation that is needed in mho
[10:40:22] <seb_kuzminsky> mozmck: do you have an opinion on cradek's synchronized homing approach?
[10:40:30] <seb_kuzminsky> it seems promising to me
[10:40:55] <mozmck> cmorley: I have a component from steinkueller (sp?) that does that, and it looks like the only problem with it is that it does not do acceleration.
[10:40:57] <cradek> I want JA to be in 2.8 (there's nothing else big in the works)
[10:41:08] <mozmck> cradek: that would be great
[10:41:24] <cmorley> mozmck: yes that is the limitation..wasn't sure how importatnt that was
[10:41:41] <cradek> cmorley: I wish I could find a middle way to motivate you personally, but not break master for everyone else who wants to use it, or work on some other parts of it that would get interrupted by the merge
[10:41:47] <cmorley> then we will wait for 2.8 for a very long time!
[10:42:16] <mozmck> cmorley: it may not be really important, but you have to make sure and set the speed low enough that there is no chance of losing position.
[10:42:53] <seb_kuzminsky> why would we make the 2.8 branch now? there's nothing major new in 2.8 that's not in 2.7
[10:43:18] <cmorley> well i'm pretty sure if you get JA working linuxcnc wise, you will merge it and that leaves alot of the programs outside linuxcnc broken. It get done all the time. So I don't see a big difference.
[10:43:43] <mozmck> seb_kuzminsky: I don't know if I know how the synchronized homing approach works!
[10:43:48] <cmorley> I mean As I understand it JA isn't super broken ...
[10:44:02] <cradek> cmorley: that's why I asked you about it in the first place, too coordinate this
[10:44:06] <cradek> to
[10:44:43] <cradek> and I think yes it is super broken right now, breaking whole classes of common machines (lathes)
[10:44:50] <cradek> I don't know how hard that is to fix because I haven't looked
[10:45:03] <ssi> what about it breaks lathes?
[10:45:03] <cradek> brb
[10:45:38] <cmorley> Well you need to have JA working, and maybe docs or examples - so I can update stepconf,pncconf any GUIs I own so not alot I can do untill thats done...at least i think.
[10:45:46] <seb_kuzminsky> mozmck: it let you mark joints with [AXIS_n]HOME_SYNCHRONIZED, and all the synchronized-home joints in the same HOME_SEQUENCE wait for each other at each step in the homing state machine
[10:46:32] <seb_kuzminsky> the intent is that each step in the homing state machine has less error than the one before it, so things like gantry racking should get better and getter as you get closer to "homed", and never worse like they can be now
[10:47:34] <mozmck> I see. Another issue that people seem to have currently is that you wind up in some mode where jogging jogs only one motor, so the gantry racks.
[10:47:59] <seb_kuzminsky> ssi: if you try any of the sim lathe configs, you get a ton of errors and the machine fails to home
[10:48:26] <seb_kuzminsky> it may not be a huge deal, but no one has debugged it yet
[10:48:33] <ssi> gotcha
[10:48:45] <mozmck> For any gantry that I'm aware of, the only time the motors should move independently is when finishing homing, with no possibility of moving either side independently.
[10:49:21] <seb_kuzminsky> mozmck: ah, yeah i hate that too
[10:49:42] <ssi> mozmck: I only get into that state if I haven't homed for the first time
[10:49:42] <seb_kuzminsky> the problem there is that the machine is in Free mode (aka Joint mode), not in Teleop mode (aka World mode)
[10:49:48] <ssi> yeah exactly
[10:49:59] <ssi> machine starts in free mode, and if you try to jog before homing, it'll rack
[10:50:07] <mozmck> The way I do it now is just use one switch, and both motors are run from one axis vel_cmd.
[10:50:16] <ssi> the other thing I ran into was that once it was homed, I had no way to get back to free mode to rehome
[10:50:23] <seb_kuzminsky> Axis does a good job of hiding that particular wart of linuxcnc, for trivkins machines, but it currently does the wrong thing (imo) on nontrivkins machines
[10:50:24] <ssi> and the way I fixed that was to set volatile homes
[10:50:28] <mozmck> Yes, totally unacceptable.
[10:50:30] <ssi> so if I disable the machine, it unhomes
[10:50:34] <ssi> then when I reenable, I can rehome
[10:50:38] <mozmck> I just use trivkins
[10:50:49] <seb_kuzminsky> ssi: in axis, "$" should switch back and forth between world and joint mode
[10:51:01] <ssi> hm I dunno if I tried that
[10:51:06] <mozmck> ooh, a secret hot key!
[10:51:10] <ssi> :)
[10:51:29] <ssi> I don't think it's secret, I'm pretty sure its on one of the menus
[10:51:44] <mozmck> Is there a way to make it never go into joint mode?
[10:51:45] <seb_kuzminsky> that works well on my gantrykins machine
[10:51:52] <ssi> it needs to be in joint mode to home
[10:51:55] <seb_kuzminsky> mozmck: no, joint mode is needed for homing
[10:51:56] <seb_kuzminsky> right
[10:52:23] <seb_kuzminsky> it'd be good if axis automatically switched to world mode after homing, on nontrivkins machines
[10:52:32] <ssi> I think it does
[10:52:35] <seb_kuzminsky> that would solve this UX problem
[10:52:38] <ssi> or at least my machine is configured to do so
[10:52:50] <mozmck> I'm using a gscreen skin, so I would have to do it there.
[10:53:02] <seb_kuzminsky> maybe it's Task that should switch mode
[10:53:04] <seb_kuzminsky> i dont know
[10:53:26] <seb_kuzminsky> it's not a super trivial issue, and desiging the right fix will take some serious thought
[10:53:34] <ssi> in case anyone's interested, here's a set of configs that worked pretty well for a gentrivkins JA gantry machine
[10:53:38] <ssi> https://github.com/ianmcmahon/linuxcnc_configs/tree/master/laser
[10:53:46] <seb_kuzminsky> a related problem is that we don't currently have incremental jogging in world mode
[10:53:59] <mozmck> I would think that it should not be a UI issue, because it's a potential machine destroyer
[10:54:21] <mozmck> oh, yeah.
[10:54:25] <seb_kuzminsky> (that's why axis leaves the machine in joint mode, and pretends to act like world mode, which works fine on trivkins machines but not on nontrivkins machines)
[10:55:01] <seb_kuzminsky> so, it's one of those seemingly simple things, but that actually requires a fair bit of designing and programming to resolve correctly
[10:55:33] <seb_kuzminsky> so i think the first step is to add incremental world-mode jogging, as strange as that might sound ;-)
[10:55:39] <mozmck> Maybe we need a flag that tells task or whoever does the mode stuff "Use joint mode *only* for homing"
[10:55:48] <mozmck> probably so.
[10:56:02] <ssi> yea cause what we'd rather have is no incremental jogging in joint mode
[10:56:06] <ssi> or continuous jogging for that matter :)
[10:57:49] <cmorley> sounds like we need to be able to 'remap' homing. otherwise in a tandem drive you always want it to act as a single axis?
[10:59:02] <mozmck> for a gantry, the only time you want joint mode is in the final stage of homing, otherwise it is a single axis.
[10:59:23] <cmorley> What else does separating joints from axis get us, besides cleaning up a concept? must be an advantage for robot kins hey?
[10:59:34] <ssi> cmorley: non-cartesian kinematics
[11:00:19] <cmorley> ssi: we have that already no? just makes it easier? better?
[11:00:51] <ssi> I've never worked with any of the robot kins, so I dunno how well they work without JA
[11:01:02] <ssi> but conceptually, that's the point of separating joints from axes
[11:02:52] <cmorley> mozmck: yes so really having some sort of programmable homing would fix that problem altogether.
[11:03:02] <cradek> seb_kuzminsky: JA does have incremental jogging in world mode
[11:03:26] <cradek> seb_kuzminsky: it currently doesn't have wheel jogging in world mode (and that is not a merge stopper IMO)
[11:03:42] <ssi> cradek: I thought so... I would have noticed if I didn't have incremental jogging
[11:03:49] <ssi> I'm running JA on the plasma, and was running it on the laser
[11:03:59] <ssi> and I had most of the issues sorted out on those machines
[11:05:47] <cmorley> mozmck: oh ya only having programmable homing still doesn't fix the no acceleration/deceleration problem.
[11:05:52] <mozmck> I have wondered how useful linuxcnc is for robots. Do they use G-code? There seems to be other projects that are already mature and used for robots such as
http://www.ros.org/, and
http://www.orocos.org/
[11:06:19] <cradek> I think some want gcode, others want just teach-in
[11:06:40] <ssi> mozmck: for instance, I have a plan to get an industrial arm and make it run linuxcnc as a five axis mill
[11:06:41] <mozmck> I see.
[11:06:45] <ssi> that is better for linuxcnc than ros
[11:08:06] <archivist> I think of robot arms as springs, so I would not be making a cutting machine tool
[11:08:25] <skunkworks> foam cutters ;)
[11:08:30] <ssi> archivist: I want to put one of those chinese water cooled spindles on it and carve wood
[11:08:37] <ssi> specifically, I would like to be able to carve propellers
[11:08:46] <mozmck> now yer talking!
[11:08:53] <ssi> with an arm, I could mount a prop blank on a pedestal and carve top and bottom in one operation
[11:09:05] <ssi> I think an arm will be rigid enough for that
[11:09:12] <mozmck> Although you can do that with a 4-axis machine I would think.
[11:09:18] <ssi> yeah but not top and bottom
[11:09:27] <mozmck> rotary on a 3-axis router table.
[11:09:43] <ssi> and I'm talking about a robot like this
[11:09:44] <ssi> http://www.ebay.com/itm/271659536669?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT
[11:10:04] <ssi> more of a spring than my vmc, but probably less of a spring than a lot of homebuilt wood routers :)
[11:10:23] <mozmck> yeah. Why not top and bottom with 4-axis? Only the two ends would not be finished I would think.
[11:10:40] <ssi> mozmck: maybe I just want a robot ok?! ;)
[11:11:24] <mozmck> go for it!
[11:11:38] <ssi> yeah... I've been trying to sort out how to get up there and bring one home
[11:11:53] <ssi> malcom2073 was supposed to go fetch them for me
[11:11:55] <archivist> by the way, need an addition, we need a stylus table
[11:12:09] <ssi> archivist: for probing?
[11:12:15] <ssi> does it need to be separate from the tool table?
[11:13:47] <archivist> yes I think it needs to be separate from tools due to calibration, orientation and multiple tips on a probe
[11:14:42] <ssi> tool table has orientation and plenty of offset data
[11:15:33] <archivist> the calibration of a ball on the end of a stylus varies with angle of contact
[11:16:08] <archivist> with an old style probe anyway
[11:24:34] <archivist> this is the stylus that made me think a bit more about the issues
http://www.renishaw.com/shop/Product.aspx?Product=A-5000-3626
[11:25:37] <ssi> ah
[11:26:26] <archivist> and my probe does not point downwards like most CMMs
[11:45:27] <seb_kuzminsky> cradek: one more reason i'm excited for JA
[11:51:04] <seb_kuzminsky> https://lh3.googleusercontent.com/-m1kKKMHLudI/VhAVGwYqnlI/AAAAAAAAT_o/T6Nvy3miK-8/s828-no/incaseoffire.jpg
[11:52:05] <ssi> lol
[11:53:26] <cradek> nooo always run tests before pushing
[11:53:26] <archivist> are the disks in the burning building :)
[11:53:45] <ssi> archivist: not if you use third party git hosting!
[11:54:06] <cradek> ssi: then you never know if the building is burning
[11:54:16] <archivist> your third party could be on the floor above
[11:54:46] <ssi> cradek: trust me, you can tell when the building is burning :D
[12:06:19] <seb_kuzminsky> http://lwn.net/Articles/659193/rss
[12:07:51] <jepler> that is great news
[12:09:28] <seb_kuzminsky> yeah
[12:11:05] <linuxcnc-build> build #3484 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/3484 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[12:18:41] <pcw_home> That does make Preemt-RT s look like best choice for the future
[12:18:55] <pcw_home> the best choice
[12:18:59] <cradek> the one we already support, whee
[12:30:44] <seb_kuzminsky> that runtests failure is in halui/jogging, and includes a 14-second nap by Task.
[12:32:08] <pcw_home> is that why these debugs printfs are in 2.7?
[12:32:10] <pcw_home> task: main loop took 0.121184 seconds
[12:32:11] <pcw_home> task: main loop took 0.110328 seconds
[12:32:13] <pcw_home> task: main loop took 0.101828 seconds
[12:33:03] <seb_kuzminsky> yeah
[12:33:45] <seb_kuzminsky> those intermittent test failures were a mystery (to me at least) for a long time, I added those warning printfs to Task to help chase the failures down
[12:35:30] <seb_kuzminsky> Task's main loop is supposed to run every 1-10 milliseconds or so, but sometimes it takes 1000x longer (because Task is not realtime, and because the VMs that run our test farm kind of suck)
[12:36:26] <seb_kuzminsky> when the tests do thing like "push the jog button and wait for the jog to start", that kind of latency (in task, or in halui, or in the other non-realtime parts of our system) can cause test failures
[12:47:21] <linuxcnc-build> build #3496 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3496 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[12:47:41] <pcw_home> those are just 10-12 times the nominal (10 ms) time
[12:47:43] <pcw_home> I dont think Ive seen any worse
[12:48:53] <seb_kuzminsky> yeah, on real hardware it's not as big of a problem (but it's still a problem)
[12:48:56] <seb_kuzminsky> joint-1 failed to jog joint-1 to -0.5
[12:48:59] <seb_kuzminsky> timed out at 0.000 after 5.000 seconds
[12:49:01] <seb_kuzminsky> task: main loop took 14.860690 seconds
[12:49:27] <seb_kuzminsky> (that's from the test failure just above)
[12:55:52] <pcw_home> thats a long time for it to be twiddling its thumbs
[12:57:08] <archivist> is this a VM bug only though
[13:00:44] <seb_kuzminsky> archivist: this bug is more pronounced on VMs (because they have worse latency behavior), but it's present on all systems
[13:01:21] <seb_kuzminsky> for example, Task does file I/O in the critical path, which can be unbounded no matter how good your platform is
[13:04:23] <pcw_home> I guess the (VM)disk could be pretty slow
[13:05:21] <archivist> on my 5 axis I get huge delays from disk access
[13:05:28] <pcw_home> especially if there are a couple compiles going on at the same time
[13:05:58] <seb_kuzminsky> SSDs are notoriously bad for worst-case latency (and notoriously good for common-case latency, which is a dangerous combination)
[13:06:59] <pcw_home> yeah you might catch them in a wear leveling frenzy
[13:07:24] <seb_kuzminsky> exactly
[13:07:55] <seb_kuzminsky> i think the fix is to move disk i/o out of Task's main thread
[13:08:01] <Tom_itx> so they're supposed to be fast but aren't because they're worried about wearing out?
[13:08:12] <seb_kuzminsky> they're usually very fast
[13:08:43] <seb_kuzminsky> sometimes they take a multi-second nap to reorganize their insides, and if you happen to call sync on them during that, you have to wait for them to finish
[13:09:28] <Tom_itx> do they throw a warning that's coming?
[13:09:35] <seb_kuzminsky> some (many?) system calls have an implicit sync() in them, the syncing one Task calls is rename()
[13:09:59] <seb_kuzminsky> Tom_itx: you might be able to predict it by looking at the SMART data from the disk, i dont know
[13:10:07] <seb_kuzminsky> it'd be vendor and model specific, in that case
[13:10:09] <seb_kuzminsky> i think
[13:10:18] <Tom_itx> probably so
[13:10:37] <seb_kuzminsky> i've not seen it done, or talked about (but i havent looked hard)
[13:13:40] <pcw_home> moving disk IO out of the main thread seems a better choice :-)
[13:15:07] <pcw_home> probably most things can proceed without waiting for the sysc
[13:15:19] <pcw_home> sync
[13:16:35] <seb_kuzminsky> pcw_home: i totally agree
[14:19:08] <cradek> cmorley: on master, RIP stepconf gives a traceback at startup:
http://timeguy.com/cradek-files/emc/stepconf-startup-master.png
[14:19:14] <cradek> cmorley: do you want me to file a bug?
[14:21:00] <cradek> err, maybe it was c813031ccb09
[14:21:28] <cmorley> no I'll fix it
[14:22:36] <cradek> I might have already - testing now
[14:22:49] <cradek> (I added axisu and axisv to the list in Submakefile)
[14:23:32] <cradek> yeah that fixes it
[14:23:41] <cradek> sorry to bug you before I looked
[14:24:42] <cmorley> ahh excellent
[14:24:57] <cradek> trying to figure out if it's master only
[14:27:15] <cmorley> I see it was Jeff's refactor of the submakefile that did it...
[14:27:25] <cradek> yep
[14:27:29] <cradek> and it is master only (yay)
[14:27:33] <cmorley> i wondered how I had messed that up lol
[14:27:48] <jepler> sorry
[14:27:52] <jepler> thanks for fixing, cradek
[14:28:13] <KGB-linuxcnc> 03Chris Radek 05master a298048 06linuxcnc 10src/emc/usr_intf/stepconf/Submakefile Fix stepconf backtrace at startup * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a298048
[14:28:14] <cradek> no problem
[14:28:21] <seb_kuzminsky> :-)
[14:28:47] <cradek> we would have had to take your cookie away if you had refucktored in 2.7
[14:28:57] <jepler> heh
[14:29:00] <jepler> but it's better now!
[14:29:00] <cmorley> easy fixes are nice :)
[14:31:12] <cradek> yeah it's a huge improvement
[14:31:16] <cradek> thanks for doing it
[14:32:02] <jepler> it was left over from some rather old branch
[14:32:57] <jepler> oh trying to detect certain bugs (repeated ids) in glade files
[15:09:45] <malcom2073> ssi: If it A: Didn't scare the living shit out of me, and B: I had a decent place for it, I'd be all over it :(
[19:03:53] <KGB-linuxcnc> 03Chris Morley 052.7 1180c46 06linuxcnc 10src/emc/usr_intf/pncconf/build_HAL.py 10src/emc/usr_intf/pncconf/external.glade 10src/emc/usr_intf/pncconf/pncconf.py pncconf -fix HAL file - VFD always being selected * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1180c46
[19:10:34] <KGB-linuxcnc> 03Chris Morley 05master d40e5d4 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d40e5d4
