#emc | Logs for 2006-09-05

[00:00:56] <davidf> halcmd show pin
[00:01:17] <davidf> sorry, wrong keyboard! heh
[00:39:01] <tomp> g'nite all
[00:39:03] <tomp> .part
[01:36:17] <Twingy> gcam is 6 - 8 weeks away from a beta
[02:10:17] <dan_falck> Twingy: cool
[02:20:20] <CIA-8> 03jepler 07HEAD * 10emc2/src/Makefile.modinc.in: not all of the correct RTFLAGS were being used to compile external modules. Lead to insmod errors like 'Unknown symbol __subsf3'
[02:40:13] <Twingy> will keep you posted
[03:36:55] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/rtapi/rtapi.h: wrong type - string module params are called 'charp' (char pointer), not string
[04:21:40] <SWPadnos> hey fenn, long time no see
[04:21:52] <fenn> ya i had too many projects going
[04:22:09] <SWPadnos> I know the feeling
[04:22:22] <fenn> someone's asking me about bending steel plates for a submarine, so i was wondering if rugludallur still hangs out here
[04:22:46] <SWPadnos> I haven't seen him in a while, but I haven't been on continuously
[04:32:56] <A-L-P-H-A> anyone got suggestions for running a linear system for 9ft x 5ft?
[04:33:13] <A-L-P-H-A> I'm thinking of using what jymmm suggested the other day... using 8020.net extrusions.
[04:33:16] <SWPadnos> get big linear components
[04:33:30] <A-L-P-H-A> they claim to have some stuff, that doesn't flex, and can be used with sliding pads.
[04:33:49] <SWPadnos> they actually have a flex calculator, I think
[04:33:54] <A-L-P-H-A> i used it.
[04:33:57] <A-L-P-H-A> it's flex is minute.
[04:34:11] <SWPadnos> you'd need to use some of their largest stuff to get good machining tolerances (0.001 or so)
[04:34:15] <A-L-P-H-A> like .009" at themiddle of 9ft.
[04:34:30] <SWPadnos> sounds like a lot, unles syou're only through cutting
[04:34:52] <A-L-P-H-A> I wonder if I beef it up from underneither, would that be good enough?
[04:35:03] <A-L-P-H-A> like put box tubing + shims under it.
[04:35:15] <A-L-P-H-A> box tubing + shims = cheap.
[04:35:25] <SWPadnos> you'd want to support it at several locations - that'll cut down the beam length in those calcs
[04:35:31] <jmkasunich> you mostly worried about vertical loads?
[04:35:36] <jmkasunich> use a membrane
[04:35:42] <A-L-P-H-A> what's a membrane?
[04:35:49] <A-L-P-H-A> in terms of machining/machines
[04:35:55] <jmkasunich> piece of 1/8" thick aluminum sheet
[04:36:05] <jmkasunich> make it 1 foot tall and 9 feet long
[04:36:32] <jmkasunich> put an 8020 at the top and bottom, and its like the web if an I bean
[04:36:34] <jmkasunich> beam
[04:36:41] <jmkasunich> much stiff (vertically)
[04:36:43] <A-L-P-H-A> oooh.
[04:36:49] <A-L-P-H-A> I see.
[04:37:15] <jmkasunich> you might even be able to use thinner
[04:37:35] <A-L-P-H-A> so I'd need to drill a few dozen holes, to bolt to the 8020 to that 'membrane'
[04:37:42] <jmkasunich> yeah
[04:37:49] <jmkasunich> holes in the sheet
[04:37:52] <A-L-P-H-A> why would I need two?
[04:37:53] <jmkasunich> the 8020 already has slots
[04:38:03] <A-L-P-H-A> why would i need to 8020?
[04:38:13] <jmkasunich> you might not need one on the bottom
[04:38:16] <SWPadnos> top and bottom, to keep the flat sheet from buckling
[04:38:19] <A-L-P-H-A> couldn't I use like a box tube on the bottom, if I did need one?
[04:38:26] <jmkasunich> could do something cheaper on the bottom
[04:38:29] <jmkasunich> like angle or box
[04:38:53] <A-L-P-H-A> or get them to put a fold in the 1/8" sheet.
[04:38:58] <jmkasunich> yeah
[04:39:01] <A-L-P-H-A> that'd stiffen it up super.
[04:40:33] <A-L-P-H-A> but that kind of messes up the extrusion if I wanted to use it as a as a linear slide... using their method of three pads, that clamp over top of the sides and top of the extrusion.
[04:40:56] <jmkasunich> ?
[04:41:05] <jmkasunich> the slide covers the top and both sides?
[04:41:12] <A-L-P-H-A> let me find that.
[04:41:15] <jmkasunich> there's a slot in the bottom, right?
[04:41:16] <SWPadnos> no it doesn't - you can have screws inside the slot
[04:41:38] <SWPadnos> screw in top slot, through center tube, into edge of flat sheet
[04:41:45] <SWPadnos> though you'd need to use a thicker sheet
[04:41:54] <SWPadnos> (the slot can take a 1/4 sheet)
[04:41:57] <jmkasunich> that would get heavy/expensive
[04:42:02] <SWPadnos> yep
[04:42:27] <SWPadnos> with the added advantage that it would work ;)
[04:42:50] <jmkasunich> anybody have a URL handy with the 8020 profile?
[04:43:00] <SWPadnos> www.8020.net I think
[04:43:41] <jmkasunich> but which profile
[04:43:44] <SWPadnos> http://www.8020.net/T-Slot-4.asp
[04:43:55] <SWPadnos> 1010 or 2020, I'd bet
[04:44:38] <A-L-P-H-A> instead of this sheet?? should I just use an angle iron instead already?
[04:44:44] <A-L-P-H-A> should=couldn't
[04:44:55] <jmkasunich> the strength of the sheet comes from its width
[04:45:01] <SWPadnos> structural steel isn't all that smooth
[04:45:38] <jmkasunich> if the slides are 8020, the reinforcement should also be aluminum
[04:45:47] <jmkasunich> (sheet, angle, box, whatever - just use alum)
[04:45:59] <jmkasunich> otherwise when temperature changes it will warp
[04:46:19] <A-L-P-H-A> 9' length of 3"x4" angel, isn't THAT expensive.. but epensive enough, if I get it in like 1/8" to 1/4".
[04:47:25] <jmkasunich> is this the slide: http://www.8020.net/Images/Application-Thumb-106.jpg
[04:47:32] <A-L-P-H-A> I'm lookin at their 6833 and 6834 products... they're linear bearings (plastic slide mechanisms)
[04:47:48] <A-L-P-H-A> jmkasunich, pretty much the same product.
[04:48:18] <A-L-P-H-A> this guy actually http://8020linearmotion.com/images/6823%20Photo.jpg
[04:48:30] <SWPadnos> note that those are basically delrin slides, *not* rolling bearings
[04:48:34] <A-L-P-H-A> http://8020linearmotion.com/images/6834%20Photo.jpg
[04:48:43] <A-L-P-H-A> they call them linear bearings, but you're right
[04:48:51] <A-L-P-H-A> http://8020linearmotion.com/images/6834%20Photo.jpg <-- that's the model I'm looking at.
[04:48:57] <jmkasunich> if your speeds permit, thats ok
[04:49:12] <A-L-P-H-A> I don't even know what the hell my speed limits will be.
[04:49:14] <SWPadnos> the surface isn't smooth - it's a textured anodized aluminum
[04:49:21] <jmkasunich> any particular reason you are using the double wide rail>
[04:49:23] <jmkasunich> ?
[04:49:25] <SWPadnos> not a deep texture, but not smooth
[04:49:34] <A-L-P-H-A> I want to go like 200 ipm... with like say a ballscrew with 1TPI, or maybe a 2TPI.
[04:49:46] <A-L-P-H-A> jmkasunich, it was for deflection.
[04:50:12] <jmkasunich> laying flat like that, its probably twice as strong side to side as vertically
[04:50:50] <SWPadnos> alomst exactly, I'd say ;)
[04:50:55] <A-L-P-H-A> this is going to probably be a 3/4" x 0.5TPI ballscrew.
[04:51:15] <jmkasunich> how heavy is the load?
[04:51:26] <A-L-P-H-A> my budget is something like $1500CDN for the frame of the machine... then get the motors, ballscrews etc.
[04:51:50] <jmkasunich> http://www.8020.net/Images/Application-106.jpg
[04:52:07] <jmkasunich> if you orient the slides like that, one side of the rail is free
[04:52:13] <A-L-P-H-A> jmkasunich, 1" plexiglass, thin sheetmetal + aluminium sheets (engraving, slight milling), 3" Max MDF.
[04:52:26] <jmkasunich> can fasten a vertical sheet to it for stiffener
[04:52:27] <A-L-P-H-A> I figured the system to be 100lbs.
[04:52:39] <jmkasunich> the moving gantry part?
[04:52:43] <A-L-P-H-A> ye
[04:52:44] <A-L-P-H-A> yes
[04:53:00] <A-L-P-H-A> i want to put a router on there, as well as eventually a plasma cutter.
[04:53:18] <jmkasunich> gonna need interchangable table tops then
[04:53:24] <A-L-P-H-A> yup.
[04:53:56] <A-L-P-H-A> I'll probably have like 1" thick MDF board, for anythign non-metal.
[04:54:01] <A-L-P-H-A> and slats for plasma.
[04:54:09] <jmkasunich> if you orient your X rails like that photo I linked, you can install both stiffener sheets and aluminum angles on the inside faces of the rails
[04:54:27] <jmkasunich> the angles (horizontal leg down) give you a ledge to fasten your table to
[04:54:42] <jmkasunich> and stiffen it somewhat for side loads
[04:54:55] <jmkasunich> the sheets stiffen it a lot for vertical loads
[04:55:18] <A-L-P-H-A> I'll need to see how fast these slides can go as well.
[04:55:36] <A-L-P-H-A> but I see your suggestion, and understand the reinforcement of the angle
[04:56:07] <A-L-P-H-A> want this machine to be mainly cabinets, and plexiglass signs.
[05:02:31] <jmkasunich> dual screws for the X?
[05:02:41] <A-L-P-H-A> single probably in the middle...
[05:02:51] <jmkasunich> above or under?
[05:02:52] <A-L-P-H-A> you think it'll skew?
[05:02:54] <A-L-P-H-A> under
[05:03:04] <A-L-P-H-A> near the same plane as the slides
[05:03:09] <A-L-P-H-A> keeping this low profile as well.
[05:03:22] <jmkasunich> how you gonna keep the plasma crap off it
[05:03:48] <A-L-P-H-A> overhead cover plate. let me find, or draw a schematic.
[05:03:54] <jmkasunich> and yes, it will skew
[05:04:00] <jmkasunich> unless the slides are long
[05:04:03] <A-L-P-H-A> poooh
[05:04:21] <jmkasunich> what level of accuracy are you aiming for?
[05:04:45] <A-L-P-H-A> in the Z, GOOD... in the x/y 1mm accuracy.
[05:04:56] <jmkasunich> hmm
[05:05:17] <jmkasunich> how heavy are the loads gonna be in x/y ?
[05:05:48] <A-L-P-H-A> shouldn't be that much... I'm going to be making signs, and milling MDF essentially.
[05:05:53] <A-L-P-H-A> the plasma was for shits and giggles.
[05:06:02] <jmkasunich> I wonder if you can use rack and pinion, or even toothbelt for X and drive both sides
[05:06:20] <A-L-P-H-A> hmm... I completely forgot about rack and pinion.
[05:06:28] <A-L-P-H-A> R&P is a great idea.
[05:06:41] <jmkasunich> run a cross shaft, pinion on each end, and skew is a thing of the past
[05:07:04] <jmkasunich> mount the rack with teeth down to avoid dust
[05:07:25] <A-L-P-H-A> so, like train track rails... but instead of smooth, it's R&P on both sides.
[05:07:34] <jmkasunich> ?
[05:07:52] <SWPadnos> like gear train rails
[05:07:54] <A-L-P-H-A> rack and pinion on both sides, but the gears are connected by one shaft
[05:07:58] <jmkasunich> yes
[05:08:09] <A-L-P-H-A> love it... nice simple idea.
[05:08:18] <jmkasunich> that means the X motor is on the gantry, but thats not too much of a problem
[05:08:22] <jmkasunich> might even be an advantage
[05:08:34] <jmkasunich> put the drivers there too - minimal motor lead length
[05:08:41] <A-L-P-H-A> nice.
[05:08:43] <jmkasunich> send power and step/dir to the gantry
[05:09:11] <A-L-P-H-A> might even be cheaper to do it R&P.
[05:09:15] <A-L-P-H-A> probably is.
[05:10:05] <A-L-P-H-A> I'll price out R&P stuff...
[05:10:19] <jmkasunich> do a 3:1 or 4:1 toothbelt reduction from motor to driveshaft (also solves the problem of needing shafts on both ends of the motor if you drive direct
[05:10:46] <jmkasunich> X motor near one end, Y near the other, to balance the weight
[05:12:07] <A-L-P-H-A> 6gt length is $50USD. would need like 18ft of it, or so, for the whole machine
[05:12:34] <jmkasunich> lots cheaper than ballscress
[05:12:35] <A-L-P-H-A> I was thinking geat in the middle of the axel, and a box to house the motor near it.
[05:12:42] <A-L-P-H-A> LOTS cheaper.
[05:12:53] <A-L-P-H-A> $150 for lengths, 32pitch.
[05:13:03] <jmkasunich> that works too, (but make sure that stuff doesn't interefere with Y travel
[05:13:07] <A-L-P-H-A> the two gears are only $10 each
[05:13:21] <A-L-P-H-A> the box would be under the table support.
[05:13:25] <jmkasunich> what size racks?
[05:13:50] <A-L-P-H-A> oh, width is shit. 3/16, I didn't read that.
[05:13:56] <A-L-P-H-A> I think I would want at elast 1/2"
[05:14:01] <jmkasunich> you looking at mcmaster?
[05:14:03] <jmkasunich> (I am)
[05:14:04] <A-L-P-H-A> yeah.
[05:14:30] <A-L-P-H-A> part number 6295K124
[05:14:37] <A-L-P-H-A> x3
[05:14:40] <jmkasunich> 16 pitch, 1/2" hi, 1/2" wide, 6 ft long, $61
[05:14:55] <A-L-P-H-A> exactly that.
[05:15:13] <jmkasunich> the splice isn't to much of a problem - you use a short length of rack to align the two pieces
[05:15:36] <jmkasunich> depending on your shop capabilities, you might want to consider the predrilled ones lower on the page
[05:16:24] <jmkasunich> an extra $15 per rail - hard to drill em yourself for that
[05:16:34] <jmkasunich> but only 4 foot lengths
[05:17:23] <A-L-P-H-A> yeah. I'd do the pre drilled.
[05:17:40] <A-L-P-H-A> think I could get away with mounting that stuff to say a an angle iron?
[05:18:02] <jmkasunich> angle iron is really crufty stuff
[05:18:08] <A-L-P-H-A> oh. sweet.
[05:18:08] <jmkasunich> the sides aren't parallel or anything
[05:18:22] <jmkasunich> aluminum angle is a lot nicer and should work OK
[05:18:33] <A-L-P-H-A> I have it here in Canada, local, no shipping. for cheaper numbers than mcmaster.
[05:19:33] <jmkasunich> hmm, 20 pitch racks are cheaper
[05:19:42] <jmkasunich> duh, 20 degree pressure angle
[05:19:45] <jmkasunich> still 16 pitch
[05:22:23] <A-L-P-H-A> how about cold rolled steel plate? [straight enough?]
[05:22:45] <jmkasunich> hard to say
[05:22:50] <A-L-P-H-A> cause then I could just have the machine's down weight to keep itself down... and have the plate as straight guides.
[05:22:56] <jmkasunich> you need to decide what your rails are gonna be
[05:23:04] <jmkasunich> then figure out what to mount them to
[05:23:50] <jmkasunich> even a plate 3/8" thick by 6" wide is pretty flexible the flat way if its 9 feet long
[05:23:55] <jmkasunich> geometry is your frient
[05:23:58] <jmkasunich> friend
[05:24:10] <A-L-P-H-A> nono... it's be like crap... let me get drawboard up.
[05:24:17] <jmkasunich> arrange it so that forces are trying to bend wide flat things the hard way
[05:28:15] <A-L-P-H-A> jmkasunich, did you get my pm?
[05:29:04] <jmkasunich> oops, not paying attention
[05:29:19] <jmkasunich> if thats what I think it is, my browser's not gonna like it
[05:29:25] <jmkasunich> trying, but no result yet
[05:30:20] <A-L-P-H-A> sec
[05:30:59] <A-L-P-H-A> does work?
[05:31:14] <A-L-P-H-A> yeah it should...
[05:31:24] <A-L-P-H-A> should autoload
[05:31:30] <SWPadnos> doesn't look likeit, unless it's dial-up ;)
[05:31:30] <jmkasunich> I'm getting nothing on either url
[05:31:39] <SWPadnos> nope - connection refused
[05:31:52] <A-L-P-H-A> nothing on either urls. oddddd.
[05:33:21] <A-L-P-H-4> err.
[05:33:25] <A-L-P-H-4> this is messed up.
[05:33:29] <A-L-P-H-4> I have the DMZ setup.
[05:33:35] <A-L-P-H-4> and it's drawn... but you guys can't connect.
[05:33:37] <A-L-P-H-4> odd...
[05:33:52] <SWPadnos> no matter - I'm too tired to pay attention
[05:34:00] <A-L-P-H-4> doesn't give you "hello"?
[05:34:15] <jmkasunich> gives me nada
[05:34:24] <jmkasunich> I'm tired too, about to head for bed
[05:34:24] <SWPadnos> zip
[05:34:51] <A-L-P-H-4> okay. night guys
[05:34:57] <SWPadnos> see ya
[05:36:02] <A-L-P-H-4> A-L-P-H-4 is now known as A-L-P-H-A
[05:41:04] <A-L-P-H-A> SWPadnos, jmkasunich, you guys still around?
[05:41:09] <A-L-P-H-A> I think I fixed it...
[05:41:53] <SWPadnos> I get the hello now
[05:42:05] <A-L-P-H-A> should autoload now
[05:42:21] <jmkasunich> "click here to download plugin"
[05:42:22] <SWPadnos> yep
[05:42:28] <A-L-P-H-A> you don't have java?
[05:42:37] <SWPadnos> I got the drawboard (I have java on Windows here)
[05:42:42] <A-L-P-H-A> :)
[05:42:47] <A-L-P-H-A> do you get my picture?
[05:43:11] <SWPadnos> mostly. what's the blue on top? (a gantry?)
[05:43:21] <A-L-P-H-A> yeah, the gantry
[05:43:52] <jmkasunich> java crap doesn't want to work
[05:43:53] <jmkasunich> fsck it
[05:43:59] <A-L-P-H-A> jmkasunich. :(
[05:44:10] <A-L-P-H-A> want a screen shot instead? :)
[05:45:15] <jmkasunich> sure
[05:46:32] <A-L-P-H-A> test
[05:46:36] <A-L-P-H-A> am I still here?
[05:46:41] <SWPadnos> no
[05:46:45] <A-L-P-H-A> I am... okau
[05:46:52] <A-L-P-H-A> windows decided to go into standby
[05:47:13] <SWPadnos> http://www.cncgear.com/images/ALPHA-drawing.jpg
[05:47:27] <A-L-P-H-A> SWPadnos, thanks! you're much quicker.
[05:47:39] <SWPadnos> heh
[05:47:53] <A-L-P-H-A> I don't even have photoshop/gimp installed.
[05:48:08] <jmkasunich> I see bearings for side-to-side, but not vertical
[05:48:21] <A-L-P-H-A> the vert should be taken care of by the weight of the system.
[05:48:24] <A-L-P-H-A> no?
[05:48:34] <SWPadnos> you probably don't want to be scraping alongthat way
[05:48:44] <jmkasunich> what holds _up_ the weight?
[05:49:20] <A-L-P-H-A> the pinions... and maybe another beating on the angle iron, from the top to support it from toppling
[05:49:22] <jmkasunich> are you planning to use the R/P as a wheel to hold up the weight?
[05:49:29] <A-L-P-H-A> yeah
[05:49:30] <A-L-P-H-A> I was.
[05:49:38] <jmkasunich> two provblems:
[05:49:56] <jmkasunich> 1) that like a car with only one axle, inherently unstable
[05:50:11] <jmkasunich> 2) rack and pinion wants a fixed center distance, not pressed together with weight
[05:50:20] <jmkasunich> more wear, and bumpy up/down motion as you move
[05:50:20] <A-L-P-H-A> oh.
[05:50:45] <jmkasunich> 3) with gearteeth up, rack will fill with dust, pinion will pack it in
[05:51:54] <jmkasunich> also, rolling bearings don't like dirt/dust either
[05:52:19] <jmkasunich> the bearings for side-to-side load are less of a problem, because most but not all dust will fall clear
[05:52:32] <jmkasunich> but the ones the support the weight will be riding over dirt
[05:52:47] <jmkasunich> which will eventually make the axis rather lumpy and mess up your Z accuracy
[05:52:58] <A-L-P-H-A> hmm.
[05:53:11] <jmkasunich> one nice thing about slides vs bearings is that slides push dust out of the way
[05:53:36] <jmkasunich> wheels or ball bearings roll over it and squish it into the track surface
[05:54:18] <A-L-P-H-A> suggestions?
[05:54:30] <A-L-P-H-A> dust covers, or something of the like.
[05:56:22] <A-L-P-H-A> maybe go for the 8020 slides still, mount to angle iron and plate?
[05:56:30] <jmkasunich> I'd be tempted to try something like bronze on drill rod
[05:56:43] <jmkasunich> or delrin on drill rod maybe
[05:56:45] <A-L-P-H-A> what thickness?
[05:56:55] <jmkasunich> that takes math, and its too late at night
[05:57:12] <A-L-P-H-A> 1/2" I know is too flexible.
[05:57:19] <jmkasunich> ideally you would use open bearings so the rod can be support over its length
[05:57:30] <jmkasunich> if its unsupported, even 1" is to flexible
[05:57:52] <jmkasunich> but supported, 3/4 or maybe even 1/2 would work
[05:58:14] <A-L-P-H-A> support rails... argh. expensive, and don't have continuous lengths of that side.
[05:59:12] <jmkasunich> how heavy is the carriage gonna be compared to the cutting forces?
[06:01:06] <jmkasunich> hmm, mcmaster sells some of the 8020 slides
[06:01:34] <jmkasunich> not cheap - one slide is $75
[06:01:37] <A-L-P-H-A> I'm thinking that the total force is not going to be more then 100N... and even then, that's shit load.
[06:01:40] <jmkasunich> 370 lbs
[06:01:43] <A-L-P-H-A> that's like 25N more than my weight.
[06:02:08] <A-L-P-H-A> I have absolutely no clue what I'd be expecting in weight.
[06:02:15] <A-L-P-H-A> it will be only soft materials.
[06:02:27] <jmkasunich> start with X, Y, and Z motors
[06:02:44] <jmkasunich> add Y screw, X pinion shaft, Y rails, the entire Z axis, and the router
[06:02:53] <jmkasunich> I bet 100 lbs easy
[06:02:57] <A-L-P-H-A> like MDF, wood, and plexiglass... maybe some engraving in alu.
[06:03:10] <A-L-P-H-A> I figured 100lbs, but i gave it 75N = 75Kg.
[06:03:15] <A-L-P-H-A> that'd be about 150lbs.
[06:04:13] <jmkasunich> Mcmaster says the higher strength (about $15 more) guide blocks are suitable for higher speed stuff like pick and place and parts transfer
[06:04:20] <jmkasunich> so maybe speed is OK with those
[06:05:05] <jmkasunich> 8020 1.5" square rails, $66 for ten feet
[06:05:30] <A-L-P-H-A> that's not too expensive.
[06:05:34] <A-L-P-H-A> but the slides are. dang.
[06:05:51] <jmkasunich> 6" long slides to fit are $87, need 4
[06:06:18] <jmkasunich> could use the 2.7" long ones, $70
[06:06:21] <A-L-P-H-A> 4? per axis?
[06:06:27] <jmkasunich> 4 for X
[06:06:38] <jmkasunich> how long is Y gonna be?
[06:07:05] <jmkasunich> might use something different if its shorter
[06:07:20] <A-L-P-H-A> y = 5ft
[06:07:41] <A-L-P-H-A> I'm looking at the iglide J material... from igus
[06:08:00] <jmkasunich> I'm going to bed ;-)
[06:08:09] <A-L-P-H-A> jmkasunich, thanks for the input.
[06:08:33] <A-L-P-H-A> something like thist. http://www.igus.com/show_dw.asp
[06:18:15] <A-L-P-H-A> http://www.igus.com/dwflash.asp
[06:56:41] <alex_joni> morning
[08:37:22] <Guest968> hello everybody
[08:38:51] <Guest968> What is it : "HAL: Error : pin 'motion.spindle-incr-speed' not found"
[08:42:36] <Guest968> then , good bye, talk you later
[08:57:26] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[12:25:26] <pier> hi all!
[12:25:50] <pier> I have a question about gpg
[12:26:26] <pier> getting the key to install emc on a breezy badger
[12:27:27] <pier> I browsed the web trying to find out to make it work behind a proxy
[12:27:57] <pier> but with no success
[12:28:30] <pier> Could anyone give me advice about this? Thanks
[12:37:40] <jepler> pier: get this file http://emergent.unpy.net/files/sandbox/key.txt
[12:38:00] <jepler> pier: then, in a terminal, change to the folder where you put key.txt and run: sudo apt-key add - < key.txt
[12:41:48] <jepler> then comment out the lines about gpg in emc2-install.sh and run it again
[12:52:24] <pier> thanks jepler
[12:54:49] <jepler> you're welcome. I hope it lets you complete the install now.
[12:54:55] <pier> I'll have to do that tomorrow from school lab... irc isn't working too so in the morning I can't have access to the channel (and your help)
[12:57:26] <pier> I am going to set a nice new cnc router to make my students to practice with G-code under linux
[12:57:54] <jepler> it sounds interesting
[12:58:26] <pier> before accessing the bridgeport machine (not as cheap as the little new baby toy) :)
[12:59:23] <jepler> I remember being confused by g-code the first time I ever saw it
[13:01:17] <pier> me too... I lernt how to use hidenhein language set on the Bridgeport milling machine we have at school
[13:01:52] <acemi> I get this message when configuring emc2:
[13:01:54] <acemi> checking for LyX version... 1.4.1
[13:01:54] <acemi> configure: WARNING: LyX version != 1.3.x, documentation will not be built
[13:02:56] <pier> so with plenty of handy functions it is hard to make all the writing without them on another machine
[13:04:25] <jepler> acemi: yes, jmkasunich determined that there are problems if some people developing the docs use lyx 1.4 and others use 1.3.
[13:04:42] <jepler> I don't know the details, but it looks like that configure test is doing its job properly.
[13:05:22] <acemi> hmm
[13:05:24] <alex_joni> jepler: the only problem is that files opened with 1.4.x will be converted automatically
[13:05:35] <alex_joni> and they _cannot_ be opened by 1.3.x afterwards
[13:06:48] <A-L-P-H-A> wuzzup?
[13:07:40] <jepler> bbl
[13:26:57] <acemi> in Debian Sarge, when I use lyx / lyx-qt /lyx-common 1.4.1, I get the above message and I can't build the documents; when using version 1.3.2-4, configure is stopped by "There were errors during the LaTeX run" after the command:/usr/bin/lyx-qt --export pdf2 ../docs/src/Master_HAL.lyx
[13:49:22] <jepler> is this the problem that goes away when you remove the line about 'hyperref'?
[13:50:29] <acemi> the first problem is solved after removing hyperref but i egt another error message later
[13:54:35] <jepler> looks like this will make lyx print the latex errors to the terminal (among a lot of other information): /usr/bin/lyx-qt -dbg 128 --export pdf2 ../docs/src/Master_User.lyx
[13:55:40] <acemi> one min, I must to instal 1.3.2 again
[13:56:06] <jepler> or just use --disable-build-documentation so you can get a working emc2 and use the online version of the docs...
[13:57:12] <acemi> to build emc is not a problem with me, i can built it after changing LYX version line in configure. I only want to inform you
[13:58:01] <jepler> I appreciate it, but so far I don't have enough information to fix anything
[13:58:03] <acemi> after changing this line to 1.4, there is no problem for me
[13:58:52] <acemi> ok, I'll try to give you more details
[13:59:59] <acemi> can you build emc2 wtih documentation in Ubuntu now?
[14:00:04] <jepler> yes it works just fine
[14:00:11] <acemi> hmm
[14:00:13] <jepler> ii lyx-qt 1.3.6-1ubuntu4 High Level Word Processor - Qt frontend
[14:00:42] <acemi> hmm, lyx in debian is 1.3.2
[14:03:26] <acemi> why is the lyx version of the build machine problem? if I can build it with version 1.4, configure has not to prevent to build.
[14:03:57] <jepler> because we expect that most people who will want to build the documentation also want to develop the documentation.
[14:04:23] <jepler> but if they develop the documentation with 1.4.x it apparently makes the files not loadable on 1.3.x
[14:05:36] <acemi> but to limit the configure file isn't the right way I think
[14:09:35] <jepler> I wish jmkasunich was around, I'd like to get his opinion.
[14:10:37] <jmkasunich> who, me?
[14:10:44] <jepler> hi jmkasunich
[14:11:04] <jepler> can you read back to about an hour ago when acemi and I started talking about the documentation build?
[14:11:04] <cradek> hey the holiday was _yesterday_
[14:11:17] <jmkasunich> I'm on vacation this week
[14:11:24] <jepler> lucky you!
[14:11:27] <SWPadnos> uh-oh
[14:11:37] <cradek> what's vacation?
[14:11:48] <jmkasunich> that thing I don't do often enough
[14:12:17] <SWPadnos> it's when you get in a car and drive 20 hours or so to get to a warehouse in an Illinois field, where you can pay with big machinery ;)
[14:12:22] <jmkasunich> this isnt a real vacation - not a day job, but working on other stuff
[14:12:25] <SWPadnos> s/pay/play/
[14:12:50] <jmkasunich> not _at_ day job
[14:13:01] <jmkasunich> anyway... lyx
[14:13:16] <jmkasunich> I suppose building docs with Lyx 1.4 is ok
[14:13:28] <jmkasunich> just don't ever save the lyx files with it
[14:15:26] <jepler> until we have more information, should we also make configure blacklist lyx 1.3.2 and older?
[14:15:38] <jmkasunich> I guess
[14:15:50] <jmkasunich> I wonder what it is about 1.3.2 that doesn't work
[14:16:33] <jmkasunich> it might not be lyx itself, might be latex2pdf or one of the other utilities
[14:17:36] <jepler> that's true
[14:17:54] <jepler> but if I understand acemi right, the only package he's changing is lyx from 1.3.2 to 1.4.x
[14:18:06] <jmkasunich> ok, thats good data
[14:20:30] <acemi> I installed lyx, latex2html (and depending packages) from sarge-backports. wtih this configuration there is no problem. when I change lyx, lyx-qt and lyx-common to 1.3.2, problem starts
[14:26:21] <jepler> I've revised the configure test, I guess I'll check it in so that acemi can test it
[14:26:48] <jepler> it's supposed to: refuse to build the docs on 1.3.x older than breezy, and warn if using 1.4 that it's not suitable for editing the documentation.
[14:27:26] <jmkasunich> sounds good
[14:27:46] <jmkasunich> I don't have 1.4 on the farm, but I can check the config output for the other case
[14:28:11] <CIA-8> 03jepler 07HEAD * 10emc2/src/ (configure configure.in):
[14:28:11] <CIA-8> acemi reports that debian sarge's lyx 1.3.2 does not build the documentation
[14:28:11] <CIA-8> correctly. require 1.3.6, which is the version on debian breezy.
[14:28:11] <CIA-8> he also reports that debian sarge's lyx 1.4 does build the documentation.
[14:28:11] <CIA-8> permit it, but warn that the documentation should not be edited with lyx 1.4.
[14:28:51] <jepler> so 1.3.6, 1.3.7, 1.4.1, and 2.77.33 should all be acceptable lyx versions now
[14:41:08] <cradek> ii lyx 1.3.7-0ubuntu4 High Level Word Processor
[14:41:48] <cradek> oh I didn't read the screen, sorry
[14:41:54] <jepler> is that dapper?
[14:41:57] <cradek> yes
[14:43:42] <jepler> unless I screwed up the configure test it should be fine
[14:43:55] <cradek> checking for LyX version... 1.3.7
[14:44:00] <cradek> checking for latex2html... none
[14:44:00] <cradek> configure: WARNING: no latex2html, documentation will not be built
[14:44:17] <cradek> and their mirrors aren't responding again.
[14:46:39] <jepler> I remember back when ubuntu had fast servers all the time
[14:47:01] <cradek> so far, the uk servers always work when the us don't
[14:47:31] <jmkasunich> perhaps the servers are as fast as ever, but popularity as increased the load
[14:48:20] <cradek> wow, I'm getting a LOT of output building docs
[14:48:29] <jmkasunich> yeah, its noisy
[14:52:01] <CIA-8> 03cradek 07HEAD * 10emc2/src/Makefile: make clean should clean docs too
[14:53:42] <alex_joni> hi all
[14:53:46] <cradek> hi alex
[14:53:48] <alex_joni> I see you're busy already :)
[14:54:44] <alex_joni> * alex_joni hates going through backup files :(
[14:55:02] <alex_joni> unpacking a 1.5G tar.gz is not fun
[14:55:24] <cradek> * cradek bites his tongue
[14:55:51] <jmkasunich> I wonder if assigning a float goes thru the FPU
[14:56:03] <alex_joni> cradek: what can I say.. I work with what I have :(
[14:56:06] <jepler> jmkasunich: I think the answer is 'maybe'
[14:56:15] <jmkasunich> thats what I think too
[14:56:32] <alex_joni> jepler: I think it's 'sometimes'
[14:56:37] <jmkasunich> bummer - that means the streamer HAL function needs to be tagged as using FP
[14:56:37] <alex_joni> depending on some factors
[14:57:06] <jepler> jmkasunich: you could use slightly-inappropriate casts instead
[14:57:08] <jmkasunich> actually, I can see if the user is streaming float data, and if not skip that tag
[14:57:40] <jmkasunich> I've already got more casts in this code than I like
[14:58:01] <SWPadnos> I think moving a float doesn't use the FPU
[14:58:05] <jmkasunich> its amazing what messy webs you can weave with pointers
[14:58:07] <SWPadnos> a double or ext may
[14:59:10] <jmkasunich> I'm gonna play it safe
[14:59:25] <SWPadnos> you could always look at the generated assembly code
[14:59:25] <jmkasunich> _if_ the user is streaming float data, I'll tag the function as FP
[14:59:39] <jmkasunich> yeah, that works for microcontrollers
[14:59:43] <jmkasunich> not for Linux
[15:00:00] <alex_joni> machine code?
[15:00:01] <jmkasunich> where the next compiler version, or the next brand of CPU, will be completely differnet
[15:00:06] <SWPadnos> that shuold be safe, and won't incur any penalty, since the generator of the float data is very likely to be tagged as using float anyway
[15:00:13] <jmkasunich> exactly
[15:00:15] <cradek> or optimization flags
[15:00:46] <jmkasunich> what would really suck is if gcc decides to be clever and uses the FPU to copy non-float data
[15:01:03] <SWPadnos> I think we looked at this way back when, when Paul was complaining that a float store isn't atomic
[15:01:05] <alex_joni> I don't think it does that
[15:01:28] <alex_joni> jmkasunich: we do have 386 in the kernel, and the code produced by gcc should run on any 386
[15:01:38] <alex_joni> even one without FPU
[15:01:51] <jepler> doubt it
[15:02:09] <jmkasunich> any modern compiler issues FPU instructions
[15:02:11] <SWPadnos> it should use FP emulation if no FPU is present
[15:02:19] <jmkasunich> right
[15:02:21] <jepler> there's no FP emulation for kernel space
[15:02:31] <jmkasunich> right
[15:02:33] <SWPadnos> there's not supposed to be FP for kernel space ;)
[15:02:44] <jmkasunich> but I really can imagine anyone using EMC on a 386SX
[15:02:48] <jmkasunich> in fact, they can't
[15:02:55] <alex_joni> no time thingie
[15:02:56] <SWPadnos> a 386 DX has no FPU
[15:02:57] <jmkasunich> the lack of RDTSC will stop them
[15:04:17] <jmkasunich> I wonder what error code is appropriate for 'failed to export a hal pin'?
[15:04:20] <jmkasunich> -EIO?
[15:04:27] <jmkasunich> -EINVAL?
[15:04:36] <cradek> what causes that failure?
[15:04:48] <jmkasunich> most likely causes of failure: already exists, out of shared memory
[15:04:59] <jmkasunich> gotta look at hal_lib to see what others there might be
[15:05:09] <SWPadnos> -EINVAL if already exists, -ENOMEM if out of memory ...
[15:05:41] <jmkasunich> * jmkasunich puts the lid back on the pandora's box
[15:05:53] <cradek> -EEXIST for "already exists"
[15:05:59] <jmkasunich> (hal_lib does not use E codes, it uses some I made up in my foolish younger days)
[15:06:36] <cradek> I opened that box briefly too, at fest
[15:06:59] <jmkasunich> maybe I should actually fix it
[15:07:01] <cradek> I changed 1e6 return values only to find that 1e9 more of them remained, so I gave up
[15:08:07] <jmkasunich> only 131 instances of "return HAL_<foo>" in hal_lib.c
[15:09:01] <jmkasunich> here are the codes I used:
[15:09:03] <cradek> it seems to me I got about four layers deep before I gave up
[15:09:10] <jmkasunich> #define HAL_UNSUP -1/* function not supported */
[15:09:10] <jmkasunich> #define HAL_BADVAR -2/* duplicate or not-found variable name */
[15:09:10] <jmkasunich> #define HAL_INVAL -3/* invalid argument */
[15:09:10] <jmkasunich> #define HAL_NOMEM -4/* not enough memory */
[15:09:10] <jmkasunich> #define HAL_LIMIT -5/* resource limit reached */
[15:09:11] <jmkasunich> #define HAL_PERM -6/* permission denied */
[15:09:13] <jmkasunich> #define HAL_BUSY -7/* resource is busy or locked */
[15:09:15] <jmkasunich> #define HAL_NOTFND -8/* object not found */
[15:09:17] <jmkasunich> #define HAL_FAIL -9/* operation failed */
[15:09:24] <jmkasunich> INVAL = EINVAL
[15:09:31] <jmkasunich> NOMEM = ENOMEM
[15:09:37] <jmkasunich> PERM = EPERM?
[15:10:10] <SWPadnos> I think there's a problem at the next level up though - almost everything returns -1 when there's a failure (such as module loading)
[15:10:27] <SWPadnos> I think some work was done on that, but I don't remember the specifics
[15:10:32] <jmkasunich> baby steps...
[15:10:39] <SWPadnos> treu
[15:10:42] <SWPadnos> err - true
[15:10:52] <jmkasunich> if I fix hal_lib, then it returns decent values, even if higher level code doesn't pass them up
[15:11:06] <jmkasunich> and newer higher level code will pass them up
[15:11:55] <jmkasunich> UNSUP = ENOTSUP
[15:13:02] <jmkasunich> LIMIT = ?
[15:13:05] <alex_joni> BADVAR = EEXIST ?
[15:13:22] <jmkasunich> that one needs to be split I think
[15:13:25] <alex_joni> LIMIT = ENOMEM ?
[15:13:36] <jmkasunich> it can be duplicate or non-existent, depending on the context
[15:13:58] <jmkasunich> for LIMIT, I'm thinking ENOSPC
[15:14:23] <jmkasunich> its not a memory issue, more like "I allocated space for 20 of these, and you just asked for number 21"
[15:15:30] <alex_joni> sounds good enough
[15:19:58] <alex_joni> jmkasunich: if you come up with some small directions, I can help parse through the other modules & components
[15:26:41] <jmkasunich> I decided to finish one thing at a time
[15:26:53] <jmkasunich> the RT part of the streamer seems to be working
[15:26:57] <jmkasunich> now gotta do the user part
[15:27:09] <jmkasunich> once both work, I'll move on to return codes before I start the sampler
[15:28:15] <alex_joni> ok..
[15:32:35] <jepler> what's 'sampler'?
[15:33:25] <jmkasunich> streamer reads lines like "3 4 12.3" from stdin and writes the results to HAL pins
[15:33:36] <jmkasunich> sampler reads hal pins and writes lines to stdout
[15:33:52] <jmkasunich> both at a specified sample rate (the thread rate that their RT function is in)
[15:34:16] <jmkasunich> they use buffers between the RT function and the user program that does the file I/O
[15:34:17] <jepler> sampler sounds like a simplified version of halscope
[15:34:28] <jmkasunich> it is
[15:34:35] <jmkasunich> very simplified
[15:34:37] <jmkasunich> no triggering
[15:34:56] <jmkasunich> no on-the-fly changin of "probe" locations
[15:35:05] <jmkasunich> but unlimited memory depth
[15:35:48] <jmkasunich> could also think of sampler and streamer as record and playback of signals
[15:38:15] <alex_joni> can you pipe that to a socket?
[15:38:21] <alex_joni> and move to another machine?
[15:38:37] <SWPadnos> it's stdin in userspace, so whatever works there ...
[15:38:41] <SWPadnos> and stdout
[15:38:51] <alex_joni> wonder how well that would work ;)
[15:39:01] <SWPadnos> depends on the network, I imagine ;)
[15:39:02] <jmkasunich> there would be lag of course
[15:39:10] <alex_joni> it's userspace..
[15:39:15] <alex_joni> so normally there is lag
[15:39:37] <alex_joni> SWPadnos: even sampler > /dev/ttyS0
[15:39:57] <jmkasunich> but if the average bandwidth is enough, and there are no pauses long enough to allow the fifos to empty, you might achieve accurate, but delayed, transfer
[15:40:04] <SWPadnos> heh - who needs a HAL serial driver? ;)
[15:40:40] <jmkasunich> anyone who wants to close a loop ;-)
[15:40:52] <SWPadnos> details, details
[15:41:15] <jmkasunich> the concept seems like fun, which is why I'm writing them
[15:41:17] <alex_joni> * alex_joni heads home
[15:41:23] <SWPadnos> see you Alex
[15:41:23] <alex_joni> later guys..
[15:41:26] <jmkasunich> this started in response to greg on the users list
[15:41:28] <jmkasunich> later alex
[15:41:30] <SWPadnos> yep
[15:41:49] <SWPadnos> he was online for a while yesterday, but didn't say anything
[15:42:10] <jmkasunich> I figured I'm a lot more familiar with writing hal components than he is, so I could implement a generalized version
[15:42:13] <jmkasunich> he was?
[15:42:31] <jmkasunich> I should have poked him (maybe I wasn't around when he was)
[15:42:32] <SWPadnos> soemone named gpetit joined IRC yesterday
[15:42:52] <SWPadnos> it was during the discussion of the fish video
[15:42:58] <SWPadnos> (may have scared him off ;) )
[15:43:09] <jmkasunich> logger_aj: bookmark
[15:43:09] <jmkasunich> See
[15:43:45] <jmkasunich> stupid firefox
[15:44:05] <SWPadnos> download instead of display?
[15:44:09] <jmkasunich> thinks the log is a bin file, and won't let me open it, only save to disk
[15:44:21] <jmkasunich> won't even let me say "open with <editor>"
[15:44:39] <jmkasunich> fsckit
[15:44:56] <jmkasunich> if the guy didn't say anything, not much to see anyway
[15:45:04] <SWPadnos> nope
[15:46:17] <jmkasunich> hmm... should the user part of streamer call hal_init?
[15:46:30] <jmkasunich> it needs to call rtapi_init, because its gonna access rtapi shmem
[15:46:47] <jmkasunich> it won't be exporting any hal pins or params (I don't think)
[15:46:55] <jmkasunich> so technically it isn't a hal component, just a helper
[15:47:32] <jmkasunich> but it might be nice to have it appear in "halcmd show comp"
[15:51:43] <jepler> and exit with 'halcmd unloadusr'
[15:52:01] <jepler> oh I was thinking that since both userspace and realtime components can be unloaded now, maybe there should just be 'halcmd unload'
[15:52:25] <jmkasunich> that seems reasonable
[15:54:20] <jepler> is there not a way to get rid of a thread?
[15:54:25] <jmkasunich> nope
[15:54:38] <jmkasunich> short of "realtime stop"
[15:54:42] <jepler> yeah
[15:55:13] <jmkasunich> actually, that might be fixable
[15:55:19] <jmkasunich> a thread is just a rtapi task
[15:55:30] <jmkasunich> and rtapi has a task_delete()
[15:55:39] <jepler> it's really no trouble using "realtime stop" or "realtime restart"
[15:55:50] <jmkasunich> yeah
[15:56:09] <jmkasunich> and the stop has the additional advantage of recovering the leaked shared memory
[15:56:57] <SWPadnos> but it has a disadvantage in that there will be no threads running, rather than just one deleted
[15:57:20] <jmkasunich> another item for the "great refactor"
[15:57:25] <jepler> in my case I was just testing a component, and so I needed to 'make; realtime restart; halcmd -f blah.hal' each time
[15:57:26] <SWPadnos> also, halscope will probably die, since the scope_rt module will stop for a while (even if it's automatically reloaded)
[15:58:03] <jmkasunich> jepler: your testing requires a new thread every time?
[15:58:14] <jepler> jmkasunich: no, but 'blah.hal' tried to load threads every time
[15:58:24] <jepler> maybe I could have used '-kf'
[15:58:28] <jmkasunich> yeah
[16:12:17] <Lerneaen_Hydra> 'lo
[16:14:24] <jepler> hi
[16:15:25] <jmkasunich> jepler: makefile question
[16:15:42] <jmkasunich> I'm trying to add a user space program in the src/hal/components dir
[16:15:53] <jmkasunich> there is no submakefile there now, I need to add one, right?
[16:16:41] <jepler> yes .. when you add a Submakefile in a directory that is listed in the main Makefile's SUBDIRS, it will be automatically picked up
[16:16:48] <jmkasunich> ok
[16:17:05] <jmkasunich> I'm looking at the halcmd stuff in src/hal/utils as a pattern
[16:17:33] <jmkasunich> the "call TOOBJSDEPS" and TOOBJS things are confusing me
[16:18:09] <jmkasunich> the OBJSDEPS one seems to include stuff for the gcc command line that halcmd needs
[16:18:11] <jepler> you can probably ignore those unless these files need special compile flags
[16:18:50] <jmkasunich> ignore the extra flags, or ignore the lines completely?
[16:18:58] <jepler> ignore the lines completely
[16:19:03] <jmkasunich> I know I need this:
[16:19:04] <jmkasunich> HALSTREAMERSRCS := hal/components/streamer_usr.c
[16:19:04] <jmkasunich> USERSRCS += $(HALSTREAZMERSRCS)
[16:19:22] <jmkasunich> well, if I spelled it right anyway
[16:19:34] <jepler> it's these two lines you don't need:
[16:19:34] <jepler> $(call TOOBJSDEPS, hal/utils/halcmd.c): EXTRAFLAGS = -DEMC2_BIN_DIR="\"$(EMC2_BIN_DIR)\"" -DHAL_RTMOD_DIR="\"$(EMC2_RTLIB_DIR)\"" -DMODULE_EXT="\"$(MODULE_EXT)\""
[16:19:37] <jepler> $(call TOOBJS, hal/utils/halcmd.c): Makefile.inc
[16:19:40] <jmkasunich> ok
[16:19:44] <jepler> you do need lines like these:
[16:19:45] <jepler> ../bin/halcmd: $(call TOOBJS, $(HALCMDSRCS)) ../lib/libemc.a ../lib/libnml.so ../lib/libemchal.so $(READLINE_LIBS)
[16:19:48] <jepler> $(ECHO) Linking $(notdir $@)
[16:19:50] <jepler> @$(CXX) $(LDFLAGS) -o $@ $^
[16:19:53] <jepler> TARGETS += ../bin/halcmd
[16:19:57] <jepler> except the list of libraries may be different
[16:20:00] <jepler> (no readline, for sure)
[16:20:01] <jmkasunich> right
[16:20:05] <jmkasunich> thanks
[16:20:16] <jepler> the lines you don't need have to do with making halcmd get recompiled if EMC2_BIN_DIR and friends change
[16:20:49] <jmkasunich> libemchal.so - whats that? hal_lib by another name?
[16:21:53] <jepler> yes
[16:21:57] <jmkasunich> ok
[16:22:04] <jepler> hm I wonder why libnml is linked into halcmd!
[16:22:11] <jmkasunich> damfino
[16:22:19] <jmkasunich> inifile stuff maybe?
[16:22:46] <jmkasunich> shouldn't really be part of libnml, but there is _lots_ of stuff in libnml that has nothing to do with NML
[16:22:50] <jmkasunich> like posemath
[16:22:50] <jepler> oh yeah probably
[16:26:53] <Lerneaen_Hydra> oh, have there been any new commits to head WRT timeout since yesterday?
[16:27:36] <jepler> 'use a default timeout value, seems that's the way other GUI's are handling it'
[16:27:55] <Lerneaen_Hydra> yeah, ok
[16:27:58] <jepler> UTC 16:28 on Sep 05, 2006
[16:53:14] <simon78> I am still having some troubles about getting CVS to run here. I get unknown symbols when the modules are to be insmodded. Any hints?
[16:53:58] <cradek> check dmesg
[16:56:01] <simon78> Everything seems OK in dmesg, except that motmod has unknown symbols:KinematicsType, KinematicsInverse and KinematicsForward.
[16:56:32] <cradek> that's your problem, you have to load a kinematics module
[16:56:52] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?UpdatingConfigurationsForDevelopmentVersions
[16:57:15] <cradek> see step 2
[16:57:23] <cradek> you may run into the other problems too if your configuration is old
[17:04:26] <jmkasunich> what is SIGPIPE?
[17:06:16] <simon78> cradek: Thanks!
[17:10:08] <Lerneaen_Hydra> hi cradek
[18:11:55] <cradek> jmkasunich: the guy on the other side of your pipe died (you're writing to a pipe and nobody is reading it)
[18:11:59] <cradek> simon78: welcome
[18:12:02] <cradek> Lerneaen_Hydra: hi
[18:12:28] <jmkasunich> ok, so streamer won't have that problem
[18:12:39] <jmkasunich> (I stole some of the signal handling from halcmd)
[18:13:44] <jmkasunich> can sigpipe also happen if I'm reading a pipe and the writer dies?
[18:13:54] <jmkasunich> or will I just read EOF
[18:14:09] <cradek> just eof I think
[18:14:13] <jmkasunich> ok
[18:14:55] <jepler> EPIPE / SIGPIPE apply when the "reading end" is closed. If you're the reader, you can't get SIGPIPE.
[18:15:02] <jmkasunich> thanks
[18:15:08] <cradek> fwiw: man 7 signal
[18:15:17] <jepler> I looked at man 2 write
[18:15:46] <jmkasunich> I looked at man kill, it has a crappy list of signals
[18:16:22] <cradek> I started there and followed a "see also"
[18:16:48] <jmkasunich> design question about streamer (want opinions)
[18:17:10] <jmkasunich> suppose streamer is reading thru a file, expecting two floats and a bit per line, and getting that
[18:17:29] <jmkasunich> then it finds a bad line (maybe a letter in the middle of a number)
[18:17:32] <jmkasunich> possible actions:
[18:17:39] <jmkasunich> print error message and quit
[18:17:50] <jmkasunich> print error message, drop the line, and read the next one
[18:18:58] <jepler> I'd say keep going, but have the error expressed in such a way that a person could hook it into the software estop chain if they need to abort
[18:19:11] <jmkasunich> thats gonna be tough
[18:19:23] <jmkasunich> since the reader that knows about the error is in user space
[18:19:43] <jmkasunich> I do have an "empty" HAL pin that asserts if the fifo ever gets empty, so that case is covered
[18:22:04] <jmkasunich> but a "transient" error in the data file...
[18:22:13] <jepler> it seems like aborting the streamer is safer if there's no other option for signalling the error
[18:22:20] <jmkasunich> yeah
[18:22:41] <jmkasunich> then the fifo runs empty, the empty pin turns on, and that does a safe shutdown
[18:22:54] <jepler> yeah
[18:23:01] <SWPadnos> how about a stop hal pin, and an error output pin -hook them together if you want it to stop on error
[18:23:11] <jmkasunich> stop hal?
[18:23:12] <SWPadnos> stop input
[18:23:19] <SWPadnos> sorry - stop HALPIN
[18:23:20] <jmkasunich> you mean like "halcmd stop">
[18:23:32] <SWPadnos> no - i'm communicating badly
[18:23:45] <SWPadnos> I meant a bit input pin that stops the streamer
[18:23:59] <SWPadnos> and a bit output pin that is asserted if there's an error
[18:24:25] <jmkasunich> the error pin would belong to the user space component, the stop pin would belong to the rt part
[18:24:41] <jmkasunich> duh, hal _does_ support userspace pins, I almost forgot
[18:24:42] <SWPadnos> if those are tied together, then the component will stop on error (+/- one RT cycle)
[18:25:11] <jmkasunich> instead of waiting for the fifo to flush out
[18:25:36] <SWPadnos> yep - you may have invalid data, so it could make sense to stop there
[18:25:37] <jmkasunich> except... I think I want to avoid hal pins on the user part
[18:25:55] <jmkasunich> by its very nature, halstreamer (the user part) is transient
[18:25:56] <SWPadnos> is there a particular reason for that?
[18:26:01] <SWPadnos> ok
[18:26:13] <jmkasunich> you can't start it, connect its pin, etc, and then later start feeding it data
[18:26:43] <SWPadnos> saure you can - connect it to a pipe or socket, and the data starts once the producer starts writing
[18:27:07] <jmkasunich> I'm thinking the most common usage will be "halstreamer 0 <somestuff"
[18:27:13] <jmkasunich> (0 is the channel number)
[18:27:50] <jepler> so can you devote a bit in the structure you send to realtime that means "malformed input line", which the realtime portion would put on a pin?
[18:27:54] <SWPadnos> I'd expect it to be used with a program generating input more often, eventually
[18:28:04] <jmkasunich> so the pin would appear, the data would start flowing, at eof, the pin would disappear, and some seconds later the buffer would empty
[18:28:34] <SWPadnos> that doesn't seem so useful, since the pin needs to be connected to a signal to do any work
[18:29:01] <jmkasunich> SWPadnos: exactly, which is why I'm reluctant to add the pin
[18:29:24] <SWPadnos> err - what pin are you talking about? (I assumed it was the channel0 pin just mentioned)
[18:29:29] <jmkasunich> I kinda like jepler's idea of a "valid" pin
[18:29:51] <jmkasunich> I forget that I'm using terms you haven't read yet
[18:29:57] <SWPadnos> yep - that can be streamed along with everything else
[18:30:08] <SWPadnos> heh - no problem. it's fun trying to figure it out ;)
[18:30:29] <jmkasunich> invocation of the RT part: loadrt streamer cfg=ff,u8u8b depth=400,100
[18:30:36] <jmkasunich> that creates two "channels"
[18:30:57] <jmkasunich> the first channel transfers 2 floats, their pins are called streamer.0.pin.0 and streamer.0.pin.1
[18:31:07] <jmkasunich> the second channel transfers two u8s and a bit
[18:31:16] <jmkasunich> pins streamer.1.pin.0 thru pin.2
[18:31:43] <jmkasunich> each streamer also has pins streamer.0.empty (bit) and streamer.0.curr_depth (int)
[18:31:56] <jmkasunich> depth is the current number of samples in the buffer
[18:32:02] <jmkasunich> empty is obvious
[18:32:17] <SWPadnos> do you get two functions (streamer.0.update and streamer.1.update)?
[18:32:23] <jmkasunich> yes
[18:32:25] <SWPadnos> ok
[18:32:41] <jmkasunich> so you can be streaming some things at 100Hz and others at 10KHz if you want
[18:33:01] <SWPadnos> there should probably be a parameter or pin that lets you skip N executions, to allow for varying rates
[18:33:02] <jmkasunich> when you start the RT part, empty is true, curr_depth is 0, and all outputs are zero
[18:33:23] <jmkasunich> maybe, or just put it in a slower thread
[18:33:50] <SWPadnos> sure. it's probably something that can be added later anyway
[18:34:07] <jmkasunich> anyway, once you do "halstreamer 0 (or 1) <foo", the empty pin goes low, curr_depth becomes non-zero, and the output pins start changing
[18:34:37] <jmkasunich> once you get to the end of foo, and halstreamer exits, curr_depth starts dropping, eventually reaches zero, empty comes on, and the output pins hold their present value
[18:35:02] <SWPadnos> ok - and they stay that way until you run halstreamer again and feed it more data
[18:35:08] <jmkasunich> if there is an underrun for any reason, the same happens - empty goes true, the outputs hold, then when more data arrives, empty goes false and out comes data
[18:35:12] <jmkasunich> yep
[18:35:56] <jmkasunich> the ability to start/stop the RT part with a pin, and the ability to divide by N, are both usefull additions
[18:36:03] <jmkasunich> but I want to get the core working first
[18:36:10] <SWPadnos> makes sense to me :)
[18:36:46] <jmkasunich> so, the easy solution: if halstreamer sees a bad input line, it prints an errormessage and exits. OR,
[18:37:39] <SWPadnos> can you throw in a "-k" option"?
[18:37:44] <jmkasunich> 1) I add another pin, and fifo entry, to tag each sample as valid or not
[18:37:49] <SWPadnos> without it, exit on error
[18:38:02] <SWPadnos> with -k, continue, but don't write the malformed line to the FIFO
[18:38:45] <jmkasunich> I guess if I really knew what it would be used for this would be an easier decision
[18:39:04] <jmkasunich> if you are using files, then abort on error makes sense, go fix the f-ing file
[18:39:25] <SWPadnos> did you already rip out the command line option parsing? ;)
[18:39:31] <jmkasunich> yeah
[18:39:40] <SWPadnos> err - un-rip it :)
[18:39:46] <jmkasunich> although -k wouldn't be _too_ hard to put back
[18:40:34] <jmkasunich> one other thought on the keep going approach
[18:41:12] <jmkasunich> if the file is truly fscked (for instance, someone pipes their favorite pron to it by accident) you'll get a storm of messages on stderr, instead of just bailing out
[18:41:35] <SWPadnos> yep
[18:41:49] <SWPadnos> I'm not sure that's a problem
[18:42:04] <jmkasunich> I suppose its a problem that ctrl-C can fix
[18:42:07] <SWPadnos> you can also do something where it bails anyway if N lines in a row are malformed
[18:42:44] <jmkasunich> I want to finish it this afternoon - I need to go pick up some metal before 5 ;-)
[18:42:52] <SWPadnos> heh
[18:42:57] <jmkasunich> I think version 1.0 is gonna quit on error
[18:43:13] <SWPadnos> I'll stop bugging you. maybe put some of the suggestions in a TODO-type comment in the source
[19:26:45] <Lerneaen_Hydra> 'night
[19:33:40] <jmkasunich> back in a bit
[19:35:04] <CIA-8> 03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/extensions/minigl.c: start support for opengl feedback buffer
[19:37:27] <cradek> what's that?
[19:37:59] <jepler> it allows you to find the transformed vertexes for all primitives drawn
[19:38:16] <cradek> ooh
[19:38:26] <cradek> you mean the coordinates pre-transform?
[19:39:04] <jepler> ?REDO FROM START
[19:39:13] <cradek> heh
[19:39:34] <cradek> forget it
[19:40:34] <jepler> "Drawing does not occur; instead, information about the primitives that would have been rendered is sent back to the application. In feedback mode, information about transformed primitives is sent back to an array of floating-point values"
[19:41:08] <jepler> so I get a series of tokens that say a 3-vertex polygon was drawn with vertices A B C
[19:41:39] <jepler> A B C are the coordinates after the MODELVIEW and PROJECTION transformations are applied
[19:41:57] <cradek> got it
[19:42:02] <jepler> it's just one step from these coordinates to the pixel locations that the primitives cover
[19:43:20] <jepler> what I want to do is a sort of "dirty rectangle" redraw in AXIS: the contents of the back buffer are saved. then at a redraw, the part that was under the coordinate read-out and the cone are restored, then any new part of the backplot is drawn, and the image is saved. Then, the cone and coordinate read-out are drawn
[19:43:32] <jepler> but to do that I need to find out the rectangle that encloses the tool cone/cylinder
[19:44:29] <jepler> if I can get it working it should really improve the framerate because the preview and backplot won't be redrawn every time
[19:45:00] <jepler> (it'll still be slow when zooming or rotating, of course)
[19:47:09] <alex_joni> hi all
[19:47:21] <jepler> hi alex
[19:48:10] <alex_joni> did you ever hear of Packard Bell ?
[19:48:36] <jepler> yes I've heard of them
[19:48:45] <alex_joni> any good?
[19:48:47] <jepler> I assume they were related to the US phone company
[19:48:54] <alex_joni> I just bought a laptop named Packard Bell
[19:48:58] <jepler> but during the 90s they were makers of cheap PC-compatible hardware. Some called them "Packaged Hell"
[19:49:02] <jepler> I dunno how they've been since then
[19:49:15] <alex_joni> seems kinda nice, pretty cheap too
[19:49:23] <cradek> I still avoid them because of the reputation 10-15 years ago
[19:49:38] <cradek> they were the first crap to show up in some of the big retail stores
[19:49:41] <alex_joni> cradek: not much of a reputation around here..
[19:49:55] <alex_joni> but they gave 2 years warranty.. so I hope it's ok :)
[19:53:03] <robin_sz> sigh .. openGL based graphics cards are just so damn expensive
[19:55:22] <robin_sz> but it would be nice to have CAD that worked quickly
[19:56:23] <jepler> it depends how much performance you need. seems like you can get a previous-generation nvidia agp card for under 50USD, e.g., http://www.newegg.com/Product/Product.asp?Item=N82E16814145003
[19:57:49] <robin_sz> hmmm
[19:58:22] <robin_sz> looks like i need a qudaro FX ... its pretty much ignores other nvidia cards and just does its own thing
[19:58:38] <SWPadnos> what softwre?
[19:58:41] <SWPadnos> software
[19:58:45] <robin_sz> solidworks
[19:58:53] <SWPadnos> ah. AGP or PCIe system?
[19:59:38] <robin_sz> well, currently AGP
[20:00:16] <SWPadnos> oh well ;)
[20:00:31] <robin_sz> but Im buying a new machine soon
[20:00:33] <SWPadnos> a prett ygood value, though still expsnsive, is the Quadro FX1500
[20:01:04] <robin_sz> I might just get a Dell precision workstation and just suffer the expense
[20:01:07] <SWPadnos> it's in the same speed class as the top of the line previous generation (FX4500 ...), but is only $600
[20:01:27] <SWPadnos> probably 600 GBP there though
[20:01:36] <robin_sz> probably
[20:02:12] <SWPadnos> check out Boxx tech for high speed, well configured CAD stations
[20:02:34] <SWPadnos> (I haven't bought from them, but their stuff looks great, and pretty much all they do is rendering and CAD stations)
[20:03:29] <SWPadnos> oops - brb
[20:04:18] <jepler> http://www.solidworks.com/pages/services/videocardtesting.html lists many of the consumer-grade nvidia chipsets as "passed with limitations" -- the "limitation" apparently being the number of accelerated windows
[20:06:48] <jepler> this one is a "6200" chipset with 256 megs RAM: http://www.newegg.com/Product/Product.asp?Item=N82E16814130014
[20:30:06] <SWPadnos> hiya gpettit
[20:31:22] <A-L-P-H-A> anyone looking for a mitutoyo digital (lcd display) 1-2" digital outside micrometer?
[20:42:13] <jepler> gpettit: hello
[20:48:04] <alex_joni> SWPadnos: got a link on the Boxx boxes?
[20:48:19] <SWPadnos> http://www.boxxtech.com
[20:48:47] <SWPadnos> better: http://www.boxxtech.com/products/Workstations.asp
[20:49:07] <A-L-P-H-A> are they cheap or something?
[20:49:11] <SWPadnos> hah
[20:49:18] <SWPadnos> I mean - no, not really
[20:49:30] <A-L-P-H-A> why are we looking at them?
[20:49:41] <alex_joni> whoah
[20:49:47] <SWPadnos> they just know what they're doing when it comes to CAD or rendering performance
[20:49:53] <alex_joni> http://www.boxxtech.com/products/apexx4_Config_Intl.asp
[20:50:14] <alex_joni> 32 GB DDR400 ECC ram
[20:50:17] <SWPadnos> they don't even list prices for the 8-processor versions ;)
[20:50:37] <jmkasunich> if you have to ask...
[20:50:41] <alex_joni> 51k$
[20:50:50] <alex_joni> it's there in front of you :)
[20:50:54] <SWPadnos> that's 8 cores - they have 8-chip versions as well
[20:51:06] <alex_joni> ahhh.. ok
[20:51:08] <SWPadnos> http://www.boxxtech.com/products/apexx8_specs.asp
[20:51:16] <alex_joni> I think I don't want to spend that much
[20:51:53] <SWPadnos> I'd love to, but I can't :)
[20:52:24] <alex_joni> just think that'll be obsolete in a few years :D
[20:52:28] <A-L-P-H-A> wish my nails wouldn't grow so fast.
[20:52:30] <alex_joni> probably 10 :)
[20:52:43] <SWPadnos> depends on your definition of "obsolete" I guess ;)
[20:53:12] <jmkasunich> worth less than 25% of what you paid for it
[20:53:18] <A-L-P-H-A> I need this... to umm... run simulations on taking over the world...
[20:58:44] <alex_joni> should have gotten this laptop: http://www.boxxtech.com/products/1400.asp
[20:59:07] <SWPadnos> I so much wanted to win that from their booth at NAB
[20:59:40] <jepler> I want a laptop that you never notice becoming warm
[21:00:11] <jepler> this probably isn't it :-P
[21:00:30] <jepler> ugh 11.3 lbs. with Battery
[21:00:41] <cradek> I notice there's no hint of battery lifetime
[21:01:26] <jmkasunich> dang! there really is a lot _more_ screen output when making docs
[21:01:34] <jmkasunich> I thought it was a lot before
[21:01:38] <jepler> nobody seems to advertise battery lifetime anymore
[21:01:42] <jepler> jmkasunich: html added a lot more?
[21:02:02] <jmkasunich> I guess thats what all that is coming from
[21:03:08] <jmkasunich> streamer seems to work OK
[21:03:30] <alex_joni> jepler: I wish the 10-12" laptops were 30% cheaper than 15" ones
[21:03:42] <alex_joni> but they're actually way more expensive :(*
[21:03:45] <SWPadnos> in area, they should be 50% cheaper ;)
[21:03:49] <jmkasunich> I set up a 100 deep fifo, and it never seems to drop below 60% full even when compiling emc
[21:04:00] <jepler> neat
[21:05:22] <jmkasunich> doing a find / -name "*.c" to thrash the disk seems to have no effect
[21:05:32] <jmkasunich> it stays 90% full
[21:05:44] <jmkasunich> maybe the file I'm redirecting into it is in cache
[21:06:13] <alex_joni> jmkasunich: try turning swap off ;)
[21:06:30] <jmkasunich> I'm too lazy
[21:06:37] <alex_joni> or boot with less memory
[21:06:41] <alex_joni> to make it swap even more
[21:06:42] <jmkasunich> I'm gonna remove a couple printfs, and commit it
[21:06:47] <alex_joni> coo
[21:07:21] <jmkasunich> it probably could stand some more severe testing (differnt numbers of pins, of different types, etc)
[21:08:49] <alex_joni> what happens if you misuse it?
[21:09:02] <alex_joni> is that possible?
[21:09:14] <alex_joni> have the writer and the reader speak different data types
[21:09:31] <alex_joni> say reader expects char, writer sends float
[21:09:36] <jmkasunich> when you loadrt the RT part you tell it the types, and it exports pins accordingly
[21:09:56] <jmkasunich> the type info is stored in shmem, and the user space part looks there to see what to expect
[21:10:15] <jmkasunich> if you define float, float, bit, u8, then the reader will expect lines containing that
[21:10:24] <jmkasunich> and complain if diffenerent
[21:10:29] <alex_joni> ok, nice
[21:12:20] <SWPadnos> that's one place where a real scanf is nice - you can build the parse string programmatically
[21:12:45] <SWPadnos> (that comes from the part of me that runs microcontroller code, which often needs sformat strings to be constants to compile efficiently)
[21:12:56] <jmkasunich> but passing pointers of the right type, and quantity, is messy
[21:13:13] <SWPadnos> that is true
[21:13:18] <jmkasunich> I did it with a loop that does a switch on type, and invokes strtol and friends
[21:22:42] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/ (Makefile Makefile.inc.in): initial commit of 'streamer', a HAL component that takes data from stdin (user space) and streams it onto realtime HAL pins at a fixed sample rate
[21:22:43] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/hal/components/ (streamer.c streamer.h streamer_usr.c): initial commit of 'streamer', a HAL component that takes data from stdin (user space) and streams it onto realtime HAL pins at a fixed sample rate
[21:29:26] <alex_joni> good night all
[21:31:05] <jepler> bye alex
[21:31:34] <jmkasunich> night
[22:17:43] <tomp> good evening all
[22:40:04] <danex> Hello all
[22:41:02] <danex> Anyone up for an e-stop question?
[22:45:52] <jepler> sometime tonight (before 10PM CDT) there will be downtime on cvs.linuxcnc.org.
[23:05:33] <danex> Hello jepler
[23:07:23] <danex> * danex is away: Away at the moment