Back
[00:38:31] <alex_joni> cradek: still there?
[00:39:44] <cradek> yeah
[00:39:47] <cradek> hi
[00:40:18] <alex_joni> hi, couldn't sleep :)
[00:40:33] <cradek> no work tomorrow right?
[00:40:33] <alex_joni> just sent an reply to Mario.. tell me what you think!?
[00:40:42] <alex_joni> no work till on the 8th I think
[00:41:50] <cradek> I don't want to say exactly what I think :-)
[00:42:06] <cradek> I mean your reply is fine
[00:42:50] <cradek> but mario has sent ten messages without really describing the problem or showing us exactly the error message -- I doubt the eleventh will be any different
[00:43:52] <jepler> the exact error text isn't there, but I found his description to be pretty clear (if hard to believe)
[00:43:55] <alex_joni> yeah, probably so
[00:44:05] <alex_joni> jepler: really?
[00:44:07] <jepler> he moves the slider and gets the latency pop-up
[00:44:13] <jepler> he never gets it any other time
[00:44:20] <jepler> uh oh, being called away...
[00:44:31] <cradek> I think he does get it other times
[00:45:00] <cradek> changing between vesa/nvidia/nv drivers makes (something?) better or worse
[00:45:08] <alex_joni> "I was trying hard to reproduce the bug again - it is very rare when the network does not work"
[00:45:15] <cradek> I'm going to go read them all again
[00:45:20] <alex_joni> this tells me it's still a RT problem
[00:45:25] <alex_joni> not an emc2 issue
[00:45:40] <cradek> did he say if he ran the rtai kern latency test?
[00:45:48] <cradek> that's where he needs to start
[00:46:03] <alex_joni> I asked him specifically to do that
[00:46:11] <alex_joni> and he said he already wrote that he did so..
[00:46:15] <alex_joni> although I can't believe that
[00:49:45] <cradek> I wonder if maybe the part where he says "could bring it to knees od 19337 ns" is talking about the kern/latency test
[00:50:04] <cradek> time between calls to motion controller of 0.957ms, 1ms,
[00:50:04] <cradek> 1ms, 1ms, 1ms and last one 1.053ms.
[00:50:21] <cradek> this part of that message is what made me change the 1.1 to 1.2 tonight
[00:50:24] <SWPadnos> he was talking about MHz pulse streams in software, I wonder if his BASE_PERIOD is insanely low
[00:50:31] <alex_joni> 20000
[00:50:35] <SWPadnos> hmmm
[00:50:36] <alex_joni> not that low
[00:50:38] <cradek> yes somewhere he said 20000
[00:50:46] <SWPadnos> ok - I didn't download the file he linked to
[00:50:47] <alex_joni> cradek: it's in the ini he sent
[00:50:52] <alex_joni> * alex_joni did
[00:51:42] <cradek> there are two configs in there - wonder which he's using
[00:52:33] <cradek> # DISPLAY = tkemc ; heeeheeeheee
[00:52:35] <cradek> ??
[00:53:00] <cradek> yes base 20000, servo 1000000, traj 4000000
[00:53:15] <alex_joni> ; Canon printer - test connect for real application
[00:53:21] <alex_joni> wonder why he changed traj
[00:53:56] <alex_joni> PROBE_INDEX = 0
[00:53:56] <alex_joni> PROBE_POLARITY = 1
[00:54:04] <alex_joni> do we still have that crap in the ini's ?
[00:54:38] <alex_joni> oh.. it seems all the ini's have that :/
[00:54:41] <cradek> yes
[00:55:39] <alex_joni> anyways.. odd that he changed the traj period
[00:56:24] <cradek> did he say what version of emc2?
[00:57:08] <SWPadnos> 2.0.5
[00:57:13] <alex_joni> yeah
[00:57:14] <SWPadnos> in his first email
[00:57:20] <cradek> ok
[00:58:52] <cradek> he talks about 1ms stalls but I don't know what he means by that
[00:59:42] <cradek> "between calls to motion controller"
[00:59:58] <SWPadnos> it's been unclear to me whether he's been looking at dmesg, and oscilloscope, tMax, or some combination
[00:59:59] <cradek> but the motion controller is *supposed* to be called every 1ms
[01:00:26] <cradek> one time he mentions dmesg, but gives us his interpretation of the message instead of the message itself.
[01:01:48] <cradek> frustrating.
[01:02:02] <alex_joni> hmm.. reading his email about tty1..tty7, I'm not sure if he means the FEED OVERRIDE slider, or the Jog slider
[01:02:08] <alex_joni> he's talking about both
[01:02:24] <alex_joni> and I'm not sure how he can change CPU speed..
[01:02:33] <alex_joni> that shouldn't be possible with the magma kernel
[01:02:50] <SWPadnos> I thought that was different machines
[01:05:39] <alex_joni> cradek: can you run an emc2 with a TRAJ value of 4000000 ?
[01:05:51] <alex_joni> TRAJ_PERIOD I mean
[01:06:04] <alex_joni> * alex_joni can't run his machine right now
[01:06:15] <alex_joni> hopefully a new PSU will fix it :/
[01:07:56] <cradek> alex_joni: no problem when I do that
[01:08:26] <cradek> 999849 YES servo-thread ( 27991, 67201 )
[01:08:27] <alex_joni> ok, thanks
[01:10:13] <cradek> make sure you're telling them the raw symptoms of what goes wrong, rather than your interpretations and theories. Let them do the interpretation and diagnosis. ("How to ask questions the smart way" by ESR)
[01:11:16] <alex_joni> heh.. right :)
[01:11:53] <cradek> some other things apply too, but I won't waste everybody's time :-)
[01:12:09] <alex_joni> only "some" ?
[01:23:13] <alex_joni> think I'll go to bed now
[01:23:15] <alex_joni> g'night all
[01:28:01] <cradek> night
[01:28:47] <jmkasunich> * jmkasunich searches for aluminum rod
[01:32:06] <jmkasunich> * jmkasunich finds aluminum rod... woot!
[01:49:28] <jepler> alex_joni: if you build your own rtai kernel you can enable stuff like CPU frequency switching .. but actually switching at least appears to trigger missed periods, because clocks-per-second changes
[01:49:47] <jepler> has he said whether he's using our magma kernel or some other rtai kernel?
[01:51:47] <jepler> * jepler disappears again
[01:52:00] <cradek> no he doesn't say.
[02:41:57] <cradek> I'm helping a guy who's building a new machine and wants to make a tool changer of the kind we fear - the tools in a grid on the table
[02:43:13] <jmkasunich> how are you approaching it?
[02:43:14] <cradek> so that'll be interesting :-)
[02:43:19] <cradek> we're not yet
[02:43:25] <cradek> he has lots of work to do first
[02:43:37] <jmkasunich> I know how I would, dunno if you'd consider it crufty or not
[02:43:59] <cradek> if it were my machine I'd just write it in C. it'd be easy.
[02:44:14] <jmkasunich> set emc's existing tool change position direclty above tool (0,0)
[02:44:16] <cradek> he may be happy enough writing the gcode
[02:44:35] <jmkasunich> once there, add in (using HAL) a move to the proper tool location relative to 0,0
[02:44:53] <jmkasunich> use limit3 blocks to control accel and vel during the move
[02:46:05] <cradek> so you'd use an intricate HAL setup and CL for sequencing?
[02:46:14] <jmkasunich> yeah
[02:46:20] <jmkasunich> not that intricate really
[02:46:46] <cradek> well it's at least four moves that you have to sequence
[02:46:47] <jmkasunich> lots of small blocks instead of one big one with the complexiiy hidden inside, thats all
[02:47:07] <jmkasunich> how many positions?
[02:47:19] <cradek> don't know yet
[02:47:20] <jmkasunich> start, above tool, on tool, above tool, start, right?
[02:47:25] <cradek> yes
[02:47:33] <jmkasunich> ok, four input mux
[02:47:41] <jmkasunich> (three, one per axis)
[02:48:11] <jmkasunich> one input is zeros (normal) one is offset to tool in X,Y only, one is X,Y,Z
[02:48:21] <jmkasunich> CL cycles thru the mux select inputs
[02:48:43] <jmkasunich> the limit3 blocks are on the mus outputs, so even tho the command changes instantly, the final position is ramped
[02:48:50] <cradek> how would you see when the move is done?
[02:49:10] <cradek> ok, I understand how it moves
[02:49:20] <jmkasunich> window comparator, comparing either feedback pos or the limit3 output to its input
[02:49:49] <jmkasunich> when the difference is less than 0.005, wait another second or so, then go to the next step
[02:49:52] <cradek> how would you do the table of X,Y vs tool number?
[02:50:00] <jmkasunich> that might be tricky
[02:50:07] <jmkasunich> uniform matrix, or arbitrary?
[02:50:15] <cradek> say uniform
[02:50:27] <cradek> the mx+b component
[02:50:34] <jmkasunich> if uniform, use SWPadnos's modmath component to break the number into row and column
[02:50:44] <jmkasunich> then scale blocks for each
[02:50:52] <cradek> yeah
[02:50:55] <jmkasunich> 2.234" per row, 4.321" per column
[02:51:12] <cradek> this is ambitious for a newbie :-)
[02:51:30] <jmkasunich> depends on how clueless he is
[02:51:39] <cradek> he's clueful
[02:51:54] <jmkasunich> I figured, otherwise you wouldn't have gotten sucked into helping him
[02:52:25] <jmkasunich> for something that complex (or even half that complex) in HAL, I'd almost certainly draw it up schematic style
[02:52:26] <cradek> right
[02:52:39] <jmkasunich> label all the pins, name all the signals, then start writing a HAL file
[02:52:40] <cradek> yeah you'd need a big picture to work from.
[02:53:17] <cradek> forgive me, but I'd still write it in C (in task)
[02:53:32] <cradek> it could do things like start and finish over the current position
[02:53:34] <jmkasunich> you're allowed
[02:53:45] <cradek> yeah isn't free software great?
[02:54:16] <jmkasunich> the thing is, your task is now forked from the main task, and as things change in the main one, you need to update manually
[02:54:30] <cradek> yep
[02:55:12] <jmkasunich> there should be a way that a C (or other language) program can step in and "take over" for a while, then step back and let EMC run things again
[02:55:17] <cradek> but if you do it in a branch like v2_1_branch it will be a pretty safe bet that cvs merge will be fine for any other bugfix
[02:55:17] <jmkasunich> without changing the core of EMC
[02:55:35] <jmkasunich> why can't custom M codes invoke a special program?
[02:55:44] <jmkasunich> well, they can
[02:55:49] <cradek> sure but they can't move the machine
[02:55:50] <jmkasunich> why can't such a program do what you need
[02:56:03] <cradek> (without the same hal gymnastics)
[02:56:24] <cradek> and the whole point is to use M6 to change tools
[02:56:36] <jmkasunich> I know
[02:56:52] <cradek> if you're willing to make the gcode specific to your machine, you'd just program the G0 moves
[02:56:56] <jmkasunich> and IMO, that kind of "gymnastics" is exactly why we have HAL
[02:57:25] <cradek> I agree it would be an interesting exercise in hal.
[02:57:38] <cradek> heck maybe we should do it as an example
[02:57:39] <SWPadnos> I don't think HAL is ideal for this
[02:57:50] <jmkasunich> real machines (like the mazak) have hundreds of rungs of ladder to do things like that
[02:57:53] <cradek> SWPadnos: I don't recall anyone saying that
[02:57:55] <cradek> :-)
[02:58:00] <SWPadnos> it'll work, but it's not the solution that should be a goal :)
[02:58:01] <SWPadnos> nope ;)
[02:58:47] <jmkasunich> they use ladder specifically because it can be customized to the machine
[02:58:59] <cradek> can the ladder cause motion?
[02:59:12] <jmkasunich> with hal tricks, yes
[02:59:20] <jmkasunich> you call them tricks anyway
[02:59:23] <cradek> I mean on "their" setup
[02:59:30] <cradek> maybe I misunderstand
[02:59:32] <jmkasunich> not sure
[02:59:50] <jmkasunich> thats a question for people like ray who have worked on traditional controls
[03:00:04] <jmkasunich> I do know I saw pages and pages of ladder in the mazak manual
[03:00:17] <jmkasunich> I dunno if any of that for example commanded quill up prior to a toolchange
[03:00:31] <cradek> is that documentation or is there a configurable ladder somehow on the machine?
[03:00:47] <SWPadnos> configurable by rewiring and replacing parts, I'd bet :)
[03:00:53] <jmkasunich> probably "configurable" only by a factory technicial
[03:01:01] <jmkasunich> technican
[03:01:30] <jmkasunich> SWPadnos: no, the CNC techs who were there refered to part of what we pulled out as "the PLC"
[03:01:41] <jmkasunich> it was most certainly NOT hardwired relay logic
[03:01:52] <SWPadnos> cool - modern then :) (not RRL)
[03:02:15] <jmkasunich> the ladder in the manual was almost certainly a "listing" of a PLC program
[03:03:06] <jmkasunich> I think at one point early on (before we ripped everything out, or maybe it was on the other machine) Jack had a ladder on the monitor and was checking stuff
[03:03:25] <SWPadnos> I'm glad to not know the Mazak that well ;)
[03:03:38] <jmkasunich> Jack (don't remember his last name) is a CNC techician who works on Mazaks for a living
[03:08:52] <jmkasunich> for the grid toolchanger, I don't think I'd mess with adding an offset to the EMC position at all
[03:09:16] <jmkasunich> I'd just replace the EMC position with the tool position, while faking EMC's position feedback
[03:09:49] <jmkasunich> that way it would go direct from wherever you stopped to the tool, and then back to that spot
[03:09:50] <cradek> yeah you'd have to hold emc's feedback steady while you did all this
[03:09:57] <jmkasunich> mux2
[03:10:09] <jmkasunich> one control bit called "in-tool-change"
[03:10:12] <SWPadnos> but still use the real feedback for PID positioning
[03:10:48] <jmkasunich> when true, it would a) switch EMC's feedback to its own command instead of the real fb, and b) switch the real command from EMC's output to the tool position
[03:10:50] <cradek> you lose following error aborts with this scheme
[03:11:20] <jmkasunich> true, because following error is built into EMC instead of the motor control part
[03:11:59] <SWPadnos> the fact that you have to duplicate trajectory limitations (like accel and vel) should be a warning that you're doing something - err - not ideal
[03:12:12] <jmkasunich> true...
[03:12:13] <SWPadnos> and other things ...
[03:12:29] <jmkasunich> the problem is that the core of EMC is monolithic (pretty much)
[03:12:42] <cradek> this "obviously" belongs in task where the existing tool change motion is
[03:12:52] <cradek> the only reason we don't want to put it there is it's compiled
[03:12:55] <jmkasunich> since its so much easier to insert custom stuff at the hal level, thats where I want to do it
[03:13:15] <SWPadnos> yes, though there have been discussions about features that could accomplish this in the interp/task - like "machine macros" for various M codes (or G codes) ...
[03:13:15] <jmkasunich> cradek: this is personal bias only, but for me thats not the only reason
[03:13:23] <jmkasunich> its compiled, and its stuff that I don't understand
[03:13:49] <jmkasunich> stuff with messages flying back and forth, and state, and all kinds of other confusing stuff
[03:15:16] <cradek> hmm now that I look at it, I know how to do the motion but not the IO.
[03:15:22] <jmkasunich> lol
[03:16:03] <cradek> ah SET_AUX_OUTPUT_BIT() etc
[03:16:11] <cradek> ok I know how to do it, no problem
[03:16:37] <jmkasunich> in C I assume?
[03:16:40] <cradek> yes
[03:16:53] <cradek> I think I could do it in 20 mins.
[03:17:05] <SWPadnos> configurable?
[03:17:20] <jmkasunich> can you decouple it so he doesn't have a custom task?
[03:17:59] <cradek> no to both. I just mean I know how to do it in the most basic way at the task level.
[03:18:42] <SWPadnos> well, that's a start
[03:19:02] <cradek> I wonder how you'd know what to do with the tool that's (maybe) in the spindle when you start up
[03:19:33] <SWPadnos> you'd probably need to save a var or something
[03:20:23] <cradek> * cradek shivers
[03:21:00] <cradek> or just always empty it, by hand at startup time if necessary
[03:24:14] <jmkasunich> that problem came up with the mazak too
[03:24:27] <jmkasunich> its a general toolchange problem, not unique to the grid configuration
[03:25:05] <SWPadnos> it's a generic problem, not restricted to toolchange
[03:25:09] <jmkasunich> there should probably be a piece of state info (IMO available in HAL ;-) that says "the tool currently in the spindle is tool N
[03:25:30] <jepler> there is -- it's just wrong at startup
[03:25:38] <SWPadnos> that only helps if you do a hal save and restore between runs
[03:25:39] <jmkasunich> ok, two problems - the "current tool" problem and the "retained over power cycle" problem
[03:25:44] <jmkasunich> jepler: there is?
[03:25:46] <jmkasunich> I don't think so
[03:25:52] <SWPadnos> or in the event of a software crash or PC hardware failure ...
[03:26:00] <jepler> maybe not -- there's the requested tool number
[03:26:06] <jmkasunich> SWPadnos: I dunno what you mean by hal save/restore
[03:26:29] <jmkasunich> I mean, EMC should output the current tool number, and (after an Tn) the prep tool number
[03:26:33] <SWPadnos> in other words, at astartup, the tool number in HAL (if ther ewere one) would be wrong, unless it had been saved before shutdown previously
[03:26:39] <jmkasunich> after the change, current would = prep
[03:27:12] <SWPadnos> sure, but that doesn't tell you where to put the one in the spindle at startup, which is the problem cradek was thinking about, I think
[03:27:33] <jmkasunich> if its getting to HAL from emc, it can get to EMC from the var file
[03:27:38] <cradek> I think it does, if you know which tool number it is that you have
[03:28:08] <SWPadnos> henc ethe var or other save method
[03:28:11] <jmkasunich> right
[03:28:48] <jmkasunich> right now, emc outputs the new tool number on tool-prep, and it remains valid until tool changed
[03:28:57] <jmkasunich> then it pretty much forgets all about that tool
[03:29:06] <jmkasunich> until you request the next tool prep
[03:29:17] <jmkasunich> all I'm suggesting is that it not forget
[03:29:32] <jmkasunich> it outputs the current tool on a hal pin, and saves it in the var file on shutdown
[03:29:45] <jmkasunich> at power up, it reloads that number and outputs it to hal again
[03:29:59] <jmkasunich> of course it would be available in the code as well, for cradek ;-)
[03:30:17] <SWPadnos> and hopefully nobody will mess with the tool while the machine is off ;)
[03:30:24] <jmkasunich> well, that is always a risk
[03:30:36] <jmkasunich> power down a machine in the middle of a toolchange, and you have a mess
[03:30:40] <jmkasunich> regardless of the machine
[03:30:48] <cradek> like my tape changer, the tool holders need barcodes, then you need a laser scanner...
[03:30:54] <jmkasunich> the mazak manual had pages of "how to recover from that mess"
[03:31:08] <cradek> you'd turn the machine on, and it would carefully look around and take inventory
[03:31:19] <jmkasunich> cradek: that would be cool, until they got crudded up
[03:31:49] <jmkasunich> there are some machines out there that speed up toolchanges by putting the old tool in the slot vacated by the new tool, instead of its original slot
[03:32:00] <jmkasunich> so over time the tool table gets _all_ screwed up
[03:32:04] <jmkasunich> but they keep track of what is where
[03:32:07] <cradek> yeah, all the more important to scan at startup then
[03:32:38] <cradek> seems like this can be almost arbitrarily hard
[03:33:18] <jmkasunich> thats why I don't like doing it in the "code"
[03:34:46] <jmkasunich> doesn't matter if its HAL, custom M codes, locked g-code subroutines, ladder - there needs to be some way that a sophisticated integrator can do sophisticated things without rewriting the actual control software
[03:35:33] <jmkasunich> even if its some stand-alone executable sending NML messages - the point is that its NOT part of the main code
[03:46:37] <jmkasunich> didn't mean to kill off the discussion...
[03:47:00] <SWPadnos> I think tiredness killed it for me
[03:47:03] <SWPadnos> good night :)
[03:47:21] <jmkasunich> goodnight
[04:06:38] <cradek> heck I didn't even mean to start a big discussion
[04:10:18] <jmkasunich> ;-)
[04:10:36] <jmkasunich> thats ok, I didn't let it stop me from working
[04:11:08] <jmkasunich> got my mobo mounted to a plate, now trying to figure out how to mount the hard disk
[04:11:37] <cradek> the screw holes on the bottom are handier than the ones on the sides
[04:11:45] <jmkasunich> yeah
[04:11:57] <jmkasunich> I'm trying to levitate the drive over the mobo to save panel space
[04:12:12] <cradek> mounted to the lid?
[04:12:21] <jmkasunich> I have 8" of height to work with, the mobo and interface cards are only 5" high
[04:13:21] <jmkasunich> no lid
[04:19:51] <jmkasunich> http://jmkasunich.dyndns.org/shoptask/pc-panel-1.jpg
[04:19:55] <jmkasunich> http://jmkasunich.dyndns.org/shoptask/pc-panel-2.jpg
[04:21:06] <jepler> jmkasunich: if you ask nicely, I happen to know chris has a 20 megabyte hardcard somewhere in his basement ..
[04:21:12] <jepler> ISA but I see you have an ISA slot there
[04:21:25] <jepler> then you don't need a separate hard drive at all
[04:21:30] <jmkasunich> oh chris......
[04:21:51] <jmkasunich> just need to put an entire distro in 20meg thats all
[04:21:53] <jepler> actually what you want is an inexpensive IDE-CF adapter and a 2- or 4-gig CF card
[04:22:57] <jmkasunich> will CF work for normal day-to-day usage as the main drive?
[04:23:17] <jepler> I don't have a good idea of the # write cycles CF will do
[04:23:26] <jepler> it's probably a bad idea to use it for swap, so you'd have to do without
[04:23:32] <jmkasunich> I'm more comfortable with a regular drive
[04:23:34] <jepler> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=150074334627
[04:23:54] <jepler> anyway .. 'night
[04:23:58] <jmkasunich> goodnight
[04:24:46] <jmkasunich> I'm thinking of a plate that attaches to the two screw holes visible on the top flange of my "back panel"
[04:24:55] <jmkasunich> and is supported somehow at the front edge of the mobo
[04:25:00] <jmkasunich> then mount the disk to that
[04:25:23] <jmkasunich> gotta remove the plate to swap video or nic cards, but thats not a big deal
[04:25:30] <jmkasunich> or a frequent event
[04:32:55] <jmkasunich> damn, I should have saved more of the sheet metal from the compile farm
[04:35:55] <cradek> two network cards?
[04:36:59] <jmkasunich> I just stuck that in there when I was aligning the back panel
[04:37:16] <cradek> ah
[04:37:30] <cradek> you could mount the drive on edge right next to the board - looks like enough metal leftover
[04:37:52] <jmkasunich> yeah, just barely
[04:37:58] <cradek> two screws is plenty
[04:38:05] <jmkasunich> I was hoping to shockmount it
[04:38:15] <jmkasunich> two screws with shockmounts would be floppy
[04:38:36] <cradek> yeah
[04:38:46] <jmkasunich> but you gave me an idea
[04:39:00] <cradek> shockmount this whole thing?
[04:39:08] <jmkasunich> see the flange at the far edge of the back panel in pic 2?
[04:39:33] <jmkasunich> I wanted to put a "wall" of sorts along that end, that would brace the back panel
[04:39:39] <jmkasunich> I could mount the drive to the outside of the wall
[04:39:54] <cradek> that'll work nicely
[04:40:09] <cradek> ... or the inside, if you don't need your last isa slot
[04:40:20] <jmkasunich> good point
[04:40:30] <cradek> I assume you won't need any of the isa
[04:40:31] <jmkasunich> I don't think I'll need either isa slot ;-)
[04:42:27] <jmkasunich> now I just need to figure out how to attach the lower edge of that wall to the baseplate
[04:42:51] <cradek> you have a sheet metal brake, don't you?
[04:43:11] <jmkasunich> I wish
[04:43:17] <jmkasunich> no brake or shear
[04:43:18] <cradek> yeah, me too
[04:43:29] <cradek> sucks to improvise
[04:43:32] <jmkasunich> that nice back panel came from the compile farm
[04:43:44] <jmkasunich> I'm kicking myself for not saving more parts of that
[04:43:58] <cradek> maybe you'll need some little aluminum angle
[04:44:07] <jmkasunich> lots of pieces with nice 90 degree flanges, even had pem nuts in the flanges
[04:44:15] <cradek> darn
[04:44:49] <jmkasunich> murphy's law of cleaning
[04:45:28] <cradek> it's nice that you won't have any crappy little fans to fail (processor/video card)
[04:45:28] <jmkasunich> I have another 6" or so of that back panel stuff
[04:45:40] <jmkasunich> actually, I think I want a CPU fan
[04:45:46] <jmkasunich> it got pretty warm without one
[04:45:57] <jmkasunich> the original design used the power supply to suck air over the CPU
[04:46:15] <cradek> I bet you could run it a little slow and save a lot of heat
[04:46:23] <cradek> or is it slow enough as-is
[04:46:26] <jmkasunich> run the processor slow?
[04:46:39] <jmkasunich> never fast enough...
[04:47:05] <jmkasunich> I have a fan that (dumb luck) plugs into the mobo, runs nice and quiet
[04:47:32] <cradek> I bet I could find you a PIII heat sink with built-in fan, just say the word
[04:47:38] <jmkasunich> when I was thinking of a "roof" to mount the disk to, I was just gonna mount the fan to the roof too, blowing on the CPU
[04:48:10] <cradek> you'll have air blowing through the whole box - I bet you won't need anything special here
[04:48:28] <cradek> hmm I should go to bed too.
[04:49:05] <jmkasunich> I have a P2 with a fan on it, wonder if I could swap it over
[04:49:34] <cradek> yes I think they mount the same way
[04:49:50] <jmkasunich> not this one
[04:50:11] <jmkasunich> the P2 has an extrusion with about 1/2" high fins running the length of the CPU
[04:50:17] <jmkasunich> fan blows into the center, out the ends
[04:50:23] <cradek> most go through the CPU card and have a sliding clip on the back
[04:50:32] <jmkasunich> the P3 has pin fins about 1" long
[04:50:38] <cradek> but unfortunately there are many other schemes too
[04:50:55] <jmkasunich> are you talking about swapping fan and sink together?
[04:50:59] <cradek> yes
[04:51:05] <jmkasunich> oh
[04:51:26] <cradek> especially if they have the pins that go through and into a metal sliding clip
[04:51:32] <jmkasunich> I wonder if a P2 sink would be enough for a P3 (assuming I can figure out the mounting)
[04:51:43] <cradek> yeah I bet so
[04:52:10] <cradek> they both were found in the wild with passive cooling only, I bet they're pretty compatible
[04:53:34] <jmkasunich> this P2 is 266MHz
[04:53:48] <jmkasunich> I'm gonna sacrifice it, see how the sink is held on
[04:53:55] <jmkasunich> (its not obvious from the outside)
[04:54:13] <cradek> goodnight
[04:54:29] <jmkasunich> goodnight
[04:56:08] <jmkasunich> this sink appears to be rivited on
[15:46:10] <jepler> jmkasunich: you ought to set LANG=C on the compile farm, to get rid of the unicode quote marks in the compiler output
[16:12:00] <alex_joni> cradek: seems Mario is finally starting to give usefull info
[16:14:30] <SWPadnos> even more coming when he gets the network reconnected :)
[16:14:32] <cradek> yes I'm glad about that
[16:14:42] <cradek> I hope he makes another reply with the exact error messages
[16:15:26] <cradek> I don't understand whether he's using the packages, or he built emc from source
[16:15:51] <alex_joni> I think he built emc from source
[16:17:21] <SWPadnos> emc from source, but not the RT stuff (apparently)
[16:25:38] <alex_joni> right, that's my interpretation too
[16:25:49] <alex_joni> he seems to clueless about a rtai install from source
[16:26:15] <alex_joni> (not clueless in general, just about RTAI)
[16:27:22] <SWPadnos> hmmm - is that how the detection works - a 10% change from any recent sample, or a 10% change from the expected value?
[16:30:26] <cradek> any recent sample
[16:32:03] <SWPadnos> ok
[16:32:14] <cradek> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/motion/control.c?rev=1.52.2.3;only_with_tag=RELEASE_2_0_5
[16:32:19] <SWPadnos> I'm not sure that makes sense
[16:32:22] <cradek> search for 'overrun detection'
[16:32:51] <cradek> well there is really no expected value available - sadly all you have to work with is cpu cycles
[16:32:53] <SWPadnos> ok. thanks (tjhis stupid windows machine is being flaky - I can't do anything that requires a file browser, such as open a file ...)
[16:33:46] <SWPadnos> somewhere within RTAI there is a variable that would give us the conversion from nanoseconds to CPU cycles
[16:33:54] <SWPadnos> sadly, I'm not sure where that variable is
[16:34:20] <jepler> I don't know about RTAI but there is one in kernel 2.6
[16:34:22] <cradek> it's possible this test is overly sensitive (I changed it to 1.2 in head)
[16:34:45] <cradek> this is a stupid hack
[16:34:53] <jepler> see the "Notes" section of rtapi_get_clocks()
[16:35:07] <SWPadnos> it seems that it would usually test half the span
[16:35:24] <SWPadnos> since you'd expect a short period to be followed by a longer one, or vise versa
[16:35:45] <SWPadnos> jepler, thanks.
[16:35:49] <cradek> that's true
[16:36:17] <SWPadnos> what was the outcome of the discussions about supporting older kernels and such?
[16:36:25] <SWPadnos> or rather, not supporting them
[16:36:26] <cradek> with my nvidia problems I would get some cycles that were many times the normal
[16:36:46] <cradek> the real problem is I don't know what represents a real problem and what doesn't
[16:36:53] <cradek> how we detect it is just an aside
[16:36:58] <SWPadnos> tight
[16:36:59] <SWPadnos> right
[16:37:21] <jepler> did you look at the overrun detection in emc1?
[16:37:38] <cradek> yes, but I don't remember how it worked
[16:37:54] <cradek> I also looked at the kern/latency test but didn't understand it.
[16:38:28] <jepler> if (emcmotDebug->cur_time - emcmotDebug->last_time >
[16:38:28] <jepler> 10 * emcmotConfig->servoCycleTime) {
[16:38:28] <jepler> reportError("controller missed realtime deadline.");
[16:38:28] <jepler> IGNORE_REALTIME_ERRORS = 1;
[16:38:28] <jepler> }
[16:39:00] <SWPadnos> hmmm - 1000% is much more than 10%
[16:39:04] <cradek> wow
[16:39:47] <jepler> I thought at first maybe it was 10* because it was running at servo rate but checking traj rate .. but that doesn't seem to be it
[16:41:12] <cradek> in our stepper config, base period is 5% of servo period. so I figured a 10% anomaly in servo would represent a real problem for step generation
[16:42:13] <cradek> servos are going to deal with it much more easily - that may be why the test in emc1 is so lax
[16:43:26] <cradek> I was going to calculate standard deviation on the history to look for an "extreme" current value but jmk talked me out of it - he said if the std dev is huge, there's a problem and you shouldn't make the test easier
[16:46:06] <jepler> is there a way to do a calculation like 'clocks * 1000000 / cpu_khz' in integer math without overflowing or losing precision? 'clocks' is already a 'long long' so there's not a wider type available
[16:47:38] <cradek> jepler: I don't think so
[16:47:49] <jepler> I guess you'll still have at least 32 bits left, so you could get a 'long' number of ns with that formula
[16:49:18] <cradek> you just mean for a small value of clocks (some difference between two readings) right?
[16:50:52] <jepler> yes, for a 'delta'
[16:53:57] <alex_joni> I get loads and loads of unexpected delays
[16:54:18] <alex_joni> but that's just me..not the PC
[16:56:07] <jepler> ns1 = clocks1 * 1000000 / cpu_khz; ns2 = clocks2 * 1000000 / cpu_khz; delta = ns2-ns1;
[16:56:23] <jepler> but this won't work?
[16:56:44] <SWPadnos> better accuracy if you do delta = (clocks2 - clocks1) * 1000000 / cpu_khz
[16:56:58] <cradek> yeah you want to do the math with the delta
[17:02:01] <jepler> Computing
[17:02:01] <jepler> deltat = (end_clocks - start_clocks) * 1000000 / cpu_khz
[17:02:01] <jepler> gives the duration measured in nanoseconds for deltas less than about 9
[17:02:04] <jepler> trillion clocks (e.g., 3000 seconds at 3GHz).
[17:02:14] <jepler> I think I'll add this text to that manpage
[17:02:29] <cradek> cool
[17:02:39] <cradek> 9 trillion is a lot of clocks (today)
[17:02:54] <jepler> I think that's right -- 2**63 / 1000000
[17:02:54] <alex_joni> cradek: it won't get much faster than this in the future
[17:03:07] <jepler> you mean I'll never get a PHz computer?
[17:03:08] <jepler> darn
[17:03:27] <cradek> alex_joni: are you serious?
[17:03:30] <alex_joni> jepler: I think they started to abandon that idea, and stuff as many cores as possible inside the CPU instead
[17:03:41] <alex_joni> cradek: for the time beeing, yes
[17:03:55] <alex_joni> it's not practical to keep increasing the frequency
[17:04:04] <cradek> won't get much faster than this in the future ... for the time being?
[17:04:06] <alex_joni> it hasn't been following Moore's law lately
[17:04:13] <cradek> that's nearly a content-free statement :-)
[17:04:24] <jepler> too bad -- it's hard to write threaded software.
[17:04:30] <cradek> you're definitely right about cores
[17:04:30] <alex_joni> cradek: at the time beeing it looks like it won't get much faster than this in the future
[17:04:42] <alex_joni> now you have some content there
[17:04:46] <alex_joni> still nothing said :D
[17:04:57] <cradek> I'm squinting hard and still don't see it...
[17:05:04] <alex_joni> * alex_joni blames the cold
[17:05:07] <cradek> just teasing you, sorry
[17:05:17] <alex_joni> I know .. :P
[17:05:27] <alex_joni> actually I think max frequency went back a bit
[17:05:43] <jepler> cradek: In the Pentium IV generation, Intel went up to the mid 3GHz range. In the current "core" and "core 2" generations, it is lower (but just how low, I'm not gonna tell you)
[17:05:46] <alex_joni> not sure there are any 3.4GHz+ processors these days
[17:06:04] <alex_joni> jepler: sometimes under 2GHz
[17:06:05] <cradek> huh
[17:06:31] <SWPadnos> there are, but only under dry-ice cooled mineral oil
[17:06:42] <jepler> PIV was very low-performance-per-MHz
[17:06:45] <alex_joni> cradek: see, told you you should have not cancelled that processor-news subscription
[17:07:02] <alex_joni> SWPadnos: those don't count
[17:07:05] <cradek> I sure don't keep up with that stuff
[17:07:06] <SWPadnos> heh
[17:07:23] <alex_joni> SWPadnos: there were Celerons (900MHz) overclocked to 2GHz+ a while a go
[17:07:27] <alex_joni> ago
[17:08:14] <cradek> if castoffs aren't fast enough for me, I buy whatever I can get for $300 which is about what a computer is worth to me...
[17:08:17] <jepler> According to wikipedia, "Core 2"'s top speed grade is 2.93GHz; he top Pentium 4 speed grade was 3.8GHz.
[17:08:19] <alex_joni> anyways, I think they follow the "make them transisters as small as possible now, to integrate as many as possible" right now
[17:08:39] <jepler> on the other hand, "Core 2" is new and maybe they'll introduce higher speed grades
[17:08:55] <alex_joni> but that direction will also be impossible to follow at one point
[17:08:58] <jepler> After all, Pentium 4's lowest grade was 1.4GHz
[17:09:33] <jepler> "In November 2000, Intel released the Willamette Pentium 4 at speeds of 1.4 and 1.5 GHz"
[17:09:42] <alex_joni> still don't think they'll cross the 4GHz line
[17:09:49] <alex_joni> at the moment it's not practical
[17:09:52] <alex_joni> at one point they may
[17:10:06] <SWPadnos> they could probably do it with the 35-micron process
[17:10:25] <alex_joni> * alex_joni stopped caring about current processors
[17:10:33] <alex_joni> it's such a waste what they are doing these days
[17:10:34] <alex_joni> :)
[17:10:46] <jepler> I figure 4 cores is useful on Windows XP: 1 core for antivirus, 1 core for decoding DRM music, 1 core for flash ads, and 1 core for running ubuntu in vmware
[17:10:50] <cradek> in the early 90s when cases had those numeric displays for the MHz, I remember laughing loudly at the case I bought which had a leading 1 digit
[17:11:20] <SWPadnos> MIPS/watt is getting more important, which is nice
[17:11:49] <alex_joni> SWPadnos: I was amused to learn that a PIV had about 10% watt waste in residual currents
[17:12:00] <SWPadnos> is it not SOI?
[17:12:08] <alex_joni> SOI?
[17:12:15] <SWPadnos> silicon on insulator
[17:12:27] <alex_joni> might be
[17:12:46] <alex_joni> but residual currents as I read it referrs to currents into the gate
[17:13:09] <SWPadnos> I think they're from the gates to the substrate, due to the very thin materials
[17:13:14] <jepler> SWPadnos: can I buy a passively-cooled laptop yet?
[17:13:22] <jepler> speaking of watts per mips
[17:13:26] <cradek> jepler: I have some I'll sell you
[17:13:27] <SWPadnos> sure, but it only lasts 20 minutes ;)
[17:13:35] <jepler> yeah I've got one like that right now
[17:13:46] <cradek> or maybe that's not your only requirement?
[17:14:04] <jepler> has to be snappy running ubuntu 6
[17:14:10] <cradek> oh
[17:14:14] <cradek> good luck with that
[17:14:16] <jepler> yeah
[17:14:18] <alex_joni> heh
[17:14:28] <jepler> thanks :-P
[17:14:36] <cradek> mine would be very snappy running minix
[17:14:42] <alex_joni> haha
[17:15:05] <cradek> minix runs great on a 4MB 386
[17:15:11] <jepler> I've thought of digging out my pentium laptop and making ingrid go back to vnc for her deskto
[17:15:14] <jepler> p
[17:15:43] <cradek> does she always sit in the one spot, or does she actually use it as a portable?
[17:16:01] <alex_joni> cradek: does emc2 run on that?
[17:16:18] <cradek> alex_joni: minix? umm
[17:16:36] <jepler> the second most frequent thing she does is take it into the kitchen when she's making a new recipe
[17:16:36] <alex_joni> cradek: have it done by new years eve
[17:16:48] <cradek> jepler: oh, hmm
[17:17:13] <cradek> jepler: I was thinking a nice $100 LCD and e-pc for her work spot there
[17:17:43] <alex_joni> e-pc?
[17:17:57] <jepler> I just don't see it...
[17:18:08] <jepler> what will I do, build a fancy arm to swing the LCD over the loveseat?
[17:18:14] <jepler> pointing device?
[17:18:17] <cradek> alex_joni: very small PC
[17:18:30] <cradek> jepler: that would be cool. I've considered doing that for over the toilet.
[17:19:59] <jepler> alex_joni: the e-pc looks something like this machine:
http://www.delwi.de/bilder/hp_epc40.jpg
[17:20:06] <jepler> (oh, and, smoking'll kill you)
[17:21:12] <alex_joni> jepler: I can read that just fine :D
[17:21:30] <cradek> it's a laptop size, but with full ports like an ATX, full size hard drive, no display/keyboard
[17:21:41] <cradek> I think they're pretty neat
[17:21:45] <alex_joni> nice
[17:23:22] <jepler> what I need is that plus a surplus keyboard/lcd for rackmount .. it'll be just like a laptop except with more cords connecting everything together
[17:24:24] <alex_joni> and a bit heavier to carry around
[17:40:52] <jepler> jmkasunich: just got ddclient set up on the machine where I wanted it .. thanks for the example using checkip!
[17:41:58] <jepler> I added a CNAME in my own dns so that I can use a name in my domain instead of .dyndns.org
[18:09:26] <SWPLinux> this is cool. VMWare 6 will allow you to script VMs from the host
[18:09:47] <SWPLinux> they even have an Eclipse plug-in that lets you debug your app in a VM from the IDE
[19:15:31] <jepler> "your app" being the hosted OS, or an app running in the hosted OS?
[19:16:18] <jepler> the latter is quite possible with gdbserver, I hear
[19:17:06] <jepler> is vmware6 one of the non-free products?
[19:22:12] <skunkworks> 10us
[19:23:58] <cradek> jepler: The index input is triggered on the rising edge. Initial testing has shown that the QZx inputs are particularly noise sensitive, due to being level triggered and polled every 25ns.
[19:24:07] <cradek> there's a level/edge contradiction here
[19:26:38] <cradek> On Tue, Dec 26, 2006 at 08:17:20PM +0100, Mario. wrote:
[19:26:38] <cradek> > So, if it is a warning, not an disaster-meaning message, why does it
[19:26:38] <cradek> > put the machine to a halt without decelerating down?
[19:26:55] <cradek> IT DOESN'T
[19:27:25] <jepler> cradek: oops, I keep making small edits to that paragraph of the docs but apparently I never read the whole thing at once.
[19:27:56] <skunkworks> cradek: what does it do? a pause?
[19:28:00] <cradek> I can't seem to download mario's log file from this advertising-laden web page
[19:28:03] <skunkworks> never had it happen while running the machine
[19:28:11] <cradek> skunkworks: no, it doesn't do anything except pop up the warning
[19:28:44] <skunkworks> really... from my playing it seemed to pause - But I wasn't paying much attention
[19:29:02] <skunkworks> plus it wasn't attached to a machine
[19:29:22] <skunkworks> maybe just the preview pane pauses'
[19:29:28] <cradek> the AXIS display may stop updating while the warning is up, but emc doesn't stop running
[19:30:50] <skunkworks> ok
[19:32:03] <skunkworks> cradek: I could email it to you
[19:32:09] <cradek> skunkworks: that would be nice
[19:32:45] <skunkworks> chris at timeguy dot com?
[19:32:58] <cradek> no, chris@timeguy.com
[19:33:02] <cradek> :-P
[19:33:13] <cradek> thanks
[19:34:44] <jepler> cradek: it's so old-fashioned, not trying to obfuscate your e-mail address
[19:34:55] <skunkworks> should be there..
[19:35:02] <cradek> and using the same email for years and years?
[19:35:05] <skunkworks> did you see he as a period of 10us
[19:35:05] <cradek> skunkworks: thank you
[19:35:06] <jepler> yep that too
[19:35:31] <cradek> it was 20 in the last ones he sent
[19:36:12] <jepler> cradek: >The index input is triggered on the rising edge. Initial testing has shown that the QZx inputs are particularly noise sensitive, due to being polled every 25ns. Digital filtering has been added to filter pulses shorter than 150ns (six polling times). Additional external filtering, such as a Schmitt buffer or inverter, RC filter, or differential receiver (if applicable) is recommended.
[19:36:21] <jepler> does it at least not contradict itself now?
[19:37:55] <cradek> yes that looks good now
[19:39:25] <jepler> what do we think about adding new hardware drivers in 2.1?
[19:39:28] <jepler> pluto and pci_8255
[19:40:32] <cradek> I don't know
[19:41:07] <cradek> it seems unlikely that doing that would destabilize any of the rest of the program
[19:41:25] <cradek> the only risk is that the drivers themselves may not be stable yet
[19:41:59] <jepler> it's entirely possible to build them apart from the main emc2 source tree
[19:42:21] <jepler> (in the case of pluto you have to change a #include path but that's about it)
[19:42:51] <jepler> sudo comp --install pci_8255.c
[19:44:21] <cradek> I don't want to decide this myself
[19:45:41] <jepler> I'll ask when they're closer to ready
[19:55:26] <alex_joni> cradek: got the error logs?
[19:55:32] <cradek> yes
[19:55:40] <alex_joni> nothing odd in there :/
[19:55:43] <cradek> I responded to him already
[19:56:23] <cradek> maybe that test is way too tight. it's hard to say what it should be.
[19:56:24] <alex_joni> sorry.. I was unavailable .. fever's rising
[19:56:36] <cradek> sorry to hear you're sick
[19:58:17] <alex_joni> 38.8 last I checked
[19:58:22] <alex_joni> need a better cooler :D
[19:58:49] <cradek> 102 - pretty hot
[19:59:09] <alex_joni> I ponder switching to water cooling :)
[19:59:58] <alex_joni> could it be possible that Mario is seeing a backlash / accel related problem?
[20:00:15] <alex_joni> I don't see anything else that might happen during an feed override change and cause such a problem
[20:00:28] <alex_joni> but you probably know better what happens on a FO change
[20:01:12] <cradek> alex_joni: I don't think so.
[20:01:41] <skunkworks> how do you remove a module rdmod?
[20:01:48] <cradek> but I have no idea why his machine is stopping.
[20:01:52] <cradek> sudo rmmod
[20:03:21] <cradek> I am having a hard time trusting anything we don't ask him to repeat three times
[20:03:46] <alex_joni> maybe we should ask him in here
[20:04:07] <cradek> he doesn't have a network on the emc machine - it would be hell
[20:04:25] <cradek> but be my guest if you feel up to it :-)
[20:04:28] <alex_joni> maybe he has them close to each other
[20:04:44] <alex_joni> obviously my mind is clouded atm
[20:05:14] <cradek> don't worry, I'm always that way
[20:05:32] <alex_joni> I _seriously_ doubt that
[20:08:36] <skunkworks> cradek: you are right - only the display paused during the popup
[20:08:38] <skunkworks> :)
[20:09:07] <alex_joni> removed the smi stuff to make it pop?
[20:09:10] <cradek> skunkworks: I know :-)
[20:09:12] <skunkworks> yes
[20:09:20] <alex_joni> nice feature that SMI
[20:09:30] <alex_joni> * alex_joni is kidding
[20:09:37] <jepler> I'm sure it has its place
[20:09:43] <cradek> skunkworks: thanks for checking for me
[20:10:03] <alex_joni> skunkworks: mind posting your findigns to the devel list?
[20:16:21] <skunkworks> sorry - was getting christmas leftovers. - I can do that.
[20:51:33] <SWPLinux> jepler: yes, I think VMWare Workstation 6 will be non-free, like WS 5.x
[20:51:43] <SWPLinux> they may release a free "player" though
[20:52:51] <SWPLinux> hopefully they will, because VM scripting can be very useful for the compile farm - you can run a script in the VM from a script onthe host
[20:53:45] <jepler> you can already start and stop them with vmware-cmd, and with the compile farm you could do the rest with 'ssh'
[20:53:59] <jepler> but yeah maybe it could be a whole lot easier
[20:54:53] <SWPLinux> I suspect it could - use a host script to detect changes (and compile on the host), then fire up the VMs in sequence to do their own compiles
[20:55:11] <SWPLinux> and background / stop them when finished
[20:55:36] <jepler> it would probably be faster if only one vm was running at a time
[20:55:44] <SWPLinux> I think so
[20:55:59] <cradek> he has just one processor right?
[20:56:04] <SWPLinux> yes
[20:56:22] <cradek> yeah one at a time is going to be a win
[20:56:33] <SWPLinux> though you can emulate single-CPU machines on multi-CPU/core machines (I'm setting up a VM for EMC2-live now)
[20:56:43] <cradek> one benefit might be that the later ones won't all try to build the syntax error
[20:57:06] <SWPLinux> heh
[20:57:44] <SWPLinux> in some cases (like a syntax error), that would be great. other failures shouldn't stop later "slots"
[20:58:22] <alex_joni> SWPLinux: why not?
[20:58:24] <jepler> it's probably hard to guess whether a problem will affect just one arch or all of them
[20:58:34] <SWPLinux> that's the reason :)
[20:58:43] <jepler> it might just be an #ifdef obsolete or something
[20:58:54] <alex_joni> so do we care if it works on BDI while it's not working on dapper?
[20:58:55] <cradek> I mean the later ones will get a newer checkout where it's fixed
[20:58:58] <SWPLinux> if something fails on BDI-4.50, that may have no bearing on Edgy ...
[20:59:13] <alex_joni> SWPLinux: I somehow doubt jmk uses BDI as his primary desktop :D
[20:59:17] <jepler> oh -- if it got fixed quickly, you mean
[20:59:19] <alex_joni> he runs dapper with RT
[20:59:25] <SWPLinux> he's also not using Edgy ;)
[20:59:25] <cradek> jepler: yes
[21:00:03] <SWPLinux> that is one problem with sequential compiles - they aren't necessarily compiling the same thing
[21:00:11] <SWPLinux> (since the checkouts may be done at different times
[21:00:13] <SWPLinux> )
[21:00:33] <cradek> SWPLinux: they will eventually settle only after they all build the same thing
[21:00:35] <SWPLinux> though you can script things so that the checkout is only done once, and that gets replicated on each of the VMs
[21:13:10] <alex_joni> cradek: seems you were right
[21:13:21] <alex_joni> that probably was an assumption from Mario that the motors stop
[21:13:49] <cradek> I wonder if by "switched consoles" he means he's switching in and out of X
[21:13:56] <cradek> that's a terrible idea if so
[21:14:32] <alex_joni> probably so
[21:14:48] <alex_joni> he mentioned tty1..7 in an earlier email, so I guess so
[21:15:49] <jepler> I can't see the screen to tell whether it's actually working, but I just ran on "install2" and used the "chvt" commandline program to switch between terminals 1 and 7. X is running.
[21:15:53] <jepler> no unexpected realtime delays.
[21:15:58] <cradek> I think I'll stop responding for a while again - let everything settle down
[21:18:04] <skunkworks> so ctrl-alt-f7 is x?
[21:18:12] <alex_joni> alt-f7
[21:18:21] <alex_joni> no need for ctrl, while on a text console
[21:18:28] <cradek> ctrl-alt-F1 to get out, alt-F7 to get back
[21:18:38] <skunkworks> ok
[21:20:11] <skunkworks> no issues here also - switching between terminal and such
[21:20:48] <maddash> hi, is there anyway for me to strip emc2 down to only a gcode interpreter and the necessary parallel port drivers to send out the corresponding signal pulses?
[21:21:09] <cradek> skunkworks: thanks for testing that too (but it sure may be different on other machines)
[21:21:15] <skunkworks> rigth
[21:21:15] <alex_joni> maddash: you mean remove a GUI ?
[21:21:26] <alex_joni> maddash: or do you mean to cut some HDD size?
[21:23:20] <maddash> both
[21:23:32] <alex_joni> well.. most parts of emc2 that exist can be removed
[21:23:44] <alex_joni> you just need a subpart of it to run it properly
[21:24:00] <alex_joni> but it's not going to be easy to do so..
[21:24:11] <maddash> I have trouble telling which parts are vital to emc2; the readmes don't say so
[21:24:28] <cradek> of course - that depends on your application
[21:24:38] <alex_joni> maddash: that's because we don't do this usually :)
[21:24:53] <alex_joni> maddash: if you care about an embedded system, you can run the GUI remote
[21:25:08] <maddash> how can this be done?
[21:25:09] <alex_joni> you probably will need to alter with the runscript to make it start without a GUI
[21:26:04] <alex_joni> you get some info about emc2 components here:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC_Components
[21:26:30] <alex_joni> but maybe it would be best if you could describe what you want to do, for us to give good advice
[21:27:29] <maddash> I've got a machine that runs @ 500 Mhz w/192 RAM. Judging from the hardware requirements listed on the wiki, EMC won't run properly here...
[21:27:50] <cradek> removing files from emc will not help that.
[21:27:55] <alex_joni> it might work ok if you start by running Xubuntu instead of the normal Ubuntu
[21:28:17] <maddash> I don't need the GUI, and I'm assuming that EMC requires so much memory and processor speed because of it
[21:28:19] <alex_joni> removing files will only save HDD space, what is not used in emc2 isn't executed
[21:28:24] <jepler> You should be able to install xubuntu 6.10 using the "alternate install CD" (text mode) and then install emc. Mostly the memory and disk requirements are due to the Ubuntu system and desktop applications, not emc2.
[21:28:48] <alex_joni> maddash: there are text-mode GUIs available for emc2
[21:28:56] <jepler> well, there's one text-mode GUI
[21:29:07] <cradek> easier still would be to get some ram. your machine is fast enough.
[21:29:10] <alex_joni> maddash: I'd do it like jepler said. install the non-X version, and use a text-mode GUI
[21:29:20] <alex_joni> jepler: well two, but one isn't really a GUI
[21:29:25] <maddash> would emc work on an ubuntu-server setup?
[21:29:42] <cradek> does that mean no X?
[21:29:52] <alex_joni> cradek: amongst other things
[21:29:54] <skunkworks> maddash: have you tried to install the emc2 live cd?
[21:29:55] <cradek> with some work you could run it without X. depends what you want to do.
[21:30:22] <alex_joni> skunkworks: the current Live CD won't run with 192 MB
[21:30:33] <jepler> for instance, emc assumes it can run a graphical program to choose the configuration file. you can get around that by specifying the configuration file on the commandline
[21:30:35] <alex_joni> the breezy one might
[21:30:38] <maddash> skunkworks: I don't have enough RAM for that
[21:30:43] <cradek> alex_joni: (with an existing swapfile it might)
[21:30:51] <jepler> use the text-mode "alternate installer"
[21:30:58] <alex_joni> cradek: yeah, but slowly
[21:31:04] <jepler> after installation, I bet (but do not know) that the xubuntu desktop will work OK in 192 megabytes
[21:31:13] <maddash> jepler: is there anyway to tell emc to open a gcode file, send out whatever signals are needed, and go back to sleep?
[21:31:18] <cradek> jepler's advice is the best
[21:31:21] <maddash> jeplerR: from the cmd line, I mean
[21:32:07] <maddash> jepler: also I have not heard of this "text mode installer." What is it?
[21:32:08] <jepler> maddash: All the user interfaces communicate with emc through an interface called "nml". You can send nml messages with C++ or Python programs, and it would be easy to write programs in those languages that are callable from the shell
[21:32:59] <jepler> ubuntu-6.06-alternate-i386.iso,md5sum b2e9120f06d70cc076c1852c6c04654e ...
[21:33:21] <alex_joni> http://www.linuxcompatible.org/Xubuntu_6.06_Beta_2_Released_s67056.html
[21:33:24] <jepler> "
[21:33:24] <jepler> The Ubuntu Alternate CD uses the text installer instead of the new GUI installer. It needs less system memory and permits advanced installs with preseeded options as well as LVM or RAID disk configurations. "
[21:33:30] <alex_joni> seems xubuntu would run on 128MB
[21:34:00] <skunkworks> alex_joni: an alternate emc2 live cd? ;)
[21:34:17] <jepler> skunkworks: alternate means "not live"
[21:34:26] <alex_joni> maddash: if you don't mind downloading a new distro, just to test, I would suggest trying the old Ubuntu Breezy Live CD
[21:34:35] <alex_joni> maddash:
http://www.cncgear.com/EMC/emc2-ubuntu-livecd.iso
[21:34:46] <alex_joni> maddash: it does only work as a Live CD, and you can't install from it
[21:34:55] <alex_joni> maddash: but it should prove if it works or not
[21:35:19] <jepler> alex_joni: it is supposed to work with 192 megs RAM?
[21:36:22] <alex_joni> jepler: just about
[21:36:34] <alex_joni> jepler: that's the minimum spec for the breezy live cd
[21:37:24] <alex_joni> I would still install Xubuntu, and go from there
[21:38:34] <maddash> alex_joni: I tried out the Puppy/emc livecd distro. it worked. but it was horribly slow, and only after I plugged in another 512 MB RAM...
[21:38:50] <alex_joni> 512MB of RAM?
[21:39:08] <maddash> alex_joni: it got so slow that the gui froze after I clicked the zoom-in button on the toolbar
[21:39:21] <alex_joni> you mean AXIS?
[21:39:27] <maddash> alex_joni: 512 + 192 RAM total
[21:39:29] <alex_joni> that might be a bit much for that setup
[21:39:40] <alex_joni> try another GUI, like tkemc or xemc
[21:39:56] <maddash> clearly. which is why I'm trying to cut out the GUI
[21:40:04] <cradek> if you have extra RAM there you could plug it in for the install, and then take all but 256 back out
[21:40:07] <alex_joni> you don't need to cut it out
[21:40:17] <alex_joni> simply use a different one
[21:40:32] <maddash> cradek: the extra ram isn't going to stay there, b/c it was cannibalized from another machine
[21:40:54] <alex_joni> 256MB of ram should be 20$ these days?
[21:41:02] <skunkworks> I ran emc2/axis for a long time on a 400mhz pentium II breezy and dapper.
[21:41:15] <jepler> maddash: how big are the g-code files you are using?
[21:42:11] <jepler> maddash: I use axis on systems with typically 512 megabytes, and axis is rarely slow and never freezes. but a large file for me is 10,000 lines
[21:43:12] <maddash> jepler: between 5k - 15 k lines.
[21:44:32] <jepler> mostly straight lines, or are there a lot of arcs? (axis, and probably the version on puppy worse than the newest versions, replaces each arc with a large number of lines when drawing the preview plot)
[21:45:31] <maddash> jepler: I didn't even load my gcode file before the gui froze
[21:46:04] <SWPadnos> that's usually a sign that the BASE_PERIOD is too low, I think
[21:46:08] <maddash> jepler: from what you've told me about the nml interface, it seems that I can compile emc into a "core module" an write my own interface. is that right?
[21:46:28] <SWPadnos> you can (sort of)
[21:46:41] <maddash> swpadnos: can you elucidate?
[21:46:46] <SWPadnos> there are many user interfaces available though - I'd be surprised if you need to write a new one
[21:47:09] <SWPadnos> the machine controller is incependent of the user interface(s) you use to control it
[21:47:14] <SWPadnos> independent ...
[21:47:26] <jepler> For instance, you could use mdi.py as a "text mode user interface", typing in one g-code command at a time:
http://cvs.linuxcnc.org/cvs/emc2/src/emc/usr_intf/axis/scripts/mdi.py?rev=1.2;content-type=text%2Fx-cvsweb-markup
[21:47:26] <maddash> swpadnos: I don't "need" to, per se...
[21:47:36] <SWPadnos> ok, if you want to, that's fine too ;)
[21:47:53] <jepler> by calling other methods on the "emc.command" object you can do things like load a g-code file and start it running
[21:48:16] <jepler> (and if you want to use mdi.py as your only interface, you'll *have* to add things to it -- for instance, a way to take the machine out of e-stop and turn it on)
[21:50:20] <jepler> emc.command and emc.stat are all that axis uses to communicate with emc, so you can write "anything you want" in terms of user interface
[21:52:34] <maddash> jepler: so, emc2\src\emc and emc2\src\hal are the core of the emc2 program? the rest is peripheral?
[21:54:22] <SWPadnos> no
[21:54:46] <SWPadnos> one sec whili I look
[21:54:48] <SWPadnos> while
[21:55:24] <SWPadnos> you need some of everything under src/
[21:56:27] <SWPadnos> most of the UIs are written in tcl/tk, and are in tcl/ (from the emc2 root)
[21:59:45] <maddash> but do I need rtapi/ since I'm running under ubuntu?
[21:59:57] <jepler> yes
[22:01:14] <SWPadnos> this is why people are saying that you can't really reduce the disk footprint much by eliminating GUIs
[22:01:31] <SWPadnos> memory footprint can be significantly reduced by not requiring X
[22:01:44] <SWPadnos> (using keystick or the telnet client)
[22:01:48] <SWPadnos> or a remote GUI
[22:02:26] <maddash> how would I compile emc to work under a text-mode gui (ie, make file parameters)?
[22:02:57] <SWPadnos> I don't think there are any make parameters for that (could be wrong though)
[22:03:29] <SWPadnos> you just need to specify keystick (?) as the DISPLAY in the ini file, and be sure to specify a config on the command line so the graphical config picker doesn't get shown
[22:05:04] <maddash> ok, I'm going to install ubuntu-server and give that a shot. thanks, swpadnos, jepler and alex_joni.
[22:06:21] <SWPadnos> you're welcome. enjoy :)
