Back
[13:54:55] <jepler> ooh, the pre-built buildmaster debs
[13:54:58] <jepler> good one seb
[13:55:26] <cradek> slick
[15:27:14] <seb> good morning
[15:34:00] <mshaver> Anyone know anything about when a Lucid/EMC2 CD might be available?
[15:34:25] <seb> soon as someone makes a lucid rtai kernel
[15:34:48] <Jymmm> mshaver: why?
[15:34:55] <mshaver> Well, there mozmck's stuff
[15:35:37] <Jymmm> and not in the current?
[15:35:39] <seb> mozmck's kernels are rumoured to not work as widely as desired, and rather than field the support calls for folks with non-booting systems the decision was made to hold back until a better kernel is developed
[15:35:44] <seb> brb
[15:35:48] <mshaver> Using 2.6.24 on Hardy I'm having Compact Flash problems. Probably libata related.
[15:36:17] <mshaver> Desktop Lucid (2.6.32) works fine.
[15:39:26] <mshaver> What happens is (on Hardy) I boot from CF and the system runs OK for 0-10 minutes or so, the I get libata error messages in the kernal log and lose communication with the disk, which is problematic.
[15:40:09] <Jymmm> http://www.listware.net/201007/emc-users/91525-re-emc-users-emc-packages-for-ubuntu-1004-lucid-lynx-.html
[15:40:13] <mshaver> The _exact same_ hardware parts work fine with Lucid.
[15:40:36] <mshaver> OK, looking at your link...
[15:42:35] <mshaver> So, from that link, I conclude that if after installing the rtai kernel your machine works, everything will be OK?
[15:45:07] <mshaver> BTW, on Hardy I've tried acpi=off. nohdparm, and removing all the hdparm related scripts from /etc, all of which helps to increase the uptime, but in the end the disk interface goes goofy anyway.
[15:50:40] <mshaver> Dapper worked fine too. Early Hardy was OK as well, but at some point in the upgrade chain it went wrong. Also I've used several very closely related, but not exactly the same, motherboard models due to changes in retail availability.
[15:53:12] <cradek> mshaver: just to be clear, why aren't you using lucid if it works? if mozmck's kernel works on your hardware, I don't see why you couldn't use it. I don't understand your support situation exactly, so I don't know how important it is for you to use packages we build vs packages you build.
[15:56:18] <mshaver> cradek: Actually, you are answering my question. I guess I wanted to know if there was any reason not to use the mozmck stuff. Also, I was hoping for a lucid package repository from which customers could receive EMC releases.
[16:01:17] <jepler> that's not set up yet
[16:01:30] <mshaver> If there was going to be a Lucid CD next week, I would probably wait for it. Right now I have this problem with the Smithy machines that I'd like to solve, but if an "official" Lucid CD was right around the corner...
[16:01:45] <mshaver> jepler: that's what I thought
[16:02:44] <cradek> I haven't heard from mozmck for a while, but I see he's logged in.
[16:03:37] <mshaver> I guess, I'll run the options past "the powers that be" and see what their thoughts are. Ultimately, we could always swap out flash cards later when the official Lucid release arrives.
[16:04:03] <cradek> my personal opinion is that if the kernel works with all the 1 and 2 processor machines we've tried, that's plenty good enough. I'm not doing the work, though, so I don't get to decide.
[16:06:29] <mshaver> Well, I have to run down the road for a little while. I'll try to test the mozmck stuff and give feedback on what happens. Thanks for the input!!!
[16:08:32] <cradek> welcome, let us know how it goes
[16:48:20] <alex_joni> if mshaver reports success with mozmck's kernel, I'm happy to pick up the work
[16:48:27] <alex_joni> help with the LiveCD and repo
[16:54:45] <jepler> we know we need to build at least one more kernel package, one that won't have trouble because a portion of the headers get replaced with an incompatible ubuntu package
[16:54:59] <jepler> after that, we can get a package repo set up on linuxcnc.org (not just a drop box full of binary packages)
[16:55:37] <jepler> I'd like to do those things before issuing a live cd, because otherwise I think we'll just have to remake it
[16:55:45] <jepler> and by "we" I mean "someone besides me" _/
[17:27:26] <moopy> anyone know if parallel port pin 14 is bi directional?
[17:29:05] <moopy> from what i read on internet seems it should be bidirectional, but hal does not recognise parport.0.pin-14-in?
[17:29:58] <moopy> am i just suffering from a tired brain?
[17:31:13] <mozmck> I'm here right now.
[17:32:10] <mozmck> Been in and out lately.
[17:33:59] <moopy> loadrt hal_parport cfg="0x378 in"
[17:34:08] <moopy> show pin *in
[17:34:42] <moopy> i must be tired
[17:43:10] <mozmck> I'm re-compiling the kernel as 2.6.32-122 instead of 2.6.32-22 right now, so that should fix the problem of ubuntu wanting to "update" the linux-headers
[18:07:37] <jepler> hi mozmck
[18:08:36] <jepler> mozmck: if you upload all the binaries and sources to linuxcnc or send them to me, I will work on getting a proper apt repository set up.
[18:09:10] <jepler> mozmck: do you need help making source packages for kernel or rtai? I have a recollection that for the kernel at least it's something a little less than obvious
[18:12:06] <mozmck> I may need pointers for that. I haven't even thought about that yet.
[18:12:43] <seb> when there's an apt repo for the lucid rtai kernel, i'll teach the buildbot to build lucid realtime emc packages, should be quick
[18:14:07] <mozmck> jepler: if you tell me what the lucid apt repo address will be I can put it in the livecd. I've got the CD basically done except for that and the re-versioned kernel.
[18:19:55] <jepler> I am pretty sure we'll end up with
[18:19:55] <jepler> deb
http://www.linuxcnc.org/lucid lucid base emc2.4
[18:19:55] <jepler> deb-src
http://www.linuxcnc.org/lucid lucid base emc2.4
[18:20:21] <mozmck> ok.
[18:20:50] <jepler> mozmck: looks like in 8.04 the line to build the kernel source packages was:
[18:20:50] <jepler> dpkg-buildpackage -S -us -I.git -I.gitignore
[18:21:03] <jepler> iirc that creates a .tar.gz and a .dsc package .. those together are the source package
[18:21:13] <jepler> er, a .dsc file
[18:21:57] <jepler> for rtai I assume you use dpkg-buildpackage which will build a source package in the normal way unless you specify -B to build only a binary package
[18:22:09] <mozmck> I see. The ubuntu way creates a package called linux-source but there seems to be nothing in it.
[18:23:13] <jepler> that's odd
[18:24:01] <jepler> does your build use make-kpkg or some other method?
[18:25:09] <mozmck> fakeroot debian/rules
[18:25:38] <mozmck> ubuntu has a bunch of custom build scripts
[18:26:37] <jepler> whatever the details are we want to make very sure that we have the corresponding source for our debian repository
[18:28:01] <jepler> looking at
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Ubuntu10.04Notes -- what package does 'fdr' come from?
[18:28:10] <jepler> it's not on my (8.04 upgraded to) 10.04 system
[18:28:25] <jepler> oh, nevermind, I read the page harder
[18:28:46] <mozmck> fdr = fakeroot debian/rules
[18:29:15] <jepler> right
[18:29:17] <jepler> thanks
[18:30:17] <jepler> oh, and dpkg-buildpackage -S ... may also create a .diff.gz file
[18:30:23] <jepler> if it's there make sure to upload it too
[18:30:58] <mshaver> Just got back, but have to go back out and do more stuff before 5pmEST. It's cool you're all still talking about this. What I'll do is to install the mozmck packages on the Smithy CF cards and use them in new machines. If possible I'll get someone to test out the machines first :)
[18:31:42] <mshaver> Will there be another point release before the CD is spun?
[18:32:17] <cradek> questions about the future are unanswerable in any real sense
[18:33:28] <cradek> (although there sure are a lot of changes since 2.4.2)
[18:33:49] <mozmck> hmm, for the livecd should I use the point release or the latest on v2.4_branch?
[18:34:48] <jepler> I'd like to do another release before finalizing the CD
[18:35:06] <jepler> particularly since there's at least one real embarassing bug in 2.4.2 that wasn't in 2.4.1
[18:35:12] <jepler> ... which is my fault
[18:35:40] <mshaver> I just want one more chance to finalize my config files...
[18:35:53] <mozmck> I need to get back to work. I'll try real hard to get my end done this week. Maybe most of it tonight.
[18:36:07] <jepler> OK. As always, thanks for your work.
[18:36:18] <cradek> yes, we really appreciate it
[18:36:45] <cradek> jepler: why don't I see that change? you are talking about the tabs on the tuning thing?
[18:36:59] <jepler> did I not push the fix?
[18:38:13] <jepler> argh, I haven't pushed the fix
[18:38:15] <cradek> not that I see
[18:38:21] <jepler> not only am I incompetent...
[18:38:26] <cradek> dude!
[18:41:24] <CIA-4> EMC: 03jepler 07v2.4_branch * r26344a5fec01 10/tcl/bin/emccalib.tcl: emccalib: Fix second and subsequent tabs
[18:43:17] <jepler> hmmmm jon elson describes a different problem -- that the last page doesn't work
[18:43:41] <jepler> * jepler wonders if there are two emccalib bugs
[18:45:50] <jepler> mozmck: I probably won't do 2.4.3 before the weekend anyway
[18:50:04] <mshaver> Between now & the weekend I can clean up my config file mess, so that's good! Maybe even run a machine test or two. Back in a while...
[18:50:34] <jepler> mshaver: OK
[18:51:04] <jepler> mshaver: feel free to push any tested configuration improvements to v2.4_branch and remember that they'll get made on master by merge so no need to push them twice.
[19:04:09] <JT-Work> jepler: you did ask me to test the emccalib patch but I never could get it to work, I didn't report back success...
[19:05:01] <jepler> JT-Work: oh that's right
[19:05:09] <jepler> you told me the patch didn't even apply, but I know it does..
[19:05:38] <JT-Work> for some reason it gave me an error when I tried to apply it
[19:06:11] <jepler> since it's on v2.4_branch now you can test just by getting the latest..
[19:07:43] <JT-Work> I'm running 2.5 pre on the Hardinge and 2.4 installed on the plasma but I think I have a RIP of 2.4 also on the plasma. I'll check this evening when I get home
[19:11:26] <skunkworks_> mozmck: I think I have all the manuals now for the asymtec
[19:28:21] <skunkworks_> mshaver: so... what are you making for mach? also - did the storms miss you?
[20:33:22] <tomaw> [Global Notice] Hi, as you're no doubt aware some of our equipment is having connectivity issues. We're looking to resolve this presently. Appologies for the noise and thanks for using freenode!
[20:49:24] <andypugh> Any chance of the motor control comps making it into the next release?
[21:01:39] <jepler> argh, I haven't even gotten those on master yet have I
[21:04:23] <andypugh> I didn't want to appear too pushy...
[21:04:50] <skunkworks_> Pusher!
[21:05:07] <skunkworks_> and what about the tool change fix? huh?
[21:06:54] <jepler> andypugh: looks like the last iteration of bldc_hall3 is Date: Sun, 20 Jun 2010 21:25:58 +0100
[21:06:57] <jepler> andypugh: is that right?
[21:07:33] <jepler> andypugh: and bldc_sine from Date: Sun, 13 Jun 2010 23:15:43 +0100
[21:08:20] <alex_joni> jepler: how about new kins?
[21:08:27] <alex_joni> would you include that in 2.4?
[21:08:50] <alex_joni> shouldn't touch anything, nor be used by anything
[21:09:06] <jepler> alex_joni: if you promise me it's tested and works well enough
[21:09:10] <alex_joni> (2.5 is just as fine for me aswell)
[21:09:28] <alex_joni> it's completely untested, and I'm not sure how to ;)
[21:09:36] <alex_joni> it's for a delta robot
[21:09:36] <jepler> alex_joni: then no
[21:09:46] <alex_joni> master it is
[21:10:01] <jepler> andypugh: I feel pretty good about putting bldc_hall3 in, less good about putting bldc_sine in.
[21:10:31] <andypugh> I am pretty sure both those versions are the latest.
[21:11:04] <jepler> andypugh: my remaining concern about the sine-wave driver is how the orient step fits in to the power sequencing. Can you remind me how this is going to work?
[21:11:27] <andypugh> I have almost forgotten myself.
[21:13:11] <jepler> I remember thinking that we could improve the motion controller to explicitly allow for this step when turning on motor amps but that requires someone with the guts to modify the motion controller to add it
[21:13:46] <jepler> let me stick hall3 in and then maybe one of us can find an irc log or e-mail where we discussed this
[21:15:05] <andypugh> The way I had it was with the actual amp-enable signals driven from the init-done pin of the driver.
[21:16:01] <andypugh> Hang, on, no I didn't.
[21:16:17] <andypugh> The machine with the test config on it is in the garage, powered down.
[21:17:31] <mshaver> jepler: Right! (re: 2.4 branch commits)
[21:18:20] <skunkworks_> mshaver: so... what are you making for mach? also - did the storms miss you?
[21:21:15] <mshaver> skunkworks_: The storms - we got some. Luckily there wasn't enough lightening to destroy my somewhat delicate outdoor communications plant. As for mach, I need to make some money, so I'm working on a CAM thingy for plasma cutter applications. I'm mostly in the research phase of this, trying to decide what technologies I can use to easily make what I want.
[21:23:38] <skunkworks_> neat!
[21:28:09] <CIA-4> EMC: 03jepler 07v2.4_branch * rf5ad8d5787d4 10/src/hal/components/bldc_hall3.comp: bldc_hall3: commutation of BLDC motor w/hall sensors
[21:29:52] <mshaver> skunkworks_; So, you read the whole internet every day?
[21:32:55] <Jymmm> * Jymmm has the whole internet on 3.5" floppy
[21:34:44] <KimK> * KimK is reminded of that early Dilbert where the PHB says, "Carol, would you print out the internet and put it in a three-ring-binder so I can read it on the plane."
[21:35:31] <jepler> andypugh: I'm on my way out. I didn't find the discussion of power-on sequence on the mailing list or my irc logs. Can you post on the developers list (and maybe cc to me) how startup will work? If it seems workable without changing motion I'll put it in v2.4. Otherwise, I'll put it on master.
[21:35:57] <jepler> and get my attention about this again on thursday or friday if you don't see any action on my end
[21:36:00] <skunkworks_> mshaver: I read the highlights...
[21:42:57] <KimK> If you don't have time to read the highlights, you can just download the internet:
http://www.stupidstuff.org/main/downloadthenet.htm
[21:45:38] <andypugh> (Parents just phoned)
[21:46:01] <andypugh> OK, Jepler, I will see what I can find up
[21:47:08] <mozmck_work> mshaver: how will your plasma CAM be compared to sheetcam?
[22:17:06] <Dave911> mshaver: Mach .... careful as you might find some stability issues .... seriously
[22:18:14] <Dave911> And if you do run into them ... there won't be a thing you can do about them.. been there...
[22:20:07] <Dave911> That stated... IMO - there is a lot of room for improvement in the Plasma market. I know of some guys ready to rip Mach off their plasma cutter due to instability..
[22:29:19] <mshaver> mozmck_work: It's not like I've thought this through or anything, but I'm aiming to make something that really simple to use with prepackaged, ready to make projects. Sort of like a scroll saw book... I'll have to load up sheetcam and see if I'm trying to reinvent the wheel. Honestly, I'm just trying to make some money. My primary source of income is cutting my hours by at least 2/3 and I've got to fill that gap!
[22:30:45] <mshaver> Dave911: I'm going to make it work for EMC too, but Mach has 10x the users. Plus, Windows users are used to paying for software.
[22:34:39] <Dave911> Making money .... yep I can relate.. Cutting by 2/3rds .. that stinks. Yes Mach does have a large following.. However it seems that the large following is beginning to become more than a bit bewildered. Still they have many more users I'm sure. Just wanted to let you know what I have seen and gotten sucked into myself... Becareful out there... :-)
[22:40:34] <Dave911> Sheetcam is a decent piece of software. But again there is room for improvement for sure. Another area where I think there is room for a new solution is part nesting software. I have yet to find reasonably priced nesting software that works. Mynesting.com is the best thing I have found without investing big bucks.
[22:48:18] <JT-Hardinge> jepler: I finally got a 2.4.2 RIP running and the emccalib.tcl commit works for me on the plasma all tabs show up for me
[22:49:59] <JT-Hardinge> but you knew it would work...
[23:13:46] <jepler> JT-Hardinge: thank you for testing.
[23:14:39] <JT-Hardinge> np
[23:44:43] <mozmck> jepler: I built a source package using the dpkg-buildpackage as you said, but it gives me this warning:
[23:44:45] <mozmck> dpkg-source: warning: source directory 'ubuntu-lucid' is not <sourcepackage>-<upstreamversion> 'linux-2.6.32'
[23:45:50] <mozmck> Should I change the directory name of my kernel source? This is the name of the the ubuntu git tree...