Back
[00:07:19] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[01:05:32] <jmk-robot> 21083 on base thread, 17173 on servo, after 20ish hours
[01:55:51] <jepler> hi again
[01:55:53] <jepler> did I miss much?
[01:59:28] <SWPadnos> [19:27:54]|<--jepler has left chat.freenode.net (Read error: 110 (Connection timed out))
[01:59:29] <SWPadnos> [19:36:08]-->|skunkworks (n=skunkwor@str-bb-cable-south-1-197.dsl.airstreamcomm.net) has joined #emc-devel
[01:59:31] <SWPadnos> [19:49:28]|<--buildmaster has left chat.freenode.net (Read error: 110 (Connection timed out))
[01:59:32] <SWPadnos> [20:06:14]<jmk-robot>21083 on base thread, 17173 on servo, after 20ish hours
[01:59:34] <SWPadnos> [20:30:09]-->|jepler (n=jepler@emc/developer/jepler) has joined #emc-devel
[01:59:36] <SWPadnos> not really :)
[02:00:00] <jepler> just as well
[02:29:03] <jmkasunich> where would I find the source tree for our kernel?
[02:31:28] <SWPadnos> apt-get source <the kernel package name>
[02:32:31] <jmkasunich> duh
[02:32:59] <jmkasunich> this is odd - on this machine (dapper), the update manager says I can update to linux-image-2.6.15-53-686
[02:33:10] <jmkasunich> uname -r says I'm already running that kernel
[02:33:33] <jmkasunich> oh, fine print
[02:33:41] <jmkasunich> new version 2.7.15-53.75
[02:33:49] <jmkasunich> can they add any more numbers to that?
[02:35:41] <jmkasunich> ahh....
http://www.ubuntu.com/usn/usn-714-1
[02:43:19] <cradek> A local attacker could exploit this to cause a system hang, leading to a denial of service.
[02:43:23] <cradek> meh
[02:43:33] <jmkasunich> yeah, I thought about the same thing
[02:43:54] <cradek> glad I have single-ish user machines (mine) or trusted users who I could smite if they screw with me on purpose (work)
[02:43:58] <jmkasunich> a local attacker could also use an axe
[02:44:08] <cradek> or the power button
[02:44:34] <cradek> really, in this case local = can log in
[02:44:41] <cradek> not necessarily physical access
[02:44:49] <jmkasunich> I guess "local" is relative, at least one of those cases the attacker could be wireless
[02:57:52] <jmk-robot> cradek: what are the proper permissions for .gnupg/gpg.conf?
[02:58:07] <jmk-robot> I got an "unsafe permissions" warning, but the perms are 600
[02:58:15] <cradek> check the directory
[02:58:30] <jmk-robot> 700
[02:58:38] <cradek> how about your home dir
[02:59:03] <jmk-robot> 755
[02:59:20] <cradek> hmm
[02:59:24] <jmk-robot> drwxr-xr-x, I think thats 755 unless my bits are slipping
[02:59:31] <cradek> yeah that should be ok
[02:59:39] <cradek> I don't know what it's trying to tell you then
[02:59:56] <cradek> what's the actual message?
[03:00:04] <jepler> owner is you, too?
[03:02:51] <jmk-robot> gpg: WARNING: unsafe ownership on configuration file `/home/jmkasunich/.gnupg/gpg.conf'
[03:02:52] <jmk-robot> gpg: Signature made Sun 25 Jan 2009 05:54:43 PM EST using DSA key ID 17063E6D
[03:02:52] <jmk-robot> gpg: Can't check signature: public key not found
[03:03:08] <jmk-robot> that was printed as it was unpacking the kernel source package
[03:03:26] <jmk-robot> drwx------ 2 jmkasunich jmkasunich 4096 2009-01-27 23:54 .gnupg
[03:03:44] <jmk-robot> -rw------- 1 jmkasunich jmkasunich 28 2009-01-26 18:47 gpg.conf
[03:03:45] <cradek> it says ownership
[03:03:48] <cradek> you said permissions
[03:03:48] <jepler> http://marc.info/?l=gnupg-users&m=111170147828145&w=2
[03:04:09] <jmk-robot> sorry
[03:04:12] <jepler> gpg would display that error if running as root but with HOME=/home/jmkasunich
[03:04:27] <cradek> I bet jepler nailed it
[03:04:39] <jmk-robot> ah - I did "sudo apt-get source <kernel>"
[03:04:47] <jmk-robot> no sudo needed for source packages I bet
[03:04:50] <cradek> right
[03:05:07] <cradek> the idea is that any user can get the source to a program he's using, whenever he wants
[03:05:29] <cradek> (one of the cool things about apt, I think)
[03:05:33] <jmk-robot> right, I just didn't think about that - I knew it was gonna stick it in my own dir
[03:05:45] <jmk-robot> I'm accustomed to using sudo apt-get install
[03:06:49] <jmk-robot> something even weirder happened
[03:06:57] <jmk-robot> (and I only noticed now)
[03:07:09] <jmk-robot> jmkasunich@robot:~$ sudo apt-get source linux-image-2.6.24-16-rtai
[03:07:22] <jmk-robot> note - I asked for the source to our RT kernel
[03:07:37] <jmk-robot> Get:1
http://security.ubuntu.com hardy-security/main linux 2.6.24-23.48 (dsc) [2257B]
[03:07:44] <jmk-robot> it didn't fetch our kernel
[03:07:55] <jmk-robot> there were three files, dsc, tar, diff, all the same name
[03:08:02] <jmk-robot> dpkg-source: extracting linux in linux-2.6.24
[03:08:02] <jmk-robot> dpkg-source: unpacking linux_2.6.24.orig.tar.gz
[03:08:02] <jmk-robot> dpkg-source: applying ./linux_2.6.24-23.48.diff.gz
[03:10:53] <jepler> I must have discovered the same thing an age ago, because I recommended directly getting the tar.gz:
http://article.gmane.org/gmane.linux.distributions.emc.user/9172
[03:11:51] <seb_kuzminsky> jepler: i made sample configs for hm2 like it says on the Emc2.3Status wiki page
[03:11:54] <seb_kuzminsky> or at least i tried
[03:12:01] <seb_kuzminsky> It Works For Me(tm)
[03:12:12] <seb_kuzminsky> is it what you had in mind?
[03:13:25] <jepler> seb_kuzminsky: I'll look
[03:13:30] <jepler> jmk-robot: looks like this incantation would do it too:
[03:13:42] <jepler> apt-get source source linux=2.6.24-16.30.linuxcnc.1
[03:13:47] <jepler> s/source source/source/
[03:14:02] <seb_kuzminsky> also, BoD guys, what are you thinking for debian package splitting for 2.3?
[03:14:32] <jepler> I don't intend to work on it
[03:14:49] <seb_kuzminsky> i'll be happy to work on it, but i'm not sure what's wanted
[03:14:50] <jepler> I don't think somebody who doesn't need it should waste his time
[03:15:03] <jepler> supposedly there are people who want "minimal systems" without "lots of dependencies"
[03:15:09] <seb_kuzminsky> hmm
[03:15:13] <jepler> none of them do any work to "fix this"
[03:15:19] <seb_kuzminsky> oic
[03:15:33] <cradek> we see a couple a year asking for this
[03:15:56] <cradek> a more important problem is updates over dialup being painful (firmwares mostly)
[03:16:12] <seb_kuzminsky> right, the firmwares are huge
[03:16:25] <seb_kuzminsky> people have dialup still...?
[03:16:30] <cradek> sure
[03:16:40] <cradek> you split the firmwares already right?
[03:16:40] <seb_kuzminsky> i took all the hm2 firmwares out of the .deb in 2.3 already i think
[03:16:45] <seb_kuzminsky> they're recommended iirc
[03:16:45] <cradek> heh
[03:17:35] <seb_kuzminsky> emc2 Recommends emc2-firmware, which means if you do nothing you get the all the firmwares, but if you want to you can uninstall the firmware without breaking emc2.deb
[03:17:53] <cradek> that sounds perfect
[03:18:10] <jmkasunich> install after downloading? that doesn't help
[03:18:21] <jmkasunich> or do you unselect them before starting the download
[03:18:29] <cradek> install CD, remove firmware package you don't want, update easily forever
[03:18:32] <seb_kuzminsky> depends on the package manager, but it's easy
[03:18:59] <seb_kuzminsky> you mark emc2.deb for installation, and it automatically marks emc2-firmware.deb for installation. you override that and tell it not to install the firmware, and it wont download it
[03:19:28] <jmkasunich> seb: right cradek: I wasn't thinking of the CD
[03:19:30] <jmkasunich> * jmkasunich shuts up
[03:20:02] <seb_kuzminsky> i like this because clueless users get the most robust install, and advanced users who care can manually choose what parts to uninstall
[03:20:02] <jepler> don't work on the "problem" without knowing what it really is
[03:20:13] <cradek> the people who are offended by large (fully featured) packages are also offended by the OS choice
[03:20:14] <jepler> I think that what you did so far is great, like everyone else said already
[03:20:26] <seb_kuzminsky> ok i'll stop then ;-)
[03:20:33] <cradek> mostly they just complain because they would have done it differently
[03:20:56] <seb_kuzminsky> well that's what 'cvs checkout' is all about ;-)
[03:21:06] <cradek> the place we could benefit is somehow breaking out the kernel version specific stuff
[03:21:09] <cradek> I have no idea how that would work
[03:21:29] <cradek> but then maybe we could have several kernels out there somehow.
[03:21:37] <jepler> seb_kuzminsky: yes, it looks like the new configs would be a much better starting point for a user, assuming they all at least load
[03:21:38] <seb_kuzminsky> sounds messy
[03:21:46] <cradek> yes, sounds awful
[03:21:50] <jepler> thank you
[03:21:55] <seb_kuzminsky> jepler: the 7i43-small and 5i23 both load for stepper and servo
[03:21:58] <jepler> delete it from that page if you feel like it
[03:22:02] <seb_kuzminsky> havent tried the others
[03:22:03] <jepler> the wiki todo list, that is
[03:22:05] <seb_kuzminsky> sure
[03:22:28] <cradek> but, you can't make an smp kernel that also boots on a pentium 2. to support anything but the LCD we will eventually need more than one kernel
[03:23:00] <seb_kuzminsky> cradek: i see what you mean now
[03:23:13] <jmkasunich> someday (but probably after the deadline for my contest) I'm gonna want to bite the bullet and make a SMP kernel for the atom
[03:23:22] <seb_kuzminsky> the ubuntu kernel is pretty LCD, but we might want something different because we care more about performance
[03:23:43] <cradek> there's a real benefit to smp (if you can get it all built right so it actually works)
[03:23:47] <jmkasunich> seb_kuzminsky: its mostly SMP that we want - getting more and more common
[03:24:10] <cradek> jmkasunich: the old one I'm using doesn't work for you?
[03:24:45] <seb_kuzminsky> an smp kernel should work on up to, no?
[03:24:58] <jepler> seb_kuzminsky: rtai (used to?) have problems
[03:25:05] <cradek> depends on the machine
[03:25:29] <jepler> seb_kuzminsky: to some extent we're still mired in superstition about "don't configure rtai this way", and it doesn't change because we'd all rather do anything but build a kernel then try it on 100 systems
[03:25:30] <seb_kuzminsky> i'm gonna delete the "split packaging" todo-for-2.3 item too, any objections
[03:25:31] <cradek> last we tried, skunkworks and I both had machines that would not boot the smp kernel
[03:25:39] <jepler> seb_kuzminsky: go ahead, or move it to the "won't do" section
[03:26:30] <jepler> 'night guys
[03:26:36] <seb_kuzminsky> goodnight jeff
[03:28:46] <jmkasunich> cradek: I tried the smp kernel you built
[03:29:03] <jmkasunich> it boots and runs (never ran it more than a half-hour or so)
[03:29:10] <jmkasunich> didn't try the latency test
[03:29:30] <jmkasunich> the issue is that it has a buggy network driver for the NIC on this board
[03:29:49] <jmkasunich> I could certainly use it for off-net work
[03:30:00] <jmkasunich> or at least, I could test it for a while and see what happens
[03:30:16] <cradek> ah, no net would suck
[03:30:56] <seb_kuzminsky> anyone know if Fest is happening this year?
[03:31:03] <jmkasunich> dunno
[03:31:08] <jmkasunich> I have a bad feeling tho
[03:31:43] <seb_kuzminsky> :-(
[03:31:50] <cradek> seb_kuzminsky: no matter what, I hope the emc folks can get together somewhere. I'm certain we can.
[03:32:10] <seb_kuzminsky> i hope so
[03:32:20] <jmk-robot> we just need some space, power, and network
[03:32:26] <jmk-robot> machine tools would be nice too
[03:32:31] <cradek> an interesting project would be nice
[03:32:53] <seb_kuzminsky> i can probably arrange plenty of the first three here at the university
[03:34:01] <jmk-robot> colorado?
[03:34:25] <seb_kuzminsky> yes, center of the continent ;-)
[03:34:54] <jmk-robot> closest city? denver, boulder, ?
[03:35:12] <cradek> going west for once would be interesting
[03:35:35] <seb_kuzminsky> http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=boulder,co&sll=37.0625,-95.677068&sspn=57.945758,121.992188&ie=UTF8&ll=39.470125,-97.602539&spn=28.556674,60.996094&z=5&iwloc=addr
[03:36:07] <jmk-robot> hell, cradek/jepler could drive
[03:36:14] <cradek> yeah, easily
[03:36:19] <cradek> for all the rest of you, it sucks though
[03:36:45] <jmk-robot> giant carpool
[03:36:51] <seb_kuzminsky> where's all the rest?
[03:37:25] <jmk-robot> swp in vermont, jmk in cleveland, alex_joni in romania, skunkworks in wisconsin
[03:37:49] <jmk-robot> bigjohnT and jon elson in missouri
[03:37:59] <jmk-robot> stuart s in wicheta
[03:38:07] <cradek> dave E in california - he'd be happier
[03:38:39] <jmk-robot> I thought he was in Wa state
[03:38:42] <jmk-robot> same diff tho
[03:38:47] <cradek> oh? ok
[03:38:55] <cradek> yeah, same
[03:39:21] <jmk-robot> $239 from cle to denver, mid may, staying over a weekend
[03:39:31] <cradek> win
[03:39:48] <seb_kuzminsky> airline let you check a bp?
[03:40:03] <jmk-robot> heh
[03:40:19] <jmk-robot> in the past, I have traveled with a pickup truck full of stuff
[03:40:27] <jmk-robot> everything but a machine tool
[03:40:38] <seb_kuzminsky> cool
[03:41:02] <jmk-robot> I only use about 10% of what I bring
[03:41:07] <seb_kuzminsky> my little mill & lathe fit easily in my pickup
[03:41:23] <jmk-robot> heh, maybe bring the atom and a keyboard, beg a monitor
[03:42:05] <jmk-robot> how far from denver to where you are? hours?
[03:42:32] <seb_kuzminsky> it's about a 30 minute drive in good traffic
[03:42:45] <jmk-robot> oh
[03:42:52] <jmk-robot> boulder must be suburb of denver then
[03:42:55] <seb_kuzminsky> it's about 45-60 minutes to the airport
[03:43:11] <seb_kuzminsky> hehe sort of i guess no not really
[03:43:42] <cradek> iirc, there's some empty space in between
[03:45:56] <jmk-robot> I thought denver was a large city (larger than cleveland anyway)
[03:45:56] <seb_kuzminsky> cradek: yes, though it's rapidly filling up with houses
[03:45:56] <jmk-robot> it's 40 mins from me to the airport
[03:45:56] <seb_kuzminsky> denver is about 3 million i think - pretty big
[03:45:56] <jmk-robot> much bigger than cleveland
[03:45:56] <jmk-robot> city maybe 1/2 million, region maybe 1.5
[03:45:56] <seb_kuzminsky> denver city ~600K, area ~2.5M
[03:45:56] <jmk-robot> oh, ok
[03:46:10] <seb_kuzminsky> boulder's pretty different, much smaller, much more gentrified, plus a large (compared to year-around population) seasonal migration of students
[03:47:36] <jmk-robot> very much not cleveland ;-)
[03:48:59] <seb_kuzminsky> well, ttyl
[04:00:49] <jmk-robot> yay - webcam driver built and loaded, camera working with RT kernel, no latency issues
[04:01:15] <cradek> yay
[04:01:53] <jmk-robot> good stopping point I think
[08:20:58] <micges> good morning
[08:22:27] <micges> in documentation (trunk) there is no mention that if tool was changed (TnM6) there is possible to send G43 without H index to enable tool offset of current tool
[08:25:05] <micges> cradek: thanks for fixing probe protection messages, It is more user frendly now (as on my machine probe can be pressed of accident)
[08:26:48] <micges> sorry for not answering yesterday, machine was broken (again by me:))
[08:27:08] <micges> (I'm evil tester)
[11:51:04] <micges_mill> "M66 E0 L0 Q0" didn't work
[11:51:08] <micges_mill> won't load
[11:52:46] <micges_mill> It show message "zero timeout with wait type != immediate return"
[11:53:17] <micges_mill> (trunk)
[11:58:08] <micges_mill> M66 E0 L0 Q0 - this also genereate the same error message
[11:58:55] <micges_mill> sorry once again: "M66 E0 L0 Q0" and "M66 E0 L1 Q0" won't load with the error message "zero timeout with wait type != immediate return"
[12:01:44] <alex_joni> how about M66 E0 ?
[12:02:46] <alex_joni> L1Q0 should give an error message, that is correct
[12:02:58] <alex_joni> but L0Q0 should work
[12:11:36] <micges> M66 L0 give the same error
[12:12:00] <micges> I know that L1Q0 give correct error
[12:14:00] <micges> M66 E0 works
[12:14:41] <micges> in a moment I will know if M66 E0 works correctly on machine
[12:19:55] <Lerman_______> Lerman_______ is now known as Lerman
[12:20:31] <alex_joni> M66 L0 should give an error
[12:20:47] <alex_joni> M66 E0 should (theoretically) be the same as E0 L0 Q0
[12:20:58] <micges> will se
[12:21:04] <micges> see
[12:22:21] <micges> ok I see bug: m66 e1 l0 q2 is accepted but m66 e1 l0 q0 isn't
[13:11:02] <cradek> micges: I don't understand what you said earlier about G43 without H word. Is there something wrong? I use it all the time: "T1 M6 G43"
[13:11:15] <cradek> bbl
[13:14:04] <micges_mill> cradek: it all ok, only it is not documented
[13:14:47] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/debian/changelog: fix SF#2478266
[13:14:48] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/motion/ (control.c mot_priv.h motion.c): fix SF#2478266
[13:33:21] <micges_mill> ok weird, "m66 p3 l3 q0.1" doesn't work too
[14:07:14] <cradek> oh I understand now, thanks
[16:11:33] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/README: mention source scripts/emc-environment
[16:16:40] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/TODO: move some long-term things to 2.4
[16:16:41] <alex_joni> cradek: do we have current toolnumber saved as a variable on shutdown?
[16:16:49] <cradek> no
[16:16:59] <alex_joni> should we?
[16:17:04] <alex_joni> err.. shouldn't we?
[16:17:21] <alex_joni> I still got 2 days for this.. right? :D
[16:17:37] <cradek> eek
[16:17:43] <alex_joni> * alex_joni looks what it would take
[16:18:15] <SWPadnos> there ought to be a way of telling EMC that a specific tool is in the spindle
[16:18:31] <alex_joni> there isn't one currently
[16:18:38] <SWPadnos> then the operator could do it, an external program could do it
[16:18:39] <SWPadnos> right
[16:19:00] <SWPadnos> that's the core functionality I think. not necessarily making a var that holds it
[16:19:29] <cradek> I agree
[16:19:47] <cradek> M6.1 heh
[16:19:52] <SWPadnos> he
[16:19:54] <SWPadnos> h
[16:19:56] <cradek> "pretend to load the tool"
[16:19:58] <SWPadnos> yeah, then JDI could do it
[16:20:08] <SWPadnos> "set current tool number"
[16:20:36] <alex_joni> ok, that sounds like a smaller job
[16:21:02] <SWPadnos> actually, it should be M0.6, since it's less than M6 :)
[16:21:25] <cradek> how would prep work though...
[16:21:43] <cradek> M0.6 is easy but how to get the tool number?
[16:21:53] <alex_joni> M6.1Pxx ?
[16:22:01] <SWPadnos> or is it Q for an int?
[16:22:19] <SWPadnos> (I thought one was int, the other float)
[16:22:34] <alex_joni> anyways..
[16:22:45] <alex_joni> it's not quite M6.1 Txx
[16:22:48] <alex_joni> that's harder to do
[16:22:53] <SWPadnos> yeah, some other word on the M0.6/5.99/6.1 line
[16:22:54] <cradek> there are no M6.x available currently
[16:23:01] <cradek> Mx.x
[16:23:08] <alex_joni> M61 then ?
[16:23:11] <SWPadnos> oh. that's a bummer
[16:23:15] <alex_joni> err.. that's probably use
[16:23:16] <alex_joni> d
[16:23:18] <SWPadnos> no 61 is IO isn't it?
[16:23:27] <SWPadnos> M7
[16:23:28] <cradek> 61 is available
[16:23:35] <alex_joni> 62..66 are used
[16:23:40] <cradek> M7 is not
[16:23:58] <SWPadnos> ok, 61 seems OK (if a little weird)
[16:30:41] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/docs/INSTALL: mention checkinstall and build documentation option for configure
[16:32:12] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/docs/NEWS: mention debian/changelog for recent news
[16:38:05] <alex_joni> micges_mill: around?
[16:38:17] <alex_joni> can you try a fix for the M66 bug you reported?
[16:39:08] <alex_joni> interp_convert: line 2438 : there is a check for (round_to_int(block->l_number) >= 0) that needs to be > 0
[16:40:19] <micges> I'll try
[16:44:35] <alex_joni> thx
[17:10:06] <alex_joni> Need positive Q-word to specify toolnumber with M61
[17:10:13] <alex_joni> how does that sound as a wording?
[17:10:45] <SWPadnos> ok, but I'd sesparate "tool" and "number"
[17:10:50] <SWPadnos> separate
[17:37:52] <alex_joni> whee.. seems to work just right
[17:37:56] <alex_joni> who wants to break it?
[17:41:05] <alex_joni> is it ok if I don't allow M61 Qx in AUTO?
[17:42:19] <alex_joni> I don't see any reason to call it from a program.. (now that Gxx.1 exist - like G43.1)
[17:42:54] <alex_joni> or G43 Hxx
[17:55:40] <jepler> what's M61?
[17:56:10] <alex_joni> allows to set the currently loaded toolnumber
[17:56:19] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/iotask/ioControl.cc:
[17:56:19] <CIA-2> EMC: add M61 Qxx
[17:56:19] <CIA-2> EMC: * allows changing the current tool number (the Q-word defines the loaded tool number from now on)
[17:56:19] <CIA-2> EMC: * for now it's not allowed to call M61 from a program, only from MDI (or while in manual mode)
[17:56:20] <CIA-2> EMC: * the canon call is CHANGE_TOOL_NUMBER()
[17:56:20] <alex_joni> (for example after a machine restart)
[17:56:22] <CIA-2> EMC: * the new NML command is EMC_TOOL_SET_NUMBER
[17:56:26] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (canon.hh emc.cc emc.hh emc_nml.hh):
[17:56:28] <CIA-2> EMC: add M61 Qxx
[17:56:30] <CIA-2> EMC: * allows changing the current tool number (the Q-word defines the loaded tool number from now on)
[17:56:32] <CIA-2> EMC: * for now it's not allowed to call M61 from a program, only from MDI (or while in manual mode)
[17:56:34] <CIA-2> EMC: * the canon call is CHANGE_TOOL_NUMBER()
[17:56:36] <CIA-2> EMC: * the new NML command is EMC_TOOL_SET_NUMBER
[17:56:41] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/sai/saicanon.cc:
[17:56:42] <CIA-2> EMC: add M61 Qxx
[17:56:44] <CIA-2> EMC: * allows changing the current tool number (the Q-word defines the loaded tool number from now on)
[17:56:45] <jepler> so it won't help if I look in the docs for it
[17:56:46] <CIA-2> EMC: * for now it's not allowed to call M61 from a program, only from MDI (or while in manual mode)
[17:56:48] <CIA-2> EMC: * the canon call is CHANGE_TOOL_NUMBER()
[17:56:52] <CIA-2> EMC: * the new NML command is EMC_TOOL_SET_NUMBER
[17:56:52] <jepler> beat's me, I don't care, I don't need it
[17:56:56] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/rs274ngc/ (4 files):
[17:56:58] <CIA-2> EMC: add M61 Qxx
[17:57:00] <CIA-2> EMC: * allows changing the current tool number (the Q-word defines the loaded tool number from now on)
[17:57:02] <CIA-2> EMC: * for now it's not allowed to call M61 from a program, only from MDI (or while in manual mode)
[17:57:04] <CIA-2> EMC: * the canon call is CHANGE_TOOL_NUMBER()
[17:57:06] <CIA-2> EMC: * the new NML command is EMC_TOOL_SET_NUMBER
[17:57:08] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/task/ (emccanon.cc emctaskmain.cc iotaskintf.cc):
[17:57:10] <CIA-2> EMC: add M61 Qxx
[17:57:12] <CIA-2> EMC: * allows changing the current tool number (the Q-word defines the loaded tool number from now on)
[17:57:14] <CIA-2> EMC: * for now it's not allowed to call M61 from a program, only from MDI (or while in manual mode)
[17:57:16] <CIA-2> EMC: * the canon call is CHANGE_TOOL_NUMBER()
[17:57:22] <CIA-2> EMC: * the new NML command is EMC_TOOL_SET_NUMBER
[17:59:25] <alex_joni> jepler: it will help, once it's added :)
[18:05:19] <cradek> http://www.linuxcnc.org/docs/devel/html/parport-block-diag.png
[18:05:31] <cradek> this image is wrong: the pin names are pin-%02d-out
[18:31:02] <BigJohnT> m61 is a new one alex_joni ?
[18:32:57] <alex_joni> BigJohnT: yeah
[18:33:00] <alex_joni> M61 Qxx
[18:33:06] <BigJohnT> ok
[18:33:07] <alex_joni> (I'd add it myself, but am on hardy now)
[18:33:13] <alex_joni> Qxx -> xx is the tool number
[18:33:17] <alex_joni> must be 0 or greater
[18:33:27] <alex_joni> it's not allowed from a program atm
[18:34:02] <BigJohnT> ok, what would one use it for?
[18:37:40] <SWPadnos> setting the tool in the spindle on startup, without doing a toolchange
[18:38:01] <skunkworks_> say a machine gets powered up with a certain tool in the spindle. You can tell emc that tool xx is in the spindle. (had an issue with the mazak because emc could not do that at the time)
[18:38:23] <BigJohnT> ok, thanks
[18:38:29] <SWPadnos> yep, it always defaulted to 0
[18:38:34] <SWPadnos> which was a PITA
[18:39:45] <BigJohnT> M61 Set Current Tool Number
[18:39:53] <BigJohnT> does that sound correct?
[18:40:03] <alex_joni> yup
[18:55:41] <cradek> BigJohnT: would you also check on the g43 documentation. if you do not specify an H number, it uses the currently-loaded tool.
[18:56:20] <alex_joni> so M61 could have been hijacked before H was implemented..
[18:56:25] <alex_joni> luckily we don't need it :)
[19:09:57] <cradek> MIN_FERROR = 10000.0
[19:10:04] <cradek> ^ from "fast jogs don't stop" guy
[19:10:31] <cradek> BASE_PERIOD = 100000
[19:10:43] <cradek> his stepgens are falling behind and he covered up the error
[19:13:25] <micges> alex_joni: thank you for M61 ! it was problem That I discovered today and even didn't tell you and you fixed it :D
[19:14:00] <micges> (problem that after start tool_loaded == 0)
[19:14:23] <alex_joni> cradek: heh
[19:16:17] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/debian/changelog: mention M61
[19:57:59] <micges> if pid.c params was changed to pins can it be done with axis.n.xxxx parameters?
[19:58:18] <alex_joni> micges: yup
[19:58:36] <alex_joni> but unlikely in the next 25-30h
[19:58:52] <micges> ?
[19:59:06] <alex_joni> check the topic
[19:59:37] <alex_joni> " 2.3 schedule: February 1: no new features on trunk, only stabilization. "
[20:00:01] <micges> I can send patch
[20:00:19] <micges> its 29.01
[20:00:41] <micges> bbl
[20:00:54] <jepler> in a chicken basket!
[20:00:59] <jepler> if you have a feature implemented, the thing to do is not sit on it
[20:01:27] <jepler> put a patch on sf, send e-mail to the list, or otherwise show us
[20:15:11] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: add m61
[20:16:41] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/Integrator_Concepts.lyx: minor edit
[20:24:18] <micges> alex_joni: M61 didn/t have upper limit of Q
[20:24:40] <micges> alex_joni: good night
[22:36:38] <micges> alex_joni: yours change fixed accepting m66 e1 l0 q0
[22:44:51] <micges> in M66 what type of data is Qn ?
[22:45:56] <micges> it seems to be integer but it should be float (to specify 0.1 sec timout)
[22:59:18] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/hal/user_comps/gs2_vfd.c: getopt_long returns int. with unsigned chars this didn't work.
[23:12:53] <micges> There is no info about that Q word in M66 gcode must be integer(seconds) here:
[23:12:53] <micges> http://www.linuxcnc.org/docs/devel/html/gcode_main.html#sec:M66:
[23:14:06] <micges> ok enough complaining
[23:14:14] <micges> good night all
