#emc-devel | Logs for 2007-04-17

[00:49:42] <jmkasunich> cradek: hi
[00:49:52] <cradek> hi
[00:49:55] <jmkasunich> thats odd, I've never seen that warning in encoder
[00:50:03] <cradek> ppc again
[00:50:10] <cradek> I think that's the last one
[00:50:13] <jmkasunich> ah... smarter compiler
[00:53:18] <cradek> I still don't understand why it's different, but ANSI lets the compiler choose signed/unsigned chars, so it's good to fix them anyway
[00:53:41] <jmkasunich> compilers sucj
[00:53:43] <jmkasunich> suck
[00:54:00] <jmkasunich> I'm gonna use __u8, __s16, etc for everything from now on!
[00:54:10] <jmkasunich> danged ambiguity!
[00:54:51] <cradek> are those ansi?
[00:55:05] <jmkasunich> doubt it
[00:55:19] <cradek> you pick one poison over another then
[00:55:25] <jmkasunich> they are in linux/types.h, and have the desirable feature of being the same in user and kernel space
[00:55:47] <jmkasunich> I think the ansi ones are _uint_16, etc, but I don't know if they are in kernel space
[00:57:35] <cradek> did you mean to close https://sourceforge.net/tracker/index.php?func=detail&aid=1699516&group_id=6744&atid=106744
[00:57:57] <cradek> or can there be an error message?
[00:58:25] <jmkasunich> it does what the manual says it does....
[00:59:28] <jmkasunich> if we want to do something about it, we should bitch about the bad config at startup, not wait for them to hit the home-all button
[00:59:41] <cradek> true
[01:00:03] <cradek> we have many, many uncaught misconfigurations
[01:00:17] <jmkasunich> exactly, what makes this one a bug?
[01:00:38] <cradek> only that it apparently bit someone and he cared enough to report the bite
[01:01:08] <jmkasunich> this is true
[01:01:42] <jmkasunich> I'm not gonna fix it, because I have some other (minor) issues with the implementation of home sequencing... if I get started in there, I won't stop
[01:01:43] <cradek> we'll just have to remember it for when/if we do a config scheme overhaul
[01:05:02] <jmkasunich> what about some of these other bug reports
[01:05:09] <jmkasunich> the spindle not turning off one....
[01:05:50] <jmkasunich> "if machine power is turned off from hal or other
[01:05:50] <jmkasunich> than GUI it does not stop the spindle"
[01:05:53] <cradek> I've been (boldly) assigning them
[01:05:54] <jmkasunich> what does that mean?
[01:06:11] <jmkasunich> "machine power turned off from hal"?
[01:06:12] <cradek> I'm not sure
[01:06:27] <cradek> the report was when a limit is hit, it turns machine off like it's supposed to, but the spindle keeps going
[01:06:40] <cradek> the rest is speculation that I don't quite understand
[01:07:00] <jmkasunich> what is controlling the spindle in that config? motion.spindle-something?
[01:07:49] <cradek> yes I'm pretty sure that's what he would be talking about
[01:07:53] <cradek> I didn't test this yet
[01:08:16] <jmkasunich> I'm waiting for my editor to open so I can look at some source
[01:09:03] <jmkasunich> *(emcmot_hal_data->spindle_on) = ((emcmotStatus->spindle.speed * emcmotStatus->net_spindle_scale) != 0) ? 1 : 0;
[01:09:50] <cradek> isn't there also spindle-fwd?
[01:10:04] <jmkasunich> yeah
[01:10:14] <jmkasunich> it too is derived from emcmotStatus->spindle_speed
[01:10:23] <jmkasunich> all the hal pins are derived data
[01:10:38] <cradek> wonder which pin he was talking about
[01:10:44] <jmkasunich> probably that one(s)
[01:11:14] <cradek> also not sure what version he's using
[01:11:22] <jmkasunich> emcmotStatus->spindle-speed is set and cleared by EMCMOT_SET_SPINDLE_VEL, EMCMOT_SPINDLE_OFF, and friends (commands to the motion controller from user space)
[01:11:33] <jmkasunich> if task doesn't tell it to turn off, it won't
[01:11:36] <cradek> yeah this is probably going to be a task bug
[01:11:43] <cradek> last one like it was (spindle stayed on after abort)
[01:11:49] <jmkasunich> I'm thinking that it should NOT be a task bug
[01:12:04] <jmkasunich> mainly because I don't trust task any farther than I can throw it
[01:12:13] <jmkasunich> EMCMOT_ABORT could turn it off
[01:12:28] <jmkasunich> problem there is that you'll wind up with task thinking its on and motion knowing its off
[01:12:30] <cradek> and that comes from task...
[01:12:55] <jmkasunich> there is a whole boatload of state stuff that is really crufty
[01:13:20] <cradek> yeah and some of it is this kind of thing that's not running in realtime but probably should be
[01:13:44] <jmkasunich> task has the machine_on, machine_off state, and motion has something that vaguely resembles that but is by no means guaranteed to be in sync with it
[01:15:32] <jmkasunich> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?RunLevels
[01:15:45] <jmkasunich> this came from discussions on a similar topic two years ago at the first fest
[01:17:24] <cradek> looks good to me
[01:17:39] <jmkasunich> the trick is going from concept to detailed spec
[01:18:02] <jmkasunich> how do you specify the levels, conditions, and actions
[01:18:22] <jmkasunich> without making the non-integrator integrator's heads explode
[01:18:56] <cradek> like usual you "just" need both configurability and sensible defaults
[01:19:30] <jmkasunich> I've gotten a big dose of reality dealing with a few users lately
[01:19:48] <cradek> is that good?
[01:19:53] <jmkasunich> the stuart stevensons of the world, who aren't really qualified to be machine designers but want to do it anyway
[01:20:38] <jmkasunich> we've given qualified people a very powerfull toolset, and we've given people with simple ambitions very usable (maybe could improve a bit) defaults
[01:20:52] <jmkasunich> but there is the middle ground, people who want to go a bit beyond their grasp
[01:21:46] <cradek> that's totally natural
[01:21:54] <cradek> and how one learns
[01:22:10] <jmkasunich> I'm not sure at what point HAL stops being a way to see into the machine and let you do what you want, and simply another layer of complexity
[01:22:47] <jmkasunich> Rug's THC controller HAL is certainly at the top end of the complexity scale - nobody is gonna say "thats easy to understand"
[01:23:02] <jmkasunich> but they also won't say "hell, I could do that in Mach", so its a tradeoff
[01:25:00] <cradek> I think we should never apologize for giving powerful tools to folks like Rug. however making the simplest usual case simple is just as important
[01:25:17] <cradek> in our case, that's step/dir with maybe some switches
[01:25:36] <jmkasunich> right, and to be honest, I think we've done pretty well there
[01:25:56] <jmkasunich> if you look at the list traffic, the questions aren't coming from folks with that class of machine
[01:26:08] <cradek> yes that's one possible metric
[01:26:11] <jmkasunich> they're coming from folks who are going a step or two or several beyond
[01:26:25] <cradek> true
[01:26:48] <jmkasunich> in all fairness to stuart, I think he's facing a hardware issue
[01:27:06] <jmkasunich> I just wish it hadn't taken so long to determine that
[01:27:09] <cradek> the homing reset? I do too
[01:27:28] <cradek> I hope Jon E is helping him (maybe he is, and we aren't seeing it)
[01:27:47] <jmkasunich> maybe
[01:27:50] <jmkasunich> I hope so
[01:40:58] <LawrenceG> jmkasunich: and cradek re the spindle @ limit switches. it may actually be correct to leave spindle on and just stop motion
[01:41:34] <jmkasunich> heh, correct is in the eye of the beholder I think
[01:41:36] <LawrenceG> less likely to grap material break the cutter
[01:42:17] <jmkasunich> I know my 1941 Van Norman had an interlock - if the spindle stopped for any reason, the first thing they do is kill the feed
[01:42:32] <cradek> this is one of the things people won't agree on
[01:42:34] <jmkasunich> those old mills had power feeds that would bend a solid 1" milling arbor
[01:42:43] <LawrenceG> I dont see a limit switch as an estop... just a stop
[01:42:59] <cradek> the right way to stop when something goes wrong depends on what went wrong
[01:43:16] <jmkasunich> exactly
[01:44:03] <jmkasunich> and IMO, the difference between a hobbiest and a real machine builder is that the real machine builder sits down and things about "what can go wrong" and "if it does, what should the machine do"
[01:44:37] <jmkasunich> not to knock hobbiests at all - nothing prevents a hobbiest from reaching or exceeding that level of work
[01:45:05] <jmkasunich> and when they do, they become a real machine builder in my eyes, even if they are only building one machine for themselves as a hobby
[01:45:12] <cradek> on a large machine all this should probably happen outside emc anyway
[01:45:27] <jmkasunich> I wouldn't say that
[01:45:36] <jmkasunich> safety things - estop, yes
[01:45:49] <cradek> ok I'm not sure if limits are safety/extop or not.
[01:45:55] <jmkasunich> but other sequencing can be too complex to do without classicladder, etc
[01:45:55] <cradek> again, probably depends
[01:46:33] <cradek> brb
[01:46:39] <jmkasunich> the mazak has 5 switches per axis: 1 home, 2 limts (that trip emc) and two more limits a bit farther out that trip the estop chain and kill everything
[01:46:56] <LawrenceG> what really pisses me off is cutting through the vice
[01:46:58] <jmkasunich> the outer ones don't even go to EMC at all
[01:47:15] <jmkasunich> heh, try dealing with that in external hardware...
[01:47:38] <jmkasunich> that kind of custom and changable 3-d workspace "limits" is a natural thing to do in the control
[01:47:46] <jmkasunich> but also very very hard
[01:47:59] <jmkasunich> not so much the geometry (which is non-trivial) but how you go about specifying things
[01:48:12] <jmkasunich> how does the user tell the control where the vice is and how big it is?
[01:49:14] <jmkasunich> if we could figure out a way for the user to describe the workspace accurately without going insane, we could probably put vice avoidance in emc
[01:49:50] <LawrenceG> a lot of that can be prevented by the gcode programmer.... I like to run around the perimeter of the work area with the cutter retracted to make sure I have everything located properly... axis helps a lot as well
[01:49:50] <jmkasunich> avoidance is the wrong word - it won't go around (avoid) the vice, it will just stop
[01:50:08] <jmkasunich> now if axis could only draw the vice.....
[01:50:55] <LawrenceG> like the puma robot
[01:51:21] <jmkasunich> we could do that
[01:51:34] <jmkasunich> we just have to teach every user Python, so when they move the vice they can adjust the image
[01:54:20] <jmkasunich> cradek: did we decide anything about the "spindle doesn't turn off" thing? need more info maybe?
[01:57:04] <cradek> let me try to test it
[01:57:26] <jmkasunich> the "switching to MDI during a home" one is probably legit too
[01:58:00] <cradek> I don't know what to think about switching modes
[01:58:15] <cradek> say you do g0x[far] in mdi, then switch to manual - what should happen?
[01:58:48] <jmkasunich> depends on who you ask... either:
[01:58:53] <jmkasunich> 1) abort the move, switch to free mode
[01:59:09] <jmkasunich> 2) reject the mode change, finish the move
[01:59:45] <jmkasunich> I think I see part of the problem (looking at code)
[02:00:06] <jmkasunich> command.c gets the command (to change modes), and for the most part accepts it without question
[02:00:23] <jmkasunich> setting a flag that tells control.c "boss wants us to do this"
[02:00:46] <jmkasunich> then control.c evaluates things, and may decide to reject the mode change
[02:00:48] <cradek> I confirm machine-off doesn't stop the spindle. estop does, abort does
[02:00:58] <jmkasunich> but command.c has already acknowledged it
[02:01:10] <jmkasunich> machine off from the GUI? F2? wow...
[02:01:31] <cradek> yes all three tested from the gui only
[02:01:43] <jmkasunich> does abort do machine off? or just stop motion but leave the machine on?
[02:01:53] <cradek> abort leaves machine on
[02:02:04] <jmkasunich> then the spindle control is clearly fscked
[02:02:28] <jmkasunich> if you think of the runlevel concept, the levels are estopped, on, aborted, and running
[02:03:10] <jmkasunich> spindle should not go off when you drop from running to aborted but remain on when you drop all the way down to machine off
[02:03:34] <cradek> sure
[02:03:38] <cradek> just a bug
[02:03:46] <jmkasunich> (and using the runlevels concept would make this kind of thing obvious)
[02:04:06] <jmkasunich> even if we only use it as a mental excercise
[02:04:24] <cradek> it's obvious either way :-)
[02:04:46] <jmkasunich> not to whoever coded that behavior
[02:05:09] <cradek> it wasn't coded on purpose
[02:05:16] <jmkasunich> it really stinks that the motion controller and task don't have the same states
[02:05:48] <jmkasunich> there is no place in motion where I can say "if ( state = estopped or machineoff ) spindle = off"
[02:06:27] <jmkasunich> in fact I don't think anybody can point to a place where we have mutually exclusive indications of the four states I mentioned a minute ago
[02:09:33] <jmkasunich> these are the motion controller states:
[02:09:34] <jmkasunich> typedef enum {
[02:09:35] <jmkasunich> EMCMOT_MOTION_DISABLED = 0,
[02:09:35] <jmkasunich> EMCMOT_MOTION_FREE,
[02:09:35] <jmkasunich> EMCMOT_MOTION_TELEOP,
[02:09:35] <jmkasunich> EMCMOT_MOTION_COORD
[02:09:37] <jmkasunich> } motion_state_t;
[02:10:31] <jmkasunich> free = trivkins manual, or joint mode manual on a non-triv machine
[02:10:48] <jmkasunich> teleop is world mode manual on a non-triv machine
[02:10:53] <jmkasunich> coord is auto and mdi
[02:11:12] <jmkasunich> disabled is... I dunno if that is estopped, machine off, or aborted...
[02:13:06] <jmkasunich> heh, and those states are my addition...
[02:13:38] <jmkasunich> they are derived from three flags (which implies 8 actual states, some of which are illegal)
[02:15:21] <cradek> well maybe I fixed or hacked around it
[02:15:30] <jmkasunich> ?
[02:15:50] <cradek> the bug
[02:16:08] <jmkasunich> oh, you've actually been working on it while I was rambling?
[02:16:14] <cradek> um yep
[02:16:29] <cradek> I hope alex checks it
[02:16:44] <cradek> he has the most clue in there
[02:17:03] <jmkasunich> so, is it gonna be 2.2 or 2.3 when we tackle some of this nasty stuff?
[02:18:40] <cradek> we?
[02:18:44] <jmkasunich> yeah, we
[02:18:50] <cradek> (yeah when I trip a limit, the spindle turns off now)
[02:18:57] <jmkasunich> good!
[02:19:31] <jmkasunich> good enough is the enemy of perfect (and vice versa)
[02:19:36] <cradek> afaic, someone could start rewriting any part of the system on any particular day
[02:19:51] <cradek> if it's gonna be a lot of breakage, he should use a branch
[02:20:01] <jmkasunich> some levels of rewrite cross too many boundaries to be a one-person mission
[02:21:03] <jmkasunich> if you look at motion.h... that defines the interface between RT and user space pretty well
[02:21:32] <jmkasunich> most of the commands aren't that bad, except for the ones that modify state
[02:21:39] <jmkasunich> feedback to user space is horrible though
[02:22:09] <jmkasunich> there are some big status structs, that everybody and their brother has a finger in
[02:22:24] <jmkasunich> modifying any of that data means modifications all the way up and down the line
[02:22:54] <jmkasunich> I'm not qualified to deal with the effects of such a change, so I can't make such a change
[02:23:06] <cradek> well I bet we all feel like that
[02:23:12] <jmkasunich> yeah
[02:23:21] <cradek> to make it worse, I feel like I could squash little bugs in task for a long time yet
[02:23:27] <jmkasunich> thats why I said "we"
[02:23:53] <jmkasunich> if we decide collectively do change something, then each person can deal with the effects of the change in their area
[02:24:25] <jmkasunich> (and a collective decision is more likely to be the right one - for all I know, what seems right to me in the motion controller might be all wrong for the GUI or task or interp)
[02:24:50] <cradek> I don't know anything about what task should look like
[02:25:08] <skunkworks> how did you guys tackle emc - emc2 ? wouldn't this be similar?
[02:25:08] <jmkasunich> IMO task should be two processes
[02:25:21] <cradek> if we'd remove it, and add back what we need, it might be much simpler
[02:25:49] <jmkasunich> fred has publically stated that if he was doing it now, he would do task differently
[02:25:54] <cradek> I don't even know what language it should be written in...
[02:26:19] <jmkasunich> its a loop that does "call interp to put things on queue", then "take things off queue and dispatch them to 'servers' like the motion controller"
[02:27:11] <cradek> skunkworks: before my time (barely)
[02:27:14] <jmkasunich> I haven't even though about language, but you're right
[02:27:34] <jmkasunich> skunkworks: basiclly, paul rewrote libnml while maintining a pretty stable API
[02:27:41] <cradek> // if traj is in free mode, then we're in manual mode
[02:27:45] <cradek> // else traj is in coord mode-- we can be in either mdi or auto
[02:27:54] <cradek> yargh
[02:28:20] <jmkasunich> and I (with help from others) rewrote about 60% of the motion controller, making not too terribly large changes to the interface
[02:29:09] <jmkasunich> cradek: well, from the controllers (and even the interps) point of view, the only diff between mdi and auto is where the g-code comes from
[02:29:45] <cradek> yeah, I still think those modes should be only in the gui (optionally)
[02:30:18] <cradek> I hate to mess with any of this because people seem to have an emotional stake in what task is/does
[02:30:35] <cradek> and besides, it's working fine
[02:30:41] <jmkasunich> optionally meaning "maybe only in gui, maybe in task", or "maybe only in gui, maybe don't exist at all" ?
[02:30:48] <cradek> the latter
[02:31:02] <jmkasunich> I think I agree
[02:31:07] <cradek> but I don't want to talk about that, sorry
[02:31:13] <jmkasunich> no prob
[02:31:19] <jmkasunich> I should be messing with FPGA stuff
[02:31:28] <jmkasunich> the pci lib works nice
[02:31:32] <cradek> good
[02:31:42] <jmkasunich> I decided not to put the security stuff in the lib... too messy
[02:32:14] <jmkasunich> (if you are running with sudo, you don't want to be dropping and getting privs, if you are setuid you do... the lib doesn't know that stuff
[02:32:50] <jmkasunich> so I'll drop and get in the calling program
[02:33:22] <cradek> shouldn't use sudo
[02:33:38] <cradek> and you can check getuid()==0
[02:33:39] <jmkasunich> in the long run, agreed
[02:34:23] <jmkasunich> in the short run, its convenient to test by doing "sudo theprog theargs" without adding additional make steps
[02:34:28] <jmkasunich> (I know, lousy reason...)
[02:35:32] <jmkasunich> I was having trouble keeping uid, effective uid, and saved set uid straight last night, thats the main reason I gave up
[02:36:18] <cradek> yeah I have to read the manpages every time
[02:36:29] <jmkasunich> I was trying to make sure the lib could be used in an ordinary program that might be run by root, and in a setuid program run by normal users
[02:36:41] <jmkasunich> I did read manpages, many times... thats what made my head spin
[02:37:32] <cradek> if you write it for the setuid case, sudo will work too (but without the safety of dropping privs)
[02:37:38] <jmkasunich> given the two use cases (A: normal prog, run by root) and (B: setuid prog, run by user)
[02:37:56] <cradek> you just have to write B
[02:37:57] <jmkasunich> I keep thinking that if I try to drop privs in case A, I'll succeed and never able to
[02:38:01] <jmkasunich> get them back
[02:38:25] <cradek> no, a drop is seteuid(getuid()) which is no change in case A
[02:38:46] <jmkasunich> in case A, getuid is always 0, right? cause root is running it
[02:38:59] <cradek> yes
[02:39:00] <jmkasunich> in case B, getuid is always the user's ID
[02:39:04] <cradek> yes
[02:39:15] <jmkasunich> euid is the one that determines what the prog can actually do
[02:39:22] <cradek> yes
[02:39:35] <cradek> and euid is "temporary"
[02:39:59] <jmkasunich> you drop privs by seteuid(getuid)
[02:40:01] <cradek> so you can go back to seteuid(0) when you need it
[02:40:32] <cradek> well there are two kinds of drops - temp and permanent
[02:40:47] <jmkasunich> right - perm is setuid(getuid)
[02:40:59] <jmkasunich> that much I figured out ;-)
[02:41:02] <cradek> hey comments
[02:41:08] <cradek> * cradek gives /me a cookie
[02:41:10] <jmkasunich> where?
[02:41:15] <cradek> in module-helper
[02:41:17] <jmkasunich> module_helper?
[02:41:28] <jmkasunich> yeah, thats how I started figuring things out
[02:41:36] <jmkasunich> I think the case that threw me for a loop was:
[02:42:11] <jmkasunich> this is a lib, it assumes that the prog author dropped privs somewhere along the line before calling the lib
[02:42:23] <jmkasunich> in the lib I want to get them, do stuff, and then drop them
[02:42:30] <jmkasunich> seteuid(0) gets
[02:42:36] <jmkasunich> seteuid(getuid) drops
[02:42:51] <jmkasunich> now why did it seem much more complicated before...
[02:43:38] <cradek> because you weren't explaining it
[02:43:50] <jmkasunich> to be honest, I think it made sense _until_ I started reading manpages
[02:44:17] <cradek> I bet you could find a nice summary online somewhere
[02:44:28] <jmkasunich> I tried
[02:44:30] <cradek> you're not the first one to deal with all the *uid() calls
[02:44:32] <cradek> hmm
[02:44:47] <jmkasunich> but I may have been so twisted around by then that even a simple explanation didn't seem simple
[02:45:01] <jmkasunich> Unprivileged user processes may
[02:45:01] <jmkasunich> only set the effective user ID to the real user ID, the effective user ID or the saved set-
[02:45:01] <jmkasunich> user-ID.
[02:45:05] <jmkasunich> from man seteuid
[02:45:12] <jmkasunich> what is the saved set-user-id?
[02:46:22] <jmkasunich> ok, I think its starting to make sense
[02:46:43] <jmkasunich> I must have been tired (or as you say, the lack of somebody to talk to...)
[02:47:35] <jmkasunich> of the three options listed in that man entry...
[02:47:54] <jmkasunich> the first drops privs (unless the real user is root)
[02:48:02] <jmkasunich> the 2nd is a nop
[02:48:23] <jmkasunich> and the 3rd is what lets you seteuid(0) on a setuid program
[02:50:01] <jmkasunich> <cradek> and you can check getuid()==0
[02:50:23] <jmkasunich> that will tell you if the user is root, right? it tells you nothing about whether the program is setuid root?
[02:50:37] <cradek> yes pretty sure
[02:50:54] <cradek> setuid means uid != euid at startup
[02:51:02] <jmkasunich> I think thats where I went astray
[02:51:22] <jmkasunich> I was treating seteuid(getuid) as if it was a stack thing
[02:51:37] <jmkasunich> save initial euid (root) and use regular ID
[02:51:50] <jmkasunich> then later restore the saved one to get privs again
[02:52:31] <jmkasunich> which had me worrying about "if I accidentlly drop twice in a row, the saved one will no longer be "root" it will be "normal user"
[02:52:42] <cradek> ah
[02:53:20] <jmkasunich> I should just write a little program and test some cases...
[02:53:42] <jmkasunich> that approach usually scares me tho, because it only tells me what works on this system with this compiler and this .....
[02:56:03] <cradek> true, but this is posix stuff, pretty widely agreed on
[02:56:14] <jmkasunich> yeah, I'm trying that now...
[02:56:48] <jmkasunich> its funny how we follow patterns - I rarely develop by the write it, try it, revise it method
[02:57:06] <cradek> heh
[02:57:15] <cradek> for me it's commit, then hope for the best
[02:57:19] <jmkasunich> I work more like a hardware designer (no surprise): read the databooks (man pages) and design to the specs, try to think thru all the edge cases, etc
[02:58:12] <jmkasunich> funny thing is, I _like_ the iterative approach... I just live in fear of the "only works for me" bug
[03:04:51] <cradek> goodnight all
[03:04:59] <jmkasunich> goodnight
[03:12:10] <jmkasunich> well whaddya know.... it actually works like I want it to...
[03:12:25] <jmkasunich> there's something to be said for little test programs
[04:02:43] <steves_logging> steves_logging is now known as steve_stallings
[05:30:02] <steve_stallings> steve_stallings is now known as steves_logging
[15:36:18] <alex_joni> 'lo
[15:46:36] <alex_joni> cradek: looks good to me.. will need to test it when I'm back home, but the commit message seems fine
[15:46:58] <cradek> thanks
[15:47:10] <cradek> I hope dallur will test it too
[15:47:11] <alex_joni> thank you for fixing it..
[15:47:29] <alex_joni> it probably was my fault (when I moved spindle to motion)
[15:48:05] <alex_joni> but then again, that's why we have bug reports :P
[15:48:17] <cradek> yes, no problem
[15:49:16] <skunkworks> cradek: btw - when you said you had mixed feeling about us ripping out the old k&t controller... dad said he would send it to you ;)
[15:49:29] <alex_joni> ha
[15:49:36] <cradek> hmm...
[15:50:13] <cradek> that's very kind and generous - I'll get back to you about it
[15:52:32] <cradek> skunkworks: you always run into this stuff though - if you find a spare knee mill with ballscrews, please let me know
[15:52:45] <skunkworks> when they where setup at trane manufacturing - they actually had air cooling units on them.
[15:53:12] <skunkworks> I will let dad know - he is the one that is always looking at used machinery
[15:53:45] <cradek> thanks
[15:54:03] <cradek> I know the trick is being in the right place at the right time ... and lincoln nebraska isn't ever the right place
[15:55:44] <cradek> I'll have to figure out how much space I could actually use for a mill - height may be a bit of a problem, and I only have 220 single phase available
[15:58:59] <skunkworks> we have a big old brown and sharp mill that dad happened to spy at a tech school auction. No one knew it was there. The auctioneer started at like $5000 and kept going down. finally when he got to 100 dad said - "I'll take it for $100" he was sweating bullets. very nice mill - all mechanicall power feeds.
[15:59:20] <skunkworks> old
[15:59:56] <cradek> cool