Back
[00:00:02] <Jon_geo01005> perhaps someone who is better at searching the archives than me could find it :)
[00:00:07] <LawrenceG> so yes to weights and the way to keep the hotwire tight
[00:00:08] <JymmmEMC> Yeah, I remember that too. he setup a special "end-suspended table for it
[00:00:54] <JymmmEMC> http://www.hotwiredirect.com/files/videos/TaperedDemo_High.wmv
[00:01:26] <SWPadnos> I'd expect a bow to significantly limit the maximum work area
[00:01:28] <LawrenceG> that is one serious foam cutter
[00:01:32] <SWPadnos> kind of like a coping saw
[00:01:48] <Jon_geo01005> Yeah.
[00:03:13] <JymmmEMC> $40K
[00:03:57] <LawrenceG> I have cut 5'long tapered wings using a template to cut around ... one end of the wire was screwed to the wall (infinity point) and the other end was hand held to trace around a template on the end of the foam blocks.. a couple of clip leads to put juice on the cutting part of the wire
[00:04:56] <JymmmEMC> When belts are used, like in a laser, is the head physically attached to the belt itself?
[00:06:49] <JymmmEMC> nm I was thinking of something else
[00:08:57] <Jon_geo01005> depends, check this out :
http://www.oemdynamics.com/#
[00:09:26] <Jon_geo01005> I have been wanting to build a machine with one of these linear harmonic drives for a while now.
[00:09:57] <JymmmEMC> I can't afford anythin with the words "linear" and/or" hamronic" in it's title.
[00:10:27] <JymmmEMC> But, I can raid their dumpsters as they are just up the street from me!
[00:10:52] <Jon_geo01005> it is actually quite simple. They say they have a patent pending on the technology, but I don't think that it is patentable.
[00:11:14] <Jon_geo01005> I don't even know where they are.
[00:11:31] <JymmmEMC> same page you linked to at bottom
[00:12:18] <Jon_geo01005> Germany?
[00:12:30] <Jon_geo01005> or Santa Clara?
[00:12:34] <JymmmEMC> 3200 Patrick Henry Drive
[00:12:34] <JymmmEMC> Santa Clara , CA 95054
[00:13:26] <JymmmEMC> http://maps.google.com/?q=3200+Patrick+Henry+Drive+,Santa+Clara+,+CA+95054+&ie=UTF8&t=h&z=16&iwloc=A
[00:13:48] <Jon_geo01005> I have looked at all of animatics pattents, both active an pending, the only technology they have a claim to is the integration of the motor in to the slide.
[00:15:18] <Jon_geo01005> fantastic gear reduction with very little backlash.
[00:27:14] <tomp> tomp is now known as tomp3
[00:33:54] <eric_unterhausen> I have a drill chuck with the only markings being 180 J6 -- how hard is it to verify that the J6 means Jacobs taper 6?
[00:35:02] <JymmmEMC> If it looks like a duck, and it qwuaks like a duck, it's gotta be a horse!
[00:37:15] <eric_unterhausen> interestingly, J6 is smaller than J3
[00:38:25] <JymmmEMC> sound like wire gauges... the larger the number, the smaller the diameter
[00:38:42] <eric_unterhausen> it would sound like that if J6 wasn't the only exception
[00:39:15] <eric_unterhausen> otherwise, J0-J5 increase in size
[00:39:33] <JymmmEMC> ah
[00:43:27] <tomp3> japan 6 ? dunno if thats a spec but jacobs likes to say jacobs buz peeple would buy jacobs ( not j's )
[00:43:47] <eric_unterhausen> everyone uses jacobs taper for their drill chucks
[00:44:10] <tomp3> oh,i thought albrects did not, and shank mounts did not
[00:46:18] <tomp3> may be of help
http://www.newmantools.com/tech/taper.htm
[00:50:54] <tomp> tomp is now known as tomp3
[00:53:28] <tomp3> is it like this ?
[00:53:38] <tomp3> TAPER# DIAMETER DIAMETER LENGTH
[00:53:39] <tomp3> 6 .67600 .62409 1.00000
[00:57:46] <cradek> the albrechts I have all have JT arbors
[00:58:03] <cradek> they are probably various ages, but not real new
[00:59:39] <tomp3> or, jacquard taper maybe
[01:00:26] <tomp3> cradek: thx
[01:00:52] <cradek> heck I think they may even say the JT taper number on them
[01:01:07] <tomp3> the above spec is true then if if the j means jacobs
[01:04:25] <tomp3> a chart for the jacquard if needed
http://www.wildagroup.com/jc22.asp
[01:27:41] <skunkworks> only about <20ft left of wall to build.
[01:36:12] <LawrenceG> skunkworks, hey... hi, how tall did you build the walls?
[01:37:58] <skunkworks> they are 10ft
[01:38:29] <LawrenceG> :} excellent height.... no fighting with the bridgeport
[01:38:32] <skunkworks> actually 10ft + the curb (between 3-6 inches)
[01:39:11] <LawrenceG> tall enough but not too big to heat
[01:41:02] <skunkworks> :)
[01:41:07] <skunkworks> how is the h-bridge?
[01:42:54] <LawrenceG> getting close... I am working on software to test it with.... any tricks you used? resistive loads? shorted tests?
[01:43:32] <skunkworks> I always use servo. Stalled for most tests.
[01:43:48] <skunkworks> never shorted the output. (was too afraid)
[01:44:20] <LawrenceG> yea... good chance of a bang! from something
[01:45:40] <LawrenceG> I have a 500w 24v brushed motor to test with.... should be good up to about 20amps
[01:46:24] <LawrenceG> I will use the current limited bench supply until I can verify my current limit logic is 100%
[01:46:25] <skunkworks> I was running 20a thru a 4.something amp 90v dc motor.
[01:46:33] <skunkworks> got warm
[01:47:56] <skunkworks> actully - the shaft got warm first. :)
[01:48:53] <LawrenceG> the nice thing with big motors is they have some thermal capacity.... the big thing is to keep current spikes below the magnet demagnetization level (which nobody really tells you what it is)
[01:49:32] <LawrenceG> but should be at leats 8 to 10x rated running current
[01:50:55] <LawrenceG> bbiab... dog requesting service
[01:59:29] <invite> night
[02:04:58] <eric_unterhausen> Pretty sure my chuck is a Jacob's taper 6, could be wrong
[02:06:21] <eric_unterhausen> but I guess tomp's not here to argue with about it
[02:14:41] <eric_unterhausen> I'm thinking a keyless chuck may not be the best match for a lathe though
[02:16:12] <LawrenceG> * LawrenceG back from dog duty
[02:24:07] <eric_unterhausen> my son started walking the dog. second time, the neighbor is out walking the dog and yells at my son because he "always" walks his dogs at that time and they don't behave around other dogs
[02:24:44] <jmkasunich> tapping heads rock
[02:24:52] <jmkasunich> * jmkasunich just tapped 108 holes in 20 mins
[02:25:33] <eric_unterhausen> manual tapping head?
[02:25:43] <jmkasunich> yeah
[02:25:50] <jmkasunich> procunier or however you spell it
[02:25:54] <jmkasunich> in the drill press
[02:26:00] <eric_unterhausen> cool
[02:26:08] <jmkasunich> it was actually only taking me 4 seconds to tap two holes
[02:26:10] <eric_unterhausen> I have one of the collet tapping heads
[02:26:17] <jmkasunich> the rest of the time was changing parts (54 parts)
[02:26:19] <eric_unterhausen> that has a quill
[02:26:39] <eric_unterhausen> steel?
[02:27:48] <jmkasunich> aluminum
[02:27:51] <jmkasunich> 1/4-20
[02:28:09] <jmkasunich> cast parts, so the chips break nicely, and thru-holes, so they just spray out the bottom
[02:28:22] <jmkasunich> I started at 500 RPM and just kept going up
[02:28:34] <jmkasunich> by the time I finished I was tapping at 1100 and retracting at 2200
[02:28:36] <eric_unterhausen> I was going to say, 4 seconds is not much time
[02:29:39] <jmkasunich> 1100 RPM is 0.9" per second at 1/4-20
[02:30:12] <jmkasunich> the part thickness is about 7/16, I had my depth stop set to make sure the taper of the tap went all the way thru - probalby about 0.9"
[02:30:25] <jmkasunich> so 1 second down, 1/2 second up, move over to the next hole, repeat
[02:31:01] <eric_unterhausen> Last time I had a lot of holes to tap in aluminum, I chucked a tap in the hand drill and went to town. 10-32 into 1/8"
[02:31:29] <jmkasunich> nice - but it doesn't reverse as fast as a tapping head
[02:31:40] <eric_unterhausen> I wouldn't do it again
[02:32:01] <jmkasunich> stripped a few?
[02:32:09] <eric_unterhausen> not very many
[02:32:23] <eric_unterhausen> I've just had a lot of cups of coffee since then
[02:32:33] <jmkasunich> a guy I knew tapped 3/8-16 into cast iron (the side of a milling machine) using a milwaukee drill
[02:32:46] <eric_unterhausen> not easy
[02:33:18] <jmkasunich> I've done 3/8-16 into a cast iron lathe faceplate on the drill press (no tapping head, and only about 100 RPM)
[02:33:21] <eric_unterhausen> last time I tried that, I had to order a tap remover from McMaster
[02:33:50] <eric_unterhausen> Then again, don't buy taps from Lowes, they should pay you
[02:41:26] <eric_unterhausen> detroit just put in a new bike path with "no bikes" signs at one end
[02:51:54] <Valen> http://www.youtube.com/watch?v=bj4lj6YSwzg
[02:51:57] <Valen> hardcore!
[02:53:45] <jmkasunich> lordy
[02:54:36] <eric_unterhausen> top gear's space shuttle was better
[02:56:19] <eric_unterhausen> I thought they routinely went higher than that
[02:56:28] <jmkasunich> that thing isn't routine
[02:56:30] <jmkasunich> 1600 lbs
[02:56:49] <eric_unterhausen> big rockets are fairly routine
[02:57:00] <eric_unterhausen> that weight may not be
[02:58:13] <eric_unterhausen> the guy videotaping it did an excellent job
[03:02:26] <eric_unterhausen> has anyone ever taken a jacobs taper chuck off? Should I buy the official wedges?
[03:02:42] <jmkasunich> do you have any unofficial wedges?
[03:02:52] <eric_unterhausen> they are called screwdrivers
[03:02:59] <jmkasunich> I've removed a couple - IIRC, one wasn't bad at all, the other was a mother
[03:03:10] <jmkasunich> I think the 2nd one had been put on with red locktite
[03:03:16] <eric_unterhausen> nice
[03:03:24] <jmkasunich> we wound up cutting the arbor off, turning the chuck around, and boring it out
[03:03:25] <eric_unterhausen> of course it works when you don't want it to work
[03:03:45] <jmkasunich> when there was about 0.005 of arbor left, we started peeling it out of the inside of the hole
[03:04:10] <cradek> open the jaws all the way and look for a hole in the back - you can usually just drive it out with a pin
[03:04:38] <jmkasunich> if there is a hole
[03:04:44] <cradek> or, I made a wedge out of CRS and it has lasted for several removals so far
[03:04:56] <cradek> yes if there is one...
[03:05:09] <jmkasunich> if you have a press, steady pressure on a pin will work better than a hammer
[03:05:09] <eric_unterhausen> bummer, no hole
[03:05:19] <cradek> darn.
[03:05:36] <eric_unterhausen> I suppose the $7 for the wedges probably is not a bad investment
[03:07:46] <eric_unterhausen> I guess the nameless chuck I have is actually an Albrecht, at least it's a real model number
[03:09:06] <eric_unterhausen> ok, that's funny, now that I googled that, I see the Albrecht name engraved on the side
[03:13:40] <eric_unterhausen> two screwdriver method worked fine, don't think it was ever really seated
[03:14:59] <cradek> whoah, it must not have been on right - check for damage
[03:15:14] <eric_unterhausen> I don't think it was ever used
[03:15:22] <eric_unterhausen> or seated
[03:15:31] <cradek> ah, good in your case then!
[03:16:06] <eric_unterhausen> I'll look at the surface though
[03:16:24] <cradek> are you putting it on a new arbor?
[03:16:32] <eric_unterhausen> yes
[03:16:53] <cradek> I like to clean both parts with alcohol to make sure there's no oil
[03:17:06] <eric_unterhausen> that's an idea
[03:17:06] <cradek> also, look for any lint or grit
[03:17:17] <eric_unterhausen> do you do anything special to seat the taper?
[03:17:36] <cradek> just clean carefully, and then whack it with a hammer a few times
[03:18:35] <toastydeath> i used logarithms for the very first time for a real problem today
[03:18:42] <toastydeath> it was bizarre
[03:18:44] <cradek> woo!
[03:18:50] <cradek> did you use a slide rule?
[03:18:52] <eric_unterhausen> now you're special
[03:18:54] <toastydeath> no unfortunately!
[03:19:17] <eric_unterhausen> what was the problem, don't tell me control theory
[03:19:17] <toastydeath> i mean i am kind of a math neophyte, so i didn't think there were many places to use them in the real world
[03:19:40] <toastydeath> no, somebody asked how many fills they could get on their paintball hpa tank from a 3000 psi scuba tank
[03:20:04] <toastydeath> i only work on totally irrelevant and pointless questions.
[03:20:11] <eric_unterhausen> I just learned not to look at my saved orders on McMaster Carr's web site
[03:20:18] <cradek> ha
[03:20:18] <eric_unterhausen> deletes the current order
[03:26:13] <cradek> ouch, I figured you meant that you didn't like to see the totals.
[03:26:32] <eric_unterhausen> yeah, I'm loving that little feature right now
[03:43:09] <Valen> so hows things peoples
[03:43:28] <Valen> oh yeah, and top gears space shuttle didnt actually work
[03:51:01] <Valen> it crashed ;->
[03:51:11] <Valen> (and then they faked the explosion, bastards)
[04:22:37] <eric_unterhausen> space shuttle worked pretty well the way I look at things
[04:22:46] <eric_unterhausen> I figured it was going to blow up on the launch pad
[04:24:55] <toastydeath> much like the real shuttle
[04:25:24] <eric_unterhausen> real shuttle waited for a respectable altitude
[04:28:34] <toastydeath> true
[04:35:31] <toastydeath> i guess i was more decrying the widely reported ramshackle design process around the shuttle
[04:35:39] <toastydeath> turbopumps etc
[04:51:07] <Valen> nothing wrong with turbopumps
[04:52:43] <Valen> on something that size anyway
[04:54:31] <eric_unterhausen> they seem to have had some problems with them though
[04:54:36] <eric_unterhausen> rebuilding them every flight
[04:54:45] <Valen> they do that with the whole shuttle
[04:54:57] <Valen> they replace the entire wiring loom
[04:55:42] <Valen> its not so much "reused" as "refurbished"
[04:56:52] <toastydeath> valen:
[04:56:57] <toastydeath> the pumps were not designed to be wear items.
[04:57:05] <toastydeath> they were designed to last the life of the engine
[04:57:11] <Valen> pretty sure the wiring wasn't either
[04:57:14] <toastydeath> yeah
[04:57:18] <toastydeath> that's what i'm criticizing
[04:58:09] <Valen> hmmm i think you need to critisize the managment without pulling the enginers into it
[04:58:17] <Valen> they turned out a work of art,
[04:58:27] <Valen> given the moving goalposts they were handed
[04:59:12] <toastydeath> considering that we did it before and it worked great on bigger, badder spacecraft
[04:59:23] <eric_unterhausen> the whole thing is stupid
[04:59:27] <toastydeath> i'm not so sure i can grant full amnisty to the engineers
[04:59:28] <eric_unterhausen> rockets are the way to go
[05:00:29] <Valen> it wasn't originally meant to have wings and half the other problems it was lumped with, but the air force said they needed to be able to launch , catch a russian satellite then fly halfway across the country on the way back down and to do it all in one orbit
[05:00:48] <Valen> but in order to sell it they said it would do all that, and do it once a month
[05:01:31] <eric_unterhausen> but they wanted the shuttle
[05:02:10] <Valen> yeah, they wanted something that could do everything
[05:02:13] <Valen> not a truck
[05:02:20] <toastydeath> a series of tubes
[05:02:24] <toastydeath> (sorry)
[05:02:43] <Valen> and now they are screwing themselves over with ares and the return to the moon thing
[05:03:06] <Valen> reusing existing difficult to use stuff
[05:04:00] <toastydeath> poor space program =(
[05:04:31] <Valen> :-<
[05:05:04] <Valen> give armadillo $4bn and they would build your moon base included in the price
[05:05:12] <eric_unterhausen> maybe proving it was a bad idea was worth the cost
[05:05:31] <Valen> give Xcore the same and you get a mars base as well
[05:06:05] <Valen> and you have only spent what has already been spent on the moon project that barley has any hardware and just got chopped from 6 passengers to 4
[05:11:20] <eric_unterhausen> let me google that for you is a brilliant site
[05:11:30] <Valen> lol yeah
[05:11:49] <eric_unterhausen> I've never had a reason to use it though
[05:12:10] <Valen> i think there is also the less polite version
[05:12:19] <Valen> justfuckinggoogleit or something close to that
[05:12:35] <eric_unterhausen> I think lmgtfy is pretty rude
[05:12:44] <eric_unterhausen> which is why I regret never using it :)
[05:18:32] <Valen> i used jfgit
[05:18:39] <Valen> i got in trouble from the mailing list admin ;->
[05:55:36] <toastydeath> i have to go in to college and try to convince someone to strike the grades from two classes from my record
[05:55:47] <toastydeath> hopefully that goes well
[06:43:35] <Poinca348> Poinca348 is now known as Poincare
[07:33:47] <Valen> dammit i wanna go play with my EMC box and get the encoders running but i have to fix a damn software bug
[09:10:28] <piasdom> g'mornin all
[09:21:02] <piasdom> how do i close a program that's frozen ? (won't close)
[09:24:26] <archivist> open terminal
[09:24:39] <piasdom> k
[09:24:43] <archivist> ps -ef|grep progname
[09:25:17] <archivist> kill -p [pid of prog]
[09:25:27] <archivist> oops kill -9 [pid of prog]
[09:25:40] <alex_joni> or killall -9 programname
[09:28:21] <Valen> sudo reboot; programname
[09:28:25] <Valen> muwahahaha
[09:28:30] <Valen> (dont do that one)
[09:29:43] <archivist> sudo kill -9 Valen
[09:29:50] <Valen> ouch
[09:29:53] <alex_joni> /kickban Valen
[09:29:54] <piasdom> hahaha
[09:30:34] <Valen> ahh cmon its only a little worse than telling somebody about alt+F4 as a shortcut to open some kind of easter egg
[09:31:00] <piasdom> i'm tyring to kiil vbox...neither of those working
[09:31:11] <Valen> kill -9 should do it
[09:31:41] <piasdom> how do i get the pid ?
[09:31:44] <alex_joni> "neither of those working" <- pretty useless report
[09:31:56] <Valen> if you run top you can see if something is chewing CPU easily and the first column is the pid
[09:32:14] <Valen> q to quit top
[09:33:05] <piasdom> thanks..top did it
[09:33:32] <Valen> but yeah the more generic one is archivists
[09:33:39] <Valen> things can hang without using CPU
[09:34:10] <Valen> and its best to do a kill PID before a kill -9 PID incase the program can be made to gracefully terminate
[09:35:16] <piasdom> first for me to use kill and top...kill i knew a little about..never heard of top
[09:35:18] <piasdom> thanks all
[09:36:34] <Valen> top is the bomb
[09:37:42] <Valen> on an EMC machine you might be interested in iotop as well to give you an idea of anything doing disk access
[09:40:24] <piasdom> great..thanks Valen
[09:41:28] <Valen> Might wind up making a power controller for this mill conversion
[09:41:56] <Valen> to use those 40A 90V motors
[09:43:35] <Valen> anybody used an OSMC board?
[10:17:56] <Mark_FAPS> hi, is there a guide to making a model in vismach or do I have to make do with the comments in vismach.py?
[10:18:39] <archivist> I think thats all the docs there are at the moment
[10:19:16] <Mark_FAPS> I thought so cos I'd been looking every, thanks anyway
[10:19:21] <archivist> see the various models like hbm...
[10:19:52] <Mark_FAPS> yeah, I trying to figure it out from the existing models at the moment
[10:21:13] <Mark_FAPS> a minimum of the components that you need to get a working file would be quite nice
[10:26:49] <archivist> well you have those as it works :)
[10:28:21] <archivist> time I did one to match my machine
[10:35:31] <Mark_FAPS> hmm, is it enough to just copy the py file into the usr/bin folder or do I have to do more to let hal know where it is?
[10:36:44] <archivist> are you trying to run live rather than sim?
[10:37:04] <Mark_FAPS> I don't quite understand
[10:37:47] <Mark_FAPS> in halrun I'm trying to use the loadusr command
[10:40:40] <Mark_FAPS> I think at the moment I'm failing at creating a simple python-script
[12:50:21] <als> SWPadnos, I filed a feature request yesterday on the max_acceleration and I had a thought that might work, define it as a equation,scaling the acceleration down as the acceleration length increases from said # to said #
[12:50:41] <SWPadnos> it's not simple
[12:51:07] <als> if it was I would do it
[12:52:23] <SWPadnos> heh
[12:52:25] <SWPadnos> me too :)
[12:54:34] <als> I made it sound simple though : )
[12:56:05] <SWPadnos> we discussed the problem somewhat last night, and there are issues with blending (for example, accel must be the same for both the blended segments)
[12:56:58] <skunkworks> smop? ;)
[12:57:03] <SWPadnos> also, the trajectory planner requires that it be able to stop by the end of the current segment, since it doesn't know that there's another one coming. if accel were to be reduced for some reason during a move, that constraint might be violated
[12:57:07] <SWPadnos> hmop
[12:57:25] <SWPadnos> multi/many-segment lookahead might help
[12:58:00] <SWPadnos> but there's a more generic use case for variable accel, and that's for machines where accel limits (and vel limits) might be dependent on the current pose
[12:58:01] <skunkworks> which causes other problems :)
[12:58:10] <SWPadnos> yeah. like I said, it's not simple
[12:59:37] <als> I will read the log from last night
[13:00:01] <SWPadnos> we might have been on the devel channel, I'm not sure
[13:09:45] <Valen> thats a nasty one to do
[13:11:10] <Valen> I wonder if it'd be possible to genericise it as a force/inertia type thing with the bits its attached to having force limits on it
[13:11:46] <SWPadnos> the HAL way would be to make the accel/vel limits input pins to the motion controller, and let some external HAL component decide when and how to change them
[13:11:53] <Valen> although that'd require EMC knowing alot more about your machine than a bunch of axes
[13:12:15] <SWPadnos> it's not independent per joint - you could have one joint that depends on the position of another for its limits
[13:12:46] <SWPadnos> as an example, consider a robot that spins, but has an arm that can be extended
[13:12:52] <Valen> passing the buck gotcha ;-> still probably the only really generic way to do it anything else winds up super complicated to handle all possible use cases
[13:13:07] <SWPadnos> the rotational inertia is higher when the arm is extended, so the rotational axis can't accelerate as fast
[13:13:08] <als> or split it up into top middle bottom of the move ,scale down and up
[13:13:50] <Valen> thats what i was thinking, if EMC knew the mass/inertia of each component in the system, it can work out the forces in the "parent" components put on it by the children and limit them to what the parent can handle
[13:14:35] <SWPadnos> that's one way to do it
[13:14:47] <SWPadnos> though tool changes and work changes would change the inertia
[13:15:02] <SWPadnos> some joints move the work, others move the tool
[13:15:04] <Valen> a simpler example is lifting a box with a 2 jointed arm, if you lift close to the base the force is pretty low, if you lift at the max extend of the arm you have lots of force
[13:15:25] <Valen> thats what i was saying about it putting alot of complexity into EMC
[13:15:26] <SWPadnos> sure
[13:15:40] <SWPadnos> that's why we'd stick it into a separate component ;)
[13:16:00] <archivist> loop limit indicates acceleration loss and peak torque at a joint
[13:16:03] <SWPadnos> similar to the kinematics modules (or part of them), you'd choose the accel model you want
[13:16:12] <Valen> Gut feel is that each "type" of machine would need a seperate module
[13:16:21] <SWPadnos> yeah, like kinematics ...
[13:16:36] <Valen> didn't know it had that lol havent got that far
[13:17:20] <SWPadnos> heh. you can run simple machines like all the other controls, or hexapods, SCARA robots, PUMA robots, and other 4 or 5 axis machines
[13:17:33] <SWPadnos> or more, those are just the ones I remember at the moment
[13:17:43] <Valen> yeah saw the hexapods running on emc
[13:17:50] <Valen> I went "cool" and kept going lol
[13:17:58] <Valen> gotta get mill working first
[13:19:21] <Valen> I'm wondering if an OSMC board can be uprated in terms of voltage to run those 90 volt servos
[13:19:33] <archivist> mine has cut metal this morning
[13:19:48] <Valen> hasn't yours been cutting metal for years?
[13:20:06] <archivist> and shown me I need better curve generation
[13:20:19] <Valen> in terms of hard or software?
[13:20:24] <archivist> software
[13:21:06] <Valen> you roll your own G-Code dont you?
[13:21:37] <archivist> changing parameters to my escape wheel, straightened a curve :((
[13:21:44] <archivist> yup
[13:21:59] <Valen> change it less ;->
[13:22:29] <archivist> I need to get the curve generating maths right
[13:23:06] <Valen> is it the implementation in Gcode or the maths behind it thats the problem?
[13:23:13] <archivist> maths
[13:23:22] <Valen> might be able to help with that
[13:24:11] <Valen> if you want it o course ;->
[13:24:54] <archivist> Im wondering if I should just cheat and use apt
[13:25:27] <Valen> whats apt in terms of cutting metal?
[13:25:41] <Valen> i'm guessing you dont mean the package manager?
[13:28:16] <archivist> collected together here
http://sourceforge.net/projects/aptos
[13:29:24] <Valen> funky
[13:30:56] <als>
[13:31:22] <als>
[13:31:36] <Valen> you need to press keys other than enter man ;->
[13:32:31] <als> screen saver
[13:33:12] <Valen> heh i normally use shift to come out of that, been burnt a few times with it doing some unintended action for most of the other keys
[13:34:07] <skunkworks> alex_joni: aj12 seems to work great. (installed on one - booted on a bunch)
[13:34:17] <als> i was about ready for ctl + alt backspace
[13:34:59] <Valen> I have wound up rebooting computers that havent responded to the keyboard
[13:35:01] <Valen> with the power button
[13:35:14] <archivist> as I did last night
[13:35:15] <Valen> only to realise that the keyboard (wireless) had lost synch
[13:35:49] <archivist> luvely bug that was found in axis last night
[13:36:00] <Valen> oh?
[13:36:42] <als> bug report?
[13:36:56] <archivist> yup open the file open dialog and click the small box for hidden files (not the text)
[13:37:54] <als> is it bad?
[13:38:04] <alex_joni> skunkworks: seems there's a small problem with it
[13:38:12] <Valen> sounds more like a bug in ubuntu/gnome rather than EMC
[13:38:13] <archivist> oh its sorted and presume updates "real soon now" TM
[13:38:16] <alex_joni> can you check: sudo apt-get update (from a terminal) ?
[13:38:27] <alex_joni> skunkworks: it probably will give you a "duplicated entry error"
[13:38:37] <archivist> valen just dont do it :)
[13:38:42] <Valen> lol
[13:38:55] <alex_joni> skunkworks: if you get it check if you have both emc2 in the regular /etc/apt/sources.list and in /etc/apt/sources.list.d/emc2.list
[13:38:57] <Valen> tried it in other similar dialogs?
[13:38:58] <archivist> freezes the kb here
[13:39:14] <archivist> yes
[13:39:32] <Valen> funky bug
[13:39:37] <archivist> look at last nights log in here
[13:39:54] <Valen> I was fixing one in some software i wrote ages ago
[13:40:14] <Valen> turns out it was MD5summing a paticular reccord rather than the record the person was working on
[13:40:38] <archivist> mildly wrong :)
[13:40:42] <Valen> that was all fine until somebody deleted that particular record :-<
[13:41:43] <Valen> caused the program to crash in 3 states
[13:41:48] <Valen> "oops"
[13:44:58] <skunkworks> alex_joni: will do
[13:49:25] <Jon_geo01005> So quick (i hope) question, where can I learn techniques to write fast c++ code, and implement that into python?
[13:50:12] <cradek> if I understand your question, the docs for extending python with c/c++ are here:
http://docs.python.org/extending/
[13:51:02] <Valen> take a look at cython its meant to make doing that kind of thing easier i understand
[13:51:21] <Jon_geo01005> Great, thanks cradek. However I'm also trying to understand how to write code in c++ that is fast...I mean optimize some calculations.
[13:51:48] <Valen> thats harder to give generic advice?
[13:51:53] <cradek> sounds like you should think of that as an entirely separate question: how to write fast C++ in general
[13:52:03] <Jon_geo01005> yeah.
[13:52:08] <Valen> what are you doing that python isnt fast enough for?
[13:52:16] <Valen> and have you tried psyco on it
[13:52:28] <Jon_geo01005> I wrote a geometric constraints solver using python, psyco didn't make it any faster.
[13:52:41] <cradek> writing a fast program is pretty much the same in any language: watch your algorithmic complexity, and if all else fails, profile
[13:53:14] <cradek> if your algorithm is O(n!) you don't have a language-specific problem :-)
[13:53:16] <Valen> psyco should speedup pure algorithmic code dramatically
[13:53:19] <Jon_geo01005> So the slow parts of the code is the actual math.
[13:53:33] <Valen> thats really what its best at
[13:54:16] <archivist> * archivist seen different versions of fast
[13:54:48] <Jon_geo01005> so maybe I can ask a more simple question, will c++ calculate "sqrt(x^2+y^2)" any faster than python?
[13:55:07] <archivist> C
[13:55:18] <archivist> assembler!
[13:55:21] <Valen> possibly but I wouldn't bank on it being by much
[13:55:36] <cradek> Jon_geo01005: use 'hypot'
[13:55:54] <Valen> can you pastebin or something the code in question?
[13:57:02] <Valen> it feels to me like you probably have a looping/function calling issue if your "optimisation" is over something that small
[13:57:18] <cradek> I agree
[13:57:25] <Jon_geo01005> You will have to forgive me. I have never been taught how to optimize code.
[13:57:32] <cradek> maybe your algorithm can be improved
[13:57:39] <Jon_geo01005> I'm sure it can.
[13:57:45] <cradek> how much too slow is it? 2x? 100x? 1000x?
[13:57:56] <Jon_geo01005> maybe 10X
[13:57:58] <Valen> its not really something that can be taught
[13:58:04] <cradek> you might get 2x by switching languages, doubt 10x
[13:58:08] <cradek> Valen: b.s.
[13:58:11] <Valen> its experience and some tricks
[13:58:22] <cradek> it's not magic
[13:58:27] <Valen> you can show somebody how to find slow bits, not how to make them better
[13:58:30] <archivist> nah good techniques can and ar taught
[13:59:01] <cradek> in part, that's why there are CS degrees
[13:59:08] <Valen> I spose, It just seems like something that is really "creative" to me
[13:59:22] <Valen> I spose there are different levels
[13:59:28] <archivist> I moved some code from php and one hour to C in a minute
[13:59:45] <cradek> archivist: haha php
[13:59:54] <archivist> interpreted to compiled is worth a lot
[14:00:00] <Valen> horses for courses ;->
[14:00:11] <Valen> true, but thats not really "optimisation" though is it
[14:00:17] <archivist> python is the interpreted slowness as well
[14:00:31] <Valen> its pretty good in that regard
[14:00:50] <Valen> not as good as C but not "dog slow" ;->
[14:01:08] <archivist> depends on the job I could use function pointers in C but only a kluge in php
[14:01:26] <Valen> I had it processing text files at 40Mb/sec (disk rate limited) on a 2.4Ghz processor
[14:01:36] <Valen> pulling about 60% CPU
[14:02:10] <Valen> stuck psyco on it and dropped that to ~20% or so
[14:02:37] <skunkworks> I once made a machine controller in qbasic. ;)
[14:02:44] <Valen> lol hardcore
[14:03:11] <Jon_geo01005> what pasetbin is best, sorry never used it.
[14:03:19] <cradek> http://pastebin.ca
[14:03:32] <Valen> I saw a guy at my highschool make a program in qbasic that actually directly accessed the frame buffer to draw circles and then to smoothly pan them across the screen
[14:03:40] <crice> To optimize, find your loops, then do ad much pre calculation as you can outside of the loop. Also find things that are calculated more than once inside the loop. Do the calculation once and store the result in a variable and use the variable.
[14:04:27] <Valen> minimise function calls within the loop section as well
[14:04:30] <cradek> crice: true for small speedups, but none of those change the algorithmic complexity
[14:04:45] <Valen> and buffer variables from foo.stuff into local variables
[14:04:45] <archivist> basicly work reduction, especially any repeated work
[14:05:02] <Valen> if its a tight loop the function calls can be a killer
[14:05:04] <crice> They do if you simplify.
[14:06:12] <Jon_geo01005> so I profiled the code and this section takes the most time:
http://pastebin.com/d49ce6a47
[14:06:27] <archivist> I see the algorithmic stupidity in #mysql everyday
[14:06:31] <Jon_geo01005> (pastebin.ca is just a blank page for me)
[14:07:03] <Valen> that should all be pretty fast
[14:07:19] <cradek> Jon_geo01005: we need to know how and why calc() is called
[14:07:21] <crice> in a loop that gets called 1000 times, every instruction that you can remove from the loop saves 1000 instruction. And yes, subroutines are killers because they hide the code. It is good to put a timestamp printf before and after the loop. Then you can see what your changes are doing.
[14:07:28] <Valen> you are using a lot of dotted access
[14:07:54] <archivist> that will be better compiled
[14:08:49] <Jon_geo01005> calc is a member of a line class. it calculated the values needed to constrain lines at an angle, vertical, horizontal and so forth. So that code is run about 1500 times to solve one set of constraints.
[14:08:54] <jepler> on the subject of eliminating function calls to increase performance (as a micro-optimization):
http://emergent.unpy.net/files/sandbox/smalldifference.py
[14:08:57] <skunkworks> http://www.electronicsam.com/images/KandT/xyz.txt
[14:09:11] <Jon_geo01005> those 1500 calls take 50ms of the 93ms for the code.
[14:09:26] <jepler> microoptimizations I'd apply to calc: load self.p1.x and so forth into locals instead of repeatedly writing it out in full
[14:09:31] <Jon_geo01005> is dotted access bad?
[14:09:39] <Valen> it is slower
[14:09:39] <jepler> use hypot(y,x) instead of sqrt(x**2+y**2)
[14:09:58] <Valen> you need to trade that off against the cost of doing the task
[14:09:59] <Jon_geo01005> ok, I have also found a way to eliminate the atan2 call.
[14:10:06] <Valen> that'll help
[14:10:41] <Valen> I'd try unwrapping this function call if its that critical
[14:10:47] <Valen> stick it in the main loop code
[14:11:06] <cradek> before any of these microoptimizations, make sure you really REALLY need to call it all 1500 times
[14:11:42] <Valen> as to the dotted access in that case its 50/50 as to if it'll be a net win, you aren't re-using anything in it that i could see so it could be more costly
[14:11:45] <cradek> all of the things suggested, together, won't give you the 10x speedup you want.
[14:12:05] <jepler> yes, the stuff I'm suggesting will probably be a modest speedup
[14:12:08] <Jon_geo01005> So what I'm really doing is running a non-linear optimization routine to solve a set of non-linear equations.
[14:12:26] <crice> Yes, you can sometimes get speedups you caching the result of a calc, then if the parameters match a previous calc call, just return the previous numbers.
[14:12:35] <Valen> unwrapping it is probably the fastest thing to try
[14:12:40] <Jon_geo01005> the optimization code it's self is about as good as it gets.
[14:12:51] <Jon_geo01005> unwrapping?
[14:12:53] <Valen> easiest thing to try rather
[14:13:04] <Valen> take the code out of the function and stick it into the outer loop
[14:13:52] <Jon_geo01005> Hmm, so going to c++ with these kind of calculations is not going to have lots of imporovement?
[14:13:53] <crice> You can sometimes use the calc to pre compute a table of results and store them in an array. Then just lookup the answer in the array. A lot depends on understanding what the code is doing.
[14:14:23] <Valen> c++ will improve it, but if you need to stick it into an existing python program your not going to get a large benifit
[14:14:59] <Valen> jumping to an external module can be quite expensive
[14:15:39] <Valen> I reckons try the stuff suggested here first it'll probably make quite a bit of difference
[14:15:48] <Valen> do you have the outer loop that this is in?
[14:16:01] <Jon_geo01005> any reason why psyco didn't make this any faster?
[14:16:29] <Valen> at a guess, most of the problem you will be having is getting into and out of the function
[14:16:42] <crice> I am not to well versed in Python, but isn't there a way to pre-interpert the code to byte code to speed it up?
[14:16:55] <Valen> thats done automatically when you run it
[14:17:02] <SWPadnos> heh
[14:17:17] <SWPadnos> that's the point of trying to do it in c++ - pre-interpreting (ie, compiling)
[14:18:08] <SWPadnos> a few more micro-optimizations:
[14:18:23] <Valen> in a loop that tight most of these arent micro ;->
[14:18:25] <Vq^> it's possible to precompile python-code
[14:18:27] <SWPadnos> 1) self.p1.x-self.p2.x (and y) are calculated more than once
[14:18:31] <Jon_geo01005> so is it only with things like string handling that moving to c++ improves performance 50x to 100x?
[14:18:34] <SWPadnos> once to do mag, again when scaling
[14:18:44] <SWPadnos> do that once, put it in a temp
[14:18:46] <Vq^> that's usually what happens when you install python libraries
[14:18:59] <crice> For most languages, converting from byte-code execution to compiled execution will give you a 20 to 200 times improvment. But you lose a lot ease of development.
[14:19:12] <SWPadnos> 2) make mag 1/(what it is now), and multiply by mag when scaling
[14:19:20] <jepler> python execution time doesn't change for byte compiling
[14:19:27] <Vq^> crice: not necessarily
[14:19:31] <jepler> python internally byte compiles everything
[14:19:32] <SWPadnos> there's not a huge speedup there, but I think a multiply is 3 clocks and a divide is 39
[14:19:38] <SWPadnos> or something close to that
[14:19:40] <Vq^> crice: there are a few good languages out there that gives you both
[14:19:48] <Valen> if he caches mag it'll give a boost as well
[14:19:52] <jepler> by using byte-compiled files, which happens implicitly for everything you 'import', you trim a tiny bit of startup time but don't alter run time
[14:21:15] <crice> Vq^: yes, that is true, that is why I said most.
[14:21:48] <Vq^> crice: sorry, missed that little word :)
[14:23:06] <crice> np, you were correct
[14:23:23] <Valen> is ** or ^ faster?
[14:23:30] <Valen> in some languages there is a difference
[14:23:40] <jepler> Valen: ** and ^ perform different functions
[14:23:50] <Vq^> Valen: if we're talking python then they don't do the same thing
[14:23:58] <Valen> * Valen has found a hole
[14:24:01] <Valen> in his knowings
[14:24:18] <Vq^> Valen: ^ is bitwise xor in Python
[14:24:31] <Valen> that would have been confusing
[14:24:45] <Valen> thanks
[14:25:38] <jepler> looks like x*x is faster than x**2: python -mtimeit '2.**2' vs python -mtimeit '2.*2.'
[14:26:36] <Valen> I thaught it might be
[14:26:56] <Valen> i rember in Visual Basic ^ was way slower than *
[14:27:12] <Vq^> sounds reasonable
[14:27:19] <SWPadnos> sure. the POW function likely does a log, multiply, exp sequence
[14:27:29] <SWPadnos> so you get rid of log and exp if you just multiply
[14:27:47] <crice> That is another thing. I am not sure about python, but normally, if you can do it in integer math, it will be much faster than float math.
[14:27:57] <Valen> you have an unhandled case in there too Jon_geo01005:
[14:28:01] <SWPadnos> that's less true these days
[14:28:22] <SWPadnos> the floating point units in modern x86 CPUs are almost the same speed as the integer units
[14:28:35] <Valen> theres more of them too ;->
[14:28:53] <SWPadnos> the main caveat being that the values are larger, and you do need explicit load/unload operations to make the numbers available to the FPU
[14:29:01] <SWPadnos> (larger meaning more bits)
[14:29:05] <crice> Yep, I am over the hill.. :)
[14:29:13] <Vq^> in Haskell ** seems to be faster than ^
[14:29:40] <Vq^> ^ is for integer exponents and ** for floating point types
[14:29:44] <SWPadnos> I still do 8-bit microcontroller work, so I have to deal with that stuff now
[14:29:48] <SWPadnos> but not on a PC any more :)
[14:29:56] <Valen> http://pastebin.com/m7fa8b54e was what i got
[14:30:08] <Valen> just quickly
[14:30:23] <Valen> I am running python on a 200mhz PDA
[14:30:53] <Valen> and i had to roll my own binary search algorithm for a 10Mb text file
[14:31:15] <Valen> rather proud of that ;->, no psyco and i'm getting 10 lookups per second on it
[14:31:34] <Valen> doing an average of 16 jumps within the file
[14:31:48] <Vq^> what architecture?
[14:32:01] <Valen> (not enough memory to stick it into ram, and no compatible databases)
[14:32:04] <Valen> arm i believe
[14:32:27] <Jon_geo01005> Hmm, well I made all those changes and it doesn't seem to help my overall performance.
[14:32:48] <archivist> ew 10 per sec, is that in syrup
[14:33:11] <Jon_geo01005> Is it just the fact that the function is getting called 1500 times, not really the time to perform the calculations that is slowing it down?
[14:33:20] <SWPadnos> could be
[14:33:29] <SWPadnos> do you have 1500 elements that need that processing done?
[14:33:34] <Jon_geo01005> would c++ improve that?
[14:33:43] <archivist> profiling is the only true answer
[14:33:44] <Valen> its in python archivist its not meant to run on 200mhz ARMs
[14:33:45] <SWPadnos> no idea without seeing the caller
[14:34:09] <crice> Did you try the mtimeit before and after the loop that calls calc?
[14:34:24] <Valen> you need to see how long it is taking you to do the calculation and how long its taking to call the function outside it
[14:34:30] <crice> What numbers did you see?
[14:34:47] <Valen> like i said, its pretty easy to just unwrap it and put it into your main code to try
[14:35:05] <SWPadnos> I think cradek mentioned that this code snippet, in isolation, is not enough information to make good recommendations on how to decrease execution time
[14:35:20] <cradek> a few times, yes
[14:35:40] <Valen> thats my lookup code
http://pastebin.com/d634c90c5
[14:35:52] <Valen> its not for "external consumption" so its still pretty messy
[14:36:23] <cradek> IMO everyone is asking/answering the wrong question (how to speed up calc())
[14:36:37] <Valen> unwrapping the "ParseInfoLine" function took execution from 7hz to 12 ;->
[14:37:05] <SWPadnos> the amount of math being performed is tiny, so it's quite obviously not the actual calculations that are the problem (there are only about 20 operations in that function, so even if each one takes 100 clocks, that's 2000 clocks, which should mean you can run the function a million times a second on a 2 GHz CPU)
[14:38:04] <Valen> yeah thats basically the consensus, the problem lies elsewhere
[14:38:06] <Jon_geo01005> So it is quite likely that the problem is in the rest of the program.
[14:38:15] <Valen> paste the calling procedure
[14:38:32] <SWPadnos> it could be the function calls themselves
[14:39:14] <Vq^> Valen: is it a large program?
[14:39:31] <Valen> Vq^: mine?
[14:39:35] <Vq^> Valen: yeah
[14:39:43] <Valen> its a barcode scanner
[14:39:50] <Valen> does an offline stocktake
[14:39:51] <SWPadnos> jeplers "smalldifference" program shows that each function call/loop takes slightly less than 1ms or slightly less than 2 ms (I'm assuming that's for the entire 1000 passes though)
[14:40:13] <archivist> Valen, ooo can I steal your code
[14:40:33] <Valen> that bit or all of it lol?
[14:40:35] <jepler> SWPadnos: right, or around 1us per call
[14:40:47] <Jon_geo01005> http://pastebin.com/m184dfb47
[14:40:49] <SWPadnos> 1 or 2, depending
[14:41:00] <Jon_geo01005> This is the class that calls that functions/
[14:41:09] <archivist> Valen, Im just getting some bits to try a stock/location database for archives
[14:41:10] <Vq^> Valen: what does it do? is there pattern-recognition involved for example?
[14:41:12] <Jon_geo01005> in the setParameters function
[14:41:58] <Jon_geo01005> i.calc()
[14:42:01] <Valen> Vq^: It takes in the barcode, then looks it up in a 10mb text file, and returns the info about the product
[14:42:12] <SWPadnos> Jon_geo01005, try replacing the calc() call on line 57 with a call to a do-nothing function - just calculate a square root or something like jepler did
[14:42:42] <tomp> tomp is now known as tpmp3
[14:42:54] <Valen> archivist, if you at all can a database is the way to go lol, There is a verification function about the same length to make sure that thing works
[14:42:56] <SWPadnos> I suspect you'll find that the iteration over self.lines is the culprit (though I'm not a python expert, so I could get corrected very soon :) )
[14:43:04] <Jon_geo01005> hmm, that is difficult because the number of times the function gets called depends on the values set in the function.
[14:43:25] <archivist> valen databases is my thing :)
[14:43:36] <Vq^> Valen: doesn't sound all that complicated, could be interesting to port it to a language that is easier to compile to native code
[14:43:55] <SWPadnos> in the code you pasted, calc gets called exactly once for each item in self.lines
[14:44:03] <Valen> it was the first real "computing" problem i've needed to solve
[14:44:21] <Valen> I've done all sorts of XMLRPC database and such like things
[14:44:34] <Valen> never anything you would find in a computer science text book
[14:44:38] <skunkworks> looks like the 5i20 sample config works (both init and done led's went off) and axis started.
http://imagebin.ca/img/z0vrLSPy.jpg
[14:46:35] <Valen> archivist did you want the interface more than the back end?
[14:47:01] <archivist> valen slow response from me is Im in #mysql answering questions as well
[14:47:02] <Valen> Jon_geo01005: you seem to be doing alot of repetition in that setParameters function oo
[14:47:07] <Valen> heh
[14:47:18] <Valen> hey heres a question for ya
[14:47:45] <Valen> got a mysql multi master replication thats been running in a split brain mode for ~6 months
[14:47:49] <Valen> now i need to merge
[14:47:52] <Valen> any tips?
[14:48:01] <archivist> ew nasty
[14:48:13] <Valen> currently planning on dumping to files then load data infile, ignore duplicates
[14:48:30] <archivist> I avoid multi master because the application needs to know
[14:48:34] <Valen> and crossing my fingers
[14:48:41] <jepler> fwiw my machine does 1500 calls to o.calc() in 20ms, and with microoptimizations it takes 12ms.
http://emergent.unpy.net/files/sandbox/jg.py
[14:49:18] <Valen> Its mainly a read only work, and its mainly done to reduce the latency for a large group of users in an office
[14:49:42] <Valen> the split was between the office system and the colo system that the interstate people use
[14:50:18] <archivist> you could run some sql to see where problems are
[14:50:30] <jepler> (so for those who are counting, that's 8us per calc_microopt() call, or 1/8 the hypothetical maximum speed SWPadnos suggested)⎋
[14:51:22] <Valen> I was in the process of loading the 2 into seperate databases then for the "dynamic" tables doing an insert into select that checks but i figured the load data infile would be easiest
[14:51:26] <steves_logging> steves_logging is now known as steve_stallings
[14:52:02] <jepler> (oh on rereading I see I misinterpreted swp; it's 800x the theoretical minimum)
[14:52:05] <Valen> hrm I spose i could look to see at what point the replication stopped by seeing when the duplicates end, then look for duplicates after that date
[14:52:26] <Jon_geo01005> SWPadnos: I ran this code
http://pastebin.com/m15068b24, and it took 15 ms.
[14:52:54] <Jon_geo01005> so it is quite likely that all of these function calls are accounting for a large portion of the time.
[14:52:55] <archivist> Valen maatkit has some utilities for replication test/fix
[14:52:58] <Valen> Jon_geo01005: did you try the version i posted?
[14:53:39] <Valen> archivist, looks interesting
[14:55:31] <Jon_geo01005> Valen: with your code, my total time for the solution went from 94ms to 78ms
[14:55:41] <Valen> yay lol
[14:56:20] <Valen> (no guarantee that that code still does what yours did btw ;->)
[14:57:17] <Jon_geo01005> so what happens here is that this function is called once for each line in a sketch, if I had a function that performed the calculations for the whole sketch in one function call that would reduce the total time a great deal?
[14:57:31] <Valen> could quite possibly
[14:57:40] <Valen> but your thinking backwards a little
[14:57:41] <Jon_geo01005> I have lots of functions that are called for each entity in a sketch ;)
[14:58:04] <Jon_geo01005> How so?
[14:58:12] <cradek> do you have any of the form (for each entity (do something to all the other entities))?
[14:58:23] <Valen> you want to get rid of functions not add more lol
[14:58:47] <cradek> do something for each one is linear time O(n), but what I described is square O(n^2)
[14:59:34] <Vq^> Valen: are functioncalls that expensive?
[14:59:56] <Valen> take stuff out of functions and stick it close to the data generation source
[15:00:07] <Valen> they are if you call them 1500 times
[15:00:25] <Valen> and if its more like function a calls b calls c and then stuff actually gets done
[15:00:52] <Jon_geo01005> well so the error in each constraint is a function (mathematically) of the values of the entities in that constraint.
[15:00:57] <Valen> then you have added alot of gumf thats using CPu at the expense of making it easier to read
[15:02:33] <Jon_geo01005> so for a point on point constraint p1.x-p2.x^2+p1.y-p2.y^2 is the error function. This is independent of other constraints. So I don't think there are many things that can be done for all the entities.
[15:03:02] <Jon_geo01005> because their error is based on only a subset of the entities.
[15:03:31] <Valen> what do you mean by constraint?
[15:03:54] <Vq^> doesn't feel right to me to compromise readability in python-code. readability is usually the reason i choose python
[15:04:30] <Valen> if you are limited by performace add comments and white space
[15:05:21] <Vq^> i would switch language instead
[15:05:39] <Jon_geo01005> Valen, this code is part of a geometric constraints solver. It solves for the position of lines, arc, and points that satisfy the constraints of the 2d, or 3d sketch.
[15:06:12] <Valen> pretend i dont know what a "geometric constraints solver" does
[15:06:17] <Valen> or is
[15:06:27] <Vq^> with inline optimisation in the compiler you can still get nice readable code without the drawbacks
[15:06:50] <archivist> HeeksCAD is in desparate need of one :)
[15:07:11] <Valen> its still garbage in garbage out
[15:07:28] <Jon_geo01005> Valen, have you ever used a real 3d parametric CAD package?
[15:07:42] <Jon_geo01005> (MCAD)
[15:07:54] <Valen> played for 20 minutes with solidworks?
[15:08:05] <SWPadnos> I suspect that you would get mich faster execution from a well-crafted c++ program. I don't know how much added complexity that would entail in the housekeeping functions you use elsewhere (like maintaining lists of objects, I/O, etc)
[15:08:06] <Jon_geo01005> did you use the sketches?
[15:08:15] <Valen> nope
[15:08:16] <SWPadnos> s/mich/much/
[15:08:34] <archivist> for cad then c/c++
[15:08:41] <Jon_geo01005> SWPadno: I have started coded it in C++, but I just want to do it right.
[15:08:53] <Valen> SWPadnos: you probably would but if you just write the code in python well it'll work ok
[15:09:10] <SWPadnos> it depends on whether there might be 2500 or 15000 objects later on
[15:09:27] <Valen> ok i think you need to do your work starting at extractparameters
[15:09:57] <Valen> SWPadnos: there are MMPOG's written both client and server in it, so it should be able to handle a bit of number crunching
[15:10:54] <SWPadnos> graphics objects are the textbook case for inheritance, and since there is no interpretation involved in choosing what function to call for a given object (even virtual functions are selected from a table), the direct speedup in code execution should be noticeable
[15:11:30] <SWPadnos> this is of course independent of algorithmic speedup, which would apply for both python and c++ (and is usually the best place to look)
[15:11:51] <Jon_geo01005> Valen: In most commercial CAD packages there is a sketcher that allows you to make lines are arcs and so forth. You can then put constraints on these lines.
[15:12:06] <Valen> he is looping over each object with dotted notation about 8 times by the look of things
[15:12:33] <Valen> and most of those are just wrapping and copying stuff around to go into that calculator
[15:12:51] <Jon_geo01005> So say that you want an arc to be tangent to a line in the sketch. The sketch tool uses a numerical solver to solve for the position of the line and the arc that satisfy all of the constraints.
[15:13:01] <Valen> ahh funky
[15:15:27] <Vq^> im with SWPadnos on that one, choosing a better or improving the algorithm should be the first step
[15:16:50] <Jon_geo01005> Well the method I'm using to solve the problem is by definition a bit inefficient. But it allows for lots of freedom in using the sketches.
[15:17:15] <Valen> give me a few minutes i'll have a look at it
[15:17:22] <Jon_geo01005> I imagine that lots of time in my code is being spent on bad programming methods.
[15:18:43] <Jon_geo01005> So I'm just asking now if somebody has a good resource(book, online, etc.) that I could turn to that will teach me how to code this well in c++
[15:18:47] <Valen> you should add some comments about the place too if your having problems
[15:20:48] <Vq^> Jon_geo01005: are you working on a cad system?
[15:21:46] <Jon_geo01005> I use Unigraphic NX here, but I'm trying to develop this solver for OpenCascade projects like HeeksCad and FreeCad.
[15:22:23] <Vq^> and they are written in C++?
[15:22:24] <archivist> Jon_geo01005, there is a solver in another package I saw the other day
[15:23:47] <Jon_geo01005> Vq^:C++ and python.
[15:24:07] <Jon_geo01005> archivist: What package was that?
[15:24:29] <archivist> heh /me checked logs the one you pointed me at :)
[15:24:57] <Jon_geo01005> yeah, sketchflat?
[15:25:03] <archivist> yup
[15:25:34] <Jon_geo01005> You may call me crazy, but I think it has some limitations.
[15:25:45] <archivist> it probably has
[15:26:16] <archivist> * archivist wants gear mates like solidworks
[15:26:17] <Jon_geo01005> The way his solver works it artificially removes some degrees of freedom from the sketch.
[15:26:24] <Valen> Jon_geo01005: in your code where does p1.x come from?
[15:27:57] <Valen> in the calc function you are using it as self.p1.x but i cant see where you are setting that
[15:27:58] <Jon_geo01005> p1 is an instance of the point object. Here are the entity class definitions :
http://pastebin.com/m5347f45e
[15:29:03] <Jon_geo01005> archivist: All the 3d constraints, can be expressed as combinations of 2d constraints. I think even the gear mate.
[15:29:35] <archivist> Jon_geo01005, probably as thats just a rotation about an axis
[15:32:41] <Valen> bah dinner is almost ready i dont have time to finish it
[15:33:14] <Valen> Jon_geo01005 what you need to do is to get rid of all the loops you are doing manipulating your points data
[15:33:38] <Jon_geo01005> Valen: thanks, I'll plan on doing that in the c++ version.
[15:33:41] <Valen> up in extractParameters you have all the information you need
[15:34:12] <Valen> just copy the calc function into there and change the variables it uses to directly access them one at a time
[15:34:21] <Valen> I'll wager you hit 40ms with it
[15:34:23] <Valen> or better
[15:35:57] <Valen> so you should have only one loop (and another for the circles)
[15:36:12] <Valen> and have that loop directly spit out totalerror
[15:37:35] <archivist> actually mod algorithms to cut loop qty would be best, cut and remove ops as errors get near 0
[15:38:00] <Valen> Jon_geo01005: knowing your own code it should only take a few minutes to try it
[15:39:11] <Jon_geo01005> Valen:I think that the changes you note may change the operation of the program, But I'll use the ideas you mention where I can.
[15:39:40] <JymmmEMC> WooHoo ebay is down!!!
http://ebay.com/
[15:40:05] <Valen> the program is the same
[15:40:17] <Valen> or it should be, your just not copying data around
[15:41:33] <steve_stallings> steve_stallings is now known as steves_logging
[15:44:02] <Valen> JymmmEMC up for me just slow
[15:48:56] <archivist> werks for me ebay.co.uk
[16:07:12] <JymmmEMC> No, that SPECIFIC link is down, just thought it was funny.
[16:07:43] <JymmmEMC> Oh damn, they fixed it.
[16:13:40] <JymmmEMC> http://www.insidebayarea.com/ci_12245969?source=most_emailed
[17:05:39] <A4ndy_> on old days... i made a card with decoder on it connect to 8255 ...PARALEL with memmory & Processor Z80
[17:06:11] <A4ndy_> is it possible in pc today with DDR2...
[17:06:56] <A4ndy_> old days using 8255 ... what is it on today? South-bridges? what kind of type ic is this
[17:07:07] <A4ndy_> ?
[17:07:11] <A4ndy_> :>
[17:10:16] <archivist> kinda hard these days as layout is critical as speed
[17:14:39] <skunkworks> robot bulders banaza book had a circuit that I think used the 8255 interfaced to an isa slot. Always wanted to build one.
[17:15:17] <SWPadnos> that's a heck of a lot easier than interfacing to a PCI slot
[17:15:23] <skunkworks> I bet
[17:15:37] <A4ndy_> :)
[17:15:39] <SWPadnos> I wouldn't even start trying to make an I/O card that sits in a DDR/DDR2/DDR3 socket
[17:15:44] <SWPadnos> but that is an interesting idea :)
[17:16:08] <skunkworks> that would literally be memory mapped i/o? ;)
[17:16:12] <archivist> not a lot of latency in a ddr slot
[17:16:13] <SWPadnos> yep
[17:16:17] <SWPadnos> nope
[17:16:18] <A4ndy_> is fpga speedy enough?
[17:16:20] <SWPadnos> yep
[17:16:28] <SWPadnos> well, speedy enough for what?
[17:16:30] <SWPadnos> and which FPGA?
[17:17:32] <A4ndy_> dont know... that the new ic i never been touch? came in my mind?
[17:17:50] <A4ndy_> xilinx?
[17:17:58] <A4ndy_> spartan?
[17:18:08] <SWPadnos> spartans have been around for a decade or more
[17:18:23] <SWPadnos> (though there are new versions regularly)
[17:18:43] <A4ndy_> any suggestion? perhaps?
[17:18:44] <skunkworks> it would be cheaper to buy a mesa card :)
http://imagebin.ca/img/z0vrLSPy.jpg
[17:19:13] <SWPadnos> yep.
http://mesanet.com/
[17:19:19] <A4ndy_> ... mesa, ill go check
[17:19:34] <jensor> Just tried to update to 2.3 and now axis won't start
[17:19:35] <SWPadnos> $200 and up for a PCI FPGA
[17:19:51] <SWPadnos> jensor, using your own config, or one of the samples?
[17:20:17] <jensor> I followed the instructions on updating to 2.3 in the wiki
[17:20:29] <SWPadnos> that doesn't answer my question
[17:20:59] <SWPadnos> did you also follow the instructions/advice here?
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UPDATING#Changes_between_2_2_x_and_2_3_x
[17:21:08] <jensor> I am using my own config
[17:21:12] <SWPadnos> ok
[17:21:14] <SWPadnos> thanks :)
[17:21:14] <jensor> yes
[17:21:20] <SWPadnos> hmmm
[17:21:36] <SWPadnos> go to a terminal, run emc, put the output on
http://pastebin.ca
[17:22:13] <SWPadnos> what hardware are you using?
[17:22:18] <jensor> I have posted my results on
http://pastebin.com/d8a178c
[17:22:21] <SWPadnos> ok
[17:22:30] <A4ndy_> mesa good, mesa using spartan...in the picture... :)
[17:22:59] <A4ndy_> run on PCI? Atom?
[17:23:54] <A4ndy_> and where is the harddrive?
[17:23:57] <A4ndy_> :)
[17:24:39] <skunkworks> A4ndy_ yes. you can just see a corner of the hardrive in the lower right of the picutre.
[17:24:52] <A4ndy_> oh, its not connected already ..i see, very prety
[17:25:07] <A4ndy_> big picture
[17:25:29] <skunkworks> the red sata cable is visable also
[17:25:33] <SWPadnos> jensor, look at line 509 in your pastebin, and then look at section 1.7 of the UPDATING wiki page
[17:25:46] <A4ndy_> how much it cost for this mesa?
[17:26:12] <skunkworks> what you see is $200
[17:26:18] <A4ndy_> the mesa card, what type is it
[17:26:22] <SWPadnos> http://wwwmesanet.com/prices.html (I think)
[17:26:24] <skunkworks> 5I20
[17:26:49] <skunkworks> 72 i/0
[17:27:29] <A4ndy_> nice one..
[17:27:40] <skunkworks> i/o eve
[17:27:41] <skunkworks> even
[17:27:48] <SWPadnos> or I/O
[17:27:48] <A4ndy_> ill go check other mesa
[17:28:10] <SWPadnos> the 5i21 is a little more expensive, but has a faster chip with twice as many gates
[17:28:12] <SWPadnos> if that interests you
[17:28:18] <SWPadnos> ($229 instead of $199)
[17:28:45] <jensor> SWPadnos I know I can fix that. I assumed that the update would automatically chage my config files. I'll chage that and see if that does the trick
[17:29:06] <SWPadnos> nope. configs are never ever changed automatically (at least not by us :) )
[17:29:11] <skunkworks> heh - no - the update will not change your configs. That gets scary.
[17:29:14] <Valen> that way lies madness
[17:29:41] <SWPadnos> we should make some sort of conversion tool, but it would only be able to do simple things
[17:30:07] <skunkworks> The developers have more important things to do :)
[17:30:16] <Valen> oh well bed time for me
[17:30:20] <Valen> catchyas all later
[17:30:22] <skunkworks> night
[17:30:33] <skunkworks> LawrenceG: any smoke?
[17:33:23] <A4ndy_> mesa great, could made stuff easier... has open source driver?
[17:33:47] <A4ndy_> (could connect to emc linux... mean yes right)
[17:34:10] <Valen> mesa is integrated into EMC
[17:34:21] <Valen> they work well togther
[17:34:58] <jensor> SWPadnos, I fixed the pin name change and that seems to have resolved the axis start up problem.
[17:35:11] <SWPadnos> excellent
[17:35:33] <jensor> thanks
[17:36:42] <A4ndy_> i found this:
http://sourceforge.net/projects/rt-com/
[17:37:44] <A4ndy_> linux now is complete
[17:38:00] <A4ndy_> ,,, next GUI to go
[17:41:09] <A4ndy_> base on prety linux today, it is not impossible... rather then vista / longhorn? 20GB bad;
[17:42:07] <A4ndy_> :)
[17:42:43] <A4ndy_> thanxs every one, ill go surf now.
[17:55:06] <jensor> 2.3 changed axis acceleration and deceleration when jogging drastically. Should that happen?
[17:55:45] <SWPadnos> do you have accel limits set in your ini file?
[17:56:03] <jensor> I'll have a look at that
[17:56:03] <SWPadnos> for each joint, not just in the TRAJ section
[17:56:05] <SWPadnos> ok
[17:56:53] <SWPadnos> as far as I know, the motion planner used for jogging will only use limits set per axis in the ini file. I know there have been some discussions about jogging recently, but I'm not sure if they're relevant
[17:57:05] <SWPadnos> (I think they were related to the hostmot2 driver)
[17:59:28] <jensor> Yes they are set and worked fine in 2.3. When I try to home an axis it begins very slowly and gradually gains speed over a 10 sec period or so, then when it hits a limit it begins decelerating at the same rate it accelerated at
[17:59:51] <jensor> consequently it over runs the lim it
[18:00:20] <jensor> This is on a bridgeport mill
[18:00:37] <SWPadnos> homing and jogging aren't the same thing. are there two problems?
[18:00:44] <jensor> yes
[18:00:54] <jensor> joggin g actr s same as homin g
[18:01:00] <SWPadnos> ok. can you pastebin your ini file please?
[18:01:06] <jensor> ok
[18:01:19] <SWPadnos> before and after, if you still have the 2.2.x version aroung
[18:01:20] <SWPadnos> d
[18:03:25] <jensor> SWPadnos,
http://pastebin.com/d743e1c30
[18:03:43] <jensor> I haven't changed it between versions
[18:03:57] <jensor> I'll see if I have an earlier version
[18:03:57] <SWPadnos> ok, the ini didn't change, only some tweaks to the HAL file?
[18:04:09] <SWPadnos> no need, if there are no changes, that's all I need to know
[18:06:05] <jensor> Only change was the pin name change in a hal file
[18:12:15] <cradek> [TRAJ] DEFAULT_ACCELERATION = .0167
[18:13:08] <jensor> That never gave a problem in 2.2.8
[18:13:18] <jensor> like I have now
[18:14:31] <cradek> from the 2.3.0 changelog: * honor [TRAJ]'s ACCELERATION settings when jogging/homing
[18:14:46] <jensor> how does one deterine what the default accel should be?
[18:14:52] <cradek> you should always read the changelog. we also send that information along with the release notification.
[18:15:14] <cradek> jensor: I think the right thing for a trivkins machine is to just comment out those ACCEL and VEL settings in the TRAJ section
[18:16:15] <jensor> I did read the log and this is all I saw
[18:16:17] <jensor> n 2.3, you must home all axes before issuing MDI commands or running part programs. This setting can be reverted to the 2.2 behavior by the inifile setting [TRAJ]NO_FORCE_HOMING = 1. For users of the mini GUI, this setting may be required.
[18:17:23] <jensor> I read this in the kn owledge base
[18:17:49] <cradek> ok, you just missed it - the thing I pasted is from the changelog
[18:18:05] <cradek> anyway, that's your problem, .0167 in/sec2 is a crazy acceleration.
[18:18:18] <jensor> sure is
[18:20:32] <jensor> anyway you mention a trivkins machine - What is a trivkens machine?
[18:21:01] <cradek> one where the axes correspond 1:1 to the joints
[18:21:10] <jensor> ok
[18:21:19] <cradek> like a regular mill where there are three orthogonal joints that move as X,Y,Z
[18:24:45] <jensor> I commented out the default acc and vel in the [TRAJ] sectioon. Works fine now!
[18:24:51] <cradek> yay
[18:25:07] <cradek> do I remember correctly that you are using an STG card?
[18:25:22] <jensor> par port
[18:25:49] <cradek> oh ok
[18:25:57] <cradek> must be someone else I'm thinking of.
[18:26:51] <jensor> By the way if you jlook at the the ini file I posted, see if you can determine why I can't get it to open axis with another ngc file
[18:28:55] <jensor> http://pastebin.com/d743e1c30
[18:30:19] <jensor> It works with another ngc file now
[18:30:23] <cradek> not sure - the [DISPLAY] OPEN_FILE version should work.
[18:30:32] <jensor> it didn't in 2.2.8
[18:30:34] <SWPadnos> or [DISPLAY]AXIS_OPEN_FILE
[18:30:45] <cradek> SWPadnos: that is incorrect
[18:30:49] <SWPadnos> oh, that's an environment variable
[18:31:28] <SWPadnos> jensor, one thing to keep in mind - Linux is case sensitive
[18:31:51] <jensor> I kn ow - I've been burned before
[18:31:56] <SWPadnos> heh
[18:33:07] <jepler> [DISPLAY]OPEN_FILE works for me in TRUNK. But when I specified a slightly incorrect path (ncfiles instead of nc_files), it didn't give any indication of problem -- it just didn't load a file at all
[18:33:19] <cradek> he said it's working now
[18:33:22] <jepler> oh!
[18:33:24] <jepler> it's magic then
[18:34:01] <jensor> no its not working - it comes up and says no file
[18:34:29] <jensor> I thought it was working when it didn't bomb ot like before 2.3
[18:34:54] <jensor> The path is correct in the ini file
[18:35:29] <cradek> oh, sorry, I misread
[18:37:50] <jensor> In 2.2.8 it wold bomb out and the log would indicate it couldn't find the file. Now it comes up and says "no file"
[18:40:40] <jepler> huh
[18:40:41] <jepler> OPEN_FILE = /users/jepler/emc2-src/nc_files/flowsnake.ngc
[18:40:44] <jepler> ^^ this is what I tried
[18:41:19] <jepler> and it did work
[18:43:02] <jepler> if you "ls -l " followed by that exact string (use cut & paste) does it show the file or say it is not found?
[18:47:29] <jensor> jepler, My fault- File wasn't where I thought it was - works fine now
[19:32:22] <jensor> Where do I find a description of the new buttons on the axis display in 2.3
[19:32:32] <alex_joni> documentation ;)
[19:32:54] <jensor> I searched the knowledge base
[19:33:17] <jensor> now I'll look at the docs
[19:33:25] <cradek> what's new?
[19:33:56] <alex_joni> I think there's a button for pan/tilt
[19:34:04] <cradek> ah
[19:34:12] <jensor> 2 buttons to right of abort
[19:34:28] <cradek> heh, I've been using it so long, I don't remember.
[19:34:28] <alex_joni> ah, the optional stop
[19:34:35] <cradek> oh, optional stop and block delete?
[19:34:40] <alex_joni> and block delete
[19:34:56] <cradek> and optional stop
[19:35:04] <Optic> and block delete!
[19:35:11] <alex_joni> optional block delete?
[19:35:30] <archivist> and ermmmmm optional erm STOP
[19:35:43] <Optic> what's an optional stop?
[19:36:07] <alex_joni> what does it sound like?
[19:36:16] <alex_joni> a stop that is optional :D
[19:36:22] <jepler> and ruthless efficiency
[19:36:33] <Optic> so you request emc to optionally stop your job, and if it feels like it, it will?
[19:36:41] <alex_joni> you program a M1 in the g-code, if optional stop is on it stops at the M1, if not it will just pass over it
[19:36:42] <archivist> less mandatory than emergency stop
[19:36:52] <Optic> haha
[19:37:03] <Optic> alex: oh, kinda of like a breakpoint
[19:37:04] <alex_joni> not sure about the M1, but the docs should have the exact Mxx number
[19:37:14] <cradek> yes M1 (it's on the icon)
[19:37:18] <alex_joni> same goes for block delete
[19:37:24] <alex_joni> for lines with / before them
[19:37:24] <cradek> 'a convenient place to stop'
[19:38:57] <jensor> docs call it an optional pause
[19:39:15] <Optic> but different from a manual tool change?
[19:39:22] <Optic> i guess that will always stop
[19:52:39] <jensor> Does skip lines with / , mean that you can prefix a line of gcode with a / and if that function is toggled "on" it will skip that line?
[19:52:48] <cradek> yes exactly
[19:52:51] <jensor> ok
[19:53:05] <jensor> that clarifys it
[19:53:06] <cradek> flip it while the AXIS preview is loaded and you will see the behavior
[19:53:17] <jensor> ok
[20:22:04] <jensor> I am confused now it wants me to home when I bring it up. I thought it stored that info in the var file from the last homing
[20:23:43] <archivist> thats one of the changes......you did read about the changes
[20:24:08] <jensor> yes
[20:24:12] <cradek> jensor: you pasted information about the relevant change earlier
[20:26:16] <jensor> if I do the [TRAJ] NO_FORCE_HOMING=1 will it revert to the previous way of reading the var info on startup?
[20:28:17] <jensor> It looks like the info indicates that it does
[20:28:26] <cradek> home position is not saved in the var file, but coordinate system offsets are. homing puts all the coordinate systems in their proper place on your machine at once.
[20:28:48] <cradek> when EMC starts, it doesn't know the position of the machine: that's what homing establishes
[20:29:08] <jensor> Oh, I thought that it stored that info
[20:29:33] <archivist> how can it see you move the table while off
[20:29:48] <cradek> well it can save joint positions which should be approximately right upon restart. these do not go into the var file though, they go into the position file.
[20:29:56] <jensor> and it was up to the user to realize whether he needs to home again
[20:30:02] <cradek> but archivist is certainly correct about moving the machine.
[20:30:19] <cradek> it will almost always move "a little bit" by itself when turned off.
[20:30:40] <jensor> I've wondered about that
[20:31:15] <archivist> anything with steppers WILL move a bit
[20:31:25] <cradek> also, anything with servos WILL move a bit :-)
[20:31:50] <cradek> steppers will probably often move most of a step
[20:32:03] <cradek> microstep drives certainly will
[20:32:29] <archivist> only thing that can possibly know where it is at switch on ....has absolute encoders
[20:33:01] <archivist> encoders/scales
[20:37:16] <jensor> But a small movement while off isn't a big deal unless one is going to approach limits
[20:37:40] <cradek> that might be true for your particular setup, but in general is not true.
[20:38:28] <jensor> I understand that
[20:39:55] <cradek> I love how I can turn on my lathe, home it, and then have it cut correct diameters with all the mounted tools... it is running to exactly the same encoder count as last time
[20:40:54] <archivist> I wish I could tool change with accuracy so I could
[20:41:24] <cradek> some quick change tool posts are better than others
[20:41:37] <alex_joni> hmm.. does using a position file "rehome" the machine ?
[20:41:42] <cradek> no
[20:42:03] <archivist> round shaft mounted tools in morse 2 collets here
[20:42:11] <alex_joni> that might be useful for some machines without switches though
[20:42:22] <alex_joni> although G28 ? then home should do it too
[20:42:32] <cradek> true (both)
[20:42:39] <cradek> not sure how it should work ideally.
[20:43:03] <cradek> seems bad for it to start up "homed" when it really isn't
[20:43:23] <alex_joni> although I suspect someone with that setup can set up so home isn't required
[20:43:31] <cradek> also true
[20:57:04] <jensor> I notice on the machie menu a un-home option is available. But I could not find any pins that provide at function in the HAL configuration
[20:58:04] <jensor> provide that functtion i meant to say
[20:58:06] <cradek> true, I don't think halui knows how to unhome
[20:58:57] <jensor> Gee, just when I thought I could set up a remote home all switch.
[20:59:37] <cradek> halui can home one joint at a time. it does not know how to home all, and it does not know how to unhome.
[21:00:31] <cradek> currently know how :-)
[21:00:53] <jensor> why can't I connect the home signal to all the necessary pins?
[21:01:12] <cradek> I bet you could
[21:01:24] <jensor> then home all
[21:01:31] <cradek> it won't start them all at *exactly* the same time, like a real "home all" would
[21:01:46] <cradek> but that only matters for uncommon setups.
[21:02:11] <jensor> Do you mean it would only do it sequentually
[21:02:39] <cradek> no, it would do them at approximately the same time.
[21:02:48] <cradek> try it and let us know!
[21:03:52] <jensor> ok thats what i want. However , I would have to unhome z first to guarentee it is 1st to home before the others
[21:04:20] <cradek> brb
[21:04:37] <skinnypup_> I need to update my laptop emc version built sim mode from source. How do I properly remove a tar compiled version before compiling 2.3?
[21:05:07] <alex_joni> skinnypup_: that's a pita..
[21:05:22] <alex_joni> but you should export DESTDIR from your shell to a temp location
[21:05:22] <jepler> if you don't use a package manager, you should use --enable-run-in-place
[21:05:27] <alex_joni> then do the make install again
[21:05:34] <jepler> we don't supply "make uninstall" because it's needless duplication of what package management systems like deb do
[21:05:43] <alex_joni> you'll see then what files get installed where
[21:05:51] <alex_joni> but as jepler said, run in place is probably best
[21:06:23] <alex_joni> if you do insist on installing it yourself, there is a utility (makeinstall ? or something like that) that builds a simple deb from the make install results
[21:06:54] <jepler> if you 'make install DESTDIR=/tmp/emc2-install-root', then /tmp/emc2-install-root contains all the same files installed
[21:07:02] <alex_joni> checkinstall it's called
[21:07:11] <jepler> bbl
[21:07:15] <alex_joni> http://www.falkotimme.com/howtos/checkinstall/
[21:07:33] <skinnypup_> Thanks guys, lappy is just for sim-mode when i'm not in garrage mode
[21:08:14] <alex_joni> skinnypup_: you do know there are sim packages.. right?
[21:08:32] <skinnypup_> .debs ?
[21:08:45] <alex_joni> yup
[21:09:07] <alex_joni> http://www.linuxcnc.org/hardy/dists/hardy/emc2.3-sim/
[21:09:08] <skinnypup_> had no clue, intended to build from tarball
[21:09:25] <alex_joni> http://www.linuxcnc.org/hardy/emc2-install-sim.sh
[21:09:31] <skinnypup_> alex_joni, Thanks man !
[21:10:03] <alex_joni> skinnypup_: sure thing ;)
[21:45:58] <dmess> http://www.toshibamachine.ca/Tools_BTD-200QH.shtml
[21:48:29] <pjm__> archivist u here?
[21:48:35] <archivist> yup
[21:48:41] <pjm__> have had some DX tonite!
[21:48:56] <pjm__> 3226445.28 miles on 32.166GHz
[21:49:35] <archivist> a fair distance then
[21:50:17] <archivist> * archivist does not believe the .28 bit
[21:50:44] <pjm__> hahh ok its further away now ;-)
[21:51:26] <pjm__> btw its the first time a ham station has copied 32GHz from a deep space satellite
[21:52:07] <archivist> I wonders what you were getting it from/to
[21:52:19] <archivist> which one
[21:54:08] <archivist> I bet it moved more than .28 during the period you were getting signals
[21:55:19] <pjm__> its the Kepler space craft
[21:55:47] <pjm__> its moving at 1.2418566Km per second currently
[21:55:54] <pjm__> (approx)
[21:58:06] <archivist> ish plus or minus a bit
[23:38:04] <JymmmEMC> wth is at 32GHz?
[23:38:35] <JymmmEMC> it sure aint phone
