Back
[00:17:59] <jepler> hm -- I bet emc2-sim + emc2-dev built for RT don't play well together
[00:18:27] <cradek> they both have the same source package too, it's a bit of a mess
[00:19:07] <jepler> hm, yuck
[00:19:12] <jepler> maybe I didn't adequately think it through
[00:19:26] <cradek> seems like it should build both from one source package
[00:19:45] <jepler> m-m-m-maybe
[00:20:53] <cradek> should I not distribute the emc2-sim packages since there isn't 100% exact corresponding source?
[00:21:43] <cradek> well it IS the exact source, but it will build for realtime, not sim, if you apt-get -b source
[00:22:33] <SWPadnos> can there be a "package config" kind of file that gets copied to the build dir (and contains options for ./configure)?
[00:23:15] <SWPadnos> with the first question being - can that boe done with configure (look for a file, and add any options listed in the file as though they had been supplied on the command line)
[00:24:35] <cradek> I've taken those two -sim packages out of the repos
[00:25:02] <cradek> anyone can build them if they want
[00:25:23] <cradek> but I'm not happy distributing a binary package unless apt-get -b source reproduces it
[00:26:58] <SWPadnos> it can be built with one command by making a script do the work. if the two packages can have different scripts (or none for the RT version), then that should work? (shouldn't it?)
[00:27:22] <SWPadnos> so they would be the same source, but slightly different source packages
[00:27:51] <cradek> different source packages (tars) with the debina/ directory configured properly in each, would be fine
[00:28:06] <cradek> it's just not set up to generate that right now
[00:28:13] <SWPadnos> ok
[00:28:48] <cradek> and I don't think it's a big enough deal to risk messing with it
[00:28:59] <SWPadnos> probably not
[00:29:11] <cradek> sim is nice for developers. I don't see much need for anyone else.
[00:29:24] <SWPadnos> well, preview is nice for anyone
[00:29:31] <cradek> other architectures, maybe, but our packages are useless for them anyway
[00:29:34] <SWPadnos> be it toolpath or metal remaining
[00:29:49] <cradek> you can preview with the realtime system just as easily as the sim
[00:30:06] <SWPadnos> right, but sim is better for previewing on non-machine-controller computers
[00:30:23] <cradek> I don't see why
[00:30:35] <cradek> unless they are a different platform, making our debs useless
[00:30:37] <jepler> consider SWP's quadricle 128
[00:30:43] <SWPadnos> well, for one thing, I can do it on amd64 / SMP / edgy computers ...
[00:30:43] <jepler> but I guess you just said you don't build a package for him
[00:30:46] <SWPadnos> heh
[00:30:48] <cradek> right
[00:30:56] <cradek> he's gonna have to compile it anyway
[00:30:56] <jepler> the package wouldn't run on edgy, either
[00:31:04] <SWPadnos> no problem - it only takes 20 seconds ;)
[00:32:01] <cradek> he can build sim on his neganon 6000 if he wants, or I'll build it for him if he buys me one
[00:32:36] <SWPadnos> I guess the number of people running Ubuntu, not on their controller PC, who want to do G-code preview is small
[00:33:09] <cradek> there's little to no drawback to installing the realtime stuff
[00:33:29] <cradek> for better or worse, I bet people tend to get it anyway, since they use our cd
[00:33:42] <SWPadnos> availability is the main one, but since there are no packages for Edgy / Feisty / RH, Suse, Slackware ..., it doesn't really matter
[00:33:43] <jepler> you might lose your wireless network card, you'll get an ugly pop-up since your machine can't handle realtime, ...
[00:33:50] <SWPadnos> you can't shut down
[00:33:54] <jepler> the RT kernel is a complete PITA on any laptop
[00:33:56] <SWPadnos> or tell battery remaining ...
[00:33:56] <cradek> "little"
[00:33:59] <cradek> heh
[00:34:06] <jepler> that's not "little"
[00:34:32] <cradek> jepler: worksforme
[00:34:44] <SWPadnos> mr. non=laptop-user :)
[00:34:49] <cradek> no, on my laptop
[00:34:52] <SWPadnos> oh. bastid
[00:35:04] <cradek> it's the noptetrons that are the problem
[00:35:12] <jepler> his laptop sucks anyway
[00:35:19] <cradek> hey
[00:35:23] <SWPadnos> my P3 laptop doesn't do so well either
[00:35:50] <cradek> well, if someone wants to fix emc2-sim in trunk, maybe we can backport it
[00:36:09] <cradek> I'm hesitant to mess with it
[00:36:11] <cradek> hi skunkworks
[00:36:20] <skunkworks> Hi. Internet is back up here
[00:36:27] <jepler> I may look at it, but I won't campaign for a back-port unless I'm very confident
[00:36:27] <skunkworks> finally
[00:36:42] <jepler> * jepler wanders off
[00:36:45] <cradek> jepler: that's great by me
[00:37:00] <SWPadnos> see ya later
[00:38:32] <jepler> what about having a different repo: deb
http://www.linuxcnc.org/emc2/ dapper emc2.1-sim
[00:39:04] <cradek> I could sure do that as-is
[00:39:23] <SWPadnos> I think a single repo is better, but I'm not the one doing the work ...
[00:39:50] <cradek> this would let us do it wihtout messing with the packaging stuff
[00:56:07] <cradek> done
[01:28:46] <fjungclaus> Oh, it's silent night here :-) Every one tired from the last busy emc weekend??? :-)
[01:29:36] <cradek> yes I think so
[01:30:26] <fjungclaus> But (since we have 02:30 AM local time here) I'm on the way to bed, too ...
[01:30:35] <fjungclaus> Hi, Chris!
[01:30:41] <cradek> goodnight
[01:30:49] <cradek> hi!
[01:32:40] <fjungclaus> Ah, yes, one more question :) Is it possible to explain in a short sentence what was the (historic) reason for having axis.tcl beside of axis.py???
[01:33:44] <fjungclaus> Or do I have to ask this to Jeff?
[01:33:49] <cradek> we started by trying to use a screen builder. when that didn't work out, we kept them separate
[01:34:44] <cradek> also tk still seems most easily/naturally programmed in tcl
[01:34:57] <cradek> jepler may have other reasons
[01:37:18] <fjungclaus> Ok, someday I ask jepler, too. I would have choosen something like Python together with one of QT / wxWidgets / GTK ...
[01:38:04] <cradek> ok, I think he'll just tell you he's most comfortable with tk
[01:38:17] <fjungclaus> TK (with it's look and feel + amount of widgets) is to old fashioned (from my point of view)
[01:39:02] <cradek> it's true that it does look older
[01:39:08] <fjungclaus> I programmed some thousand line Tcl/TK, but this was 13 (!!!) years ago ...
[01:40:11] <fjungclaus> But it's still doing it's job and processors are now fast enough ...
[01:40:58] <fjungclaus> My TCL/TK application 13 years ago was horribly slow on a amd486 :-)
[01:41:28] <cradek> aha, they are a little faster now.
[01:42:29] <jepler> even a few years ago, Tkinter was standard and advanced bindings like pygtk were not easily available. that's another reason I chose Tkinter
[01:42:44] <jepler> (on redhat 9; people on debian systems probably had it available)
[01:43:17] <fjungclaus> Hi, Jeff!
[01:43:16] <jepler> I tried wxpython for a bit, but never grew to like its API.
[01:44:07] <fjungclaus> Ok. So QT/GTK or something like that is for the next generation axis, 5 years in the future ....
[01:45:23] <jepler> if I was doing it again, I think I'd take a crash course in pygtk and use that
[01:45:30] <cradek> I doubt either of us has any energy left for a rewrite
[01:45:55] <cradek> I think I will just use it as-is for a long time, now that it's fairly functional
[01:46:53] <fjungclaus> fairly functional: yes, indeed, I agree to that!!! you both did a good job!
[01:47:00] <cradek> thank you
[01:47:32] <cradek> and thanks again for your improvements
[01:47:48] <fjungclaus> Are there planning to integrate gdepth to axis?? Or do you think this does not really match into axis?
[01:48:38] <cradek> I think the gdepth preview could not be a replacement display, but it could be run from a menu as a secondary program
[01:49:19] <jepler> I have a feeling gdepth would make the refresh rate too slow on most computers to be useful
[01:50:09] <cradek> yeah it can't replace the (very fast) line preview
[01:51:27] <fjungclaus> So, how slow is gdepth? Did give it a try yet. Only have seen the very promising screenshots ...
[01:51:35] <fjungclaus> So, how slow is gdepth? Did NOT give it a try yet. Only have seen the very promising screenshots ...
[01:51:55] <cradek> something like a minute to generate the view
[01:52:42] <fjungclaus> 1 minute oh .... no, then we have o wait for faster CPU :-)
[01:53:05] <cradek> I think it's ok to wait a minute for a nice preview.
[01:53:45] <cradek> imagine File/Preview on the menu
[01:54:05] <cradek> you would only use it when you want to
[01:54:10] <fjungclaus> But if see how fast some cam tools can draw such previews, I think there's some space left for optimisations to the gdepth code?
[01:54:19] <cradek> of course
[01:54:37] <fjungclaus> Or is this just the tribute for using interpreted python code?
[01:54:50] <cradek> however with a machine that runs EMC, you are probably not going to have accelerated opengl.
[01:55:00] <fjungclaus> File/Preview sounds good!
[01:55:02] <cradek> so there's a fundamental problem.
[01:56:28] <fjungclaus> No acc. opengl here ... simply a good old matrox 450 ...
[01:56:57] <cradek> yeah something like gdepth will be slow then. lots of triangles.
[01:57:56] <fjungclaus> BTW, the matrox xorg-driver is causing interference with rtai ... I sometimes get somewhat like "unexpected realtime delay" when heavily moving around windows ...
[01:58:07] <cradek> yuck
[01:58:17] <cradek> with emc2.1?
[01:58:19] <fjungclaus> So this problem is well known!?
[01:58:33] <cradek> yes lots of hardware causes that problem
[01:58:58] <cradek> there is more detail in your dmesg, so you can see how bad it is
[01:59:48] <fjungclaus> I think this is definetly not an emc problem ... running rtai latency without emc and moving around any windows in a fast manner show some problems too ...
[02:00:22] <cradek> that's good to know
[02:00:29] <fjungclaus> The solution is not to move around windows while my machine is running :-)
[02:00:53] <cradek> that's one solution I guess!
[02:01:28] <cradek> it can be hard to get a machine to work perfectly with realtime
[02:01:39] <fjungclaus> cradek: no, not emc-2.1 ... I'm on "pre-2.2 CVS HEAD" on edgy eft
[02:01:47] <cradek> ok
[02:02:56] <fjungclaus> I would have given emc-2.1 a try, so test out your very hard work from the weekend, but I fear it won't work with edgy ...
[02:04:08] <cradek> you could compile the release yourself from cvs, but since you're doing development, I think you're better off using the trunk anyway
[02:04:27] <cradek> a few hints about latency problems here:
http://rtai.dk/cgi-bin/gratiswiki.pl?Latency_Killer
[02:04:58] <fjungclaus> Not using the matrox driver and simply using the standard vesa xorg-driver doesn't show the problem to ... but the vesa driver is slow compared to the matrox one
[02:05:26] <cradek> jepler has to use the vesa driver too, and it is slow
[02:05:40] <fjungclaus> cradek: ok, I'll check your link and hope the xorg-guys will fix this problems sooner or later ...
[02:08:03] <cradek> https://mail.rtai.org/pipermail/rtai/2005-January/010050.html
[02:08:07] <fjungclaus> On my opinion this one this biggest problems with linux: no fixed binary interfaces for kernel stuff and others ... new API's for everything and every month ... they're still adapting old drivers to these
[02:08:22] <cradek> I wonder if this is slower or faster than the vesa driver
[02:08:40] <fjungclaus> new API's but they aren't carefully enough with testing these old drivers
[02:09:26] <fjungclaus> The maxtrox driver is defnitely faster then the vesa driver!!!!
[02:09:51] <cradek> yes but someone else said the framebuffer X driver (??) also lets RTAI work right
[02:09:57] <cradek> I wonder if FB or vesa is faster
[02:10:08] <jepler> FB will also be unaccelerated, won't it?
[02:10:24] <cradek> yes
[02:10:51] <fjungclaus> Did not test frame buffer yet ...
[02:14:11] <fjungclaus_> Before my head will punch on the keyboard and I fall asleep, I'll start a second attemp to find my bed now :-) ... 03:10 AM localtime now ...
[02:14:21] <jepler> goodnight again
[02:14:23] <cradek> goodnight
[02:14:37] <fjungclaus_> If someone of you is bored, he can try my latest history changes on trunk :-) The also copy/past (special feature for SWP)
[02:14:51] <fjungclaus_> good night! CU
[02:16:00] <fjungclaus_> If someone of you is bored, he can try my latest history changes on trunk :-) There's also copy/past (special feature for SWP) .... I definetly need a spell checker for my irc-client :-))))
[02:16:25] <fjungclaus_> Grrrr ... If someone of you is bored, he can try my latest history changes on trunk :-) There's also copy/paste (special feature for SWP) .... I definetly need a spell checker for my irc-client :-))))
[02:16:38] <cradek> close enough!
[02:16:38] <fjungclaus_> away ...
[02:16:40] <cradek> goodnight
[02:30:57] <fjungclaus__> fjungclaus__ is now known as fjungclaus
[02:31:52] <fjungclaus__> fjungclaus__ is now known as fjungclaus
[02:32:41] <fjungclaus_> fjungclaus_ is now known as fjungclaus
[03:28:58] <jmkasunich> hi
[03:30:10] <jmkasunich> jepler: tristate_bit seems fine to me - as cradek said, its not something we need now, but it could easily have uses in the future
[03:30:20] <jmkasunich> tristate_float might be even more usefull
[03:30:32] <jmkasunich> then you could make an N input mux kind of thing
[03:30:54] <jepler> actually I did like 'conv' and wrote a template that can be replaced by the individual type names
[03:30:57] <jmkasunich> I'd probably drop the params for the float version
[03:31:07] <jepler> just base it on 'enable'?
[03:31:10] <jmkasunich> yeah
[03:31:17] <jepler> I am not sure if those params are the most useful
[03:31:25] <jmkasunich> actually, I already have a use for the float version
[03:31:41] <jmkasunich> suppose you want three buttons to select x1, x10, x100 for jogwheel increments
[03:32:04] <jmkasunich> let the butttons enable three tristate-floats, each with its input set to the relevant scale factor
[03:32:19] <jmkasunich> wires the outputs together and send to the jogwheel-scale pin
[03:32:29] <jmkasunich> (use radio buttons)
[03:32:36] <jepler> I guess that saves the decoding in HAL
[03:33:08] <jmkasunich> yeah - otherwise you need to decode the three buttons to a pair of bits for a mux4
[03:33:20] <jmkasunich> and what if you want to use 5 settings, from x1 to x10K?
[03:33:47] <jepler> here's the code for the 'float' version, with enables:
http://emergent.unpy.net/files/sandbox/tristate_float.comp
[03:34:03] <jepler> it gets very simple if you want only the explicit enable pin
[03:34:49] <jepler> if(enable) out = in_;
[03:34:48] <jmkasunich> the idea of detecting change and/or zero on an analog signal bugs me
[03:35:01] <jepler> yep -- it is a bad generalization
[03:35:02] <jmkasunich> because real analog signals are always changing and never 0.00000000.....
[03:35:22] <jmkasunich> so for float I have a moderately strong preference for the enable only version
[03:35:37] <jepler> I don't think those enable params even match what you really want for bit, let alone the other types
[03:35:49] <jmkasunich> for bit I can see the merit of the params
[03:35:55] <jmkasunich> you can make an open collector (sort of)
[03:36:04] <jepler> IMO you're more likely to want enable-on-positive-edge or enable-on-negative-edge
[03:36:36] <jmkasunich> I'm tempted to say leave the params out
[03:36:58] <jmkasunich> and make an open-collector-bit that writes to out when in is low
[03:37:04] <jmkasunich> or something like that
[03:37:50] <jmkasunich> switching topics
[03:37:55] <jepler> maybe start with 2 tristate components with only the one explicit enable -- bit and float
[03:38:02] <jepler> switch away
[03:38:01] <jmkasunich> yeah
[03:38:14] <jmkasunich> on the "streamer as toolchange" thing
[03:38:27] <jmkasunich> I'm 100% in favor of the handshake option for streamer
[03:38:45] <jmkasunich> the larger part of that idea is gonna need some hashing out
[03:38:57] <jmkasunich> I suspect many folks will rebel at the idea of doing it on HAL
[03:39:18] <jmkasunich> and there are other complexities
[03:39:41] <jepler> yeah there are bound to be a lot of complexities
[03:39:41] <jmkasunich> for instance, the "grid of tools" toolchange, will need a different position (or a couple) in the sequence, depending on the tool number
[03:39:54] <jmkasunich> so either multiple streamer files, or on-the-fly ones
[03:39:56] <jepler> that's why I say that I expect the integrator will have to write a special-purpose component
[03:40:25] <jmkasunich> I suspect that a lot of the logic for a changer will be done in CL
[03:41:01] <jmkasunich> and cl bits might be used to send one of N target positions to the motors
[03:41:12] <jepler> yeah that sure would be one way
[03:41:22] <jmkasunich> everybody is gonna have their own approach
[03:41:28] <jmkasunich> depending on the tools they like
[03:41:44] <jmkasunich> lerman is an interp guy, so of course he favors g-code
[03:41:52] <jepler> yep
[03:41:53] <jmkasunich> I'm a hal guy, so I like a hal approach
[03:42:09] <jmkasunich> I hope we can get some good discussion going
[03:42:23] <jmkasunich> but I have a feeling the entire thing is complex enough that it will kind of peter out
[03:42:33] <jepler> I think I started back at preferring the g-code approach, but on the other hand I fear that the current interp is not set up to make stuff like "wait for pin to go TRUE" easy
[03:42:37] <jmkasunich> and we'll wind up with several incompatible ad-hoc solutions
[03:43:18] <jepler> you are familiar with the free planner (is that the right term?) -- what is your guess about whether it can be used during the middle of running a g-code program?
[03:43:31] <jmkasunich> sure
[03:43:48] <jmkasunich> (the planner itself is unused at that time
[03:44:34] <jmkasunich> that planner is the only piece of the "tp" that I understand well
[03:44:43] <jmkasunich> quotes, because it isn't really part of the tp
[03:44:45] <jepler> I think I I heard a rumor that you wrote it
[03:44:47] <jmkasunich> heh
[03:45:12] <jmkasunich> recently I was second guessing my decision to pull free mode out of the main TP though
[03:45:44] <jepler> what happens with the free planner if its goalposts keep moving -- does it do a nice within-machine-limits attempt to reach the goal position?
[03:45:51] <jmkasunich> yes
[03:46:08] <jmkasunich> hmm, the link to the hal manual at linxcnc.org is busted
[03:46:12] <jepler> uh oh
[03:46:15] <jmkasunich> http://linuxcnc.org/docs/HAL_Documentation.pdf
[03:46:29] <jepler> I'll look into that, then I'm away for the night
[03:46:47] <jmkasunich> actually, thats the wrong doc anyway
[03:47:06] <jmkasunich> I think I want the dev manual
[03:47:14] <jmkasunich> where are the autobuilt docs again?
[03:47:26] <jepler> http://linuxcnc.org/docs/2.1/
[03:47:33] <jmkasunich> (seems like a link to those otta be on the main docs page)
[03:47:53] <jmkasunich> ah, I see the problem with the hal link
[03:47:55] <jmkasunich> 2 actually
[03:47:57] <jmkasunich> adding 2.1
[03:48:04] <jmkasunich> and HAL_Documentation vs. HAL_User_Manual
[03:48:09] <jepler> yes
[03:48:12] <jepler> actually I created a symlink to fix it up
[03:48:47] <jmkasunich> have you looked at fig 3.1 in the dev manual?
[03:49:01] <jepler> no
[03:49:16] <jmkasunich> take a quick look - its relevant to the "can we use the free mode planner" thing
[03:50:05] <jepler> hm -- "free mode" implies working in joint space?
[03:50:10] <jmkasunich> yeah
[03:50:21] <jmkasunich> that whole "joint controller" is a joint mode thing
[03:50:23] <jepler> I guess I mean "teleop" then
[03:50:28] <jmkasunich> every axis is independent at that point
[03:50:41] <jepler> I don't think I want joints
[03:50:52] <jmkasunich> oh, you're right... because they're gonna want tool coords in cartesean space
[03:51:33] <jmkasunich> you need to do the moves upstream of the kins, so they are coordinated
[03:51:46] <jepler> * jepler wrinkles his nose
[03:51:51] <jepler> darn it's not simple like I thought
[03:51:56] <jepler> anyway -- goodnight
[03:52:00] <jmkasunich> goodnight
[03:52:07] <jmkasunich> NEFS
[03:52:09] <jepler> man you wrote a lot of good documentation, I'm sure I still haven't read it all
[03:52:52] <jmkasunich> I just scratched the surface though - I only documented the parts I know, which ain't all that much in the big picture
[03:54:50] <jmkasunich> damn I wish I had called the motmod axis.N.foo pins joint.N.foo.....
[04:17:02] <cradek> any reason not to change it today?
[04:17:34] <jmkasunich> busting everybodys configs when 2.2 comes out?
[04:17:51] <jmkasunich> plus busting everybody who's running CVS head?
[04:18:07] <cradek> wonder if 2.2 will be a long or short release - and whether we'll bust configs in a dozen other ways too
[04:18:37] <jmkasunich> I'd certainly consider making the change for 2.2
[04:18:54] <jmkasunich> but not literally "today" as in without a discussion or anything
[04:19:00] <cradek> today, unlike a week ago, we can be a lot more bold adding new features and breaking things
[04:19:07] <cradek> sure
[04:19:11] <jmkasunich> I do hope to bust things for 2.2
[04:19:18] <jmkasunich> I'd like to move to the instance model for hal
[04:19:22] <cradek> heh that's an easy goal
[04:19:45] <cradek> I'd actually like a summer 2.2 release - maybe right after fest
[04:19:52] <jmkasunich> where you don't do "loadrt foo cfg_array="bunch,of,data"
[04:20:06] <cradek> that would be nice
[04:20:25] <jmkasunich> instead you do loadrt foo; newinst foo cfg=bunch; newinst foo cfg=of
[04:20:25] <jmkasunich> etc
[04:21:02] <jmkasunich> with options, so when you do newinst not, you by default get "not.N", where N autoincrements
[04:21:08] <jmkasunich> but you can specify a differnet name
[04:21:19] <jmkasunich> like "limit-sw-inverter"
[04:21:35] <cradek> did jepler put in newinst and then take it out? I remember seeing something like this
[04:21:40] <jmkasunich> yes
[04:21:50] <cradek> did it not work right?
[04:21:50] <jmkasunich> the implementation only worked in sim, IIRC
[04:21:55] <cradek> oh
[04:22:01] <jmkasunich> and there were other issues - it wasn't fully thought out
[04:22:15] <jmkasunich> so we agreed to defer it
[04:23:04] <jmkasunich> you know that big electrical box I got for the shoptask?
[04:23:08] <jmkasunich> its filling up scary fast
[04:23:07] <cradek> sure
[04:23:21] <cradek> I remember you knew that would happen
[04:23:33] <cradek> is everything going to fit?
[04:23:43] <jmkasunich> I just laied it on its back and started sticking things in there, sliding them around, etc
[04:23:50] <jmkasunich> I'll make it fit
[04:24:00] <jmkasunich> but I'm afraid it won't be pretty
[04:24:55] <jmkasunich> I gotta grind off the other two panel mounting studs, that will help a little
[04:25:21] <jmkasunich> (but its late and my wife is asleep - dremeling thru a 3/8" stud mounted to a sheet metal resonator won't make her happy
[04:25:42] <cradek> haha
[04:27:19] <jmkasunich> hmm... wish I had a way to measure airflow
[04:28:09] <jmkasunich> and pressure
[04:30:43] <jmkasunich> man.. the internet is more than willing to sell me junk exactly the same as the junk I already have... but specs for the junk? forget it.
[05:01:48] <cradek> haha
http://timeguy.com/cradek-files/emc/g64p.1.png
[05:05:55] <cradek> "OK if that's what you really want" </emc>
[05:08:27] <jmkasunich> heh
[05:08:51] <cradek> it looks like me trying to do a coloring book
[05:09:24] <jmkasunich> Stay inside the lines.
[05:09:27] <jmkasunich> What lines?
[05:10:20] <jmkasunich> my 1995 era potential spindle VFD is 3/8" too wide to mount edgeways in the cabinet (which would save a ton of space)
[05:10:35] <cradek> arg
[05:11:00] <jmkasunich> 9.25 x 16 x 4
[05:11:09] <jmkasunich> it it was 8.9 it would fit
[05:11:16] <cradek> did you say you got your motors?
[05:11:16] <jmkasunich> if it was
[05:11:23] <jmkasunich> the steppers - yes
[05:11:34] <cradek> have geckos yet?
[05:11:44] <jmkasunich> yeah, had those for several months
[05:12:09] <jmkasunich> its tempting to wire everything up on the bench and spin them
[05:12:14] <cradek> yeah no kidding
[05:12:18] <cradek> I wouldn't be able to resist
[05:12:27] <jmkasunich> I'll do it sooner or later
[05:12:32] <cradek> heck I'd probably never finish the box
[05:12:39] <cradek> maybe your way is better :-)
[05:12:42] <jmkasunich> but I know that slapped together wiring leads to blown up drives
[05:12:54] <cradek> yep
[05:12:56] <jmkasunich> and I don't have enough bench space
[05:13:10] <cradek> 11:15!?
[05:13:15] <cradek> how the heck does that happen
[05:13:21] <jmkasunich> time flies when you're having fun
[05:13:43] <cradek> I'm having fun playing with the (perfectly working) 2.1 emc
[05:14:10] <cradek> I think this is going to be another good run.
[05:14:18] <jmkasunich> I hope so
[05:14:41] <cradek> well goodnight, morning comes fast
[05:14:45] <jmkasunich> goodnight
[05:14:59] <jmkasunich> I should be going to be soon too
[16:50:55] <SWPadnos> nice post there, Ray
[16:54:00] <rayh> thanks
[16:55:26] <SWPadnos> someone had mentioned the idea of making most (if not all) g-codes into "macro calls" - that may be a good solution for a number of problems
[16:55:32] <SWPadnos> and of course the source for a gunch more :)
[16:55:36] <SWPadnos> bumc
[16:55:39] <SWPadnos> bunch, that was
[16:56:26] <jepler> at least everyone agrees my approach to toolchange movement is the wrong one
[16:56:37] <SWPadnos> actually, I like your approach also
[16:56:58] <SWPadnos> though I see a possible problem with glitches on changeover to HAL / external control
[16:57:00] <rayh> jepler: not exactly
[16:57:15] <SWPadnos> it's an ecellent solution to a different problem, I think
[16:57:17] <SWPadnos> gah - excellent
[17:00:07] <rayh> phone
[17:12:44] <rayh> jepler: I was impressed with the creativity of your suggestion.
[17:13:09] <rayh> I think that there would be a lot of applications that can use it easily.
[17:13:37] <rayh> I also like your idea about timing next read.
[17:16:33] <jepler> jmk seemed to think that the halstreamer change I proposed was a good one, whether or not it is to be used for changing tools. Is that what you mean?
[17:19:17] <rayh> Yes. Exactly.
[17:20:00] <rayh> It should make those modules work much more like I was imagining when we talked about serial communication the other day.
[17:21:20] <rayh> oh. interesting promotional for dr dobbs. mind if I share here?
[17:23:04] <rayh> Please join Dr. Dobb's Journal and Electric Cloud for this informative NetSeminar:
[17:23:06] <rayh> Managing the software build process with geographically distributed teams
[17:23:07] <rayh> Date: Thursday February 22, 2007
[17:23:07] <rayh> Time: 11:00 AM PT / 2:00 PM ET
[17:23:24] <rayh> To bad my connections is slower than they require.
[17:24:37] <jepler> it could be interesting
[17:26:14] <rayh> I presume that electric cloud is a software solution but the issues they bring up should be of value.
[17:27:49] <jepler> "With Electric Cloud, software development teams can now significantly reduce the time they waste waiting for builds to finish, and shorten the overall development cycle. As it stands many builds can take over eight hours to complete. With Electric Cloud those hours literally shrink to minutes."
[17:27:59] <jepler> this is really not a problem we face at all
[17:28:59] <cradek> http://en.wikipedia.org/wiki/Electric_Cloud
[17:29:06] <cradek> haha - See also: distcc, ccache
[17:30:23] <cradek> (wonder if this "NetSeminar" might just be an infomercial)
[17:31:12] <jepler> it really does sound interesting "[Electric Cloud] deduces dependencies on the fly by monitoring file accesses during the build, so that it knows when it is or isn't safe to run build steps in parallel."
[17:31:38] <jepler> but we've already got a build system with correct dependency information that can perform many steps in parallel
[17:31:46] <cradek> most people don't have that
[17:31:56] <jepler> no, and it can be a big PITA to get it
[17:33:56] <cradek> only because of legacy setups. You'd think over these decades people would have learned to use make.
[17:35:52] <cradek> "Recursive Make Considered Harmful" (Miller) is 10 years old now
[17:36:10] <jepler> It's crazy, but systems like GNU automake *still* do not assume gmake, so they can't do things like use %-style implicit rules or assume that Make will restart after building its dependencies
[17:36:26] <cradek> yes that is crazy.
