#emc | Logs for 2006-04-18

Back
[00:02:05] <cradek> ah "update -dP" not "up -dP"
[00:13:45] <SWPadnos> so up isn't really a synonym for update?
[00:17:49] <cradek> not in .cvsrc I guess
[00:24:52] <SkunkWorks_> Hello?
[00:25:41] <SkunkWorks_> cradek: you around?
[00:26:57] <SkunkWorks_> got this error after updating ubuntu
[00:26:59] <SkunkWorks_> Starting emc...
[00:26:59] <SkunkWorks_> HAL: ERROR: thread 'servo-thread' not found
[00:26:59] <SkunkWorks_> HAL config file /home/ace/emc2/configs/stepper//../common/core_stepper.hal failed.
[00:26:59] <SkunkWorks_> Shutting down and cleaning up EMC...
[00:27:30] <SkunkWorks_> so I coppied the core_stepper.hal to my common dir and got this error
[00:27:48] <SkunkWorks_> Starting emc...
[00:27:48] <SkunkWorks_> insmod: error inserting '/usr/realtime-2.6.12-magma/modules/emc2/motmod.ko': -1 Operation not permitted
[00:27:48] <SkunkWorks_> HAL:5: ERROR: insmod failed, returned 1
[00:27:48] <SkunkWorks_> HAL config file /home/ace/emc2/configs/stepper//../common/core_stepper.hal failed.
[00:27:48] <SkunkWorks_> Shutting down and cleaning up EMC...
[00:28:30] <SkunkWorks_> probably something stupid I did :)
[00:29:04] <SkunkWorks_> I will be around later - thanks.
[00:34:11] <jmkasunich> need a dmesg listing to know what is going on
[00:34:29] <cradek> I bet he didn't update his custom config according to the release notes
[00:34:39] <fenn> probably the same problem i had - base period in seconds
[00:34:42] <jmkasunich> probalby
[00:34:54] <jmkasunich> I hate changes like that
[00:34:55] <fenn> why was that changed again?
[00:35:44] <jmkasunich> so it could be loaded and saved using the normal HAL utilities, instead of treating motmod special (and being forced to load it with code in the main emc script)
[00:36:23] <fenn> oh because hal still has no multiply/divide :)
[00:36:30] <fenn> * fenn lols
[00:36:30] <cradek> we didn't like it, but we figured the time to undo bad decisions was before the main release
[00:37:19] <jmkasunich> fenn: I've thought about math ops in hal, but I don't want to re-invent bash or some other scripting language
[00:37:37] <fenn> have you thought about using some scripting language in hal?
[00:37:55] <cradek> SIOD
[00:37:55] <fenn> like emcsh is just wish with some extra commands
[00:38:07] <jmkasunich> SIOD?
[00:38:13] <fenn> oh yuck scheme
[00:38:30] <cradek> you say yuck to scheme but not tcl? that's not right
[00:38:47] <fenn> hmm given a choice i'd say just shoot me
[00:38:54] <fenn> between tcl and scheme
[00:38:58] <cradek> haha
[00:39:06] <fenn> at least tcl uses words, scheme is all parentheses
[00:39:17] <jmkasunich> for us, tcl has only one advantage over scheme:
[00:39:40] <jmkasunich> unless we rewrite a lot of stuff, we already require tcl, we don't currently require scheme
[00:40:08] <cradek> siod is one source file that would be compiled into halcmd, it's just C
[00:40:22] <cradek> but I'm only half serious, so forget it
[00:40:27] <jmkasunich> but what _is_ SIOD?
[00:40:31] <jmkasunich> never. mind, /me googles
[00:40:52] <jmkasunich> oh
[00:41:48] <cradek> Scheme In One Defun (or Scheme In One Day) is a small-footprint implementation of the Scheme programming language, written in C and designed to be embedded inside C programs. </wikipedia>
[00:41:52] <jmkasunich> yeah
[00:42:14] <cradek> GIMP uses SIOD as its primary extension language, Script-Fu.
[00:42:16] <cradek> I did not know this
[00:42:20] <cradek> never programmed gimp
[00:42:37] <jmkasunich> bet few people do
[00:43:38] <jmkasunich> I have absolutely no desire to teach people scheme so they can configure their machines
[00:43:52] <jmkasunich> (nor do I have any desire to teach myself scheme so I can .....)
[00:44:05] <cradek> it's probably no worse than teaching halcmd
[00:44:09] <cradek> but like I said, never mind
[00:44:39] <jmkasunich> not to drag out the argument, but I have to disagree with that statement...
[00:44:48] <cradek> haha
[00:44:52] <jmkasunich> halcmd + scheme has to be more complex than just halcmd
[00:45:12] <cradek> I'm assuming here that you add scripting capabilities to halcmd, like fenn said when this conversation started
[00:45:34] <cradek> I just think that before writing a new scripting language, one is smart to look around and find something that does the job already
[00:45:39] <jmkasunich> or, if you look at it the other way, scheme extended to manipulate the HAL has to be more complex than scheme alone, and presumes you understand the concepts of HAL
[00:46:11] <jmkasunich> I agree that we don't want to reinvent the wheel
[00:46:13] <cradek> let's just not put a scripting language in halcmd I guess
[00:46:18] <jmkasunich> yes
[00:46:20] <cradek> hello Guest715
[00:46:31] <jmkasunich> and if we do, use something well known like bash
[00:47:41] <Guest715> Guest715 = Wholepair - to lazy to type in name right now - just seein who is around
[00:48:03] <fenn> yay bash
[00:50:39] <skunkworksorg> logger_aj: bookmark
[00:50:39] <skunkworksorg> See http://81.196.65.201/irc/irc.freenode.net:6667/emc/2006-04-18#T00-50-39
[01:01:39] <skunkworksorg> where are the release notes located? :)
[01:02:03] <cradek> they are shown in the update manager before the update, but afterward they are in /usr/share/doc/emc2
[01:02:17] <cradek> you can find release notes for every deb package there
[01:02:35] <cradek> err I guess it's called changelog, not release notes
[01:03:19] <skunkworksorg> are they in the csv? somewhere? am I getting annoying yet?
[01:04:08] <cradek> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/debian/changelog?rev=1.5.2.1
[01:05:14] <skunkworksorg> thanks. I was snooping but could not find it.
[01:05:37] <cradek> it's probably hard to find if you don't know where to look
[01:05:43] <cradek> since it's on the release branch
[01:05:56] <skunkworksorg> I figured it would be in the emc2 root.
[01:06:18] <cradek> this location debian/changelog is mandated by the debian build system
[01:06:58] <skunkworksorg> ok - thanks again. bbl
[01:07:06] <cradek> welcome
[01:07:12] <fenn> cradek what sort of anti-backlash nuts do you use? do they have a spring and a tapered collar?
[01:07:42] <fenn> i'm trying to decide what spring to buy
[01:07:56] <jmkasunich> acme screws?
[01:08:08] <fenn> yeah 1/2-10
[01:08:19] <jmkasunich> what kind of load do you anticipate?
[01:08:25] <fenn> nfc
[01:08:44] <fenn> let's say light aluminum milling for now
[01:09:08] <cradek> fenn: I got the from some web site ... they are tapered with a spring
[01:09:22] <cradek> they are for 1/4-16 acme though, very small compared to what you want
[01:09:28] <jmkasunich> I've always liked bellville washers (for heavy loads) or wave washers (for lighter)
[01:09:47] <fenn> hm i never even considered that
[01:10:02] <jmkasunich> but since I haven't actually built anything, my opinion should be taken with a grain of salt
[01:10:58] <fenn> wave washers would be a lot more compact and probably cheaper
[01:11:26] <cradek> you mean put these between two leadnuts and anchor just one of them?
[01:11:39] <jmkasunich> yeah
[01:11:54] <cradek> how do you keep the unanchored one from turning (loosening)?
[01:11:58] <jmkasunich> you have to "anchor" the second one so it can't rotate, or it will unscrew
[01:12:06] <cradek> yeah that
[01:12:12] <fenn> i was thinking a split nut with collar and spring, you screw the nut into its carrier to adjust the preload
[01:12:35] <cradek> picture number 4 on http://timeguy.com/cradek/cnc is a similar scheme
[01:12:42] <jmkasunich> split lengthwise, so it tightens like a one slot collet?
[01:12:51] <fenn> jmkasunich: right
[01:12:59] <fenn> or maybe multiple slits
[01:13:40] <fenn> cradek: what do you estimate was the spring rate (in pounds per inch) of that spring :)
[01:13:42] <cradek> I think you really want spring-loaded, not adjustable, because of leadscrew variation/wear
[01:13:43] <jmkasunich> there are limitations to that approach
[01:13:58] <jmkasunich> right, I was just gonna mention screw variations
[01:14:04] <cradek> fenn: "enough to move the table, then some more"
[01:14:04] <fenn> cradek it's adjustable and spring loaded at the same time
[01:14:26] <jmkasunich> something like in cradek's pic is adjustable in increments of a half turn
[01:14:34] <cradek> right
[01:14:44] <cradek> and if you move the table too far, it shoots at you
[01:14:48] <jmkasunich> heh
[01:14:59] <cradek> then you have to figure out which damn half turn it was set at
[01:15:12] <jmkasunich> I have a commercial dual-nut ballscrew for my Z
[01:15:20] <jmkasunich> there is a heavy wave washer between the two nuts
[01:15:35] <jmkasunich> one nut has cross slot in the top
[01:15:37] <cradek> you can sort of see my new nuts here http://timeguy.com/cradek-files/emc/lathe-setup.jpg
[01:16:16] <jmkasunich> then there is a piece that goes around the washer, it has a tongue that goes in the slot on nut A, and is setscrewed into nut B
[01:16:35] <jmkasunich> so it holds the relative rotational position of B vs A, and thus the preload
[01:16:53] <cradek> so you can adjust it in 1/6th turns or so?
[01:16:58] <cradek> or is the nut round?
[01:17:03] <jmkasunich> round
[01:17:06] <cradek> cool
[01:17:09] <cradek> sounds easy to make too
[01:17:18] <jmkasunich> actually, I described it wrong
[01:17:22] <jmkasunich> each nut is the same
[01:17:40] <jmkasunich> round, with a threaded section on one end, maybe 1" x 16TPI
[01:17:55] <jmkasunich> the ballscrew is 5/8-5TPI
[01:18:10] <jmkasunich> one nut screws into a threaded hole in the table or whatever
[01:18:22] <jmkasunich> the other nut screws into the piece with the tab
[01:18:36] <jmkasunich> the slot is on the opposite end of the nut from the threaded section
[01:19:02] <jmkasunich> so nut A threads rigidly into the table (or whatever)
[01:19:31] <jmkasunich> intermediate piece with tab floats in the slot on nut A, it can move in/out, but not rotate
[01:19:42] <jmkasunich> nut B threads into the intermiedate piece, screw it in and out to adjust preload
[01:19:51] <jmkasunich> then theres a small setscrew that locks it
[01:20:41] <cradek> I think I get it
[01:20:43] <jmkasunich> the wave washer is between A and B (hidden inside the intermediate piece, its OD is smaller than the threaded section
[01:21:29] <jmkasunich> a pic is better than a thousand words, but I can type a couple hundred (maybe even a thousand) in less time than it takes to snap a pic and upload it
[01:22:09] <fenn> whew
[01:22:14] <fenn> ok while you were typing i drew a pic
[01:22:28] <fenn> http://fenn.dyndns.org/pub/irc/anti-backlash-nut.png
[01:23:02] <cradek> that's approximately how mine work
[01:23:06] <fenn> the carrier screws into one of my telescoping tubes
[01:23:39] <fenn> guess i should add a setscrew or something
[01:23:53] <jmkasunich> so the collar squeezes the right hand end of the nut?
[01:24:00] <cradek> yes
[01:24:31] <cradek> I think the threads are cut a little deep, so the squeeze is on the taper, not the root of the thread
[01:24:34] <jmkasunich> meaning that as soon as you have a little nut wear, only the right end is gonna be snug, and the wear at that end will accelerate
[01:24:50] <jmkasunich> must be, squeeze at the root is useless
[01:25:24] <cradek> I can't find the website anymore.
[01:25:31] <fenn> dumpster cnc i thnkk
[01:25:54] <fenn> http://www.aanrip.nl/cnc.htm <- that too
[01:26:03] <cradek> yep you found it
[01:27:48] <cradek> looks like he mills pcbs too
[01:28:40] <jmkasunich> you guys are referring to the "YABS" thingy?
[01:29:25] <cradek> jmkasunich: I don't know what YABS is
[01:29:39] <jmkasunich> on the annrip.nl page
[01:29:49] <jmkasunich> Yet Another Backlash Solution
[01:29:51] <fenn> yabs is a design i am considering
[01:30:03] <jmkasunich> bout 3/4 down the page
[01:30:15] <cradek> o rings??
[01:30:21] <fenn> someone pointed out that the o-rings might develop a "set" and not clamp anymore
[01:30:31] <fenn> but its definitely simpler
[01:30:42] <cradek> looks a bit crappy to me
[01:30:57] <fenn> by crappy do you mean "genius"?
[01:31:20] <cradek> it's smart, but I think the springiness would not be at all consistent over time
[01:31:44] <jmkasunich> it all depends on how much load is needed
[01:31:59] <fenn> i'm not sure really how to calculate that
[01:32:09] <jmkasunich> obviously its not a high load machine, otherwise he wouldn't be using plastic for the nuts in the first place
[01:33:16] <jmkasunich> for light loads it might be a very good (and simple) approach
[01:46:47] <cradek> argh
[01:46:56] <cradek> an email from someone saying "can I make a link to your web site"
[01:47:17] <jmkasunich> ?
[01:47:17] <cradek> when I reply saying of course you can, that's what the web is for, his mailbox is "full"
[01:47:38] <cradek> I hate when people ask that
[01:47:50] <cradek> the whole POINT of the web is it's hypertext
[01:47:50] <jmkasunich> are you sure its legit
[01:47:55] <cradek> yes
[01:48:16] <cradek> it's a guy who I linked to long ago
[01:48:19] <jmkasunich> ok
[01:50:06] <cradek> "I think the important thing to remember here is that we haven't been attacked again at home since September of 2001," McConnell said.
[01:50:14] <cradek> arrrgh we're surrounded by fuzzy thinkers
[01:51:05] <cradek> rant rant rant
[01:51:05] <jmkasunich> warning,warning, warning! politics on #emc
[01:51:12] <cradek> sorry, I'm better now
[01:52:03] <cradek> so what should we do about emc?
[01:52:14] <cradek> there are a couple fixes in the release branch
[01:52:46] <jmkasunich> I'm working on farm output to the commit list and then to CIA
[01:52:56] <jmkasunich> hope to finish that off and get on with life
[01:53:33] <cradek> I found a bug while using my recently-reenabled rotary axis, and fixed it
[01:53:47] <jmkasunich> saw that
[01:54:00] <jmkasunich> I want to get back to the canonical encoder thing
[01:54:18] <cradek> and I'm anxious to work on threading some more
[01:54:29] <cradek> if all goes well, I should have a nice setup for work during fest
[01:54:40] <jmkasunich> the sherline lathe?
[01:54:42] <cradek> yes
[01:55:05] <jmkasunich> you still don't know the ppr of that encoder do you?
[01:55:14] <cradek> your encoder changes will probably influence the threading code
[01:55:22] <jmkasunich> I have a hunch its higher than you can count in software
[01:55:23] <cradek> nope, but I have a scheme in mind if I have to divide by 4 or 16
[01:55:28] <jmkasunich> ok
[01:55:39] <jmkasunich> I don't think the encoder changes will affect threading
[01:55:42] <cradek> hopefully it's a multiple of 4 and/or 16
[01:55:52] <cradek> ok
[01:55:58] <jmkasunich> they're gonna affect homing instead
[01:56:15] <jmkasunich> scheme in mind = hardware?
[01:56:21] <cradek> yeah
[01:56:36] <fenn> flipflop
[01:56:43] <cradek> not at all complex, a couple logic chips
[01:56:51] <jmkasunich> good
[01:56:52] <cradek> binary up/down counter actually
[01:57:10] <fenn> * fenn panics, and attempts to flee!
[01:57:37] <jmkasunich> I suppose knowing the pinout and supply voltage for the encoder would be usefull too
[01:57:45] <cradek> true
[01:57:58] <cradek> where did you get that thing? It's a monster
[01:58:14] <jmkasunich> three guesses, and the first two don't count
[01:58:26] <jmkasunich> by industrial standards its not that big
[01:58:43] <cradek> ok I know your secret
[01:58:51] <cradek> have any more?
[01:59:08] <jmkasunich> I had two, in fact I just looked in the encoder box expecting to see the other one
[01:59:10] <jmkasunich> not there
[01:59:16] <cradek> uh-oh
[01:59:22] <fenn> * fenn whistles innocently
[01:59:27] <cradek> hey
[01:59:33] <jmkasunich> these are industrial encoders: http://www.avtron.com/tachs.htm
[01:59:44] <jmkasunich> most are about 6" dia
[01:59:46] <fenn> sure they're not tachs? :)
[02:00:10] <jmkasunich> I'm sure (Avtron was my first full-time employer)
[02:00:58] <jmkasunich> http://www.avtron.com/hollow_vs_modular.htm
[02:01:04] <fenn> mouse wheels are looking better and better every day
[02:01:14] <jmkasunich> the one you have is a hollow shaft
[02:02:10] <jmkasunich> fenn: why you say that?
[02:02:41] <fenn> plenty of resolution, cheap and plentiful, less fiddling around with hardware
[02:02:57] <jmkasunich> huh?
[02:03:27] <jmkasunich> sticking mouse guts onto the ass end of a motor sounds like lots of "fiddling around with hardware" to me
[02:03:42] <fenn> oh, by hardware i meant electronic hardware
[02:04:07] <jmkasunich> at moderate resolution, the only hardware needed is a parport
[02:04:07] <SWPadnos> mouse wheels have crap for resolution
[02:04:34] <SWPadnos> they get by by using a roller that's 20x the diameter, so you get more revs on the encoder wheel
[02:04:43] <fenn> yes i know
[02:04:48] <SWPadnos> (20x the diameter of the encoder spindle)
[02:05:01] <SWPadnos> they're actually about 32ppr, roughly
[02:05:14] <jmkasunich> that sounds about right from the mouse wheels I've seen
[02:05:33] <fenn> some mouse wheels are 64 lines per rev
[02:05:50] <fenn> but even with 32 thats .0006 on a 10 tpi screw
[02:05:51] <jmkasunich> still pretty low
[02:06:01] <fenn> er .0008
[02:06:18] <SWPadnos> 32 or 64 will be after the quadrature multiplication, I think
[02:06:20] <jmkasunich> 32*4*10 = 1280 counts/inch
[02:06:29] <SWPadnos> so just 32*10
[02:06:30] <fenn> well the mouse i took apart had 32 slots
[02:06:39] <jmkasunich> SWP: that would be only 8 or 16 slots, I know they're finer than that
[02:06:39] <SWPadnos> that could work then
[02:07:03] <SWPadnos> 8 is small, 16 is about right for some older ones (the only encoder mice I still have ;) )
[02:07:33] <jmkasunich> I probably have a dozen encoder mice, trashpicked for just that reason
[02:07:40] <jmkasunich> but I doubt I'll actually use them
[02:08:13] <jmkasunich> maybe I'll bring them to cnc workshop and toss em on the swap table "Cheap Encoders for sale cheap!"
[02:08:35] <jmkasunich> I wish I could get good data for the stegmann encoders I have
[02:08:57] <fenn> why? what parameters are there besides number of lines?
[02:09:25] <jmkasunich> I _think_ they are 1000 cycles/rev, sin/cos outputs, with a serial channel that can give you absolute position at power up
[02:09:27] <SWPadnos> max pulse rate, for one
[02:09:49] <jmkasunich> supply voltage, pinout, output signal levels, pullup needed (or not)....
[02:09:53] <fenn> oh so this is more than just a disk and phototransistor
[02:09:58] <jmkasunich> lots of info besides just slots
[02:10:19] <SWPadnos> it's basically a disk and phototransistors, but trasnistors have different charicteristics
[02:10:26] <SWPadnos> transistors, too
[02:10:58] <fenn> ok i'm trying to get my msc order in before i pass out
[02:11:52] <SWPadnos> don't worry about it - it won't ship until tomorrow anyway (I think)
[02:12:45] <fenn> only at msc do the "utility" springs cost as much as the "precision" springs
[02:12:56] <SWPadnos> they're so useful ...
[02:13:04] <Jymmmm> MSC bought Enco
[02:13:58] <fenn> whats next, harbor freight?
[02:14:22] <jmkasunich> fsckers
[02:14:28] <Jymmmm> Eh, MSC's cheapo line I guess
[02:14:46] <jmkasunich> It really pisses me off when a company insists that I register just to look at their product datasheets
[02:15:00] <SWPadnos> I usually move along at that point
[02:15:11] <Jymmmm> registering to see pricing is okey
[02:15:18] <SWPadnos> I hate that as well
[02:15:23] <jmkasunich> well in this case, I trashpicked the encoders, and I want the datasheet
[02:15:35] <jmkasunich> so [email protected] is going to register
[02:15:38] <Jymmmm> jmkasunich nobody/password
[02:15:52] <Jymmmm> jmkasunich [email protected]
[02:17:21] <jmkasunich> these are definitely strange encoers
[02:17:23] <jmkasunich> encoders even
[02:17:31] <SWPadnos> how many pins?
[02:17:32] <jmkasunich> they have sin, cos, and rs-485 connections
[02:17:50] <SWPadnos> sounds more like resolvers
[02:18:08] <jmkasunich> no, the sin and cos aren't excitation signals
[02:18:17] <jmkasunich> 512 cycles per rev analog quadrature
[02:18:34] <jmkasunich> can convert to 2048 count digital quadrature with a couple comparators
[02:18:51] <SWPadnos> ah, OK
[02:19:06] <jmkasunich> but they are intended to be used with adcs to get resolution at low speed of a 50Kcounts or more per rev
[02:19:36] <jmkasunich> 15 bit absolute position by serial link at power up
[02:19:43] <jmkasunich> then count the sin/cos
[02:19:43] <SWPadnos> cool
[02:20:00] <jmkasunich> but so far I'll I've found is generalities
[02:20:01] <SWPadnos> absolute within one revolution, I assume (no rev counter or anything)
[02:20:11] <jmkasunich> pinouts and such are missing
[02:20:13] <jmkasunich> yeah
[02:20:52] <jmkasunich> heh, they also make multi-turn versions (but I don;t think these are)
[02:21:00] <fenn> mmm 4 arcsecond resolution huh
[02:22:04] <SWPadnos> more like 2.3 arc-minutes, I think
[02:22:27] <jmkasunich> actually, they claim resolutuon up to 4 million counts/rev, or 5 arc-seconds
[02:22:36] <SWPadnos> that's high res
[02:22:54] <jmkasunich> thats some pretty hefty interpolation, even with 512 counts/rev basic cycle
[02:23:56] <jmkasunich> interpolating one sin/cos 360 degree cycle into 8000 steps
[02:24:01] <SWPadnos> I imagine you'd need a nice 16-bit (or more) A/D, and differential across the two outputs in addition to the two outputs separately
[02:24:32] <jmkasunich> don't know about that
[02:24:51] <jmkasunich> measure sin and cos, do atn2(sin, cos)
[02:25:23] <SWPadnos> round-off can be a bitch for atan though
[02:25:51] <jmkasunich> 360 degrees / 8000 counts = 22 counts per degree, or several minutes of (electrical) angle per count
[02:26:04] <jmkasunich> I bet 12 bit ADCs would be close
[02:26:52] <jmkasunich> anyway, the 4 million counts is marketing fluff, as product designer you get to pick the amount of interpolation you want
[02:27:29] <jmkasunich> even dividing each 90 electrical degrees into 10 steps would give you 40960 counts per rev, which is damn high by our standards
[02:27:39] <SWPadnos> yes indeed
[02:27:45] <jmkasunich> and dividing by 10 would be trivial even with 8 bit ADCs
[02:28:13] <SWPadnos> not really, because around the 90 deg mark (for sin), the slope is near zero
[02:28:27] <jmkasunich> but cos is changing rapidly then
[02:28:36] <SWPadnos> though you maybe able to use the more accurate cos in that region
[02:29:31] <jmkasunich> any decent atn2() algorithm breaks things into quadrants, then uses the most accurate form for the quadrant you are in
[02:30:07] <SWPadnos> I'm thinking of microcontrollers, so I never know if there *is* an atn2 function ;)
[02:30:34] <jmkasunich> well, no, but you'd write one suited to the amount of interpolation you need
[02:30:41] <SWPadnos> yep
[02:31:41] <jmkasunich> biggest problem if you had any speed would be sampling both sin and cos at the same time
[02:32:07] <SWPadnos> there are actually interesting FPGAs that have analog sections now
[02:32:32] <SWPadnos> including A/D with 32-channel mux (I'm not sure how many sample/holds there are)
[02:32:43] <skunkworks> are you talking about resolvers?
[02:32:58] <SWPadnos> no, but the conversation is applicable
[02:34:06] <skunkworks> I found a resolver to encoder chip that digikey still sells.
[02:34:24] <jmkasunich> I have a bunch of encoders too....
[02:34:26] <jmkasunich> ;-)
[02:35:23] <fenn> does emc handle linear slides correctly at all?
[02:35:32] <skunkworks> http://www.analog.com/UploadedFiles/Data_Sheets/460727771AD2S1200_0.pdf
[02:35:35] <jmkasunich> what do you mean?
[02:35:40] <fenn> er, linear encoders
[02:35:50] <jmkasunich> they're just encoders
[02:35:52] <Jymmmm> * Jymmmm has a super duper decoder ring, does that count? (get it... decoder, count... eh nm)
[02:36:06] <skunkworks> (it was a thought for our "accupins" on our K&T
[02:36:08] <skunkworks> )
[02:36:13] <SWPadnos> no Jymmmm, it doesn't count
[02:36:13] <fenn> say you have a tach on the motor and linear scales
[02:36:23] <fenn> does emc know not to oscillate wildly?
[02:36:31] <Jymmmm> aw shucks!
[02:36:48] <jmkasunich> oh, you mean linear encoders driven by motors with backlash in the drivetrain?
[02:36:55] <fenn> yes
[02:37:01] <SWPadnos> bang bang bang bang bang bang
[02:37:01] <jmkasunich> emc itself doesn't know anything about that
[02:37:02] <skunkworks> there should be no backlash
[02:37:14] <jmkasunich> you could try to address it in hal
[02:37:37] <jmkasunich> its control theory stuff, hal is good for building things like that
[02:37:45] <fenn> does all the leadscrew mapping stuff still work?
[02:37:46] <skunkworks> rayh said something about separating the pid from somthing to make it more posible.
[02:37:52] <skunkworks> It was over my head.
[02:38:07] <jmkasunich> leadscrew mapping isn't enabled right now
[02:38:30] <jmkasunich> the issue isn;t the mapping, its getting the map thru task and NML and all that rot and down into the motion controller code
[02:38:40] <fenn> right
[02:39:21] <fenn> well i'll burn that bridge when i come to it
[02:45:07] <skunkworks> jmkasunich: - this is the start. http://www.electronicsam.com/images/KandT/eaglesch.JPG
[02:46:30] <jmkasunich> add bypass caps
[02:47:02] <skunkworks> across?
[02:47:41] <jmkasunich> each drivers power pins (1 and 2 I think), the 4049s power pins (1 and 8?), and the main DC bus
[02:47:57] <jmkasunich> the chips can use 0.1uF or 0.01uF 50V ceramics
[02:48:02] <skunkworks> ok - yes - I am going to be adding them.
[02:48:17] <jmkasunich> the main DC bus should have more
[02:48:30] <skunkworks> can never have too many :)
[02:48:43] <jmkasunich> I'd probably put a 100V 100uF electrolytic plus some smaller caps on the bus
[02:49:52] <skunkworks> Thanks again.
[02:49:56] <jmkasunich> np
[02:50:16] <skunkworks> this is going to work the first time out of the box. :)
[02:50:22] <jmkasunich> sure
[02:50:33] <skunkworks> I can dream.
[02:50:35] <jmkasunich> and I have some nice swampland in florida to sell you
[02:50:46] <skunkworks> :)
[02:50:53] <skunkworks> going to bed. night
[02:50:58] <jmkasunich> goodnight
[02:52:25] <SWPadnos> oh yeah - bed. what a plan
[02:52:34] <SWPadnos> night all.
[02:52:41] <SWPadnos> SWPadnos is now known as SWP_Away
[02:57:23] <CIA-4> 03jmkasunich 07HEAD * 10infrastructure/farm-scripts/ (results_list results_web): added script to send results to emc-commit list
[02:57:32] <cradek> cool
[02:57:59] <jmkasunich> not done yet
[02:58:02] <jmkasunich> committed to test
[03:16:34] <CIA-4> 03cradek 07HEAD * 10emc2/configs/sim/keystick.ini:
[03:16:34] <CIA-4> Some tweaks to make keystick work. I like the separate xterm
[03:16:34] <CIA-4> (and it sets the right terminal settings) but some may not agree.
[03:16:34] <CIA-4> If that's the case, we need to clean up a bit so we don't mess up the
[03:16:34] <CIA-4> display with the various informative/debug messages that are printed.
[03:16:35] <CIA-4> 03cradek 07HEAD * 10emc2/scripts/emc.in:
[03:16:37] <CIA-4> Some tweaks to make keystick work. I like the separate xterm
[03:16:41] <CIA-4> (and it sets the right terminal settings) but some may not agree.
[03:16:43] <CIA-4> If that's the case, we need to clean up a bit so we don't mess up the
[03:16:45] <CIA-4> display with the various informative/debug messages that are printed.
[03:16:47] <CIA-4> 03cradek 07HEAD * 10emc2/src/emc/usr_intf/keystick.cc:
[03:16:49] <CIA-4> Some tweaks to make keystick work. I like the separate xterm
[03:16:51] <CIA-4> (and it sets the right terminal settings) but some may not agree.
[03:16:55] <CIA-4> If that's the case, we need to clean up a bit so we don't mess up the
[03:16:57] <CIA-4> display with the various informative/debug messages that are printed.
[03:17:28] <cradek> I wish it didn't do that for every directory, but that's the unfortunate nature of cvs
[03:17:55] <jmkasunich> you mean the duplicate CIA msgs?
[03:18:21] <cradek> yes
[03:18:38] <cradek> it merges them only if they're in the same directory
[03:18:43] <jmkasunich> the old one said "14 files in 5 dirs" if it was a big commit
[03:19:02] <jmkasunich> must be some complex scripting to merge the cvs output into one mail
[03:19:05] <cradek> yeah but I'm repulsed by the hackery necessary for that
[03:19:33] <jmkasunich> did you look at the original script?
[03:19:39] <cradek> it would write state into /tmp and then sleep for a while, waiting for commits in other directories that "seem related"
[03:19:45] <jmkasunich> ah
[03:19:47] <cradek> yes
[03:20:20] <jmkasunich> was it as "oh ... my ... god" as the original farm scripts?
[03:20:22] <cradek> also, it's perl, which would require me to move thousands of files into my chroot
[03:20:29] <jmkasunich> eww
[03:20:33] <cradek> oh any perl makes me say that
[03:20:39] <jmkasunich> lol
[03:20:58] <cradek> hmm, maybe I just hate all programming languages
[03:21:05] <cradek> (if you can call perl that with a straight face)
[03:21:09] <CIA-4> 03jmkasunich 07HEAD * 10infrastructure/farm-scripts/ (results_list run_farm): final tweaks to list notification
[03:21:17] <cradek> on the bright side, keystick works right
[03:22:15] <cradek> it's actually a fairly nice ui
[03:24:32] <jmkasunich> damn, somebody's gonna have to bust something before list notification gets tested
[03:25:03] <cradek> oh that's easy, want me to do it?
[03:25:24] <cradek> so does this work only on head?
[03:26:35] <jmkasunich> nope, all slots, all trees
[03:26:52] <jmkasunich> I even have my ubuntu box (this one) acting as a slot
[03:26:55] <cradek> so when I check in a change on the v2_0_branch the farm gets it and builds it?
[03:27:02] <jmkasunich> oh, that
[03:27:15] <jmkasunich> I did add emc2testing to the list of trees that it builds
[03:27:23] <jmkasunich> http://linuxcnc.org/compile_farm/
[03:27:42] <cradek> ok cool, it gets the tagged version
[03:27:58] <jmkasunich> and I no longer attemp to build rcslib or emc on BDI4 (or ubuntu)
[03:28:21] <cradek> yeah, who cares
[03:28:28] <jmkasunich> the scripts are written so you can build in any checkout dir(s), you just make a list of them in a file
[03:28:31] <cradek> it'll probably always build
[03:28:45] <cradek> cool, good work on this
[03:28:49] <cradek> is it done now?
[03:28:51] <jmkasunich> not done yet
[03:28:59] <jmkasunich> now I have to make XML that CIA will accept
[03:29:10] <jmkasunich> the CIA guy never got back to me
[03:29:32] <jmkasunich> I strongly suspect that the XML message schema defined for build results isn't implmented yet
[03:29:36] <cradek> I never saw any docs, just copied the message format that someone else's script uses
[03:29:52] <cradek> yeah I bet you're gonig to have to fake it
[03:30:17] <jmkasunich> http://svn.navi.cx/misc/trunk/cia/xml/schema.xsd
[03:30:33] <jmkasunich> thats the "documentation" ;-)
[03:31:21] <cradek> * cradek 's eyes gloss over
[03:31:43] <cradek> bookmarked to read earlier in the day
[03:31:44] <jmkasunich> I can't really read python, but I looked at the source module thats supposed to process builder messages
[03:31:56] <jmkasunich> and I think the key formatter function is a nop
[03:32:32] <cradek> can you take a break for a minute and look at something with me
[03:32:39] <cradek> http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_33a.html#1013246
[03:33:07] <cradek> do you think ABC should also go home on g28/g30? (It doesn't)
[03:33:40] <jmkasunich> fsck if I know - ask somebody who actually cares about g-code
[03:33:48] <jmkasunich> ;-)
[03:33:52] <cradek> :-P
[03:34:26] <jmkasunich> I don't see why a part program would care about going home, just do G0 X0Y0Z0A0C0B0 if you want
[03:34:42] <cradek> g0 g53 x0y0z0a0b0c0
[03:34:49] <jmkasunich> whatever
[03:35:07] <cradek> it's just a shortcut for a thing I type often
[03:35:10] <jmkasunich> mego when people talk about the interp and gcode, I'm a motion control guy
[03:35:30] <cradek> ok, forget I asked, thanks
[03:35:39] <jmkasunich> sorry
[03:35:53] <jmkasunich> hopefully someone else in this channel can be more helpfull
[03:36:21] <cradek> it's not a matter of knowing gcode, I just wondered what you think the docs say
[03:36:34] <cradek> np if you don't care, seriously
[03:36:43] <jmkasunich> yeah, I decided to stop being a shit and I'm reading it again now
[03:37:17] <jmkasunich> seems to me all 6 axis should be treated the same
[03:37:57] <cradek> I agree, I think that's what it says because the first sentence says parameters 5161..5166
[03:38:06] <cradek> that's 6 of them defining the home position
[03:38:16] <jmkasunich> what _does_ worry me is that talk of parameters defining home
[03:38:31] <jmkasunich> right now, ini file params define home
[03:38:37] <cradek> it says there are two - I've never heard of that
[03:38:54] <cradek> maybe those are filled out by the ini values?
[03:39:06] <jmkasunich> the motion controller only understands whats in the ini, when you home the machine (start a home sequence, not just "move to home") thats what it uses
[03:39:27] <jmkasunich> "return to home" implies that the machine was already homed
[03:39:44] <jmkasunich> so all it really is is a remembered position and a shorthand way to command a move there
[03:40:16] <jmkasunich> I dunno if one or the other parameter set is loaded from the ini vars
[03:40:25] <cradek> I see what you mean
[03:40:54] <jmkasunich> a "home" command to the motion controller starts a possibly long sequence that results in the machine being at a known position
[03:40:56] <cradek> so it's not "return to home" as much as "return to predefined point that defaults to 0,0,0,0,0,0"
[03:41:15] <jmkasunich> yeah, I think so
[03:41:53] <jmkasunich> I want to finish this CIA stuff tonight (I was up till 4 last night, big mistake)
[03:42:16] <jmkasunich> but tomorrow, I'll fire up the sim machine with the sim limit and home switches, and do some homing
[03:42:26] <cradek> I fixed it
[03:42:40] <cradek> ok I'll leave you alone about it, thanks
[03:43:16] <jmkasunich> well, getting the sim machine working (and homing on switches) is the first step to homing on index pulses, which is my next project anyway
[03:43:27] <jmkasunich> so tomorrow...
[03:43:47] <cradek> that'll be a lot of hal work
[03:43:55] <jmkasunich> not too much
[03:44:05] <cradek> you'll emulate switches that trigger at certain positions?
[03:44:10] <jmkasunich> I forget where I left off, but I think most of it is done
[03:44:12] <jmkasunich> yes
[03:44:48] <jmkasunich> look at servo_sim.ini and servo_sim.hal (in the sim config)
[03:45:08] <jmkasunich> the switch stuff is already there I think
[03:45:20] <CIA-4> 03cradek 07HEAD * 10emc2/src/emc/rs274ngc/interp_convert.cc: make g28/g30 work according to the kramer doc.
[03:45:21] <jmkasunich> just have to set the search_vel and other homing params to use them
[03:46:21] <jmkasunich> thanks for that commit, saves me scrolling
[03:46:37] <jmkasunich> (I'm comparing the message you send with the output to the channel)
[03:46:45] <cradek> ah
[03:47:16] <jmkasunich> generator section should probably identify the script
[03:47:32] <jmkasunich> source section will need a little fudging
[03:47:38] <jmkasunich> I don't have tag info
[03:47:54] <jmkasunich> I have names like emc2head and emc2testing
[03:48:04] <CIA-4> 03cradek 07v2_0_branch * 10emc2/src/emc/rs274ngc/interp_convert.cc: make g28/g30 work according to the kramer doc.
[03:48:07] <jmkasunich> I suppose I can put that into module, and leave tag blank
[03:48:41] <cradek> yeah I'm not sure I am even doing it right
[03:49:00] <cradek> I get the whole path in cyan and just the filename in white, seems odd
[03:49:29] <jmkasunich> I'll probably be leaving files blank
[03:51:24] <jmkasunich> is it possible for you to capture the actual message that got sent?
[03:51:39] <jmkasunich> (is there a sent mail dir on the server?)
[03:52:11] <cradek> not easily, no
[03:52:14] <jmkasunich> darn
[03:52:28] <jmkasunich> some fields in the message can easily be mapped to the output they generate in channel
[03:52:34] <jmkasunich> author for example
[03:52:53] <jmkasunich> others are harder
[03:53:05] <jmkasunich> echo " <module>$dir</module>"
[03:53:22] <jmkasunich> seems like that should be "emc" or "emc2" or "infrastructure", not a complete path
[03:55:15] <cradek> well I wanted it to say emc2/full/path/here (file1 file2 file3)
[03:55:28] <cradek> but maybe you're right, and that's why they don't merge
[03:55:38] <cradek> I don't know who's supposed to do the merging
[03:55:46] <jmkasunich> module is cvs speak for the top level
[03:56:05] <jmkasunich> we only have documents, rcslib, emc. emc2, and infrastructure
[03:56:28] <jmkasunich> module+tag identify the checkout uniquely
[03:57:30] <cradek> I think I have the output if you still want it
[03:57:38] <jmkasunich> it might help
[04:02:30] <CIA-4> 03ignore-testing 07v2_0_branch * 10emc2/src/emc/rs274ngc/interp_convert.cc: make g28/g30 work according to the kramer doc.
[04:05:07] <CIA-4> 03ignore-testing 07emc2head * 10emc2/interp_convert.cc: testing automated reporting of compile farm results
[04:09:35] <CIA-4> 03Ubuntu-5.10 (2.6.12-magma) * 10emc2head/interp_convert.cc: build FAILED
[04:09:55] <CIA-4> 03Ubuntu-5.10 (2.6.12-magma) * 10emc2head/: build FAILED
[04:09:59] <SWP_Away> hmmm - would it make sense for the farm results to be checked back into cvs? (a separate module, of course)
[04:10:21] <jmkasunich> that would bloat cvs I think
[04:10:33] <SWP_Away> it would also give history, and a web interface
[04:10:35] <jmkasunich> (do you mean the full log, or just pass/fail results)?
[04:10:47] <SWP_Away> both, for best results
[04:10:58] <jmkasunich> the full log is many K long
[04:11:24] <jmkasunich> the compile farm webpage provides the most recent full log, and a pass/fail history of all builds
[04:11:39] <SWP_Away> doesn't cvs store diffs?
[04:11:53] <jmkasunich> yeah but still
[04:12:24] <jmkasunich> I think of cvs for storing the result of human labor, so you can restore, revisit, etc
[04:12:30] <SWP_Away> well - I can claim illness and tiredness for the suggestion ;)
[04:12:34] <CIA-4> 03cradek 07HEAD * 10emc2/src/.cvsignore: cvsignore updates
[04:12:34] <CIA-4> 03cradek 07HEAD * 10emc2/bin/.cvsignore: cvsignore updates
[04:12:34] <CIA-4> 03cradek 07HEAD * 10emc2/.cvsignore: cvsignore updates
[04:12:35] <jmkasunich> not for storing log
[04:12:46] <jmkasunich> logs
[04:12:53] <jmkasunich> or other autogenerated bloaty stuff
[04:13:18] <jmkasunich> anyway, what do you guys think of the message format?
[04:13:31] <jmkasunich> Ubuntu-5.10 (2.6.12-magma) * emc2head/: build FAILED
[04:13:32] <SWP_Away> it just seemed like it would be good for looking at what changed from build to build
[04:13:48] <cradek> maybe it should have a link to the full report
[04:14:19] <jmkasunich> Ubuntu-5.10 (2.6.12-magma) * emc2head/: build FAILED; see http:/blablah
[04:14:24] <cradek> you're going to have cia report success and failure, but email only the failuers?
[04:14:29] <jmkasunich> yes
[04:14:31] <cradek> great
[04:14:40] <cradek> yes I think see http://... is good
[04:15:03] <jmkasunich> does having the "author" field be the system name seem right?
[04:15:07] <jmkasunich> I could also do:
[04:15:17] <jmkasunich> emccf Ubuntu-5.10 (2.6.12-magma) * emc2head/: build FAILED; see http:/blablah
[04:15:30] <jmkasunich> use emccf (or something) for author
[04:15:44] <jmkasunich> and use the "branch" field for the system name
[04:15:44] <cradek> doesn't matter to me
[04:16:37] <jmkasunich> http://cia.navi.cx/stats/project/emc
[04:16:48] <jmkasunich> fscking with author messes up the stats
[04:16:55] <jmkasunich> we now have two new authors
[04:17:05] <cradek> arg
[04:17:21] <cradek> oh well
[04:17:25] <jmkasunich> maybe the author for all such messages should be "emccf"
[04:17:56] <jmkasunich> or "compile_farm"
[04:18:07] <cradek> compile_farm/compile-farm
[04:18:13] <jmkasunich> ok
[04:18:20] <cradek> for me: 306 messages since the first one, 1.46 years ago, for an average of 1.74 days between messages
[04:18:43] <cradek> apparently I mess something up every 1.74 days
[04:18:50] <Jymmmm> lol
[04:20:24] <CIA-4> 03compile-farm 07Ubuntu-5.10 (2.6.12-magma) * 10emc2head/: build FAILED ; see http://blahblah
[04:21:08] <jmkasunich> would it be better if the checkout name (emc2head) came first, then the system name?
[04:21:31] <cradek> don't care
[04:21:43] <cradek> as long as the information is there
[04:22:07] <jmkasunich> forget I said that - emc2head _is_ the module name, no reason to fsck it up any more than it needs to
[04:22:44] <jmkasunich> ok, got a message format, just need to automate it
[04:23:54] <cradek> * cradek shakes his head at the sf site status page
[04:33:03] <CIA-4> 03jmkasunich 07HEAD * 10infrastructure/farm-scripts/results_cia: script to report farm results to CIA
[04:34:40] <CIA-4> 03jmkasunich 07HEAD * 10infrastructure/farm-scripts/run_farm: added cia reporting to main script
[04:41:48] <CIA-4> 03jmkasunich 07HEAD * 10infrastructure/farm-scripts/results_cia: change file name, fix missing XML tag
[04:44:36] <CIA-4> 03compile-farm 07Ubuntu 5.10 (2.6.12-magma) * 10emc2head/: build PASSED ; see http://linuxcnc.org/compile_farm/emc2head_slot7_log.txt
[04:50:50] <CIA-4> 03jmkasunich 07HEAD * 10infrastructure/farm-scripts/build: fixed some missing info in build log
[04:53:24] <CIA-4> 03compile-farm 07Ubuntu 5.10 (2.6.12-magma) * 10emc2head/: build PASSED ; see http://linuxcnc.org/compile_farm/emc2head_slot7_log.txt
[04:56:27] <jmkasunich> sorry about all the test messages.... the most recent one (and the others that should follow from the slower farm slots) are the real deal
[05:12:38] <alpha1125> alpha1125 is now known as A-L-P-H-A
[05:28:18] <CIA-4> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build PASSED ; see http://linuxcnc.org/compile_farm/emc2head_slot2_log.txt
[05:28:46] <jmkasunich> it works much better when the outgoing mail port isn't firewalled
[05:28:59] <jmkasunich> compile was done 10 mins ago....
[05:32:01] <CIA-4> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build PASSED ; see http://linuxcnc.org/compile_farm/emc2head_slot2_log.txt
[05:35:35] <CIA-4> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build PASSED ; see http://linuxcnc.org/compile_farm/emc2head_slot2_log.txt
[05:36:02] <jmkasunich> well that sucks
[05:36:22] <jmkasunich> two systems, both sending virtually the same message using the same program
[05:36:33] <jmkasunich> one is accepted, the other rejected
[05:36:45] <jmkasunich> it always fscking something...
[05:36:57] <jmkasunich> time for sleep, fight with it tomorrow
[05:37:08] <Jymmmm> G'Night
[05:58:12] <CIA-4> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build PASSED ; see http://linuxcnc.org/compile_farm/emc2head_slot2_log.txt
[06:35:23] <alex_joni> morning
[06:37:25] <Jymmmm> hi
[07:44:08] <alex_joni> what's up Jymmmm ?
[07:44:11] <alex_joni> except the
[07:44:18] <alex_joni> except the 'm' count on yournick ?
[07:45:37] <Jymmmm> Jymmmm is now known as Jymmmmm
[07:45:40] <Jymmmmm> =)
[07:45:53] <Jymmmmm> some delay there alex_joni =)
[07:46:06] <Jymmmmm> Just writing up some legalese at the moment
[07:50:58] <alex_joni> a bit delay.. some are actually working ;)
[07:51:10] <Jymmmmm> yeah, but not you.
[07:51:16] <Jymmmmm> your fucking off on irc
[07:53:13] <alex_joni> :P
[07:53:47] <Jymmmmm> I hate writing legalese
[07:53:59] <alex_joni> * alex_joni goes away
[07:54:07] <Jymmmmm> promises promisies
[08:44:21] <giacus> morning
[08:49:50] <Bo^Dick> morning
[11:40:58] <chinamill> Howdy
[13:38:56] <SkunkWorks> so a base period of .00004 should not be 40000
[13:39:21] <SkunkWorks> and all other periods in the ini should be changed accordingly?
[13:40:52] <cradek> yes
[13:41:01] <SkunkWorks> that is easy enough :)
[13:41:03] <cradek> and you have to change your halfile to load motmod
[13:41:13] <cradek> let me find an example of the change in webcvs
[13:42:04] <SkunkWorks> I had coppied the core_stepper.hal from the samples. (I had not changed it so I could use stock)
[13:42:38] <SkunkWorks> I figured my only other problem was the period issue
[13:44:53] <cradek> ok, I bet if you just copy the new halfile you'll be allright then
[13:44:58] <cradek> http://cvs.linuxcnc.org/cvs/emc2/configs/common/core_stepper.hal.diff?r1=1.2;r2=1.4
[13:45:04] <cradek> otherwise, here is the necessary change
[13:45:51] <SkunkWorks> Thanks
[13:48:53] <SkunkWorks> wanted to look at the gcode output from eagle in axis last night but I broke emc :)
[13:59:28] <cradek> there are always the distributed sample configs like sim
[14:17:02] <chinamill> The introduction of HAL referes to bin/hal_parport but in my emc2/bin i cant find it. Is it replaced by some other thing?
[14:19:40] <jepler> chinamill: you'll want to use the realtime parport module. Load it with halcmd "loadrt hal_parport" followed by the proper configuration string
[14:20:02] <jepler> standard_pinout.hal:loadrt hal_parport cfg="0x0378"
[14:20:16] <jepler> the above line is for a single parport at the standard address.
[14:20:31] <chinamill> ok
[14:20:36] <jepler> if you have two ports then it would be: loadrt hal_parport cfg="0x0378 0xnnnn" where nnnn is the address for the second port
[14:21:47] <SkunkWorks> logger_aj: you don't seem to be logging :)
[14:21:47] <SkunkWorks> I'm logging. I don't understand 'you don't seem to be logging :)', SkunkWorks. Try /msg logger_aj help
[14:46:34] <SkunkWorks> boy - my connection here sucks.
[14:46:48] <SkunkWorks> I think I am hooked up but I am not.
[14:53:59] <Bo^Dick> if someone has serious skills involving the script capabilities in eagle, please let me know
[14:56:06] <SkunkWorks> what do you want to do? (I have no experience with eagle scripts) but I would think there is already something out there that does what you want to do.
[15:26:05] <Bo^Dick> what i want to do is an autoplacer that automatically rotates the parts and finds the optimal configurations with least number of wire crossings
[15:26:56] <cradek> even if you were a master of the language, that would require a complex algorithm
[15:28:38] <SWP_Away> SWP_Away is now known as SWPadnos
[15:29:11] <cradek> if you could write it, you would be a hero among eagle users
[15:29:24] <SWPadnos> but all the connectors would end up in the middle of the board ;)
[15:30:40] <Bo^Dick> well first of all i would like to implement a function that counts the number of crossing wires between two components in the board layout
[15:30:47] <cradek> all I'm saying is it's a hard problem independent of whether or not you know the language
[15:31:26] <Bo^Dick> well i believe you but now i have problems with the script language. i'm completely aware of what i wanna do
[15:33:03] <cradek> the script language is a lot like C, and the help for the various functions is on the eagle main menu
[15:33:50] <Bo^Dick> i know that. my request is slightly more advanced i'm afraid
[15:34:06] <cradek> ok lets backup, what's your actual question
[15:34:16] <jepler> cradek: "<Bo^Dick> well first of all i would like to implement a function that counts the number of crossing wires between two components in the board layout"
[15:34:19] <jepler> let's consider this the question
[15:34:44] <Bo^Dick> and with wires i mean unrouted wires
[15:34:55] <jepler> clearly this is 'for(airwire1 in airwires) for (airwire2 in airwires) if(crosses(airwire1, airwire2)) crossing_count ++;
[15:35:01] <cradek> ok, I think you can get the endpoints, so it's a geometry problem
[15:35:04] <jepler> so now just figure out how to write 'crosses' and 'for airwireN in airwiares'
[15:35:10] <jepler> s/wiares/wires/
[15:35:12] <Bo^Dick> precisely
[15:35:30] <cradek> so it's not an eagle question, it's a geometry question now, that's easier
[15:35:31] <Bo^Dick> well of course i must know how i fetch the unrouted wires for a component
[15:35:45] <Bo^Dick> it is an eagle question!
[15:36:14] <Bo^Dick> i must know how i fetch the unrouted wires for a component. a component in eagle is of the type UL_ELEMENT
[15:36:16] <jepler> the board() will have several signals() each of which can correspond to several airwires. I think you have to look at the contactrefs() and "do something"
[15:36:42] <jepler> I've never done anything in eagle that needed to loop over airwires, so I don't know how to find them
[15:37:44] <cradek> http://www.math.niu.edu/~rusin/known-math/95/line_segs
[15:37:50] <cradek> here is a discussion of the geometry problem
[15:38:32] <Bo^Dick> cradek: thanks
[15:38:38] <cradek> at the very end is the algorithm I pictured, using cross products
[15:39:30] <jepler> "This ULP automatically routes all airwires of the given net creating straight connections between pad" ftp://ftp.cadsoft.de/eagle/userfiles/ulp/routenet.ulp
[15:39:54] <jepler> Bo^Dick: this might be useful in answering the question "how do I find all airwires in the schematic"
[15:40:03] <jepler> I've never used it, though.
[15:40:04] <cradek> cool
[15:41:15] <Bo^Dick> yeah
[15:41:49] <jepler> S.wires(W)
[15:41:51] <jepler> if(W.layer == LAYER_UNROUTED)
[15:42:09] <jepler> so you loop over the board() signals() wires() and check the wire's layer
[15:48:39] <Bo^Dick> btw, i know that the command S.wires(W) automatically loops through all of the wires but what if i wanna loop through the first three only for example?
[15:50:19] <cradek> easiest is probably to use a board with three wires
[15:50:31] <cradek> or, there might be break/continue etc
[15:51:04] <Bo^Dick> to be honest, i think i like for-loops better
[15:51:52] <cradek> yeah I'm also not sure I like their looping
[15:52:07] <cradek> but aside from the odd syntax it seems like what you usually want
[15:52:14] <Bo^Dick> i wonder if one could come around that somehow
[15:52:24] <Bo^Dick> thats true
[15:52:33] <Bo^Dick> most often that is
[16:00:57] <Bo^Dick> to illustrate more clearly i can show you a simple board layout with no cross connections: http://www.carmi.se/misterstarshine/img/simple.gif
[16:01:32] <Bo^Dick> in this particular example it is clear that this very configuration is the optimal one...
[16:02:04] <Bo^Dick> this might not be as apparent for a lot more complex layouts!
[16:02:33] <Bo^Dick> btw, the code calculates the correct number of wires
[16:02:46] <Bo^Dick> in this case there are five of them
[16:04:58] <Bo^Dick> so if i could calculate the number of crossed airwires i could automatically rotate the parts and log how many crossing airwires the different configurations might have and pick the optimal one. pretty smart huh?
[16:09:34] <jepler> keep plugging away
[16:21:05] <skunkworksorg> lets try this.
[16:21:19] <skunkworksorg> nice little applet
[16:21:55] <skunkworksorg> logger_aj: bookmark
[16:21:55] <skunkworksorg> See http://81.196.65.201/irc/irc.freenode.net:6667/emc/2006-04-18#T16-21-55
[16:22:57] <skunkworksorg> sorry.
[16:24:16] <skunkworksorg> logger_aj: bookmark
[16:24:16] <skunkworksorg> See http://81.196.65.201/irc/irc.freenode.net:6667/emc/2006-04-18#T16-24-16
[20:09:11] <NickServ> This nickname is owned by someone else
[20:09:11] <NickServ> If this is your nickname, type /msg NickServ IDENTIFY <password>
[20:09:26] <CIA-4> 03compile-farm 07Ubuntu 5.10 (2.6.12-magma) * 10emc2head/: build PASSED ; see http://linuxcnc.org/compile_farm/emc2head_slot7_log.txt
[20:09:36] <alex_joni> hui, that was fast ;)
[20:10:02] <Lerneaen_Hydra> alex_joni: compile farm, id more than one computer compiling EMC?
[20:10:10] <skunkworks> Lerneaen_Hydra: thanks - yes it is getting clearer how this all works togather
[20:10:13] <alex_joni> yup, as you can see that is slot 7
[20:10:23] <jepler> Lerneaen_Hydra: for more details, visit http://linuxcnc.org/compile_farm
[20:10:38] <jepler> it includes ubuntu plus several older "bdi"
[20:11:22] <Lerneaen_Hydra> jepler: Are the beowolfed or set up so one computer takes one branch and so on?
[20:11:26] <SWPadnos> that one was jmk's main workstation, a reasonably fast machine
[20:11:49] <SWPadnos> the other slots have much slower processors
[20:11:53] <jepler> Lerneaen_Hydra: no; the idea is that the changes are tested on all the different realtime kernel and OS variations
[20:11:56] <Lerneaen_Hydra> jepler: I had to ask, sorry (/. thing)
[20:12:09] <SWPadnos> it's a backplane with 7 processor cards in it
[20:12:19] <Lerneaen_Hydra> nonstandard I take it?
[20:12:30] <SWPadnos> standard, for "blade server" type machines ;)
[20:12:32] <alex_joni> SWPadnos: stop kidding ;)
[20:12:43] <CIA-4> 03alex_joni 07v2_0_branch * 10emc2/docs/Hal_Introduction.pdf: updated changes
[20:13:23] <jepler> Lerneaen_Hydra: In fact, the "farm" is mostly outdated junker PCs, last I knew
[20:13:31] <alex_joni> SWPadnos: thought those were blade pc's, not blade processor cards? each has hdd, etc
[20:13:37] <alex_joni> jepler: mostly P200 MHz
[20:13:39] <cradek> I think they're original pentiums
[20:13:44] <alex_joni> but good enough for the job
[20:13:57] <alex_joni> cradek: solaris is/was an original P133 ;)
[20:14:04] <Lerneaen_Hydra> how are the cards connected and aware of each other? Do each run thier own OS, completely unbeknowst to each other?
[20:14:07] <alex_joni> with the F00F bug in it :-P
[20:14:19] <Lerneaen_Hydra> rather old stuff them?
[20:14:21] <alex_joni> Lerneaen_Hydra: basicly they are sepparate PC's running in the same rack
[20:14:23] <Lerneaen_Hydra> the floating point divide bug?
[20:15:10] <alex_joni> Lerneaen_Hydra: rather old, but still more than good enough for a proxy/webserver (even apache)/firewall/vpn/irc logger/mirror/ and who knows what else runs on that box ;)
[20:15:22] <alex_joni> I meant even php
[20:15:29] <Lerneaen_Hydra> alex_joni: Ah, so that's not compiling anything?
[20:15:36] <alex_joni> my P133 isn't
[20:15:42] <alex_joni> but jmk's P200 all are
[20:15:57] <SWPadnos> that's why they take ~45 minutes to compile ;)
[20:15:58] <CIA-4> 03compile-farm 07BDI-2.18 (2.2.18-rtl3.0) * 10emc2head/: build PASSED ; see http://linuxcnc.org/compile_farm/emc2head_slot2_log.txt
[20:16:18] <alex_joni> he has a standard 19" rack (8U or the like) with a few (I think 6) pc's in it
[20:16:31] <skunkworks> I got my box working. it was the second to nanosecond update.
[20:16:52] <alex_joni> SWPadnos: that wasn't ~45 minutes :D
[20:16:55] <SWPadnos> oops - 10 minutes on BDI 2.18, 14:25 on BDI-TNG, 21:32 on BDI-4.20, and 24:21 on BDI-Live
[20:16:59] <Lerneaen_Hydra> 45 minutes.. doing a larger compile would not be very fun
[20:17:04] <SWPadnos> I just reread jmk's message ;)
[20:17:28] <alex_joni> Lerneaen_Hydra: they are always doing 'make clean' && 'make'
[20:17:35] <alex_joni> so they always recompile all of emc
[20:17:41] <Lerneaen_Hydra> constantly?
[20:17:52] <SWPadnos> only when there's a CVS change
[20:17:56] <Lerneaen_Hydra> so CIA-bot writes stuff when it has compiled and updated?
[20:18:15] <SWPadnos> I'm not sure if they get notified by the commit message now (jmk was working on that)
[20:18:24] <alex_joni> CIA is a bot which writes stuff in here, when it gets an XML formatted email
[20:18:25] <SWPadnos> if not, then they just check CVS every hour, and compile if needed
[20:18:39] <alex_joni> which can be from CVS commits or from the compile_farm
[20:19:04] <alex_joni> Lerneaen_Hydra: the compile_farm scripts are in CVS if you care
[20:19:45] <Lerneaen_Hydra> alex_joni: That's a bit over my head, I'm not a coder (yet).
[20:21:23] <Lerneaen_Hydra> Bye all, it's late over here in Sweden
[20:21:30] <bill20r3> good night.
[20:21:31] <skunkworks> bye
[20:21:40] <SWPadnos> see ya
[20:21:40] <alex_joni> heh, earlier than here
[20:21:44] <alex_joni> but 'night Lerneaen_Hydra
[20:21:45] <skunkworks> hey bill - how is the machine coming?
[20:21:52] <SWPadnos> and later than here
[20:21:59] <Lerneaen_Hydra> alex_joni: I get up at 6:00 am :(
[20:22:01] <bill20r3> good.
[20:22:10] <alex_joni> Lerneaen_Hydra: I go to bed at 6am ;)
[20:22:15] <alex_joni> kidding
[20:22:16] <bill20r3> slow, but good. I got one end of a screw turned down to bearing-size.
[20:22:24] <bill20r3> turning off the threads sure is a pain.
[20:23:31] <skunkworks> is it pretty hard? (steel)
[20:30:32] <bill20r3> yeah, and the threading means you have to take really light cuts.
[20:30:46] <bill20r3> *click* *click* *click* *click*
[20:37:47] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/docs/Hal_Introduction.pdf?graph=1 <- quite a nice graph
[20:38:59] <alex_joni> * alex_joni is off to bed
[20:39:02] <alex_joni> good night all
[20:39:14] <skunkworks> night alex
[20:42:44] <bill20r3> * bill20r3 falls asleep too.
[20:44:28] <skunkworks> bbl
[20:46:48] <giacus> night alex_joni
[20:47:02] <chinamill> nighty
[21:50:06] <giacus> night
[21:50:56] <dmessier> hi all..
[21:52:32] <dmessier> apperantly if you stress relieve an assembly with dissimialr metals you make scrap out of the lot
[21:55:49] <dmessier> i would have thought 375 deg f would just seat the lee plug and the bushings... but no...
[22:13:22] <fenn> different coefficient of expansion makes everything warp, then it cools in the wrong shape
[22:14:07] <bill20r3> you have to disassemble it and anneal everything separatly?
[22:14:46] <dmessier> i know... but the 2 newbees didnt... might have scrapped 2 parts... 40 G us each
[22:15:37] <dmessier> 4330v.... 304ss and 17-4 ph
[22:16:29] <dmessier> the ss 's needed NO stress relief... so they are facked now
[22:16:36] <bill20r3> ouch.
[22:17:12] <dmessier> lee plug and bushes.. not the end of the world... but the cylinder i need to save
[22:18:28] <dmessier> pull it all apart ... do a visual... then mag particle... see what comes of them... ; (
[22:22:33] <dmessier> 1 part was a fix up from the field nad now has ANOTHER boo boo... still in the fix process.. so its strike 3 for that one...
[23:07:23] <robin_sz> ahh, now .. theres a solution to the trajectory planner ...
[23:07:33] <robin_sz> all we need is a quantum computer :)
[23:07:34] <robin_sz> http://www.theregister.co.uk/2006/02/23/quantum_computing/