Back
[01:38:15] <cradek> jepler: what's the state of the emc world now that it's dark?
[01:41:11] <DanielFalck> cradek: what's the state of your garage? how's it going?
[01:42:18] <cradek> going ok. the roof's 2/3 done now, walls are done, one door is in
[01:42:37] <DanielFalck> so now you have a dedicated shop?
[01:42:45] <cradek> yes
[01:42:50] <DanielFalck> great!
[01:42:57] <cradek> yes it's very nice
[01:43:08] <cradek> unfortunately no place to park the cars... but that's coming
[01:43:25] <cradek> racing against the weather is the thing that makes it stressful
[01:43:57] <DanielFalck> the cars will survive for a little while
[01:44:06] <cradek> sure
[01:44:22] <cradek> but without shingles, the roof sheathing won't
[01:44:48] <DanielFalck> I lived in NE Iowa with no garage
[01:44:49] <cradek> pretty much have to finish it
[01:45:03] <DanielFalck> yep
[02:04:04] <jmkasunich_> hi cradek
[02:04:09] <cradek> hi
[02:04:32] <jmkasunich_> "roof 2/3 done" - does that mean all the framing is done and 2/3 of it is shingled? or 2/3 of the framing?
[02:05:05] <cradek> all the framing, half the sheathing (and felt), no shingles
[02:05:30] <jmkasunich_> ah - so you will be very busy whenever there is light in the sky
[02:05:43] <cradek> yeah
[02:05:44] <jmkasunich_> you doing it all yourselves?
[02:05:49] <cradek> so far
[02:05:54] <cradek> a roofer will do the shingles
[02:06:01] <jmkasunich_> I'm impressed
[02:06:27] <jmkasunich_> when we did our garage, all I did was the electrical and install the garage door opener
[02:06:33] <cradek> don't be until it's done and I say it looks right
[02:06:50] <jmkasunich_> what about the concrete? did you contract that out?
[02:06:57] <cradek> yeah that's more our speed, but why not try it once?
[02:07:20] <cradek> yes we had the concrete done. we needed other failry extensive concrete work too
[02:07:30] <jmkasunich_> if you have the time, trying it is good
[02:07:43] <jmkasunich_> my dad built his garage, it took him all summer
[02:07:57] <jmkasunich_> my brother and I "helped", that's probably why it took so long
[02:08:18] <jmkasunich_> (I was 6, bro was 4)
[02:08:39] <cradek> haha
[02:10:29] <jmkasunich_> is the new garage attached to the house?
[02:10:38] <cradek> yes on the front of the old one
[02:10:40] <jmkasunich_> ISTR the old one (now the shop) is
[02:10:49] <cradek> right
[02:10:51] <jmkasunich_> oh, interesting
[02:11:01] <jmkasunich_> doesn't that look a bit odd?
[02:11:09] <cradek> no, it's not bad
[02:11:22] <cradek> there's room for one or two more before the street :-)
[02:11:30] <jmkasunich_> heh
[02:11:38] <jmkasunich_> at some point it would definitely start to look odd
[02:11:47] <cradek> definitely
[02:12:30] <jmkasunich_> you're keeping the rollup door between old and new, right?
[02:12:36] <jmkasunich_> (for delivery of toys)
[02:12:55] <cradek> no, we're putting a wall with double doors there
[02:13:12] <jmkasunich_> the better to keep the heat in?
[02:13:21] <cradek> yes then most of it can be a real wall
[02:13:50] <cradek> 99% of the time we'll only use one door
[02:14:50] <jmkasunich_> flat floor going through the door, or is there gonna be a threshold or something there?
[02:15:00] <cradek> flat
[02:15:10] <jmkasunich_> for the pallet jack ;-)
[02:15:11] <cradek> everything is flat to the street now
[02:15:21] <cradek> (still only 7' high though)
[02:15:43] <jmkasunich_> the new garage door is only 7'?
[02:16:05] <jmkasunich_> I'd have been tempted to get a taller door, and make the old-to-new double door extra tall as well
[02:16:06] <cradek> the existing garage door will be the new garage door
[02:16:25] <jmkasunich_> ah - frugal ;-)
[02:16:25] <cradek> there's a lot of 2x12 in the way of that
[02:17:03] <cradek> the extra few inches just isn't worth it
[02:17:29] <jmkasunich_> your next machine will be a larger lathe anyway, lathes aren't as tall
[02:18:06] <cradek> yeah the only problem I've ever had with height was the bp, and with only a day's work I managed
[02:18:39] <cradek> it would be easier today without the 2-3" step
[02:20:18] <cradek> Latest release: EMC 2.1.7
[02:20:20] <cradek> * cradek sighs
[02:20:27] <jmkasunich_> ?
[02:20:46] <cradek> I'm hoping for a release this weekend
[02:21:48] <jmkasunich_> until I "heard" folks talking in this channel earlier today, I thought the release was still weeks away
[02:22:18] <cradek> do you know of a problem or something we should wait for?
[02:22:25] <jmkasunich_> no
[02:22:38] <jmkasunich_> I've been kind of out of it, just watching
[02:23:16] <cradek> I've been testing and fixing minor bugs the last few days. I've run out of stuff that I think is wrong
[02:23:51] <jmkasunich_> what about that " '-' in the mdi box stops the spindle" thing?
[02:24:07] <cradek> I'll try it right now
[02:24:49] <cradek> works fine here
[02:24:55] <cradek> (I haven't tried it on 2.1.7)
[02:25:37] <cradek> last night I was facing with continuous jog
[02:25:47] <jepler> cradek: hi
[02:25:58] <cradek> I found to my great delight that I could poke F12 to speed up the spindle as I got nearer the center
[02:26:02] <cradek> hi jeff
[02:26:20] <cradek> (while holding down the jog key)
[02:26:22] <jepler> cradek: I have some .debs built, and the .changes files signed. but I have no idea what the procedure is for putting them on linuxcnc.org, so I stopped trying to figure it out.
[02:26:40] <cradek> do you want to work on it now?
[02:27:52] <cradek> ouch, the repo is 600MB
[02:27:57] <jepler> cradek: if you can tell me about the procedure, sure
[02:28:07] <cradek> I was thinking I would give you a copy of my scripts and the full repo (so you can rsync it)
[02:28:42] <jepler> I did a lftp 'mirror' of the repo earlier, but who knows if it will do the right thing in a subsequent rsync or whatever
[02:28:57] <jepler> 629064dists/
[02:29:17] <cradek> that matches mine
[02:30:30] <jepler> yeah but I don't know about timestamps and such
[02:30:36] <cradek> yeah
[02:31:05] <cradek> I could make a tape...
[02:31:07] <jepler> ok so assuming this is a good copy of that tree, what do I do next with the new files?
[02:31:25] <cradek> http://timeguy.com/cradek-files/emc/jepler.tar.gz
[02:31:55] <cradek> this crapola is what I've done, I'm sure there's an easier way
[02:32:37] <cradek> you need to make a dists/dapper/emc2.2 and .../emc2.2-sim
[02:32:59] <cradek> symlink or copy the kernel etc (maybe everything but emc?)
[02:33:23] <cradek> fiddle up the necessary two? conf files
[02:33:29] <cradek> fix the update-mirror script
[02:34:40] <cradek> hmm what happens when/if I want to make another 2.1 release
[02:34:59] <cradek> my rsync would delete all the 2.2 stuff
[02:35:29] <cradek> well we'll burn that bridge when we cross it
[02:36:07] <jepler> OK I think I follow all this
[02:36:26] <cradek> great
[02:36:27] <jepler> I think you'd have to rsync down the tree, then do all your stuff, then rsync it back up .. and ditto for me
[02:36:37] <cradek> yeah I bet so
[02:36:49] <jepler> I'll run this locally and see if everything goes OK.. then actually work up the 2.2.0 changelog, which will be a real blast
[02:36:58] <cradek> I'll remember to be careful
[02:37:09] <cradek> I did most of that work a while back
[02:37:15] <cradek> so it should be pretty close
[02:37:34] <cradek> don't forget to insert all the 2.1 stuff into the 2.2 branch's changelog
[02:37:50] <cradek> ... don't forget to branch
[02:37:59] <jepler> assuming we really did fix all those bugs
[02:38:17] <cradek> again, thanks for taking this over
[02:38:25] <jepler> say that again after I botch the operation
[02:38:36] <cradek> nah, you'll do a good job even if you screw it up once
[02:38:44] <jmkasunich_> he'll be especially thankfull if you botch it
[02:38:51] <jmkasunich_> cause everybody will blame you, not him
[02:39:16] <cradek> if he botches it too badly, it's probably my fault for not explaining/documenting
[02:39:49] <cradek> fwiw
http://cvs.linuxcnc.org/cvs/infrastructure/release-procedure?rev=1.1
[02:40:01] <cradek> (not worth much)
[02:40:03] <jepler> I was reading that earlier
[02:41:04] <cradek> hmm if you use that script as-is, you'll end up signing all the old repos, but people don't have your key.
[02:41:14] <cradek> so be careful to not do that I guess
[02:41:39] <jepler> but dists/dapper/Release and Release.gpg do cover 2.0, 2.1, and will cover 2.2
[02:42:00] <cradek> oh, dangit
[02:42:12] <cradek> wonder how we'll deal with that
[02:42:24] <jepler> beats me
[07:59:56] <fenn> can someone post emcinfo.pl somewhere for me?
[08:00:09] <fenn> the wiki engine
[10:35:48] <alex_joni> fenn: anything particular you have in mind?
[10:36:55] <alex_joni> fenn: you can probably get it from here:
http://www.usemod.com/cgi-bin/wiki.pl?UseModWiki/Download
[11:29:30] <alex_joni> cradek: I'm still trying to come up with a solution, but I think it would be best if we still use one signing (if you wouldn't mind..)
[11:51:17] <alex_joni> bbl, lunch
[15:47:30] <CIA-18> 03alex_joni 07TRUNK * 10emc2/docs/src/motion/tweaking_steppers.lyx: nice document on tweaking software step generating
[15:48:05] <CIA-18> 03alex_joni 07TRUNK * 10emc2/docs/src/motion/pid_theory.lyx: fix page-alignment
[15:49:00] <CIA-18> 03alex_joni 07TRUNK * 10emc2/docs/src/Master_Integrator.lyx: add software step gen doc, and fix page layout
[15:54:48] <CIA-18> 03alex_joni 07TRUNK * 10emc2/docs/src/ (Submakefile index.tmpl): add tweaking_steppers to the HTML docs
[15:55:05] <jepler> alex_joni: I was just typing something to ask you about the HTML doc portion .. thanks
[15:57:47] <CIA-18> 03jepler 07TRUNK * 10emc2/docs/src/Submakefile: additional items need to be cleaned
[16:17:50] <alex_joni> jepler: np, hope I didn't forget anything
[16:18:17] <awallin> is 2.2 coming out soon?
[16:18:37] <alex_joni> any day now :)
[16:19:28] <awallin> ok! I'd like to mess around with interactive PID tuning etc. but better leave that to later (assuming the fork for 2.2 hasn't been made already?)
[16:32:48] <alex_joni> nope, that will happen just before release
[17:24:14] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/paramsetter
[17:24:35] <jepler> example usage: loadusr paramsetter pid.0.Dgain pid.0.FF0 pid.0.FF1 pid.0.FF2 pid.0.Igain pid.0.Pgain pid.0.bias pid.0.deadband
[17:24:57] <jepler> it creates pins like paramsetter.pid.0.Dgain and when their values are changed it sets the parameter a short time later using halcmd
[17:28:09] <alex_joni> so it's a pin<-> param converter?
[17:40:16] <jepler> one-way only (to set parameters)
[17:42:02] <jepler> bbl
[17:42:54] <tomp> urf! i type too slow, he left can it change the param after its been set ( iterative use )?
[17:57:41] <jepler> yes that's the idea -- when the pin value is changed, a short time later the parameter is set
[18:00:00] <jepler> http://www.pillsbury.com/view/breads/crescent_rolls.aspx <-- apparently the old-fashioned pillsbury crecent roll (which you had to roll up yourself) is now too difficult and time-consuming for consumers. Introducing new "Place `n Bake Crescent Rounds" "now made *even simpler*"
[18:12:48] <awallin> jepler: that's a nice utility, will allow pyvcp control of PID parameters. a bit of a workaround though...
[18:13:18] <alex_joni> I think the nices thing will be to replace all params with pins
[18:13:22] <alex_joni> (but that will be 2.3)
[18:14:15] <awallin> ok
[18:14:45] <alex_joni> this is nice:
http://www.dynamism.com/oqo2/main.shtml
[18:17:32] <awallin> alex_joni: hmm, wonder if it would hold up as your only work machine
[18:17:41] <awallin> if not, it
[18:17:49] <awallin> s just another gadget to carry around
[18:20:50] <alex_joni> awallin: it would probably work instead of my laptop
[18:21:05] <alex_joni> but then again, I doubt it can run emc2 inside vmware
[18:21:36] <awallin> right. what I meant I
[18:21:44] <awallin> damn this enter key...
[18:22:08] <awallin> I meant I wont carry around a phone, a laptop, and this one. that's three things, one too many
[19:10:03] <CIA-18> 03jepler 07TRUNK * 10emc2/debian/changelog:
[19:10:03] <CIA-18> add release notes from 2.1 series
[19:10:03] <CIA-18> don't note again in 2.2.0 release notes things that were added in 2.1 series
[19:10:03] <CIA-18> several small rewordings
[19:20:52] <CIA-18> 03jepler 07v2_2_branch * 10emc2/debian/changelog: note the ALPHA QUALITY nature of pluto_step
[19:20:52] <CIA-18> 03jepler 07v2_2_branch * 10emc2/src/hal/drivers/pluto_step.comp: note the ALPHA QUALITY nature of pluto_step
[19:22:28] <CIA-18> 03jepler 07v2_2_branch * 10emc2/VERSION: bump for release
[19:23:48] <CIA-18> 03jepler 07v2_2_branch * 10emc2/VERSION: bump version after release
[19:24:02] <alex_joni> YAY :)
[19:24:16] <cradek> wheeee
[19:28:03] <CIA-18> 03alex_joni 07TRUNK * 10emc2/VERSION: we now have v2_2_branch, this is pre-2.3
[19:28:38] <awallin> so now can we changes PID params to pins? ;)
[19:28:49] <alex_joni> awallin: yup :)
[19:29:45] <awallin> I'll probably look at PID tuning next week, might do some pyvcp stuff also if I get inspired
[19:29:56] <alex_joni> good
[21:58:39] <alex_joni> * alex_joni heads to bed
[21:58:42] <alex_joni> good night all
[21:58:56] <alex_joni> jepler: thanks for 2.2.0
[22:20:42] <skunkworks> that is cool - when your logged into linuxcnc.org - it automagically puts your user name in for the irc client.
[22:20:51] <skunkworks> alex_joni: you around?
[22:22:49] <jepler> goodnight alex, I hope 2.2.0 will be a decent version
[22:22:57] <skunkworks> jepler: thanks
[22:22:57] <jepler> you know, the kind where the next bugfix release can wait all the way until the next week-end
[22:23:01] <jepler> hi skunkworks
[22:23:21] <jepler> skunkworks: 2.2.0 is ready, except the packages aren't on the servers yet..
[22:23:45] <skunkworks> I have some new old hardware at work to test when it is ready
[22:24:45] <jepler> bbl
[22:59:46] <fenn> it would be nice to change ALL parameters to pins, and keep the distinction so things dont get so cluttered
[23:00:01] <fenn> i mean make it so you can read/write to a parameter in realtime
[23:00:46] <SWPadnos> I was thinking it would be nice to be able to add a pin type to the show command
[23:00:53] <SWPadnos> like show pin bit stepgen
[23:01:11] <fenn> its sorta like that with tab-completion right?
[23:01:26] <SWPadnos> nope, you still get all types of pin
[23:01:29] <SWPadnos> but it is nice
[23:01:39] <fenn> i remember something works based on pin type
[23:01:49] <SWPadnos> yes, link* and net
[23:02:09] <SWPadnos> linksp <something> will only complete pins of the type of <something>
[23:03:51] <fenn> what about just "show bit stepgen"
[23:04:18] <SWPadnos> sure, if pins and params are combined, then the type would make sense that way
[23:04:42] <SWPadnos> something like "show unconnected pins" would also be cool
[23:06:32] <fenn> i was thinking a good way to do a hal gui is a tree view in each component box, that dynamically resizes the box and has a "bus" going to the top level or multiple buses or nets to each node/leaf
[23:06:53] <fenn> so its more like dangly wire bundles than circuit board traces
[23:07:09] <SWPadnos> hmmm
[23:07:21] <SWPadnos> I wonder if that would be more intuitive for users?
[23:07:38] <fenn> there's too much on the screen otherwise
[23:07:56] <SWPadnos> yeah, schematics can definitely get pretty big pretty fast
[23:09:59] <SWPadnos> one concept that would be nice (if I may use the name of LabView in a positive way), is the "bundle"
[23:10:14] <fenn> right, i'm looking for something about that
[23:10:26] <SWPadnos> it basically combines a group of wires, similar to a bus but not necessarily all the same type
[23:11:05] <jepler> afaik HAL names can include punctuation.. pick one: net X/step ? net X:step ? X'step ? X@step ?
[23:11:06] <SWPadnos> for those things that have a canonical interface, you'd just plug the "encoder" into the "axis", and that would be all
[23:11:44] <SWPadnos> jepler, for what? (I don't understand what you're answering there :) )
[23:11:56] <jepler> then you just modify the graphical tools (er, write them I mean) to show all the things with the same prefix as a bus or bundle
[23:12:01] <SWPadnos> ah
[23:12:33] <SWPadnos> I'm not sure that would do it
[23:12:58] <fenn> this is kinda what i was thinking (the wire bundling part)
http://graphics.uni-konstanz.de/publikationen/2007/clustered_graphs/Balzer et al. -- Level-of-Detail Visualization of Clustered Graph Layouts.pdf
[23:13:16] <SWPadnos> a servo system would have a PID that connects to the encoder, plus the output path, and they'd all logically want the same prefix, but they shouldn't be in the same bundle
[23:13:28] <SWPadnos> 404
[23:13:34] <SWPadnos> ah - broken URL
[23:13:59] <jepler> http://graphics.uni-konstanz.de/publikationen/2007/clustered_graphs/Balzer%20et%20al.%20--%20Level-of-Detail%20Visualization%20of%20Clustered%20Graph%20Layouts.pdf
[23:16:29] <SWPadnos> ok, I'm running LabView so I can take a screenshot. if I lose the connection, you'll know why
[23:16:31] <fenn> so wires would be bundled if the tree is closed, and they would separate when you open the tree up for viewing
[23:23:58] <fenn> death by labview
[23:24:04] <SWPadnos> almost daead
[23:24:05] <SWPadnos> dead
[23:28:08] <SWPadnos> http://www.cncgear.com/images/LV%20Wire%20Types.png
[23:28:57] <SWPadnos> one thing LabView is actually very good at is diagramming (unfortunately, that's also how you program with it, so it sucks a lot overall)
[23:30:06] <SWPadnos> so the idea is to have a single "wire" shown when someone does the single logical operation of connecting their encoder to the PID feedback (even though there may be several individual HAL signals that are connected)
[23:31:10] <SWPadnos> the box labeled "Boolean Text.font" is a cluster constant, which would also be applicable for something like a full set of axis parameters
[23:31:13] <SWPadnos> (scale, limits, etc)
[23:36:01] <fenn> they just look like lines to me :\
[23:36:21] <SWPadnos> exactly, though somewhat differentiated by thickness, style, and color
[23:36:42] <SWPadnos> the idea is that you are connecting one "thing", it doesn't matter how many little pieces that thing is composed of
[23:37:07] <fenn> oh so you're plugging the whole thing in at once
[23:37:17] <SWPadnos> yes
[23:37:47] <fenn> i'm talking about variable level of detail stuff
[23:37:50] <SWPadnos> if I had some component that output a "text style" bundle, I could connect it to that text style input (on multiple components, if I wanted to change them all at once), and it would still be one line
[23:37:54] <fenn> no change in the core hal functionality
[23:39:12] <fenn> i dont think anyone messes with hal files that often do they?
[23:39:29] <fenn> usually whoever is doing it is doing it for the first time
[23:40:00] <fenn> or they are looking at a demo file
[23:40:09] <SWPadnos> for a graphical tool, it would be kind of confusing to see the twenty or so connections you get for each axis
[23:40:44] <SWPadnos> since it's really composed of only a few logical things: position output, position feedback, jogwheel (? else)
[23:42:05] <fenn> as opposed to what?
[23:42:24] <SWPadnos> oh - I don't know. how many pins are there for each axis?
[23:43:17] <fenn> about 15 pins and 20 params
[23:43:46] <SWPadnos> ok - how many different functions do those pins provide? (I'm asking because I don't have an emc-capable machine turned on at the moment)
[23:44:12] <fenn> most of the pins dont really need to be pins
[23:44:23] <fenn> i mean they should be somewhat hidden
[23:45:30] <fenn> http://pastebin.ca/761586
[23:45:49] <SWPadnos> hmmm. I don't think I was suggesting (this time) that HAL should have bundle support. a GUI tool should, but it can still be several connections in the .hal file
[23:46:42] <fenn> i just cant think of any cases where it would be worth the effort to learn how to do that
[23:46:52] <fenn> doesn't mean i'm right though
[23:47:10] <SWPadnos> well, you and I know how to edit text files, and what HAL stands for :)
[23:47:25] <SWPadnos> I'm not sure either of us is qualified to decide what's best for a novice ;)
[23:49:11] <fenn> seems the ability to repeat a pattern multiple times would be more useful (well for hexapod users at least :)
[23:49:21] <SWPadnos> heh
[23:49:44] <fenn> or is that what you're suggesting?
[23:49:52] <SWPadnos> sort of, yes
[23:50:15] <SWPadnos> even a bundle that has the +/- limit switch inputs is somewhat useful
[23:50:38] <SWPadnos> it would have to be two connections at the I/O (if they're separate), but it's one logical connection to the motion controller - limits
[23:51:16] <SWPadnos> that may need some higher level information though - like a checkbox for "home is shared" or "home is -limit"
[23:51:30] <fenn> you could use a 'net' tool and a 'bus' tool
[23:51:53] <SWPadnos> I guess the idea of a DAC / ADC / encoder bundle isn't all that useful, because there's really only one active pin - the resta re parameters
[23:52:04] <SWPadnos> except for an encoder, which ahs teh index RW connection
[23:52:09] <fenn> so the bus would connect your signal to all of the similarly named pins as the one you clicked on
[23:52:27] <SWPadnos> yeah, I had thought about that
[23:52:46] <SWPadnos> though index and index-enable are generally connected between motion and encoder
[23:53:05] <fenn> that's probably one of those problems that's easy for a human to do but a computer will always get it wrong
[23:53:09] <SWPadnos> yep
[23:53:15] <SWPadnos> more than half the time, anyway
[23:53:34] <fenn> yeah, always, like i said :)
[23:53:42] <SWPadnos> right :)
[23:54:36] <SWPadnos> this of course brings up the concept of configuration, which leads me to the unfortunate realization that we should revamp the way config data is handled before going too far with GUI tools
[23:54:36] <fenn> ok its bedtime for me
[23:54:41] <SWPadnos> night
