Back
[02:47:36] <cradek> woohoo!
http://emc2-buildbot.colorado.edu/~buildmaster/dists/lucid/master-rt/binary-i386/
[02:55:38] <seb> :-)
[03:04:23] <cradek> micges: I think I agree with jepler - why not keep the names? they're not gratuitously bad or anything. you could easily avoid breaking hal files.
[03:08:11] <cradek> also, I think it's totally great that you're working on that. it will make everything much less sucky!
[03:09:03] <cradek> we should have done it when we moved spindle control into motion... 20/20 hindsight.
[03:11:04] <cradek> seb: will the deb-lucid-rt-binary-i386 build always start with a fresh pbuilder setup?
[03:19:28] <cradek> jepler: "(Note) The initial level represents the absolute position of the drilling axis when switched from the canned cycle cancel status to the canned cycle mode." </fanuc 10M, 11M, 12M>
[03:20:37] <cradek> so if you wanted a new "initial" height you'd cancel with G80 (or other non-cycle motion I assume) and then begin the new cycle
[03:20:59] <cradek> I always wondered what the point of G80 is - I have never used it
[03:54:34] <seb> cradek: yeah, pbuilder uses a tarball that it unpacks and chroots into, builds the deb in there & copies it out, then throws away the chroot leaving the tarball untouched
[03:57:06] <seb> the "update pbuilder" step of that build unpacks the chroot, "apt-get dist-upgrades" inside, and saves the result as the new tarball
[03:57:18] <seb> so each time it builds the deb it does so in a fresh, minimal lucid install
[03:59:17] <cradek> that's quite fancy
[03:59:23] <cradek> no wonder you notice the missing dependencies
[03:59:30] <seb> pbuilder's good stuff
[04:00:16] <cradek> thanks for doing the care and feeding of all that handy goo
[04:05:49] <seb> sure! :-) and thanks for making a machine controller that's worth building and distributing :-)
[04:06:19] <cradek> oh you give me too much credit - I've probably only hacked on half of it :-)
[04:06:24] <seb> hehe
[04:06:41] <cradek> right now I'm wading through the canned cycle code
[04:07:11] <seb> you said above "</fanuc>"... do you have access to any fanuc g-code specs?
[04:07:13] <cradek> trying to fix retract modes (robh awesomely sent me a fanuc manual)
[04:07:17] <seb> ah!
[04:07:20] <cradek> yes!
[04:07:50] <seb> is it hardcopy?
[04:08:16] <cradek> yes
[04:08:20] <seb> boo
[04:09:07] <seb> it seems like fanuc is a kind of de facto standard... do you have a feel for how emc2's gcode differs?
[04:09:37] <cradek> yes I have a little more of a feel after flipping through it
[04:09:46] <cradek> the more obscure the feature, the more we differ
[04:09:55] <seb> makes sense
[04:10:00] <cradek> fanuc 10m seems like it was an amazing control for 1984
[04:10:12] <cradek> that's the same age as the BOSS8 and it was not nearly as capable
[04:10:46] <seb> what fanuc version are they on now? is there a lot of gcode differences between fanuc versions?
[04:10:59] <cradek> I don't know either of those answers
[04:11:44] <seb> do they have all the cool O-word features emc2 has?
[04:11:47] <cradek> this seems to be part of what ngc was modeled after - a lot of stuff is just the same
[04:11:59] <cradek> they have subprograms etc, but format is completely different
[04:12:05] <seb> ugh
[04:14:45] <seb> when using the "o<filename> call" syntax, it seems like filename.ngc can not define new subroutines and have them become available in the caller's scope, is that true?
[04:16:39] <cradek> I think it assumes filename contains just one subroutine o<filename> sub ... endsub
[04:16:55] <cradek> (I sure don't know how that stuff works)
[04:17:47] <seb> that's a cool feature
[04:18:16] <cradek> yes it is
[04:18:23] <seb> i wonder if people use that as a kind of shared library mechanism, with things like slot.ngc, helix-hole.ngc, etc
[04:18:30] <cradek> I wish it worked better in mdi so we could have gui macros in an obvious way
[04:18:39] <seb> ooohhh!
[04:19:02] <cradek> touchy has that feature already (on a branch)
[04:19:25] <cradek> it awaits a working O-call in mdi mode that I hope will happen someday
[04:19:50] <seb> nifty
[04:20:21] <seb> there's something similar available in the M1xx codes, right?
[04:20:43] <cradek> those just run a shell script and wait for it to finish
[04:20:52] <cradek> fairly different
[04:21:00] <seb> right, not gcode... hmm
[04:21:13] <cradek> it's an adequate way to make a custom gcode that sets a hal bit for instance
[04:23:03] <seb> oh, here's what i was thinking of
[04:24:05] <seb> if your ini has some [HALUI]MDI_COMMAND stanzas, then your M1xx script can use halcmd to poke halui.mdi-command-yy to run those g-codes. i think!
[04:25:53] <cradek> that may work in a roundabout way in mdi mode, but it wouldn't work while running a program, because the system's not in mdi mode
[04:26:21] <seb> oh, right
[04:30:00] <cradek> if (motion == G_73 || ((motion > G_80) && (motion < G_90))) {
[04:30:16] <cradek> can you write the opposite of this case to help me sanity-check?
[04:31:04] <cradek> forget it - I'll put a ! in front of it, duh
[04:31:11] <seb> if (!(motion == G_73 || ((motion > G_80) && (motion < G_90)))) {
[04:31:13] <seb> heh
[04:31:17] <cradek> :-P
[04:31:52] <seb> } else {
[04:31:55] <seb> :-P
[04:57:58] <cradek> ouch, I changed canned cycles pretty substantially and didn't break any runtests
[05:23:27] <CIA-2> EMC: 03cradek 07master * rdf5a469d702a 10/src/emc/rs274ngc/ (4 files): Fix g98/g99 to match fanuc retract planes behavior
[05:23:56] <cradek> goodnight!
[10:52:32] <alex_joni> seb: I think (not 100%) sure that when you do an o-call of a named file, all the functions get added to the scope, but the one called has to be in there
[10:52:59] <alex_joni> so O<foo> call calls foo from foo.ngc, but if a bar proc is before that you can afterwards call bar
[10:53:33] <alex_joni> at least that's how my (spotty) memory remembers the explanation from lerman
[10:54:04] <alex_joni> (it was many moons ago, so it might be that I remember it wrong, or that the behaviour is broken in the mean time ;)
[11:48:18] <alex_joni> micges: hi
[11:48:45] <alex_joni> I agree with cradek and jepler, moving the pins to RT and keeping the names is the best way to do it
[11:49:11] <alex_joni> I'm really sorry I added the icontrol.0. part, as it wasn't ever meant to have more than one, but maybe it's ok to live with it
[11:51:48] <micges> alex_joni: hi
[11:53:38] <micges> alex_joni: I don't agree with you all, but seeing trouble with changing tool table format, keeping hal names is only sane way
[11:54:07] <alex_joni> micges: I know it would be nice to change them - having more descriptive names, etc
[11:54:15] <alex_joni> but as you've seen it causes problems with users
[11:54:28] <alex_joni> and doing lots of aliases is also not a solution
[11:54:39] <alex_joni> (especially with stepconf/pncconf around now)
[11:56:50] <micges> if we can mark pins as depreciated and it will show warning message if user use it by net command, hal names can be changed more often
[11:56:58] <micges> (just an idea)
[11:57:51] <alex_joni> well.. if users configure/run configs from the terminal (to see the warnings) then they will have no problems with changing the names
[11:57:59] <alex_joni> it's the other users I'm worried about
[11:59:03] <micges> so I think we should accumulate all nessesary hal names changes into one major change
[11:59:19] <alex_joni> right, maybe have it together with ja3 changes
[11:59:30] <alex_joni> where axis.* changes to joint.*
[11:59:47] <micges> I hope 2.5.0
[11:59:49] <morficmobile> <CIA-2> [00:04:26] EMC: cradek master * rdf5a469d702a /src/emc/rs274ngc/ (4 files): Fix g98/g99 to match fanuc retract planes behavior <---- SWEET!
[12:00:24] <alex_joni> on that note: seb: I got some fanuc documentation in electronic form if you (or someone else) wants it
[12:01:10] <morficmobile> mind /msg morfic the link directly, so my forgetful self won't forget to get it?
[12:01:22] <alex_joni> which link?
[12:02:04] <morficmobile> unless you do not link the documentation in electronic form, then i hope morfic's auto accept is working :>
[12:02:30] <alex_joni> ah for the fanuc? it's not online, as it's probably not allowed to redistribute it :)
[12:03:06] <alex_joni> /msg me an email addy
[12:54:42] <jthornton> is this a rtai version of 10.04?
http://linuxcnc.org/mozmck/newest/ubuntu-10.04-desktop-i386-linuxcnc.iso
[12:55:33] <jthornton> I assume you don't use jepler install script with it
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Ubuntu10.04PackageNotes
[12:56:17] <jthornton> * jthornton needs to RTFM slower when following instructions
[12:57:04] <micges> haha
[12:57:56] <jthornton> yea after fouling that up and rebooting it left me at the command line LOL
[12:59:32] <jthornton> I wish there was a README on this page
http://linuxcnc.org/mozmck/newest/
[13:00:40] <mozmck> jthornton: didn't think of a README. It is a rtai version with emc2 and emc2-dev installed
[13:01:12] <jthornton> so do I have to install all the files on that page?
[13:02:47] <mozmck> If you use the iso you don't need any of the other files. the iso_md5sum.txt has the md5sum for the iso to make sure it downloads correctly
[13:03:20] <mozmck> All the other files there are in the lucid repository now.
[13:04:33] <jthornton> I downloaded the iso and installed it but there was no CNC menu but I didn't get a chance to check the md5sum
[13:06:55] <mozmck> no CNC menu? I don't know how that could be - unless the install grabbed another kernel from the net and made emc2 uninstallable...
[13:07:06] <mozmck> What kernel is it running?
[13:08:02] <jthornton> don't know I've all ready covered that one up with a fresh stock install to try jepler script but I can try again in a bit
[13:10:22] <jthornton> I just put your disk in and installing it now
[13:12:53] <mozmck> When I installed stock 10.04 on this machine I think it downloaded and installed the pae kernel because the machine had 4gig memory. The CD doesn't have the pae kernel so that must be what it did.
[13:14:16] <jthornton> I can't even pretend to understand what you said LOL
[13:15:57] <jthornton> I think I have 8gig of memory on this one
[13:17:23] <morficmobile> which adds fuel to what he suspects, memory size related automagic not getting you the right kernel
[13:18:02] <morficmobile> mozmck: you can't get rid of this logic for the emc iso?
[13:18:54] <mozmck> I probably can, but I didn't even think about that until now. I'll have to dig in and see what it's doing.
[13:19:38] <jthornton> mozmck as soon as it installs I'll let you know what kernel it has
[13:20:18] <mozmck> Thanks, that will give us something to start with. Of course now that we're looking it will all work fine :)
[13:35:38] <jepler> I suspect that it's /usr/share/ubiquity/check-kernels that does it. I'd try deleting the group of lines below the comment that mentions bug
https://launchpad.net/bugs/413135
[13:39:46] <mozmck> thanks jepler. I'm trying to find ubiquity documentation and it seems more sparse than grass in in the Mojave!
[13:44:15] <jthornton> mozmck the install is done and the kernel is 2.6.32-21-generic and reports that I have 1.9GiB of memory
[13:45:19] <jthornton> and no CNC menu
[13:45:50] <jthornton> do you need me to check anything else before I try jepler's instructions on the wiki?
[13:46:47] <jepler> jthornton: dpkg -l emc2
[13:46:49] <jepler> is the package installed?
[13:46:55] <jthornton> ok
[13:47:13] <jepler> if the installer removed the realtime kernel (instead of just selecting the pae kernel as default) then it will have removed the emc2 package too
[13:47:42] <jepler> if so the emc2-install.sh should download what you need
[13:47:44] <jthornton> unknown option -1
[13:48:07] <jepler> el, not one
[13:48:24] <jthornton> when I tried the emc2-install.sh when it was done it booted to the command prompt
[13:48:50] <jthornton> no packages found matching emc2
[13:48:50] <jepler> oh.
[13:49:19] <jthornton> I have a stock 10.04 disk that I can try
[13:50:06] <jepler> it would be interesting to know if that behaves any different
[13:50:35] <jthornton> ok, I'll try it now if nothing else is needed from mozmck's install
[13:50:45] <jepler> did emc2-install.sh say it was going to *remove* any packages?
[13:51:20] <jthornton> I didn't notice anything but will watch it closer this time
[13:51:39] <jepler> running it again will probably not do much
[13:51:49] <jepler> well, it will if you reinstall from the mozmck cd first
[13:55:03] <jepler> bbl, it's breakfast time here
[13:55:06] <jthornton> it just says that extra packages will be installed
[13:55:08] <jthornton> ok
[13:55:45] <jthornton> bbl, time to run the backhoe for a while before it gets way too hot
[13:57:51] <mozmck> that's weird. Are you sure you installed from my CD? Because I completely removed all other kernel packages.
[14:01:32] <mozmck> that really doesn't make sense, because the latest kernel from ubuntu is 2.6.32-24, not -21
[14:02:36] <mozmck> I think you accidentally burnt the wrong ISO! :)
[14:10:19] <alex_joni> jthornton: check the livecd first and see if the CNC menu is up
[14:19:38] <CIA-2> EMC: 03mshaver 07v2.4_branch * r44780f562246 10/configs/smithy/ (12 files):
[14:19:38] <CIA-2> EMC: Improves system behavior by pausing the program when a guard is opened during a
[14:19:38] <CIA-2> EMC: program. When the door is closed the spindle will restart, but the operator will
[14:19:38] <CIA-2> EMC: have to manually resume axis motion. This gives the spindle time to reach the
[14:19:38] <CIA-2> EMC: programmed speed and improves operator safety.
[15:05:53] <Guest480> Guest480 is now known as skunkworks_
[15:21:16] <cradek> jepler: I remember you made a patch for 2.4 that combined my two attempts to fix the rfl/Osub problem, but I can't find that you pushed it.
[15:58:33] <jepler> cradek: hmmmm
[16:00:56] <jepler> thanks
[16:01:02] <CIA-2> EMC: 03jepler 07v2.4_branch * r9a21aa6fa588 10/src/emc/task/emctaskmain.cc: Fix RFL when starting between a sub definition and its call
[16:15:40] <jthornton> weird this time jeplers script installed EMC just fine on top of mozmck's and it is running 2.6.32-122-rtai
[16:18:13] <jthornton> however my max jitter is 775,500ns :(
[16:19:31] <jepler> that's no good
[16:19:59] <jthornton> yea, I'm going to try the stock 10.04 then your script to see what that does
[16:22:27] <jthornton> bbl, almost got the stump dug out :/
[16:23:33] <Jymmm> jthornton: explosives
[16:39:29] <cradek> jepler: thanks
[16:58:20] <CIA-2> EMC: 03cradek 07master * re9d24671e482 10/src/emc/rs274ngc/interp_cycles.cc: Fix g83 peck retract to match fanuc
[17:28:48] <jthornton_> jthornton_ is now known as jthornton
[17:51:53] <CIA-2> EMC: 03jepler 07v2.4_branch * r046d44714200 10/ (VERSION debian/changelog): release version 2.4.3
[18:15:09] <cradek> yay!!
[18:15:17] <cradek> thanks jepler!
[18:15:28] <jepler> don't celebrate until I get it built...
[18:15:51] <cradek> it's OK if I'm forced to celebrate twice.
[18:15:55] <jepler> hah
[18:16:12] <jepler> (I upgraded to 10.04 on the system where I normally do the 8.04 builds)
[18:17:36] <jepler> I suppose that just means I should start with 10.04
[18:21:39] <jepler> argh, that machine's not ready to build packages either, it doesn't have the docbuilding stuff
[18:50:42] <cradek> I might have any particular machine you need (if slow), just let me know
[18:56:05] <jepler> thank you
[19:03:14] <jthornton> If I can help with any of this let me know
[19:03:52] <alex_joni> jepler: let me know when it's ok to upload the tar.gz to sourceforge and do the linuxcnc announcements
[19:04:27] <alex_joni> it's probably best that I wait till the tar.gz is uploaded to sources
[19:07:16] <jepler> 8.04/amd64 packages are uploading now
[19:11:20] <Dave911> dgarr: I'm getting this "REDIRECT_STATUS=404: Not Found" when I go to the links you put above ...
[19:34:27] <jepler> alex_joni: if you want to go ahead, you should be able to use hardy/emc2.4/source/emc2_2.4.3.tar.gz
[19:35:39] <alex_joni> jepler: thanks
[19:41:37] <jthornton> jepler: when I install a fresh copy of 10.04(from Ubuntu) then run your script everything works fine and I'm back to my 5700ns latency on that motherboard
[19:42:52] <jepler> jthornton: so you get bad latency when running lantecy-test booted from the live CD, good latency when running from the hard drive?
[19:43:09] <jepler> try accessing the cdrom while booted from the hard drive and running latency-test
[19:43:44] <alex_joni> on the p4 I tried I got 5000ns latency until I started with cdrom accesses
[19:43:45] <jthornton> no, when I ran your script on top of mozmck's to install EMC
[19:43:51] <alex_joni> then it went up to 27800
[19:44:15] <alex_joni> jthornton: if you really used the latest (and only one) iso from mozmck then you shouldn't have to install anything
[19:45:07] <jthornton> yes, I know and it is the one from mozmck but I didn't check the md5 so it might be bad I don't know
[19:49:08] <jepler> I don't have any other immediate guesses about what the difference is
[19:58:53] <mozmck> I don't see how the kernel could be 2.6.32-21 because I completely removed that from the CD. So if it downloaded something it should have gotten 2.6.32-24, and it should really have gotten the pae kernel.
[19:59:02] <jthornton> I don't either but it works now so I'll finish setting it up for editing docs etc
[19:59:19] <mozmck> jthornton: did you see if the CNC menu was there just booting off the liveCD?
[19:59:23] <jepler> but if jthornton had a non-rtai kernel then the latency test wouldn't have run at all
[19:59:45] <jthornton> mozmck I went straight for the install
[19:59:56] <jthornton> didn't try the try it now option
[20:00:28] <mozmck> jepler: I think he only could run the latency test after running your script to install the kernel and emc2
[20:01:14] <mozmck> I wonder if going straight to the install works differently somehow than booting first and then installing from the icon on the desktop?
[20:02:58] <jepler> I can't imagine why they'd make it that way
[20:07:35] <mozmck> me neither. I'll have to try it both ways and see if it does differently.
[20:09:22] <jthornton> guys, I must have grabbed the wrong .iso from my desktop at work and burned it to the CD... it is the only explanation I can come up with
[20:13:02] <mozmck> no cnc menu when booted on the liveCD?
[20:13:19] <jepler> 2.4.3 packages for 8.04 should now be live on the package repository
[20:21:36] <cradek> yay!!
[20:23:37] <CIA-2> EMC: 03cradek 07master * r266aca1e364d 10/src/emc/usr_intf/touchy/ (hal_interface.py touchy.py): touchy: finish support for panel indicators of status
[20:29:42] <micges> cradek: in iotask there is pin named user-request-enable and it is strobed for one io cycle (100ms default) for reset optional HAL latch
[20:29:57] <JT-Work> I can now confirm that I grabbed the wrong .iso from my desktop here at work
[20:31:11] <micges> I wonder if I must left it configurable (iotask remove)
[20:35:38] <mozmck> JT-Work: that's good to hear on my end! sorry for the trouble it caused you though.
[20:37:47] <alex_joni> micges: I'm not sure I understand
[20:39:02] <micges> in EMC_AUX_ESTOP_OFF_TYPE there is line *(iocontrol_data->user_request_enable) = 1
[20:39:25] <micges> at end of loop there are
[20:39:26] <micges> esleep(EMC_IO_CYCLE_TIME);
[20:39:39] <micges> *(iocontrol_data->user_request_enable) = 0;
[20:40:27] <micges> so it seems that there is peak for some hal latches of duration of one [io]CYCLE_TIME
[20:43:15] <alex_joni> hmm.. user_request_enable should be the output from emc2 that tells estop reset
[20:43:31] <alex_joni> check the comment at the beginning of iocontrol.cc
[20:44:20] <micges> user-enable-out is for this task
[20:45:41] <micges> I can easly copy whole behavoiur, but I don't know if duration of that request-enable pin must be configurable
[20:46:04] <alex_joni> nobody complained until now
[20:46:18] <alex_joni> and if needed they can add an external latch
[20:47:15] <micges> so 1ms peak for driving external latch should be ok?
[20:53:59] <jepler> and now the 10.04 packages should be live as well.
[20:56:23] <alex_joni> alex_joni has changed the topic to: EMC2 development --
http://linuxcnc.org/ | Latest release: EMC 2.4.3
[20:58:05] <seb> i have a .ngc file that calls another using "o<otherfile> call", which is cool
[20:58:31] <seb> when i run it in axis, and it gets to the other-file call, the file view pane on the bottom doesnt show the called file, instead it shows the bottom of the calling file
[20:59:26] <jepler> yeah, that's what it does
[20:59:27] <mshaver> So, I have a 10.04 system that has the -122 kernel. I'm pointing at the lucid repo, but can't install the update because: Depends: linux-image-2.6.32-22-rtai but it is not installable + Depends: rtai-modules-2.6.32-22-rtai but it is not installable + Recommends: hostmot2-firmware but it is not installable
[20:59:52] <alex_joni> hmm.. sounds like packages depend on -22 ?
[20:59:54] <seb> after the other-file call returns, the next motion line in the calling file updates the file view pane with the active motion line
[21:00:07] <mshaver> Of course, my system may just be too weird to exist...
[21:00:30] <jepler> no, I probably just uploaded broken packages :-/
[21:00:45] <jepler> I built them on a system with 2.6.32-22-rtai installed
[21:01:02] <jepler> * jepler curses up a storm
[21:01:07] <alex_joni> mshaver: just hang on a while
[21:01:08] <mshaver> Should I "downgrade" the kernel? Being as there's no real -122?
[21:01:19] <alex_joni> there's a reason these things are still in beta
[21:01:24] <mshaver> OK, digging in...
[21:01:30] <alex_joni> mshaver: there is a 122 (which is the latest)
[21:01:54] <alex_joni> just jeff didn't have it installed, so the packages he built depend on -22 which isn't in the repo
[21:02:17] <mshaver> yea, but that big number (122) is just a way of disabling auto upgrades, right? I mean, there wasn't a 121 or 120, etc
[21:02:35] <mshaver> Oh, OK.
[21:02:37] <alex_joni> right
[21:02:48] <alex_joni> it's a 22 rebranded
[21:03:46] <mshaver> right, and that's what we're going to do? I mean, there's no "official" way to disable auto upgrades - other than this method?
[21:04:30] <jepler> you must be looking for the room full of experts in apt, they're not here
[21:04:38] <jepler> we tossed around some ideas and went with this one
[21:05:42] <alex_joni> my guess was that this one is the most likely to get right
[21:05:43] <jepler> well, I'll get a new package built but it'll be awhile due to the glacial upload speed on my line
[21:06:24] <mshaver> I pretty much always expect everyone else to be much smarter than me and that they must be total experts at everything. I may be mistaken, but it makes me feel better to know that it's not really that way.
[21:06:54] <jepler> mshaver: for the moment you might try to sudo apt-get install emc2=1:2.4.2-37-gf5ad8d5
[21:07:07] <mshaver> OK, hanging out then - no hurry I was just fooling around
[21:07:10] <jepler> that'll request the version just older than the one built today that is leading to the dependency problem.
[21:07:13] <seb> if you "o<file> call" a file that defines named variables, those variables do not become available in the calling program :-(
[21:08:50] <mshaver> $dpkg - l emc2 --> 1:2.4.2-37-gf5 (now & before I tried the upgrade)
[21:09:33] <jepler> oh, I guess dpkg stopped with your old packages installed then
[21:10:03] <mshaver> yes
[21:10:09] <seb> mshaver: dpkg --audit?
[21:11:02] <mshaver> seb: that just returns with no output
[21:11:12] <seb> hm
[21:11:45] <seb> you're trying to apt-get dist-upgrade when you get that "Depends:" error above?
[21:12:05] <seb> do you have the "base" component in your .list file?
[21:12:59] <jepler> seb: no need to troubleshoot mshaver's problem
[21:13:02] <jepler> seb: I put up a busted package
[21:13:07] <mshaver> no, I've already got lucid installed and all the "latest" mozmck packages. I'm just doing apt-get update; apt-get upgrade to get the latest emc2
[21:13:22] <alex_joni> which jepler will upload in a bit
[21:14:48] <mshaver> and I'm only doing that because I happened to click on the irc window and noticed what was going on - and my "must always upgrade immediately" tendencies took over.
[21:15:15] <jepler> no, I'm glad to have the problem reported
[21:15:58] <mshaver> yea, I thought it had to be tried :)
[22:07:02] <jepler> new "2.4.3.1" packages for Ubuntu 10.04 are now available .. and this time I checked that they install, too
[22:12:43] <robh__> through you might like to see some results from trying out the 10.04 live CD on two systems.
[22:12:49] <robh__> Motherboard : gigabyte - ga-ep41-ud3l -
http://pastebin.com/EPaMyp1q
[22:13:42] <robh__> this one is abit more odd, works fine on 8.04 but 10.04 is quite high on the latency, not sure why. MotherBoard : gigabtye - ga-p35-s3g -
http://pastebin.com/HacJ2R3F
[22:14:56] <jepler> yuck, too bad about the latter system
[22:15:56] <robh__> yes not sure why it would work fine in 8.04 live cd seems no SMI support to try for that chipset ICH9
[22:16:56] <mshaver> In
http://www.linuxcnc.org/emc2/dists/lucid/emc2.4/binary-i386/ there's an emc2_2.4.3.1.tar.gz, but no emc2_2.4.3.1_i386.deb. There is an
http://www.linuxcnc.org/emc2/dists/lucid/emc2.4/binary-i386/emc2-dev_2.4.3.1_i386.deb.
[22:18:35] <jepler> what the?
[22:18:38] <jepler> how'd I do that :-/
[22:18:54] <alex_joni> robh__: one won, one lost :/
[22:19:45] <mshaver> deuce - the line is, "What the deuce?" Family Guy, Stewie Griffin...
[22:20:32] <mshaver> Not one of my favorite shows, but one can't get behind on pop culture references!
[22:21:02] <skunkworks> Greeat job on the release!
[22:21:06] <skunkworks> great!
[22:21:19] <jepler> skunkworks: thanks, but it'll take a charmed third try at getting a 10.04 package right :-/
[22:21:30] <skunkworks> heh
[22:37:46] <cradek> micges: I know a 1ms strobe won't work on at least one of my systems, because it uses a physical relay to latch. I don't think 1ms is nearly long enough.
[22:39:42] <micges> cradek: 100ms?
[22:40:22] <cradek> if that's what it does now, yes, that is enough :-)
[22:40:40] <micges> that's default length
[22:41:11] <micges> cradek: thanks for info
[22:41:27] <cradek> micges: and thanks for doing the work
[22:41:54] <CIA-2> EMC: 03micges 07iotask_remove * r63b46039ef75 10/src/emc/ (14 files in 5 dirs): Move estop functionality from iotask to motion
[22:42:14] <micges> will change strobe tomorrow
[22:42:18] <micges> good night all
[22:42:29] <cradek> cool, I will look at it, goodnight
[22:43:26] <cradek> seb: I can tell you're itching to become our expert in task and interpreter!
[22:43:54] <alex_joni> especially o-word functions across files
[22:44:00] <alex_joni> and how the GUIs treat them
[22:44:21] <cradek> definitely, and also O-call from mdi
[22:44:53] <cradek> argh, I pushed a change by chris@jr.(none)
[22:44:54] <alex_joni> yeah, for unloaded files
[22:46:42] <skunkworks> cradek: did you see
http://www.electronicsam.com/images/KandT/conversion/servo/x-zservo_mount
[22:47:01] <skunkworks> moving the estop to motion should solve the tool chain issue - shouldn't it.
[22:47:21] <alex_joni> skunkworks: does that cound 10.04 downloads too?
http://emc2-buildbot.colorado.edu/~seb/billions-served/
[22:47:24] <alex_joni> count*
[22:48:24] <cradek> skunkworks: cool! I hope you don't enter it in any beauty contests though...
[22:49:02] <skunkworks> heh
[22:49:41] <JT-Hardinge> skunkworks: what tool chain issue?
[22:49:46] <alex_joni> the paper tape is especially pleasing design
[22:50:18] <jepler> * jepler hopes it's right this time
[22:52:02] <alex_joni> jepler: I notice lucid packages are 13MB, hardy are 16MB
[22:53:05] <skunkworks> jthornton: found that if you call a tool - but don't do a tool change (m6) and then hit the estop - when you bring the machine back up - it finds the tool again.
[22:54:06] <JT-Hardinge> oh, that is different than the problem I have from time to time
[22:54:10] <skunkworks> alex_joni: those servos pick up eveything
[22:54:22] <skunkworks> (strong maganets)
[22:54:41] <cradek> skunkworks: didn't I fix that? or someone?
[22:54:57] <JT-Hardinge> If I start a tool change but the turret misses then Axis is kinda locked up for a long time and there is no way to abort the tool change
[22:55:26] <skunkworks> I have a patch that seemed to work. I don't know if it was added to git.
[22:55:49] <skunkworks> I think jepler sent it to me.
[22:58:13] <cradek> if it's right, it should be in git. don't lose track of it or let him forget then.
[22:58:33] <alex_joni> jepler: it seems the pdf's for hardy are 3MB larger than the same pdf's for lucid
[22:58:42] <alex_joni> maybe compression got better
[22:59:12] <alex_joni> skunkworks: ans make sure you check after iocontrol is gone ;)
[22:59:40] <alex_joni> we should recheck all bugreports for iocontrol for the same reason
[23:17:16] <mshaver> OK, upgraded - seems to work!
[23:24:34] <jepler> alex_joni: interesting -- I hope the new pdfs are right, not wrong..
[23:25:06] <jepler> I don't remember what patch I sent sam :-/
[23:25:28] <cradek> that's going around lately
[23:25:37] <cradek> http://emc2-buildbot.colorado.edu/~buildmaster/dists/lucid/master-rt/binary-i386/emc2_2.5.0~pre0-645-g266aca1_i386.changes
[23:25:44] <cradek> I can't believe all the stuff waiting for 2.5
[23:27:33] <jepler> cradek: that doesn't filter out the stuff gotten via merge from v2.4_branch, so it's not quite as much as it looks
[23:27:44] <cradek> oh ok
[23:29:35] <jepler> 178 commits on v2.4_branch since v2.4.0. 496 on master since 2.4.0 (whether reachable from v2.4_branch or not). 323 on master and not on v2.4_branch (and why 178+323 != 496 I'm not sure)
[23:30:10] <cradek> cool, buildbot also built 2.4.3. maybe someday we can just start using those for releases?
[23:33:34] <skunkworks> so - if I install the lucid livecd - anything special I need to do to get all the updates?
[23:34:23] <skunkworks> just try it and see what happens ;)
[23:37:30] <cradek> unless mozmck made a new one while I wasn't looking, you won't have the linuxcnc repository in your apt sources list.
[23:37:54] <skunkworks> ok - so If I go into the package manager and add it - I should be ok?
[23:38:24] <cradek> yes
[23:39:01] <skunkworks> 41%
[23:40:43] <skunkworks> * skunkworks now has to figure out how to do that and what exactly to add. :)
[23:43:47] <skunkworks> those servos are heavy