Back
[00:03:40] <alex_joni> hi john
[00:03:46] <jmkasunich> hi alex
[00:03:53] <jmkasunich> either I'm early or you are late ;-)
[00:04:02] <alex_joni> a bit of both ;)
[00:06:49] <jmkasunich> how was your week?
[00:06:59] <alex_joni> busy :)
[00:07:01] <alex_joni> yours?
[00:07:09] <jmkasunich> same here
[00:07:16] <alex_joni> * alex_joni is fighting with a VERY simple thing, and it doesn't want to give in
[00:07:25] <jmkasunich> what thing is that?
[00:07:35] <alex_joni> first 2 hal pins for halui
[00:08:10] <jmkasunich> hal side or NML side?
[00:08:35] <alex_joni> hal side
[00:08:59] <jmkasunich> can I help?
[00:09:16] <alex_joni> maybe telling you what I did helps :)
[00:09:26] <alex_joni> I've set up a struct (the usual way)
[00:09:32] <alex_joni> but with 2 pointers to it
[00:09:42] <alex_joni> 1 for the current values, 1 for the old values
[00:09:56] <jmkasunich> double buffering?
[00:10:08] <alex_joni> so I'm trying to compare old values with new values, to see what changed and send appropiate NML messages
[00:10:59] <alex_joni> if (*(halui_data->machine_on) != *(old_halui_data->machine_on)) {
[00:10:59] <alex_joni> if (*(halui_data->machine_on) != 0)
[00:10:59] <alex_joni> sendMachineOn();
[00:10:59] <alex_joni> else
[00:10:59] <alex_joni> sendMachineOff();
[00:11:01] <alex_joni> //*(old_halui_data->machine_on) = *(halui_data->machine_on);
[00:11:04] <alex_joni> }
[00:11:28] <jmkasunich> what does (old_halui_data->machine_on) point to?
[00:11:38] <jmkasunich> remember, machine_on is a pointer, not a data value
[00:11:42] <alex_joni> it's an identical struct
[00:11:49] <alex_joni> initiallized with hal_alloc
[00:12:14] <jmkasunich> halui_data is allocated with hal_alloc, right?
[00:12:25] <alex_joni> hal_malloc() yes
[00:12:30] <alex_joni> true for both of them
[00:12:46] <jmkasunich> and then you call hal_pin_new with the address of a member of halui_data
[00:12:58] <alex_joni> ahh.. I see
[00:13:13] <jmkasunich> which tells HAL "halui_data->machine_on is a pointer to some signal (initially a dummy signal)
[00:13:32] <alex_joni> yeah.. but for old_halui_data there's none telling that
[00:13:36] <jmkasunich> but you never call hal_new_pin with old_halui_data (and you shouldn't)
[00:13:59] <alex_joni> right.. I probably need to make the old values static
[00:14:01] <jmkasunich> another thing - the old_data ones shouldn't be allocated with hal_malloc, that just wastes shmem
[00:14:07] <alex_joni> right
[00:14:24] <jmkasunich> it can live in memory that belongs only to halui
[00:15:05] <jmkasunich> I'd be inclined to have two struct definitions
[00:15:07] <alex_joni> so should I duplicate the struct? (omce with pointers for the pins, and once with static values?
[00:15:10] <alex_joni> right
[00:15:13] <jmkasunich> yes
[00:15:23] <jmkasunich> so you wind up doing:
[00:15:48] <jmkasunich> if ( *(halui_data->machine_on) != old_data->machine_on ) {
[00:15:53] <jmkasunich> some stuff
[00:15:59] <alex_joni> old_data.some_stuff
[00:16:11] <jmkasunich> yeah, you can statically allocate it
[00:16:36] <jmkasunich> old_data.machine_on = *(halui_data->machine_on)
[00:16:37] <jmkasunich> }
[00:16:47] <alex_joni> yeap
[00:16:54] <jmkasunich> "some stuff" in my code = send NML msg
[00:17:17] <alex_joni> well, that's what I meant
[00:19:32] <alex_joni> so, how's everything
[00:19:57] <jmkasunich> I'm tired
[00:20:07] <jmkasunich> up past midnight every day this week
[00:20:23] <jmkasunich> machining test jigs for a customer
[00:20:34] <jmkasunich> shipped them this morning. Yay!
[00:20:40] <alex_joni> yay, it works
[00:21:07] <alex_joni> I can switch machine on/off with sets
[00:21:20] <jmkasunich> cool
[00:21:32] <alex_joni> yeah, but these are the easy pins..
[00:21:33] <jmkasunich> I should get back to work on halvcp
[00:21:43] <alex_joni> the more complicated ones will need some states
[00:21:53] <alex_joni> * alex_joni doesn't wanna go there :))
[00:22:06] <alex_joni> NML states too
[00:22:11] <alex_joni> :/
[00:22:26] <jmkasunich> well if its too complicated to work with a single button, its probalby not a candidate for pendant style controls
[00:22:41] <alex_joni> seen the wiki page rayh started?
[00:22:55] <jmkasunich> which one?
[00:22:59] <alex_joni> about halui
[00:23:17] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?Halui
[00:24:30] <jmkasunich> not sure how I feel about bidirectional pins
[00:24:42] <alex_joni> that's my bad..
[00:24:48] <alex_joni> in the meantime I changed it all
[00:24:54] <alex_joni> there are 2 pins for each thing
[00:24:59] <jmkasunich> good
[00:25:00] <alex_joni> 1 to set it, 1 for status
[00:25:20] <alex_joni> e.g.: halui.0.general.0.machine-on & halui...machine-is-on
[00:25:37] <jmkasunich> is there also a halui.0.general.0.machine-off?
[00:25:44] <alex_joni> no
[00:25:51] <jmkasunich> probably should be
[00:25:52] <alex_joni> should there be?
[00:26:05] <jmkasunich> the NIST principle uses buttons, not maintained contacts
[00:26:17] <alex_joni> ok, so machine-on = 0 does nothing, and machine-off = 1 shuts it down?
[00:26:46] <jmkasunich> so a momentary 1 on machine_on sends a machine on NML and a momentary 1 on machine_off sets a machine off NML
[00:26:59] <alex_joni> right, i can do that
[00:27:23] <alex_joni> this should work with a maintained switch too
[00:27:36] <alex_joni> err.. strike that
[00:27:36] <jmkasunich> for some value of "work" ;-)
[00:28:31] <jmkasunich> the names are kinda long
[00:28:43] <alex_joni> I know :(
[00:28:49] <jmkasunich> halui.machine-on
[00:28:56] <jmkasunich> no.
[00:29:02] <alex_joni> there will be a bunch of them
[00:29:10] <jmkasunich> halui.control.machine-on
[00:29:18] <jmkasunich> halui.control.machine-off
[00:29:31] <jmkasunich> halui.stat.machine-is-on
[00:29:40] <jmkasunich> or even halui.stat.machine-on
[00:30:23] <alex_joni> I like machine-is-on better
[00:30:26] <jmkasunich> ok
[00:31:49] <alex_joni> how about io?
[00:31:54] <jmkasunich> ?
[00:31:58] <alex_joni> halui.io.mist-on ?
[00:32:07] <alex_joni> halui.iostat.mist-is-on
[00:32:30] <jmkasunich> what does io give you?
[00:32:30] <alex_joni> or all of those into halui.io.*
[00:32:32] <jmkasunich> not much
[00:32:53] <alex_joni> lube/coolant/spindle
[00:32:57] <alex_joni> on/off/status
[00:33:05] <alex_joni> for spindle also speedsettings
[00:33:09] <jmkasunich> they have nothing to do with IO tho
[00:33:12] <jmkasunich> they are control
[00:33:36] <alex_joni> if you look at it that way they are all control
[00:33:43] <jmkasunich> exactly
[00:33:44] <alex_joni> because they control the machine :)
[00:33:59] <jmkasunich> which is why it doesn't need such long names
[00:33:59] <alex_joni> but I'd rather split them up based on area
[00:34:14] <alex_joni> e.g. jogging stuff separated from io
[00:34:21] <jmkasunich> there are only two kinds of pins - commands from the user, and information to be displayed to the user
[00:34:33] <alex_joni> there's not even half of the pins in that list
[00:34:55] <jmkasunich> ?
[00:34:56] <alex_joni> it will be a LONG list of pins
[00:35:14] <jmkasunich> nothing wrong with that is there?
[00:35:17] <alex_joni> that's only for starters
[00:35:40] <alex_joni> I mean, I only enumerated a bunch I imagined are needed
[00:35:49] <alex_joni> but that's only at first glance
[00:35:58] <alex_joni> I really think there will be loads of other pins
[00:36:06] <alex_joni> based on what the user wants to do
[00:36:32] <alex_joni> I mean to make it really flexible it will have more than 50 pins I imagine!?
[00:36:47] <jmkasunich> maybe
[00:36:52] <jmkasunich> whats wrong with that
[00:36:53] <alex_joni> so keeping them all under the same name halui.* will be a long list
[00:37:01] <jmkasunich> whats wrong with that
[00:37:03] <jmkasunich> ;-)
[00:37:11] <alex_joni> imagine a user looking at halconfig
[00:37:28] <alex_joni> selecting halui in the tree will make it go 4-5 pages
[00:37:37] <alex_joni> no WAY anyone can keep an overview there
[00:38:31] <jmkasunich> I can't see adding artificial heirarchy just to make a tree display look pretty
[00:38:34] <alex_joni> heck, even I can't remember them 2 days after I wrote them
[00:38:50] <alex_joni> well.. that's semantics imho
[00:39:03] <alex_joni> any heirarchy is more or less artificial
[00:39:26] <jmkasunich> not true
[00:39:37] <alex_joni> jmkasunich: imagine grepping with halcmd show pin halui.io.
[00:39:47] <jmkasunich> for instance, I see nothing wrong with halui.axis.blahblah
[00:40:09] <jmkasunich> axis is a natural grouping
[00:40:22] <alex_joni> and io isn't ?
[00:40:32] <jmkasunich> nope ;-)
[00:40:41] <alex_joni> control, status, io, axis, jog, program, probe
[00:40:43] <jmkasunich> halui.0.io.0.spindle-stop
[00:40:53] <alex_joni> halui.io.spindle-stop
[00:41:01] <jmkasunich> the io tells you nothing - I'd rather see halui.spindle.stop
[00:41:14] <jmkasunich> that groups all spindle stuff together
[00:41:30] <alex_joni> what's so special about spindle?
[00:41:42] <jmkasunich> its more logical than io
[00:41:49] <alex_joni> imo a spindle is not really needed for machining
[00:41:59] <alex_joni> ;)
[00:42:15] <alex_joni> I could have something else.. like a cutting head (but that's OT)
[00:42:30] <alex_joni> I didn't mean IO as in DIO or similar
[00:42:46] <jmkasunich> I don't know what you _do_ mean by IO
[00:43:00] <alex_joni> but rather as in interface to tooling & related
[00:43:07] <jmkasunich> unless you mean "things handled by iocontrol", but that is an internal distinction
[00:43:13] <alex_joni> everything what the iocontrol does
[00:43:18] <alex_joni> yes
[00:43:30] <jmkasunich> but that is an artifical distinction
[00:43:48] <alex_joni> depends on the point of view
[00:43:59] <alex_joni> if you look from the users point of view, maybe
[00:44:10] <alex_joni> if you look from emc, then no
[00:44:30] <jmkasunich> I could make all IO go thru the RT code (motion controller)
[00:44:31] <alex_joni> software design can be either way :)
[00:44:52] <alex_joni> ok, then maybe tooling?
[00:45:05] <alex_joni> but I can't find a better word to mix them together
[00:45:08] <jmkasunich> there is nothing that makes "axis.0.motor-pos-cmd" any different than "spindle-speed-cmd" or "tool-number"
[00:45:14] <alex_joni> spindle, coolant, lube, etc
[00:45:43] <alex_joni> how do you mean that?
[00:46:20] <jmkasunich> I just feel that the division of stuff between the RT motion controller and the user space iocontrol is somewhat artifical
[00:46:30] <jmkasunich> and don't see why the user interface should care about it
[00:46:40] <alex_joni> well, I don't really care where this stuff is handled
[00:46:50] <alex_joni> if it's in iocontrol or motion controller
[00:47:05] <alex_joni> but I can't find a word to keep them together
[00:47:14] <jmkasunich> if a knob or button is going to be used to control the spindle, call it halui.spindle.speed, or halui.spindle.fwd, or halui.spindle.stop
[00:47:22] <alex_joni> well, other than 'io', which is probably poor
[00:47:40] <jmkasunich> why do you feel the need for another "layer" to keep things together?
[00:47:43] <alex_joni> yes, but that's treating the spindle special..
[00:48:13] <alex_joni> because of the same reason you want to keep the spindle stuff together
[00:48:29] <jmkasunich> halui.spindle, halui.axis, halui.mode, halui.misc
[00:48:41] <alex_joni> yes, but why spindle?
[00:48:47] <alex_joni> what's so special about spindle?
[00:48:53] <alex_joni> and not lube for example?
[00:49:01] <jmkasunich> because there are (can be) several controls/displays that are related to the spindle
[00:49:20] <jmkasunich> there is only one lube
[00:49:35] <alex_joni> there is only one spindle (most of the time)
[00:49:51] <jmkasunich> but it has multiple things associated with it
[00:50:00] <alex_joni> so does lube
[00:50:00] <jmkasunich> fwd, rev, stop
[00:50:07] <alex_joni> lube -on/off, level
[00:50:26] <jmkasunich> level isn't a user thing
[00:50:42] <jmkasunich> maybe an output to the user, but not a control
[00:50:51] <alex_joni> right
[00:51:03] <alex_joni> it's only NML->HAL
[00:51:09] <alex_joni> but that's OT again
[00:51:19] <jmkasunich> I really don't care whether it is halui.spindle.forward, or halui.spindle-forward
[00:51:23] <alex_joni> I agree spindle has more than 2 things
[00:51:35] <jmkasunich> but sticking .0.io.0 in there just makes the name longer for no reason
[00:52:00] <jmkasunich> the spindle-fwd vs spindle.fwd thing matters only when you use the tree widget
[00:52:00] <alex_joni> no, I want halui.io.spindle-* halui.io.lube-* halui.io.coolant-*
[00:52:14] <jmkasunich> and thats the part that I don't understand
[00:52:29] <jmkasunich> what does that extra level do for you?
[00:52:40] <alex_joni> I don't see why spindle should be separate and lube & colant in another place
[00:52:51] <alex_joni> or you want halui.lube-* ?
[00:53:15] <jmkasunich> how many lube controls are there?
[00:53:22] <alex_joni> 2 (on & off)
[00:53:36] <alex_joni> same for flood & mist
[00:54:17] <alex_joni> spindle has a bunch (on/off, fwd/backwd, speed-etting, speed-incr, speed-decr, brake on/off, ...)
[00:54:21] <jmkasunich> so halui.lube-on and halui.lube-off and halui.lube-is-on
[00:54:49] <alex_joni> ok, if it's like that, then I don't have anything against halui.spindle*
[00:55:19] <alex_joni> but as I said sooner, I think we'll end up with too manby pins under the halui.* hierarchy
[00:55:47] <jmkasunich> so halui.lube.on and halui.lube.off and halui.lube.is-on
[00:56:00] <jmkasunich> only one entry at the top level that way
[00:56:27] <alex_joni> yes but still a few of them (spindle, lube, mist, flood, etc)
[00:56:33] <jmkasunich> so?
[00:56:34] <alex_joni> but I guess I can live with that
[00:57:05] <jmkasunich> some of the ones in the list on the wiki don't seem like UI stuff at all
[00:57:14] <alex_joni> like?
[00:57:19] <jmkasunich> what is "joint.x.limit-min-soft"?
[00:57:49] <alex_joni> a pin that turns true when the software min limit has been exceeded
[00:58:05] <jmkasunich> so indication to the user, not command from the user
[00:58:08] <alex_joni> right
[00:58:18] <jmkasunich> if anything, I think that should be the top level tree distinction
[00:58:22] <alex_joni> stat not control
[00:58:28] <jmkasunich> halui.cmd.blah vs halui.stat.blah
[00:58:41] <jmkasunich> or maybe not
[00:58:42] <alex_joni> cmd is not very accurate imo
[00:58:50] <jmkasunich> cmd from the user
[00:58:54] <jmkasunich> ctrl if you prefer
[00:59:07] <alex_joni> yeah, control/ctrl is better
[00:59:17] <jmkasunich> but thinking about it, I'm not sure that should be top level
[00:59:49] <jmkasunich> is it better to separate control and indication, or to separate by function?
[01:00:05] <alex_joni> I would prefer by function
[01:00:16] <alex_joni> then have it by control/indication
[01:00:40] <jmkasunich> I think so to (I changed my mind ;-)
[01:00:47] <jmkasunich> but -
[01:01:01] <alex_joni> it's twisted anyways you look at it
[01:01:10] <jmkasunich> halui.0.joint.x.limit-min-soft should be halui.joint.x.on-min-limit
[01:01:18] <alex_joni> right
[01:01:32] <alex_joni> like I said, I only wrote them down hastly
[01:01:58] <alex_joni> all the namings are up for debate ... and I like that you're looking them over
[01:02:25] <jmkasunich> the whole thing needs some thinking
[01:02:35] <jmkasunich> including the separate on and off inputs
[01:02:50] <jmkasunich> suppose you have a lighted pushbutton labeled LUBE
[01:03:00] <jmkasunich> push once, light turns on, lube is on
[01:03:10] <jmkasunich> push same button again, light turns off, lube is off
[01:03:28] <jmkasunich> another guy might want two buttons, one green for on, one red for off, and no light
[01:03:39] <alex_joni> that is usually done with a holding button
[01:03:49] <alex_joni> push it, it stays down and lights up
[01:03:51] <jmkasunich> not by NIST
[01:04:02] <alex_joni> the other guy doesn't like NIST
[01:04:08] <alex_joni> :-)
[01:04:21] <jmkasunich> their philosophy (not sure you agree or not, not sure I agree or not), is that you can control from anywhere
[01:04:36] <alex_joni> but either way.. he can take care of this with CL if he really needs
[01:04:52] <jmkasunich> if I use the physical button at one side of the machine to turn lube on with halui, I still want to be able to turn it off from a regular GUI on the other side of the machine
[01:05:11] <alex_joni> right, and not with momentary buttons :)
[01:05:23] <jmkasunich> it MUST be momentary buttons
[01:05:24] <alex_joni> so we need a T-flip/flop in HAL
[01:05:33] <alex_joni> errr.. yeah , that's what I meant
[01:06:02] <alex_joni> you're familiar with T-flip/flops?
[01:06:10] <jmkasunich> yeah, and that is the wrong answer
[01:06:14] <alex_joni> why?
[01:06:28] <jmkasunich> a T flipflop in HAL will turned momentary buttons into maintained
[01:06:35] <jmkasunich> that is exactly what we don't want to do
[01:06:43] <alex_joni> well.. something like it then
[01:06:55] <alex_joni> but without the maintained output
[01:07:04] <jmkasunich> if the T flipflop says "lube is on", you can't ever turn it off except by the T flipflop
[01:07:12] <alex_joni> or provide a heck of pins for each crap
[01:07:39] <alex_joni> crap.on crap.off crap.on/off crap.is-on
[01:07:46] <jmkasunich> lol
[01:08:10] <jmkasunich> you probably never saw it, but there used to be an advert on late night TV for something called the clapper
[01:08:13] <alex_joni> the on/off will change it's state on momentary 1 signals
[01:08:24] <alex_joni> guess I missed that
[01:08:28] <jmkasunich> it was a sound operated switch, so you could lay in bed and clap, and the light would go out
[01:08:38] <alex_joni> yeah I know the type
[01:08:43] <jmkasunich> their little song went "clap on, clap off, the clapper!"
[01:08:51] <alex_joni> lol
[01:08:56] <jmkasunich> thats what I thought of when you typed "crap on, crap off"
[01:09:08] <alex_joni> the crapper
[01:09:22] <alex_joni> ;-)
[01:09:34] <alex_joni> so.. is that any better?
[01:09:45] <alex_joni> -on -off -on/off -is-on ?
[01:10:31] <jmkasunich> I dunno
[01:10:41] <jmkasunich> I agree that is a lot of pins
[01:10:46] <alex_joni> ok, I'll try to clean up the names a bit and commit
[01:10:52] <alex_joni> then you can edit if you want
[01:10:59] <jmkasunich> I think we could leave out the -on/off pin
[01:11:28] <jmkasunich> if you know the current state (is-on), you can decide whether a button push should go to -on or -off
[01:11:51] <jmkasunich> either with CL, or with a dedicated HAL block
[01:12:06] <alex_joni> a t-flip/flop and a mux
[01:12:17] <alex_joni> the T goes to the mux select
[01:12:21] <jmkasunich> "toggler"? one input is the user button, one is the current state, and the two outputs are -on and -off
[01:12:29] <jmkasunich> no T flipflop
[01:12:41] <alex_joni> I'm talking only theory
[01:12:53] <alex_joni> I don't want a t-flip/flop as a hal module
[01:12:56] <jmkasunich> the flipflop implies state information INSIDE the HAL and thats exactly what we don't want
[01:13:04] <jmkasunich> we want the state info to come from emc
[01:13:08] <alex_joni> right
[01:13:19] <alex_joni> but it will come as a hal pin
[01:13:40] <alex_joni> ok, the toggler sounds ok
[01:13:40] <jmkasunich> yes, "is-on"
[01:13:55] <jmkasunich> you know, we could have fewer pins if we did it the other way
[01:14:04] <jmkasunich> lube.toggle and lube.is-on
[01:14:20] <jmkasunich> if you want a single button control just connect it to lube.toggle
[01:14:50] <jmkasunich> if you want an on button and an off button, connect them thru a mux controlleed by lube.is-on
[01:15:06] <jmkasunich> when its on, the mux looks at the off button, when its off it looks at the on button
[01:15:12] <alex_joni> right
[01:15:20] <alex_joni> but that might mean a lot of mux-es :)
[01:15:46] <jmkasunich> only for the things where the user really wants two buttons
[01:16:18] <alex_joni> like machine on/off, spindle on/off, estop on/off
[01:16:56] <jmkasunich> estop is a special case anyway
[01:17:09] <jmkasunich> the NIST principle doesn't apply there
[01:17:10] <alex_joni> this time we only talk about internal emc estop
[01:17:21] <alex_joni> so NIST does apply
[01:17:28] <jmkasunich> estop inputs are maintained, if ANY one is tripped, the machine can't run
[01:17:41] <alex_joni> we only need momentary pushes to set emc into estoped mode
[01:17:47] <alex_joni> and a momentary push to get it out
[01:17:56] <alex_joni> this is NOT the external ESTOP
[01:18:03] <jmkasunich> halui.estop.stop, and halui.estop.reset
[01:18:48] <alex_joni> something like that
[01:19:11] <alex_joni> I named them estop.activate & estop.reset
[01:19:21] <jmkasunich> that's good
[01:19:40] <jmkasunich> I just hate "estop.on" and "estop.off" because its ambiguous
[01:20:07] <jmkasunich> does "on" mean "the machine can be turned on now" or "estop is 'ON' and therefore the machine is off"?
[01:20:21] <alex_joni> yeah, just look at mini for a great example :)
[01:20:27] <jmkasunich> activate and reset are clear and unambiguous
[01:20:35] <alex_joni> * alex_joni never knows what's going on there
[01:21:08] <jmkasunich> me neither
[01:23:13] <alex_joni> any idea how to use a NetMos Technology PCI 9815 Multi-I/O Controller with emc?
[01:23:30] <jmkasunich> I have no idea what a NetMos Technology PCI 9815 Multi-I/O Controller
[01:23:33] <jmkasunich> is
[01:23:41] <alex_joni> it's a dual parport PCI card
[01:24:23] <jmkasunich> loadrt parport cfg="0x<addy1> 0x<addy2>"
[01:24:43] <jmkasunich> finding the addresses is the fun part
[01:25:11] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?NetMos
[01:25:26] <alex_joni> * alex_joni falls off the chair
[01:26:10] <jmkasunich> why?
[01:26:31] <alex_joni> it's in the wiki :)
[01:26:52] <alex_joni> our wiki
[01:26:57] <jmkasunich> yeah
[01:27:05] <alex_joni> never would have dreamed
[01:27:05] <jmkasunich> thats what its for, right?
[01:27:06] <alex_joni> :)
[01:27:09] <alex_joni> right
[01:27:19] <alex_joni> ok, so first I'll commit the halui changes
[01:27:26] <jmkasunich> you just did a google and thats where it showed up>?
[01:27:31] <alex_joni> yes
[01:27:46] <alex_joni> actually redpoint.co.uk (the old wiki)
[01:27:56] <alex_joni> but I knew where to look
[01:29:14] <alex_joni> the old wiki is at #4, the new one at #20
[01:29:25] <alex_joni> between google's results
[01:30:03] <jmkasunich> guess since the old ones been there longer
[01:30:11] <alex_joni> probably
[01:35:24] <jmkasunich> how late is it there?
[01:36:43] <alex_joni> 03:37
[01:36:49] <jmkasunich> go to sleep
[01:36:58] <alex_joni> I want to commit this first
[01:37:03] <alex_joni> feeling fresh :)
[01:38:21] <jmkasunich> I hope you don't expect me to look at it tonight
[01:38:28] <alex_joni> no way :)
[01:38:31] <jmkasunich> I'm not feeling fresh at all
[01:38:36] <alex_joni> but I want it to be there for reference
[01:38:49] <alex_joni> if we want to discuss it further tomorrow, or lateron
[01:39:59] <jmkasunich> ok
[01:40:16] <jmkasunich> we should be thinking about release
[01:40:29] <jmkasunich> does halui need to be done for release? I say no
[01:40:37] <alex_joni> no way
[01:40:54] <alex_joni> not even threading imho
[01:40:58] <jmkasunich> right
[01:41:04] <jmkasunich> so what else does need done?
[01:41:17] <jmkasunich> that should be topic #1 this weekend
[01:41:34] <alex_joni> there's cleaning up HEAD :)
[01:41:42] <alex_joni> or maybe start a branch for the release?
[01:42:02] <alex_joni> some things need to get out of the way for the release
[01:42:11] <alex_joni> halui, threading, etc
[01:42:29] <alex_joni> but there are some fixes since the last TESTING which need to be there
[01:42:31] <jmkasunich> hmm
[01:42:45] <jmkasunich> I was assuming that things like threading could be in there but not used
[01:42:50] <alex_joni> just throwing the idea in the air, we'll discuss it this weekend
[01:42:55] <jmkasunich> yeah
[01:43:08] <alex_joni> that works too
[01:43:48] <SWP_Away> SWP_Away is now known as SWPadnos
[01:45:10] <jmkasunich> hi swp
[01:45:16] <SWPadnos> hi there
[01:47:19] <jmkasunich> I forgot to email Steve S about linuxcnc
[01:47:27] <SWPadnos> oops ;)
[01:47:52] <alex_joni> jmkasunich: about what?
[01:47:55] <SWPadnos> need his phone number?
[01:48:08] <jmkasunich> SWP: sure, /msg it
[01:48:25] <jmkasunich> alex: ftp access to the linuxcnc server has been down since march 10
[01:48:33] <alex_joni> oh..
[01:48:34] <jmkasunich> so the compile farm results aren;t getting updated
[01:48:48] <alex_joni> hope he didn't take it down because of me
[01:49:03] <alex_joni> I asked him of a list of users to set up on cncgear
[01:49:19] <alex_joni> and he sent me the list, but we never talked about stopping ftp
[01:49:30] <SWPadnos> the FTP server was refusing connections, before asking for login info
[01:50:04] <alex_joni> SWPadnos: yeah, but maybe he had to stop the server to get the list? windows software sometimes has very mysterious ways of working
[01:50:40] <SWPadnos> indeed
[01:56:47] <SWPadnos> hmmm - I wonder if I should mention that "estop" is a bad name for a software halui mode?
[02:00:49] <alex_joni> software halui mode?
[02:01:25] <SWPadnos> I noticed estop in the commit mesasge, snd since this is software, I just started thinking ...
[02:01:25] <alex_joni> jmkasunich: HAL seems to like 0xd800 as a parport address (the address I suspect from my NetMos card)
[02:02:01] <alex_joni> but speed is not really improved
[02:02:14] <alex_joni> I went down to BASE_PERIOD=6usec
[02:02:16] <SWPadnos> sorry - estop is one of the names you can assign to halui
[02:02:18] <jmkasunich> oh, you were trying to get a faster period?
[02:02:24] <alex_joni> jmkasunich: yes
[02:02:31] <alex_joni> was thinking it might be faster
[02:02:38] <jmkasunich> isn't 6us fast enough?
[02:02:45] <alex_joni> it's PCI not ISA
[02:02:49] <jmkasunich> jeez, thats a 160KHz interrupt
[02:02:51] <alex_joni> it's PLENTY fast
[02:03:02] <alex_joni> a bit sluggish on tkemc :)
[02:03:20] <alex_joni> on 5usec it still ran, but not useable
[02:03:20] <SWPadnos> it should be a little faster on PCI, but the best speedup would be from combining multiple narrow writes into single wide writes
[02:03:36] <alex_joni> moving the mouse took a few seconds to update
[02:03:37] <SWPadnos> which the hardware is unlikely to support
[02:04:00] <alex_joni> and after 3minutes I rebooted, didn't have the nerve to wait for emc to startup fully
[02:04:11] <SWPadnos> did you try 5.5 uS?
[02:04:17] <alex_joni> not yet :)
[02:04:20] <SWPadnos> heh
[02:04:34] <alex_joni> trying now
[02:04:46] <SWPadnos> o
[02:04:49] <SWPadnos> k
[02:04:54] <SWPadnos> t
[02:04:55] <SWPadnos> h
[02:04:57] <SWPadnos> e
[02:05:00] <SWPadnos> n
[02:05:04] <SWPadnos> :)
[02:05:30] <alex_joni> [ 422.422473] HAL: creating thread base-thread, 5500 nsec
[02:05:31] <alex_joni> [ 422.422506] HAL_LIB: ERROR: clock period too long: 5867
[02:05:46] <SWPadnos> that doesn't seem too long ;)
[02:05:55] <alex_joni> 5867 is too long to fit into 5500
[02:06:07] <jmkasunich> hmm
[02:06:12] <alex_joni> I know that message is backwards
[02:06:33] <alex_joni> jmkasunich: what worries me a bit:
[02:06:47] <alex_joni> [ 422.422506] HAL_LIB: ERROR: clock period too long: 5867
[02:06:47] <alex_joni> [ 422.422514] MOTION: failed to create 5500 nsec base thread
[02:06:47] <alex_joni> [ 422.422520] MOTION: init_threads() failed
[02:06:47] <alex_joni> [ 422.422554] RTAPI: WARNING: module 'HAL_motmod' failed to delete shmem 02
[02:07:44] <jmkasunich> dunno what thats about
[02:07:51] <jmkasunich> the clock period thing I think I can explain
[02:08:06] <jmkasunich> it calls the RTOS with a request to set the period to 5500
[02:08:19] <jmkasunich> the RTOS sets it to the nearest possible value
[02:08:25] <alex_joni> right
[02:08:29] <jmkasunich> (based on timer clocks, etc)
[02:08:39] <jmkasunich> and the RTOS returns the actual value
[02:08:43] <alex_joni> 5900 nsec is running now
[02:08:55] <jmkasunich> if the returned value is more than 1% longer than asked for you get that message
[02:09:26] <alex_joni> but the PC feels like a 5-600 MHz one
[02:09:37] <alex_joni> maybe less
[02:09:41] <alex_joni> ;-)
[02:10:04] <alex_joni> but it's useable
[02:10:34] <jmkasunich> heh, 5867 is 7 clocks of the 1.19MHz 8254 clock
[02:11:07] <alex_joni> right
[02:11:12] <alex_joni> so that's a good value
[02:11:47] <alex_joni> still it's pretty insane to have a RT interrupt every other 7 clocks :)
[02:11:58] <alex_joni> * alex_joni loves it :D
[02:13:01] <SWPadnos> what CPU and chipset?
[02:13:07] <alex_joni> SWPadnos: older :)
[02:13:12] <SWPadnos> of course
[02:13:21] <alex_joni> juve@ubuntu:~/emc2$ cat /proc/cpuinfo
[02:13:21] <alex_joni> processor : 0
[02:13:21] <alex_joni> vendor_id : AuthenticAMD
[02:13:21] <alex_joni> cpu family : 6
[02:13:21] <alex_joni> model : 6
[02:13:23] <alex_joni> model name : AMD Athlon(tm) XP 1600+
[02:13:30] <alex_joni> stepping : 2
[02:13:30] <alex_joni> cpu MHz : 1400.266
[02:13:30] <alex_joni> cache size : 256 KB
[02:13:39] <alex_joni> bogomips : 2752.51
[02:14:17] <alex_joni> juve@ubuntu:~/emc2$ lspci -v
[02:14:18] <alex_joni> 0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge
[02:14:21] <alex_joni> Subsystem: VIA Technologies, Inc.: Unknown device 0000
[02:14:44] <SWPadnos> ah - KT400. I have a couple of KT333 and an older KT-133A
[02:15:05] <alex_joni> it might be KT600 not sure
[02:15:37] <alex_joni> it's a MSI mobo
[02:15:39] <SWPadnos> I don't think I've gotten that kind of response on my Gentoo/RTAI machine
[02:15:47] <SWPadnos> though it's been quite a while since I've tried
[02:16:02] <SWPadnos> (that's an Athlon XP2400, I think)
[02:16:40] <alex_joni> yeah, I have a 2.66 P4 and it's worse :)
[02:16:52] <SWPadnos> is this an ubuntu install?
[02:17:06] <alex_joni> as you can see in the stuff I pasted
[02:17:19] <alex_joni> stock ubuntu with cradek's kernel
[02:17:21] <SWPadnos> so I can, if I bother looking ;)
[02:18:02] <jmkasunich> yay! SF finally removed that fenn lock on the bin directory
[02:18:02] <alex_joni> otoh, naming a box ubuntu doesn't imply it's really an ubuntu
[02:18:08] <alex_joni> jmkasunich: yay
[02:18:14] <SWPadnos> cool
[02:18:18] <alex_joni> will you do the honour? or should I?
[02:18:25] <alex_joni> too late :)
[02:19:36] <alex_joni> ok guys.. I'm off to bed
[02:19:44] <jmkasunich> goodnight alex
[02:19:45] <alex_joni> it's getting late
[02:19:46] <alex_joni> :)
[02:19:52] <SWPadnos> see you later
[02:20:12] <alex_joni> * alex_joni envies you guys
[02:20:17] <jmkasunich> why?
[02:20:18] <alex_joni> I like your timezone better
[02:20:23] <alex_joni> ROFL
[02:20:28] <SWPadnos> heh - it's great, until morning ;)
[02:20:31] <alex_joni> really :)
[02:20:50] <alex_joni> I could stay up a few more hours (2-3) then go to sleep
[02:21:01] <alex_joni> it would be just right
[02:21:14] <alex_joni> ok, I'm off
[02:21:25] <alex_joni> jmkasunich: forgot one thing
[02:21:41] <jmkasunich> ?
[02:21:42] <alex_joni> I moved a few more things from linuxcnc to cncgear/joomla/
[02:21:52] <alex_joni> if you spot anything that needs moving let me know
[02:22:08] <jmkasunich> as long as you don't move the compile farm directories
[02:22:17] <alex_joni> I won't touch those
[02:22:22] <SWPadnos> "add" is a better term ,rather than move
[02:22:28] <SWPadnos> or copy
[02:22:34] <alex_joni> yeah right.. copy/add
[02:22:47] <alex_joni> duplicate :)
[02:22:51] <SWPadnos> right
[02:22:57] <SWPadnos> "web replicated data stores"
[02:23:13] <alex_joni> jmkasunich: maybe we can announce it next week on the devel list for people to use a critical eye on it
[02:24:03] <SWPadnos> you know, we should be able to test functionality by pointing our machines at the dreamhost nameservers
[02:24:04] <jmkasunich> I'll leave that to you guys, I still haven't done much with it
[02:24:14] <SWPadnos> we can then use linuxcnc.org as the URL
[02:24:30] <alex_joni> SWPadnos: how do you mean that?
[02:24:59] <SWPadnos> I mean pointing DNS (resolv.conf) at Dreamhost for your local machine
[02:25:05] <alex_joni> did you put it into their namesers?
[02:25:24] <SWPadnos> yes, it's added as a domain on their site, which automatically adds it to their DNS
[02:25:40] <alex_joni> oh, cool.. what's the ns addy?
[02:25:43] <SWPadnos> though it isn't accessible anywhere else, because the root servers don't point there
[02:25:49] <SWPadnos> one sec - let me see if it works
[02:26:02] <SWPadnos> ns[123].dreamhost.com, I think
[02:26:07] <alex_joni> I want to dig linuxcnc.org @ns.dreamhost.com
[02:26:34] <alex_joni> linuxcnc.org. 14400 IN A 208.97.140.179
[02:26:39] <alex_joni> seems to work
[02:27:14] <SWPadnos> is that different from what you get with your normal nameservers?
[02:27:28] <jmkasunich> good news and bad news - the good news is that the compile farm is working
[02:27:32] <alex_joni> linuxcnc.org. 16004 IN A 64.124.155.133
[02:27:36] <SWPadnos> so it is
[02:27:37] <jmkasunich> the bad news is that slots 2 and 3 still fail
[02:27:41] <SWPadnos> bummer
[02:27:58] <alex_joni> jmkasunich: the farm runs a configure each time.. right?
[02:28:04] <jmkasunich> slot 5 passed tho (and I suspect slot 4 will too, its still chugging along)
[02:28:05] <jmkasunich> yes
[02:28:22] <jmkasunich> configure, make clean, make
[02:28:45] <SWPadnos> I wonder if it would make sense to try a clean checkout in the event of a failure?
[02:29:06] <jmkasunich> as opposed to cvs up -dP?
[02:29:17] <jmkasunich> that should work, if not something is screwy
[02:29:23] <SWPadnos> if up -dP fails, then make a clean dir and do a new checkout
[02:29:27] <jmkasunich> (besides, I'm too lazy to code all that)
[02:29:30] <SWPadnos> just in case
[02:29:38] <jmkasunich> I made the dirs and manually did the initial checkout
[02:29:57] <alex_joni> SWPadnos: it's highly unlikely that anyone touches the sources in the farm
[02:30:03] <jmkasunich> so the scripts don't know beans about how to do a checkout, what the module name is or anything like that
[02:30:13] <alex_joni> so cvs up -dP should always be IDENTICAL to a clean checkout
[02:30:18] <SWPadnos> I agree, but ther ecan possibly be issues that make clean doesn't remove, or cruft left over from an older compile
[02:30:33] <SWPadnos> true, for the sources, but not for generated files
[02:30:37] <jmkasunich> then a failure is good, we can investigate and fix make clean
[02:30:52] <alex_joni> * alex_joni agrees and goes to bed
[02:30:54] <SWPadnos> true
[02:30:55] <jmkasunich> another issue is disk space, a complete tree is something like 20-50 meg
[02:31:24] <jmkasunich> I don't want to have a runaway where some completely unrelated problem makes it do a fresh checkout every hour
[02:31:26] <SWPadnos> though you get more information if a clean checkout succeeds and an update doesn't
[02:32:24] <SWPadnos> nope - if fail, then clean checkout. if that succeeds, then log it that way (and save the failed log)
[02:32:56] <SWPadnos> I'd then swap to the clean directory, and do things from there
[02:33:09] <SWPadnos> (since it's less likely to break than the older one, I think)
[02:33:10] <alex_joni> SWPadnos: adding ns1.dreamhost.com on top of /etc/resolv.conf does the trick
[02:33:17] <SWPadnos> cool.
[02:33:35] <SWPadnos> unless that server goes down, in which case you'll be mighty confused ;)
[02:34:09] <alex_joni> I still have my regular ns in there
[02:34:15] <alex_joni> mighty 192.168.0.1
[02:34:17] <alex_joni> :D
[02:34:19] <SWPadnos> that's the confusing part ;)
[02:34:43] <SWPadnos> though the DNS cache would keep things working for a particular session
[02:35:14] <alex_joni> too much to think about at 4:30 am :)
[02:35:21] <SWPadnos> yep. good night ;)
[08:28:20] <Roguish_> Roguish_ is now known as Roguish
[15:22:02] <rayh> Hey Steven. Good additions to the fest page.
[15:22:13] <SWPadnos> thanks
[15:28:24] <jepler> some variation of 'cp -Rl' (recursive hardlink) from the CVS checkout tree to the build tree would avoid the extra space use of a true copy of the tree, while removing dependance on "make clean" working perfectly.
[15:30:15] <jepler> the clean, if any, should be run at the end of the run, not at the beginning of the next run. It's stupid to say that today's "make clean" should remove the .tmp directory that last year's Makefile created, even though the existence of that directory is what demonstrated the bug in depend.sh recently.
[19:51:41] <jmkasunich> quiet today
[19:51:50] <cradek> yep
[19:52:11] <cradek> I'm trying to fix a nice 21" monitor
[19:52:22] <cradek> too bad I don't know what I'm doing though
[19:52:24] <jmkasunich> tube?
[19:52:27] <cradek> yeah
[19:52:33] <jmkasunich> heavy
[19:52:38] <jmkasunich> don't shock yourself
[19:52:43] <cradek> yeah
[19:53:05] <cradek> a new horizontal output transistor changed it from completely dead to a 2" wide strip of video down the center - still obviously not right
[19:53:36] <cradek> but better than dead I guess
[19:53:44] <jmkasunich> might get dead soon
[19:54:05] <jmkasunich> sounds like a problem with the horiz deflection coils, maybe shorted turns or something
[19:54:24] <cradek> yeah the trick is finding the other problem before the new transistor goes (they're > $20 so I only bought one)
[19:54:25] <jmkasunich> could cause added stress on the new output transistor and toast it
[19:54:30] <cradek> yep
[19:54:42] <cradek> and no service information of course.
[19:54:47] <jmkasunich> of course
[19:55:00] <jmkasunich> I should have sent you one of the 18" LCDs I sent to fenn
[19:55:09] <jmkasunich> backlights are bad, but panels are fine
[19:55:20] <jmkasunich> then you could get rid of the tube
[19:56:04] <cradek> oh I've got no need for monitors - plenty of them around, it's just that this is a nice one I hate to see thrown out for the want of a few little parts
[19:56:23] <jmkasunich> I know the feeling
[19:56:27] <cradek> I do have a nice 21" lcd on my good computer
[19:56:40] <cradek> this one will go on my mill's machine if I happen to luck out and fix it
[19:56:41] <jmkasunich> I felt bad about tearing apart that 150CD library for a few mechanical parts
[19:57:04] <cradek> yeah, I bet it wasn't even broken
[19:57:11] <jmkasunich> probably not
[19:57:27] <jmkasunich> but I couldn't think of a good use for it
[20:01:39] <jmkasunich> this weekend I'd like to step back from threading and such and see what needs done before release
[20:02:05] <cradek> that sounds like a good idea
[20:02:36] <cradek> jeff says we need a stable branch where we quit messing it up long enough to test and release
[20:02:44] <cradek> and he's probably right
[20:03:07] <cradek> I'm tempted to say it should be before you changed the motmod stuff
[20:03:29] <cradek> the only real bugfix I know of since TESTING-2006-03-12 is the Fxxxx display units problem
[20:03:44] <cradek> maybe there were a few other small ones
[20:04:10] <jmkasunich> ray will probably want his tuning tool in the release
[20:04:32] <jmkasunich> I'd rather NOT do the release before the motmod change
[20:05:06] <jmkasunich> that change breaks things - I'd rather only break the people who are using testing, rather than breaking everybody when we do the next release
[20:05:25] <cradek> that's a good point.
[20:06:15] <jepler> If it's breakage we have to accept at some point before the release, then sooner is better than later.
[20:07:47] <cradek> so is anything broken right now?
[20:08:00] <jmkasunich> not that I know of
[20:08:15] <jmkasunich> the second half of the hal file change needs done
[20:08:23] <jepler> did my last build system changes fix anything, or just make it worse?
[20:08:49] <jmkasunich> http://linuxcnc.org/compile_farm/
[20:09:03] <jmkasunich> same as before - slots 2 & 3 fail, 4 & 5 work
[20:09:21] <jepler> bdi 2.xx actually builds if you upgrade make to the latest version
[20:09:25] <jmkasunich> so you fixed the temporary problem with slots 4 & 5
[20:10:20] <jmkasunich> whats involved in upgrading make? are there RPMs? (this is a RH6 based system, I have my doubts)
[20:10:41] <jepler> and it looks like the bdi-tng failure might not be due to the makefiles
[20:11:05] <jepler> I build make from source, copied it to /usr/local/bin, and then ran /usr/local/bin/make instead of make
[20:11:28] <jmkasunich> so non-trivial for the kind of folks a BDI is aimed at
[20:12:22] <jepler> not harder than building emc itself
[20:12:44] <jmkasunich> my feelings about support for the old BDIs are very mixed
[20:13:19] <jmkasunich> I'm not going to do anything to the compile farm slot (like a new make) that isn't made easily available (and spelled out in detail) to Joe user
[20:13:42] <jmkasunich> otherwise, the farm slot results become meaningless
[20:14:00] <jmkasunich> I'd rather drop support for 2.xx completely
[20:14:32] <jmkasunich> after all, its been a couple months now (I think) since the new build system was added, and it stopped working on BDI-2
[20:14:39] <jmkasunich> how many complaints have we gotten?
[20:15:04] <jepler> one person posted to the mailing list recently
[20:15:15] <jepler> that's why I started in on this last set of changes
[20:15:37] <jepler> I don't know which bdi he was using, actually
[20:16:33] <jepler> some system using rtl
[20:16:44] <jmkasunich> IF it was a bdi, it was 2.xx
[20:16:53] <jmkasunich> all the later ones use some flavor of rtai
[20:17:25] <cradek> it wouldn't surprise me if rtlinux is broken; I stopped using it and I think I was the only one
[20:19:16] <jepler> I say, dump support for all platforms for which there's no interested developer.
[20:19:42] <jmkasunich> that will pretty quickly mean ubuntu only
[20:20:43] <jmkasunich> to me its fairly important to have a "platform" that can run on older hardware
[20:21:03] <jmkasunich> ubuntu can do that as long as bloatware (aka Gnome) is avoided
[20:21:31] <cradek> for which there's no interested maintainer
[20:22:00] <cradek> doesn't have to be one of our developers, it can be anyone who's willing to keep up and submit a patch once in a while
[20:22:40] <jmkasunich> perhaps the BDI-2.xx and BDI-TNG slots should be dropped, and replaced by puppy or something else, hopefully something that is lightweight
[20:22:43] <jepler> That's more or less what I had in mind; I didn't have in mind the narrow list of "developers" that you might see on the sf website
[20:23:08] <jmkasunich> seems reasonable to me
[20:23:24] <jepler> but on the other hand, if someone provides high-quality patches, give them SF commit access.
[20:23:38] <jepler> (or even someone like me)
[20:23:58] <cradek> no argument there
[20:24:08] <jmkasunich> there are actually a couple issues wrt supporting multiple platforms
[20:24:16] <jmkasunich> one is things like this make incompatability
[20:24:21] <jmkasunich> the other is the source itself
[20:24:49] <jmkasunich> anyone who commits code, even if they don't give a flying fsck about platform X, should try to avoid breaking platform X without a damned good reason
[20:25:06] <jmkasunich> (thats what the farm is for - to alert people to such breakage)
[20:25:50] <jepler> If, on the balance of things, the Makefiles I wrote are not enough of an improvement to warrant dropping the old bdis, then revert it or tell me to revert it.
[20:25:54] <jmkasunich> thats also what rtapi was all about - the goal was that 99% of the code would have no system dependencies in it at all
[20:26:09] <jmkasunich> thats not where I was going at all
[20:26:25] <jmkasunich> a reliable depends system is worth far more than the old compiler support IMO
[20:26:37] <cradek> I have no doubt about that
[20:27:10] <jmkasunich> I'm talking about source breakage - if someone writes a new driver, or a new GUI or whatever, that should be done as portably as practical
[20:27:30] <jmkasunich> if they say "I only care about ubuntu, I tested this on ubuntu and it works, not my problem", then thats a problem
[20:28:50] <cradek> I don't think I've seen any of that kind of thing
[20:28:55] <jmkasunich> nope
[20:29:21] <jmkasunich> I'm just thinking about the implications of "support only platforms with an interested maintainer"
[20:29:56] <jepler> If not based on the presence of interested maintainers, how do we choose when to drop platform support?
[20:30:12] <jmkasunich> when supporting a platform hurts too much
[20:30:22] <jmkasunich> I'd say the gcc version thing meets that criteria
[20:30:50] <cradek> simply when it's more trouble than it's worth
[20:30:54] <jmkasunich> right
[20:31:05] <cradek> I think we can get together and evaluate that.
[20:34:24] <jepler> as for having a farm slot based on puppy, I don't think the development environment is available on the .iso
[20:35:37] <jmkasunich> oh
[20:35:54] <jmkasunich> does puppy have apt?
[20:36:14] <jepler> no, puppy is not based on apt or rpm
[20:36:22] <jmkasunich> oh. DI-4 iso's didn't have the complete dev environment either,
[20:36:25] <jmkasunich> oops
[20:36:54] <jmkasunich> The BDI-4 iso's didn't have the complete dev environment either, but we had a wiki page that walked you thru the steps to go from a base install to a build-ready one
[20:37:33] <jmkasunich> if thats not practical for puppy, then you're right, no reason to have it in the farm
[20:39:08] <jepler> I think those instructions are even right these days :-P
[20:39:40] <jmkasunich> s/had/have ;-)
[20:40:17] <jmkasunich> but the farm has nothing newer than BDI-4.20, so 4.27, 4.30 and 4.38 are a crapshoot
[20:40:36] <jepler> I'm now kinda-sorta regularly testing 4.38
[20:41:07] <jmkasunich> IIRC, I needed paul's help to get 4.20 installed in the farm - those "boxes" have small disks and weak graphics, they really prefer text only installs
[20:41:10] <jepler> I don't know how seriously the results should be taken, because it's a strange setup
[20:41:14] <jmkasunich> (which BDI doesn't have)
[20:41:22] <jepler> not gonna get much of that these days
[20:41:39] <jmkasunich> ubuntu has a server install
[20:41:44] <jepler> I mean, help from Paul
[20:41:51] <jmkasunich> oh, right
[20:42:11] <jmkasunich> which is why I haven't even tried to install a later BDI
[20:42:26] <jmkasunich> sometimes I think the entire farm is a waste of electricity
[20:42:32] <jmkasunich> othertimes I want to keep it going
[20:43:00] <jmkasunich> or even inprove it (email to the dev list on failure, for example)
[20:43:09] <jepler> What I've done is install 4.38 in qemu, then set it up so I can mount and chroot into the bdi 4.38 root on my real machine
[20:43:21] <jmkasunich> and decrease the lag from commit to build attempt and thus results
[20:43:53] <jepler> The only thing I had to do to get emc2 to compile was replace /bin/uname with a shell script that prints the right things
[20:44:25] <jepler> so the results are fast, and maybe even accurate
[20:44:45] <jmkasunich> I've never used qemu or anything like it
[20:45:12] <cradek> if I wanted to set up something like the farm, I'd try to do it with virtual machines
[20:45:14] <jepler> qemu is sloooowwwww but it can successfully emulate bdi2 and bdi4. I don't think I tried with bdi-tng, not sure why not.
[20:45:25] <jmkasunich> how slow?
[20:45:41] <jepler> it takes minutes and minutes to boot
[20:45:51] <jmkasunich> eww
[20:46:33] <cradek> so do pentium 166s?
[20:46:39] <jepler> otoh this chroot trick lets me check that emc2 and axis HEAD compile on "bdi 4.38" in around 2 minutes
[20:46:43] <jmkasunich> the farm slots are 200MHz Pentiums with 128K ram, so they don't exactly set speed records
[20:47:01] <jmkasunich> I have a dual P3-600 server box, if I could emulate the farm in that it would be interesting
[20:47:21] <jmkasunich> emc2 compiles take 10-20 mins on the farm
[20:47:27] <jmkasunich> TNG-Live is slowest
[20:47:28] <jepler> also, qemu really needs a live "X" to display to. vncserver might do.
[20:47:38] <jmkasunich> drat
[20:47:57] <jmkasunich> the dual P3 box is a server, has a pretty lame on-board graphics card
[20:48:12] <jmkasunich> it has PCI slots, but no AGP
[20:48:15] <cradek> lame video cards can run X...
[20:48:49] <jmkasunich> slowly, at low resolution, and low color depth
[20:49:15] <jepler> I assume, but don't know for sure, that qemu would work on a 256-color X server
[20:49:22] <jepler> bbl
[20:50:19] <jmkasunich> would vanilla ubuntu be a good host platform for QEMU?
[20:50:26] <cradek> sure
[20:50:33] <jmkasunich> maybe I should try to install it on that box
[20:50:33] <cradek> there is even a qemu deb that works fine
[20:50:43] <cradek> (it's how I run autocad)
[20:50:50] <jmkasunich> (actually, I'd want an SMP kernel to take advantage of the dual CPUs)
[20:51:12] <cradek> I'm sure there is one you can install with deb
[20:52:48] <jmkasunich> linux-image-2.6.12-10.686.smp?
[20:53:42] <cradek> sure
[20:55:37] <jmkasunich> so if I understand correctly, I'd install ubuntu and the SMP kernel on the box, then use qemu to install several distros on the same box (such as ubuntu with your kernel, bdi-x, puppy, or whatever)
[20:55:46] <jmkasunich> then I can have all of them running at the same time?
[20:55:57] <cradek> yes
[20:56:11] <cradek> in X windows, with networking
[20:56:26] <cradek> their filesystems are just a file on disk
[20:56:42] <jmkasunich> that box has 2x18G scsi drives, so plenty of space
[20:56:48] <cradek> yep
[20:56:55] <cradek> you could give each OS a few gigs each
[20:57:13] <cradek> to install, get the iso and qemu -cdrom thefile.iso
[20:57:26] <cradek> er, something like that
[20:57:30] <jmkasunich> oh, don't even have to burn the cd?
[20:57:34] <cradek> nope
[20:57:37] <jmkasunich> cool
[20:57:46] <cradek> you can use a real CD if you already have it
[20:57:58] <jmkasunich> cds seem to have a half-life of a few weeks at best in my basement
[20:58:44] <jmkasunich> if I set things up right, I could also ssh -x into the base system too, right?
[20:58:47] <cradek> I've noticed it's much lower if you never write on them what they are
[20:59:01] <cradek> sure
[20:59:19] <cradek> if you run the qemus in vnc, you could even pull up the screen containing all of them
[20:59:33] <cradek> then you don't need to run X on the actual machine
[20:59:44] <jmkasunich> right now I have an old 17" (maybe 15" tube) and a keyboard wedged into the top of the 19" rack, you have to stand to do anything, and there is no place to set the mouse
[21:00:03] <cradek> doesn't sound very comfortable
[21:00:16] <jmkasunich> doesn't normally get used much, only when there is a problem
[21:00:45] <jmkasunich> I wonder if I have a kvm cable long enough to reach?
[21:00:48] <jmkasunich> doubt it
[21:01:09] <jmkasunich> its only about 8 feet as the crow flies, but it goes past the furnace and some other stuff
[21:02:48] <jmkasunich> now if I can just find my ubuntu 5.10 CD
[21:03:23] <jmkasunich> and its not scratched
[21:03:44] <cradek> might be faster to download it again...
[21:04:03] <jmkasunich> I already have the iso
[21:04:23] <jmkasunich> but I can never remember the cdrecord incantation
[21:04:50] <cradek> in ubuntu, cdrecord file.iso seems to work
[21:05:12] <jmkasunich> it finds the drive all by itself?
[21:05:29] <cradek> seems to
[21:08:04] <jmkasunich> note to self: next time you have a dead CD to get rid of, don't break it in half
[21:08:11] <jmkasunich> shrapnel everywhere
[21:08:26] <cradek> haha
[21:08:34] <cradek> some make confetti instead
[21:09:06] <jmkasunich> I think I'm gonna go for it
[21:09:23] <jmkasunich> but I need to clear a spot on the bench first
[21:12:55] <cradek> I've got a resistor here and the colors appear to be yellow purple black orange brown
[21:13:04] <cradek> any idea what that means? It's too many stripes
[21:14:08] <jepler> http://www.epanorama.net/documents/markings/resistor_colorcodes.html
[21:14:49] <jepler> 470 x 1000 1%
[21:15:09] <cradek> hmm, so 470k
[21:15:17] <cradek> I think it reads ~ 220k
[21:15:19] <cradek> checking again
[21:15:30] <cradek> 220k isn't within 1% is it
[21:15:50] <jepler> um
[21:15:52] <jepler> let me check
[21:16:18] <jepler> no
[21:16:30] <jmkasunich> how many watts?
[21:16:37] <cradek> 1/4 maybe
[21:16:38] <jmkasunich> (power resistor or just generic)
[21:16:42] <cradek> generic
[21:16:48] <cradek> it's a little blue epoxy deal
[21:17:04] <jmkasunich> do a substution and see what happens
[21:17:10] <jmkasunich> (got a 470K laying around?)
[21:17:13] <jepler> "Resistor body colors white and blue are used to mark non-flammable resistors and fusible resistors. If you encounter [this] type of resistor in the circuit do not replace it with normal reistor because this would cause fire danger is something goes wring in the circuit."
[21:17:32] <cradek> blah blah blah
[21:19:00] <cradek> crap, it went down to ~ 470k this time
[21:19:02] <jmkasunich> if I did the math right it takes 342V across 470K to dissipate 1/4 watt
[21:19:15] <jmkasunich> "down" to 470K?
[21:19:21] <jmkasunich> you said it was 220K before?
[21:19:27] <cradek> uh, to the left on the meter is "down"
[21:19:37] <jmkasunich> oh, analog ohmeter
[21:19:47] <alex_joni> hello
[21:19:50] <cradek> hi alex
[21:19:51] <jmkasunich> hi
[21:19:52] <alex_joni> * alex_joni just got home
[21:20:17] <jmkasunich> I imagine for the qemu stuff, as much memory as I can get is a good thing?
[21:20:38] <alex_joni> jmkasunich: that's a rule that's always true
[21:20:41] <jepler> jmkasunich: qemu takes a few megs more than you want to give to the virtual machine
[21:20:47] <cradek> probably, if you're going to be running them all together
[21:21:01] <jmkasunich> it has 4 slots
[21:21:20] <jmkasunich> I have 2x256 and 1x64M in there now (robbed some of that from the other similar server)
[21:21:32] <alex_joni> so, what did I miss today so far?
[21:21:45] <jmkasunich> the other one now has no memory (its a single P2 400Mhz, I'll probably never use it)
[21:21:57] <jmkasunich> much changing of topic
[21:22:12] <jmkasunich> but we did _start_ talking about what's needed before release
[21:24:34] <alex_joni> ok, got a small summary?
[21:25:24] <jmkasunich> we got distracted almost immediately ;-(
[21:26:21] <alex_joni> wanna talk now?
[21:26:39] <alex_joni> cradek: no hiding allowed ;)
[21:27:11] <jmkasunich> well, I'm trying to do an install, and cradek is trying to fix a monitor
[21:27:50] <alex_joni> I see..
[21:27:54] <alex_joni> * alex_joni looks at Tasks
[21:28:36] <jmkasunich> the conversation started about 1.5 hrs ago, if you want to go back
[21:28:55] <jmkasunich> 15:01 here (its now 16:28)
[21:29:57] <jmkasunich> it took about 10 mins to divert to build issues on older BDIs, and another 20 to get onto compile farm issues totally unrelated to release
[21:35:41] <alex_joni> yeah, I've seen :)
[21:36:21] <alex_joni> https://sourceforge.net/pm/task.php?group_project_id=46285&group_id=6744&func=browse
[21:36:34] <alex_joni> looking at that I seen only "bridgeport" support still needed?
[21:36:46] <alex_joni> although quite a few people have been using testing
[21:37:03] <alex_joni> and no-one ever complained that something like that was missing
[21:40:07] <jmkasunich> probably most (by no means all) users are using the basic stepper configs
[21:40:14] <alex_joni> there is one thing I am concearned now, and that is that I don't really know the current status
[21:40:25] <alex_joni> e.g. what's working, what's not
[22:55:16] <cradek> hmm, found a burnt resistor
[22:55:31] <cradek> the colors are brownishyellow, blackish, blackish, blackish
[22:55:40] <cradek> anyone know what value that is?
[22:56:25] <alex_joni> brown=1
[22:56:37] <alex_joni> but there's brown, red, orange, yellow
[22:57:17] <alex_joni> http://engr.astate.edu/circuits/resistor-code1.jpg
[22:57:19] <cradek> I was trying to be funny - I don't think it's possible to tell the value of this one
[22:59:56] <alex_joni> cradek: 3 pins working on halui ;)
[23:00:05] <alex_joni> you can switch machine on/off and see the status :D
[23:00:25] <cradek> cool
[23:10:04] <jmkasunich> thats gonna be a hard resistor to figure out
[23:10:08] <jmkasunich> altho..
[23:10:27] <alex_joni> that sounds like 100 Ohm
[23:10:29] <jmkasunich> if the first color is yellow, only one 10% value starts with yellow - 47
[23:10:39] <jmkasunich> 40 * 10^? of course
[23:10:44] <jmkasunich> s/40/47
[23:10:59] <alex_joni> brown, black, black, black ?
[23:11:05] <jmkasunich> one other 5% value starts with yellow - 43
[23:11:23] <jmkasunich> he said yellowish brown, blackish, blackish, blackish
[23:11:31] <jmkasunich> due to it being overheated
[23:11:37] <alex_joni> ahhh.. ok
[23:11:45] <jmkasunich> anybody's guess as to what the original colors were
[23:11:53] <alex_joni> missed the first part of the conversation :)
[23:14:15] <cradek> well I know the third stripe isn't yellow (470k) and I have a hard time believing it was red or orange, so I'm going to guess 470
[23:14:35] <jmkasunich> what does the ohmmeter say it is now?
[23:14:45] <cradek> inf
[23:14:53] <jmkasunich> ah
[23:14:58] <cradek> to my great dismay
[23:15:00] <jmkasunich> what size?
[23:15:02] <alex_joni> does it still have legs on both sides?
[23:15:05] <jmkasunich> 1/4W, 1/2W?
[23:15:08] <cradek> yes it's intact
[23:15:10] <jmkasunich> bigger?
[23:15:12] <cradek> 1/4w flameproof
[23:15:28] <jmkasunich> any idea where it is in the circuit?
[23:15:33] <jmkasunich> ie what volts it might see
[23:15:53] <jmkasunich> 12V across 470 = 0.3W
[23:16:09] <jmkasunich> if it sees 12V all the time, it must be more than 470 ohms
[23:16:18] <cradek> it's between the drain of a mosfet and a pin on a small transformer
[23:16:52] <jmkasunich> the drain?
[23:16:58] <cradek> yes
[23:17:01] <jmkasunich> big mosfet? (TO-220 or more)
[23:17:06] <cradek> hmm, on the same pin is a 1kv capacitor
[23:17:13] <cradek> it's probably not 470 then is it
[23:17:21] <jmkasunich> hard to say
[23:17:23] <cradek> it is to220
[23:17:33] <cradek> let me find its datasheet
[23:17:42] <jmkasunich> anything else hooked to the mosfet drain?
[23:18:38] <cradek> diode cathode, 1kv .001u resistor
[23:19:05] <cradek> mosfet is 6.5A 200V
[23:19:08] <cradek> p-channel
[23:19:23] <jmkasunich> the cap is on the drain end of the resistor, or the xfmr end?
[23:19:37] <cradek> drain end
[23:19:55] <jmkasunich> p channel, thats odd
[23:20:26] <jmkasunich> I wonder if the proper value is 4.7 or even 0.47 ohms
[23:21:07] <jmkasunich> you're kinda wandering around in the dark unfortunately
[23:21:31] <cradek> the last two colors sure look the same
[23:21:47] <cradek> well the monitor works "a bit" with it open (some horizontal deflection)
[23:22:06] <jmkasunich> do you have 4.7K on hand?
[23:22:11] <jmkasunich> tack one in, see what happens
[23:22:45] <cradek> sure, what the hell
[23:22:52] <jmkasunich> how big is the transformer? 1" cube? half inch? 2 inches?
[23:23:33] <cradek> I think that could not have been red
[23:23:57] <cradek> 1" cube
[23:24:03] <jmkasunich> I suspect the actual value is lower
[23:24:20] <jmkasunich> but if infinity doesn't make smoke, I'd start high and work down ;-)
[23:25:30] <jmkasunich> if thats the only drain feeding the xfmr, then all power to the xfmr probably comes from the fet, thru the resistor
[23:25:40] <jmkasunich> so the proper value is pretty low I think
[23:26:02] <jmkasunich> the problem is if the reason it burnt was an excessive load on the xfmr (some other bad part)
[23:26:07] <jmkasunich> you'll just smoke the new one
[23:26:14] <cradek> the HOT was bad
[23:26:23] <cradek> it's fixed now but not being driven right
[23:28:00] <jmkasunich> is this xfmr the drive xfmr by chance?
[23:29:13] <cradek> some of this transformer hooks to the C of the HOT
[23:29:31] <jmkasunich> the C?
[23:29:36] <cradek> collector
[23:29:39] <jmkasunich> right
[23:29:40] <cradek> it's NPN
[23:29:44] <jmkasunich> but thats strange
[23:29:52] <cradek> yeah
[23:29:54] <jmkasunich> C = output
[23:29:58] <jmkasunich> D = outout
[23:30:14] <jmkasunich> why a HOT and a FET both driving the xfmr?
[23:30:50] <cradek> no clue
[23:31:10] <cradek> I don't know monitors very well
[23:32:06] <jmkasunich> neither do I, theres some black magic in the deflection stuff
[23:32:14] <jmkasunich> especially multisync
[23:32:18] <cradek> yep
[23:34:11] <cradek> the other nearby resistors of this type have odd colors too
[23:34:28] <jmkasunich> dang, memtest86 takes a long time
[23:34:52] <jmkasunich> odd as in burnt, or odd as in non-standard values?
[23:35:28] <cradek> not burnt, just not familiar values
[23:35:56] <cradek> a bunch of grey black gold gold?
[23:36:09] <jmkasunich> grey black = 91
[23:36:18] <cradek> red white? grey? gold
[23:36:21] <jmkasunich> gold gold might be x0.1 or x0.01
[23:36:46] <jmkasunich> I mean, first gold might be 0.1 or 0.01, second gold is probably tolerance
[23:37:14] <jmkasunich> ISTR silver = x0.1 and gold = x0.01, but not sure
[23:37:22] <cradek> they should print the values on flameproof resistors like they do on wirewounds
[23:37:31] <jmkasunich> that would make it too easy
[23:37:37] <cradek> because the colors are obviously destroyed when they go out
[23:37:56] <jmkasunich> actually, the builder would probably install the resistors with the numbers facing down, just to make it more interesting for you
[23:46:58] <cradek> jmkasunich: I think I see a hint of X X gold gold
[23:47:17] <jmkasunich> on the burnt one?
[23:47:23] <cradek> yes
[23:49:41] <alex_joni> cradek: lots of great ideas in that doc
[23:49:50] <alex_joni> even if it's from 2003, most of it is stil actual
[23:49:54] <alex_joni> and not done
[23:50:08] <alex_joni> also a bit about lathe stuff, you might want to read that once of these days
[23:50:19] <cradek> alex_joni: ok
[23:51:03] <alex_joni> grep for "New features:"
