Back
[02:00:14] <cradek> mozmck: I see grub-installer does support grub-legacy. comments in there say you cannot boot from lvm or ufs if you do not have grub2 though.
[02:00:47] <cradek> I know what lvm is (and I don't recall seeing it as an option in the installer) but I don't know what ufs is - I think it might be a bsd filesystem?
[02:00:59] <mozmck> grub-installer? I haven't even heard about that!
[02:01:22] <cradek> see /usr/share/grub-installer/grub-installer
[02:01:39] <mozmck> grub2 is nice for autodetecting other operating systems, but I'm not sure we need to worry about that for this.
[02:01:41] <cradek> /usr/lib/ubiquity/ubiquity/grubinstaller.py calls it pretty directly
[02:01:58] <mozmck> ok, I'll look at it.
[02:02:35] <cradek> I think it might just work if you change the grub version on your live cd filesystem and rebuilt the cd
[02:02:36] <mozmck> It definitely boots every time on my machine here, I'll try it Monday on the machine at work which was doing worse.
[02:03:22] <mozmck> I think so. I haven't started the livecd for 10.04 yet because I've been working on a kernel, but the livecd doesn't take very long.
[02:03:36] <cradek> wow, grub-installer has a surprising amount of evil in it :-/
[02:04:34] <cradek> iirc, the hard part is getting your new kernel to be the one that boots when you run the cd live
[02:05:34] <mozmck> I did that on the 9.10 livecd I made. You mainly just uninstall the other kernels and install the new one. I had to re-pack the initrd with lz compression though...
[02:06:07] <mozmck> For some reason the installed initrd is gz, but the one on the livecd was lz. I don't know if 10.04 is the same yet or not.
[02:06:13] <cradek> you are miles ahead of me.
[02:06:42] <mozmck> :) if they haven't changed too much since then - maybe.
[02:07:42] <mozmck> almost bought a motherboard today and 6-core proc, but got talked out of it at Frys.
[02:08:08] <cradek> talked out how?
[02:08:23] <mozmck> the guy said Gigabyte is coming out with a new board in a week or so with bug fixes.
[02:08:35] <cradek> ahh
[02:08:37] <mozmck> I'm doing a little more research to see what I can find.
[02:09:13] <mozmck> reviews on Amazon look pretty good though:
http://www.newegg.com/Product/ProductReview.aspx?Item=N82E16813128435
[02:10:35] <cradek> cool
[02:11:02] <cradek> I wish newegg would help me understand what processor/mb/ram go together
[02:11:53] <mozmck> hard drives are ridiculous now. got a 500 Gig for $44. 2TB for $122
[02:12:02] <mozmck> Yeah, I have to look elsewhere for that.
[02:12:25] <mozmck> The AM3 processors can handle DDR3 up to 1600 Mhz now.
[02:12:57] <mozmck> AM2 were only good up to 1333 (I think 1600 worked but ran slower than that).
[02:13:09] <cradek> good googly that's fast ram
[02:14:26] <cradek> you are doing an i386 distrib, right?
[02:16:40] <mozmck> yes. based off the i386 generic.
[02:17:14] <mozmck> I bumped the processor up to 586TSC because I'm doing SMP builds.
[02:18:04] <mozmck> So far I've had zero problems with the SMP on single core computers. I've used them since 9.10 on about 4 different computers now.
[02:18:40] <cradek> very nice. what is the oldest machine you tried?
[02:19:04] <mozmck> My brother just set up a little desktop router with 9.10 I had installed for him a while back, and with a replacement video card he was getting latencies only up about 13000.
[02:19:05] <cradek> I think we had trouble with original pentium and maybe pentium II machines. I doubt either is relevant now.
[02:19:23] <mozmck> That was a 2.4 gz dell celeron I think.
[02:19:45] <mozmck> I don't think I've done anything much older than that.
[02:20:18] <cradek> I bet I have two working PII machines but they are both multiprocessor
[02:21:13] <cradek> well when you have a cd ready I will test on all sorts of weird old stuff. I have piles of old crap around.
[02:21:23] <mozmck> I don't know if I even have one of those anymore. I think some of the previous problems were in RTAI and were supposed to be fixed since 3.7.0 or .1
[02:21:32] <cradek> if it runs on very old and very new, we're probably fine
[02:21:47] <mozmck> Ok. I'll try and work on that next week.
[02:24:13] <cradek> hmm, I should be installing 2.4.0 on everything
[03:19:46] <KimK> cradek: Hi Chris. I finally got around to ordering the K&R C book. And speaking of new software, I'm trying to get used to the new left corner window buttons. Yes, I found the script to fix it, tried that on a test install and it worked fine, but then I decided to go with the standard, etc. Besides, there's a rumor they're developing something new that goes in the upper right corner? Anyway, I decided to go with the flow. And it's not so bad, and getting b
[03:19:46] <KimK> etter.
[03:20:08] <KimK> ha, b-etter, lol
[03:23:43] <cradek> I changed it right away... A promise of something great in the future isn't enough to make me get used to something new...
[03:24:29] <cradek> hm, this is not good. I installed 2.4.0 and hostmot2-firmware-5i20. Everything runs, but when I exited EMC the machine stayed on. This means the watchdog isn't working right.
[03:25:03] <cradek> er no, I must be crazy
[03:25:32] <cradek> false alarm
[03:25:44] <cradek> I already had it in estop, and the sound didn't change
[03:25:57] <KimK> * KimK hopes cradek figures it out soon, he's violently oscillating...
[03:26:17] <cradek> but some fans etc stay on in estop - it confused me
[03:26:21] <cradek> it's fine
[03:26:28] <cradek> experts agree: everything is fine
[03:26:35] <KimK> Ha, well, that's good then, I like it when problems go away
[03:27:33] <cradek> yes
[03:27:35] <KimK> "If you see ten troubles coming toward you down the road, you can be sure that nine of them will run into the ditch before they reach you." -Calvin Coolidge
[03:27:48] <cradek> and I like it when new major releases work right
[03:28:39] <KimK> Yes, 10.04 has been good, 2.4.0 has been good, now for RTAI x.x.x.x ?
[03:29:13] <KimK> I mean our new kernel
[03:29:43] <cradek> 2.4 is going to be another great series. I'm very excited it's out.
[03:29:46] <cradek> it's been a long time coming.
[03:31:08] <KimK> I'm still unclear about the business of the tool length offsets being referenced to one of the offsets and not to the machine. Is that true? Seems wrong.
[03:31:38] <KimK> to one of the offsets -> to one of the fixture offsets
[03:31:55] <cradek> it is a debate about how tool table touch off in AXIS works, not about how tool lengths work
[03:33:02] <cradek> in AXIS when you do a tool table touch off, just like a fixture touch off, the number you type is what the DRO ends up saying. This means all active offsets are taken into account when calculating the number that goes into the tool table.
[03:33:10] <CIA-2> EMC: 03cmorley 07v2.4_branch * rc14ae1145382 10/src/emc/usr_intf/pncconf/pncconf.py: Add a splash screen / progress bar
[03:33:32] <cradek> this is right if you want to turn and measure a diameter on a lathe, and then set the TLO such that the DRO should become the measured value
[03:34:04] <cradek> if you're measuring a tool to the spindle nose though, you need to switch to a coordinate system that makes sense for the nose (probably a system with no offsets)
[03:34:28] <cradek> it just depends what you're touching the tool to
[03:36:33] <KimK> OK. I'll have to think about it, maybe it will become clearer. But the tool offsets are still referenced to machine coordinates?
[03:36:47] <cradek> I see the value both ways - if you always used a fixture unrelated to your work, it'd be nice to not have to remember to switch to its system (or an unoffset system) before using it
[03:36:51] <KimK> Even if a fixture offset is also used?
[03:37:23] <cradek> I don't understand that question - I don't know what it means for a tool offset to be "referenced to" something
[03:38:08] <cradek> tool offsets represent how tools are different lengths. they reference (?) one tool to another, or all tools to a "master" tool
[03:40:25] <cradek> I have a probe - I call it tool length zero. If a drill is 1" longer than the probe it gets a TLO of 1. if an end mill is 3" shorter, it gets TLO -3
[03:41:05] <cradek> so I guess they're referenced to my probe / reference length tool / zero length tool
[03:41:28] <KimK> Ah, and this gets into the personal style of how different people like to set up their tools. Some people like to use a "master tool". But (and maybe I am applying my biases here) on an XYZ mill for example, you have only two permanent references, the axis of spindle rotation, and the table (no fixtures). So...
[03:42:12] <cradek> yep, you could measure all your tools from the gage line, they'd all get (big) positive lengths then
[03:42:12] <KimK> ...if you set height referenced to the table, then you can add/move/change any fixture, and you're good.
[03:43:17] <cradek> unless you can't get to the table... I sometimes have something mounted up off the table and covering all of its travel
[03:43:31] <KimK> Of course, that gets back to fact that there's no good way (at present) to shut off all the fixture offsets. Except for G53 which doesn't last long, right?
[03:44:26] <cradek> with AXIS's tool touch off I could touch my probe to anything, set a fixture offset to zero there (touch off g59.3 Z=0) then touch the new tool there, tool table touch off Z=0
[03:45:03] <cradek> right, the best you could do is keep one of them unoffset (G10 L2 P9 X0 Y0 Z0)
[03:45:06] <KimK> Yes, that would work too.
[03:46:35] <KimK> I'd still like to expand the number of offsets available. I think Haas uses G154 followed by P1 thru what, P199? for more offsets.
[03:46:54] <cradek> sure, then nobody would complain about keeping one just for measuring tools
[03:47:27] <cradek> I will thoughtfully consider a patch that does this if someone wants to tackle it.
[03:48:17] <cradek> frankly it would require some design, because you'd have to save all those somewhere
[03:49:10] <cradek> wear offsets have come up a lot lately too, and we're in better shape than ever to add them if someone wants to (new tool table format gets around our previous restrictions)
[03:49:42] <KimK> If you had a fixturing plate to make a bunch of small, closely spaced widgets, it would be helpful to have more offsets. Of course EMC2 could still handle that fixture the way it is by re-declaring the same fixture offset over and over and then doing the work.
[03:49:57] <cradek> yep
[03:50:33] <cradek> if they were evenly spaced maybe it'd be somewhat nuts to set up a system for each one anyway
[03:50:38] <KimK> Yes, wear offsets (with entry limits?) would be very helpful. Prevents operator blunders.
[03:50:46] <cradek> brb
[03:50:57] <KimK> OK
[12:16:04] <JT-Dev> what is the result of running EMC on a stepper machine with poor latency? lost steps? steps out of time?
[12:41:12] <SWPadnos> JT-Dev, assuming what about the config?
[12:41:37] <SWPadnos> if you have bad latency and you make a proper configuration that takes it into account, you have a slow but reliable machine
[12:42:12] <JT-Dev> I mean if you get the latency error on start up but ignore it
[12:42:16] <SWPadnos> if you don't take high latency into account, your machine most likely locks up or is unresponsive
[12:42:39] <SWPadnos> ok, if it's randomly bad like that, then you could get stalls, lost steps, etc
[12:42:53] <SWPadnos> 10us 10us 10us 10ms is bad
[12:43:11] <JT-Dev> SWPadnos: thanks
[12:43:15] <SWPadnos> sure
[15:51:01] <CIA-2> EMC: 03jthornton 07v2.4_branch * r0a39101f0a0b 10/docs/src/drivers/hostmot2.lyx: add svst2 4 7i47 to 5i20 chart
[15:51:06] <CIA-2> EMC: 03jthornton 07v2.4_branch * r275edfacb384 10/docs/src/config/ini_config.lyx: add info on homing with index
[17:04:28] <CIA-2> EMC: 03jthornton 07v2.4_branch * rf667e9b60e93 10/docs/src/ (16 files in 3 dirs): add point n click to getting started guide
[20:52:09] <JT-Hardinge> something in 2.5 causes it to load files and respond to button pushes very slow... The only difference between the configs for 2.4 and 2.5 is the 2.5 uses mux16 and the halui for direct feed override
[21:20:28] <micges> JT-Hardinge: trying to reproduce
[21:21:41] <JT-Hardinge> ok, I'm making a config without the differences to see if that makes a difference as soon as I finish running these parts
[21:35:30] <micges> JT-Hardinge: do you have halui FO direct pins conncted?
[21:35:44] <micges> on 'slower' config?
[21:36:12] <JT-Hardinge> yes
[21:36:38] <JT-Hardinge> do you see a problem with it?
[21:39:18] <micges> when I had connected my own 'direct FO' value pin, all user part was much slower and keyboard keys was often lost
[21:39:29] <micges> it is halui problem
[21:40:11] <JT-Hardinge> ok
[21:40:16] <SWPadnos> is halui sending FO messages every time through its event loop?
[21:40:48] <micges> here it was
[21:40:58] <micges> many NML messages was bad thin
[21:40:59] <micges> g
[21:41:23] <SWPadnos> ok, that's probably an error - it should be looking for changes (but then again float != float is kinda dubious)
[21:43:16] <alex_joni> there's a delta iirc
[21:43:26] <SWPadnos> nope, not in direct mode
[21:43:26] <alex_joni> and it only changes if the difference is greater
[21:43:36] <SWPadnos> line 1759
[21:43:39] <alex_joni> hmm.. ok, not sure what direct FO is :D
[21:43:56] <alex_joni> ah.. the potentiometer abomination?
[21:43:57] <JT-Hardinge> alex_joni: you can input the fo value with it
[21:43:59] <micges> now it sends nml every loop
[21:44:01] <SWPadnos> yes
[21:44:16] <JT-Hardinge> no, a binary switch fo input
[21:44:18] <alex_joni> ah, then it's just about good that it causes the system to become unstable
[21:44:18] <SWPadnos> SO has the same problem
[21:44:19] <alex_joni> :P
[21:44:23] <JT-Hardinge> through mux16
[21:44:27] <alex_joni> it's not NIST-like
[21:44:42] <SWPadnos> yeah, shows them non-NIST-like folks who's boss
[21:45:56] <alex_joni> it should compare current-FO (from the status buffer) with the halui input pin
[21:46:16] <alex_joni> if greater than some value (maybe another halui input pin) send a new FO NML message
[21:46:37] <alex_joni> that way it'll send a new message even if someone tries to change the AXIS slider
[21:48:00] <micges> cmorley added direct feature, but he removed != part
[21:48:37] <micges> alex_joni: will you fix it or I?
[21:49:01] <alex_joni> no git access atm
[21:49:23] <alex_joni> I'm planning on installing 10.04 these days, not sure when I get around it
[21:49:31] <JT-Hardinge> that would be my fault I told cmorley that it was working
[21:49:51] <micges> I'll fix it tommorow morning
[21:49:59] <JT-Hardinge> ok thanks micges
[21:50:04] <alex_joni> good night all
[21:50:15] <micges> JT-Hardinge: it works but it can works better ;)
[21:50:24] <micges> good night alex
[21:50:32] <alex_joni> yeah, with an encoder :D
[21:51:21] <JT-Hardinge> many machine come equipped with feed override binary switches
[21:51:37] <JT-Hardinge> all my cnc machines have them
[21:51:47] <alex_joni> JT-Hardinge: I know..
[21:52:12] <JT-Hardinge> I can look at the knob and know what my fo is set at :)
[21:52:51] <alex_joni> my knob is close to 1am, so I'm outta here ;)
[21:53:38] <JT-Hardinge> good night
[21:59:11] <JT-Hardinge> micges: how could the direct input fo work better?
[22:02:06] <micges> JT-Hardinge:
http://pastebin.com/SKxnHyZE
[22:04:00] <JT-Hardinge> I can run that here in a few minutes I think
[22:08:19] <JT-Hardinge> micges: I think the same problem exists for spindle override and max velocity
[22:08:29] <micges> yes
[22:08:52] <micges> I'll commit it tommorow
[22:09:19] <JT-Hardinge> ok I'll just wait for that then
[22:09:32] <JT-Hardinge> micges: thanks for helping on this
[22:09:38] <micges> sure
[22:14:05] <CIA-2> EMC: 03cmorley 07master * r6958427563b2 10/src/hal/components/mux16.comp: fix mux16 outputs to match truth table