Back
[01:28:32] <jepler> http://emergent.unpy.net/files/sandbox/emc2-gutsy.png
[01:30:45] <jepler> however something went very wrong when I made the machine beep
[01:30:53] <jepler> max jitter (ns) 164746527
[01:31:32] <jepler> opengl is broken so I can't try axis
[01:32:47] <jepler> I gave up and build a UP kernel and it seems to be working </last-words class="famous">
[01:35:38] <SWPadnos> 164746527 seems like a lot of ns
[01:37:48] <jepler> that's when it didn't display negative numbers :-P
[01:38:26] <SWPadnos> heh
[01:49:01] <jepler> Runtest: 21 tests run, 20 successful, 0 failed + 1 expected
[01:49:16] <jepler> though that's not the whole story -- sometimes the tests fail
[01:49:42] <jepler> one failure I saw involved undefined symbol errors in sampler, really kinda odd behavior
[01:53:54] <jepler> RTAPI: ERROR: could not open shared memory (errno=2)
[01:57:22] <SWPadnos> another helpful error number :)
[01:57:31] <SWPadnos> at least it's not -1 (Resource unavailable)
[02:07:43] <jepler> open("/dev/rtai_shm", O_RDWR) = -1 ENOENT (No such file or directory)
[02:08:08] <SWPadnos> oh good. -1 has different meanings in different places :)
[02:08:28] <SWPadnos> oh - it's "Operation Not Permitted" whenever it's at insmod time
[02:19:48] <jepler> I'm still none the wiser
[02:20:45] <jepler> sometimes CheckLoaded detects that the rtai_shm device exists and is writable but halcmd can't actually open it as shown above by strace
[02:25:03] <SWPadnos> that is odd behavior
[03:32:24] <fenn> something's wrong with the way joint names work
[03:33:03] <fenn> for example, the scara robot can move in X Y Z and C, but it has 4 joints so C is not lined up with the joint numbers somehow
[03:33:26] <fenn> if i put XYZA in the coordinates section, i can't jog in A in teleop mode (but i can move the joint in joint mode jogging)
[03:33:40] <fenn> if i put XYZC i get this error: emcTrajSetAxes failing: axes=4 axismask=27
[03:33:50] <jmkasunich__> joint to axis mapping is and has been screwed up for years
[03:33:58] <fenn> (and XYZR as it is now doesnt do anything)
[03:35:15] <fenn> jmkasunich__: is this something that can be fixed in one place? or does it need to be messed with in every kinematics module?
[03:35:20] <SWPadnos> xyzc should work. that mask "looks right"
[03:35:49] <SWPadnos> is this a clean checkout/build?
[03:36:11] <fenn> no, lemme try that
[03:37:37] <fenn> 111001 is 57 and 100111 is 39
[03:38:20] <fenn> what's 27? bc is misbehaving
[03:38:41] <SWPadnos> I'd bet 27 is hex
[03:38:48] <jmkasunich__> fenn: it runs through lots of things - if it was easily fixed it would have been already
[03:38:49] <SWPadnos> 0010 0111
[03:39:09] <SWPadnos> XYZABCUVW in increasing bit order (right to left in the binary representation)
[03:39:19] <fenn> ok the hex threw me
[03:39:53] <SWPadnos> I'm assuming it's hex because it makes sense to me :)
[03:40:47] <SWPadnos> hmmm. you know you're in trouble when it takes longer to install updates than it does to download them
[03:41:23] <fenn> dpkg -la | wc -l
[03:41:23] <fenn> 1695
[03:42:01] <fenn> this is what happens when you let information free :(
[03:45:46] <fenn> fresh co/compile has the same problem (with XYZA)
[03:46:50] <fenn> ok i see the problem now :)
[03:47:34] <fenn> looking at emcTrajSetAxes, it only works if they go in order, so you can't do XZ for example
[03:53:44] <SWPadnos> xyuv is working for some people, so I'm not sure of that
[03:54:00] <SWPadnos> and it was specifically written for lathes, which are XZ
[03:57:13] <fenn> (paraphrasing here) emcTrajSetAxes(axis, mask) { if(axismask >= (1<<axes)) error; }
[03:57:33] <SWPadnos> I wonder how XYUV works then ... ??
[03:57:35] <fenn> if axes==4 then 1<<4 is NOT 39 (or 27 in hex)
[03:58:09] <SWPadnos> I'm reasonably sure I heard about someone or some-two using if
[03:58:14] <SWPadnos> it
[03:58:23] <fenn> SWPadnos: it uses trivial kinematics so it never calls emcTrajSetAxes
[03:58:36] <SWPadnos> ah, ok
[03:58:42] <fenn> i think the fix is simple enough
[03:58:57] <fenn> deconstruct the bitmask by looping and shifting
[03:59:11] <fenn> i dunno why it needs all this stuff anyway
[05:01:42] <elson> Hello, all!
[05:03:07] <elson> I'm updating one of my customer's machines, I installed the 2.1.6 and then installed a version from CVS trunk (possibly a mistake, but I wanted to give him all the new improvements.)
[05:04:03] <elson> Anyway, the big problem isthat halscope and halmeter won't run, I get RTAPI: version mismatch 531 vs 529. Did I fail to update and/or compile something?
[05:04:37] <SWPadnos> I'm betting that there's a path problem
[05:05:10] <SWPadnos> I think that usually happens when something (RTAI) comes from the installed version and somethign else (hal utils) from the run-in-place
[05:05:44] <SWPadnos> try the command `. scripts/emc-environment` before running EMC
[05:06:19] <elson> right, that sounds like it. But, I'm pretty sure it is running the trunk version of EMC, and clearly it is running the trunk axis (but then that doesn't care, or does it?)
[05:06:44] <SWPadnos> dunno. I have a very limited set of answers :)
[05:06:50] <elson> OK, do I just run that environment script once and it changes something?
[05:07:13] <SWPadnos> it changes the path so the RIP version of things will be found before installed
[05:07:29] <SWPadnos> and changes some other environment stuff
[05:07:57] <elson> OK, that sounds good. I've got a couple more odities to track down, this is the first machine I have set up in pure mm units, so I'm learning stuff!
[05:08:19] <SWPadnos> heh
[05:08:29] <SWPadnos> just keep it trivkins or your head will explode ;)
[05:08:55] <elson> Oh, yeah, I've been following that development from a safe distance!
[05:09:05] <SWPadnos> a few hundred miles should suffice
[05:10:08] <SWPadnos> question about your PWM servo drives: did anyone ever make them work with the 5i20?
[05:10:24] <SWPadnos> I remember a discussion about it some time ago, but don't recall the ending
[05:10:55] <elson> I'm having enough problems just getting simple servos to work. One odditiy, I just turned the accel up from inch values line 5.0 to mm based like 50, and I get servo faults when in incremental jog (any size) but continuous jog is fine, in axis. I don't know if this is real, yet, if I get halscope running I will see.
[05:12:13] <elson> Yes, I have a customer who has the gear, I don't know whether he has made serious effort on it. I just shipped the first brushless drive to a guy in Italy who is going to hook it to a Mesa with 19 KHz PWM. I'm sure I will hear more in a week or two.
[05:12:21] <SWPadnos> the new axis allows you to set jog increments in "english" - you can set an ini var with a list of values (like 0.001in, 0.01 in, 0.1 in, 0.1mm, 1mm ...)
[05:12:22] <SWPadnos> ok
[05:12:45] <SWPadnos> I may be interested in that setup. I have a boatload of Mesa gear, and I like the fact that your drives can use a bit more of my motors potential than the Geckos
[05:12:49] <elson> Right, I think the customer want a pure mm system, so I'm trying to do that.
[05:13:30] <SWPadnos> ok. you'd be best off asking Jeff or Chris about it, if you can nail down the conditions a bit
[05:14:02] <elson> Well, the only tricky thing with my brush servo amps is they need this bootstrap pulse in each direction to turn on the fet drivers. The brushless amp has a CPLD and doesn't need such crude tricks.
[05:14:22] <elson> I'm not sure this is even a problem, yet.
[05:14:27] <SWPadnos> luckily the Mesa cards have a "CPLD" on them as well :)
[05:15:03] <SWPadnos> I'm really curious to see the difference between analog control and step control for a servo. I'm betting that there will be a noticeable difference in finish
[05:15:49] <elson> One other tangent, I'm looking into NXP's Arm+everything microcontroller chip to do an ethernet adaptor for my parallel-port based boards.
[05:16:06] <SWPadnos> yah
[05:17:10] <elson> Well, I can tell you that using high-resolution encoder schemes really helps. My minimill has 16 TPI screws and a 4:1 belt ratio, and 500 cycle/rev encoders gives 128,000 counts/inch. It gets rougher as the encoder resolution goes down.
[05:17:44] <SWPadnos> sure. I've got 2:1 gearing at the moment, and with the geckos, I can't exceed ~65% of the servo rated speed
[05:18:06] <SWPadnos> with yours, I could get to 100% speed if I thought the mill could handle it (2500 RPM = 250 IPM = scary)
[05:18:22] <SWPadnos> bu tI can also gear down to 3:1 or 4:1 instead
[05:18:54] <SWPadnos> I have 1000CPR encoders (4000 line), so it's 40k/inch at 2:1, 60k or 80k at 3:1 or 4:1
[05:19:00] <elson> Hmm, my analog velocity servos on my Bridgeport are pretty weak, 1/8 Hp continuous motors, but they can definitely set the whole 1500-Lb machine rocking!
[05:19:06] <SWPadnos> heh
[05:19:18] <SWPadnos> I've got 27 in-lb @ 2500 RPM motors, 4x that peak :)
[05:19:20] <elson> 40K counts/inch should be fine.
[05:19:45] <elson> Yow, a bind-up at the end of travel could be a real mess.
[05:19:48] <SWPadnos> heh
[05:19:57] <SWPadnos> it would be a mess for the mill and mu foundation
[05:19:59] <SWPadnos> my
[05:20:22] <SWPadnos> are you looking at the ARM7 or ARM9 chips?
[05:20:36] <elson> I've been redesigning my brush servo amps to take best advantage of my pick&place machine.
[05:20:46] <SWPadnos> ah. SMT all the way then :)
[05:21:05] <elson> The NXP23xx and 24xx are Arm7 based designs, with a ton of on-chip peripherals.
[05:21:32] <SWPadnos> it sems that pick&place may be at the stage "hobby CNC" was a few years ago. I've been thinking about making a small machine to sell
[05:21:36] <SWPadnos> ok
[05:21:49] <SWPadnos> have you looked at the Atmel AT91SAM7X chips?
[05:22:01] <elson> They really have everything, ram, flash, ethernet, USB, serial, CAN, IIC, etc. on the chip.
[05:22:11] <SWPadnos> same deal with the Atmels
[05:22:26] <SWPadnos> 128 or 256k program flash (512k coming I think)
[05:22:38] <elson> Not really looked into the Atmel, the NXP is $7 - 13 in single quantity.
[05:22:50] <SWPadnos> multiple SPI/UART/ethernet, USB full/high speed ...
[05:23:02] <fenn> same price for at91sam
[05:23:04] <SWPadnos> ok, that's a good deal, though it's around the same as the Atmels
[05:23:14] <fenn> not like it matters
[05:23:32] <fenn> you're only using one right?
[05:23:35] <elson> Hmm, I don't know about building a hobby-level P&P. Seeing how complicated all this stuff is, and how much tinkering it takes to even get a $100,000 machine to run right, it might be a customer support nightmare.
[05:23:45] <SWPadnos> I'm sure it could be
[05:24:20] <SWPadnos> I was thinking that it would only need to handle smaller parts at first. The main problem with hand-building is all the bypass caps and that kind of stuff (and of course fine pitch)
[05:24:54] <elson> The first plan is to use the NXP or other micro to connect my motion control boards to PC's without parallel port. but, there's so much capability there, I'm sure I could come up with more things to make it do.
[05:24:59] <SWPadnos> on this board I just did, if I had an 8-feeder machine that only did 0603 and tantalums (like 3528), it could have placed about 220 of the 250 parts on the board
[05:25:48] <elson> Hmm, I'm getting into a wide range of parts, and trying to figure out how to do it all with 3 non-changeable nozzles.
[05:26:17] <elson> I'm doing everything from 0805 to 20+ mm flat packs.
[05:26:37] <elson> I think I had 27 feeders running on the last one!
[05:27:23] <elson> I ran out of real feeders, so I had to hand-place some of the one-per-board items on the vibratory feeder, and teach the machine to pick them up from there.
[05:27:29] <fenn> do you normally do a test run when using the p&p machine?
[05:27:40] <SWPadnos> every run is a test run :)
[05:27:51] <fenn> that works too
[05:28:21] <elson> The first part is the test. If it is a total screw-up, I just wipe the parts off, remove and reapply the solder paste. I only did that on the first board I ever ran on it.
[05:29:21] <elson> After that, I just inspect the first board, and always find some diodes are backwards, or some such. I fix it with tweezers, (before the reflow) and then edit the mounting data on the machine.
[05:30:23] <fenn> what sort of format is the "mounting data"?
[05:30:31] <SWPadnos> XYRS files
[05:30:37] <SWPadnos> XY location, rotation, side
[05:30:38] <elson> I have a c program I wrote that takes the P&P file from my CAD system and turns it into the P&P's file format. I have to get into the CAD system and see why the diodes always come out backwards, they must default to anode being the #1 pin.
[05:31:55] <elson> Well, there's more. The P&P file from the cad system, is mostly XYRS and identifier data. I write a component file that has component ID, feeder # and orientation in the feeder.
[05:32:02] <SWPadnos> I think I ended up making versions of SMT diodes with A and K pins instead of 1 and 2
[05:32:44] <SWPadnos> sure - there's more info about getting the part and how to move it around, which the PCB design software doesn't know
[05:33:04] <elson> The c program combines this, and the output is X Y R and then a long coded # that tells feeder, head and some other stuff.
[05:34:28] <elson> Then, you have to set a bunch of component/feeder info like raise and lower timers, how much vacuum indicates a good or bad pick-up for that part, whether the mechanical aligner should be used, where to dump the part if the vcacuum isn't good,.....
[05:34:51] <SWPadnos> oh, it's never easy (at first)
[05:35:44] <SWPadnos> if you ever get a Texmac fixtureless tester, let me know. I may still have a copy of the code I wrote to take Tango PCB pad locations and generate test patterns
[05:36:08] <elson> I do the A and K too, but the cad system has some definition of where 0 degrees is on the parts orientation. Chips are always done right, R & C don't care except for electrolytics, which are ALSO going in backwards. I just fixed the data on the fly, but I need to fix it right.
[05:36:23] <SWPadnos> hmm
[05:36:41] <elson> That's a flying probe tester? Hmm, I think I'll let my board house do that level of testing. That is interesting, though.
[05:36:43] <SWPadnos> does Protel output 0 or 360 (or some combination) for "upright" parts?
[05:36:50] <SWPadnos> yeah, flying probes
[05:37:36] <SWPadnos> I'm noticing tha Altium seems to output 360 a lot, but I don't know if it's because I rotated the part 4 times and then copied it :)
[05:37:57] <fenn> gotta alter that electron spin
[05:38:10] <fenn> an object isnt the same when you turn it 360 degrees ya know
[05:38:11] <SWPadnos> yerah, but that should only be a half-turn ;)
[05:38:25] <elson> Ugh, I don't actually know. I think I do see all sorts of weird angles coming out. For an R or C, it shouldn't need to turn a full 270 degrees, 90 would be fine. I believe, but the thing is so damn fast you can't tell unless you slow it down, but if you say 360, it actually spins the head a full turn between pickup and placing it.
[05:38:42] <SWPadnos> guh
[05:38:43] <SWPadnos> ugh
[05:39:00] <SWPadnos> I assume it can handle negative rotations though?
[05:39:21] <SWPadnos> that seems a simple fix for a C program
[05:39:33] <SWPadnos> or the scripting language in Altium. maybe I'll learn that one day
[05:39:41] <elson> Yes, I sometimes edit 270 to -90 when I'm fixing those diodes. it takes it fine.
[05:40:05] <elson> I'm still with P99SE, and I'm staying there, at least for a while.
[05:40:10] <SWPadnos> heh
[05:40:31] <SWPadnos> well, I was happy to see that they quietly improvd Protel import in Altium
[05:40:55] <SWPadnos> I can load 99SE and even Advanced Schematic/PCB 2.7x files perfectly now
[05:41:10] <SWPadnos> PCB, schematic, and library all work
[05:41:13] <elson> Gee, you'd think they'd want to make it easy for old customers to move their designs in, wouldn't you?
[05:41:25] <elson> That's good to know.
[05:41:35] <SWPadnos> it was more or less OK for 99SE, but I had the even older AS/APCB 2.xx and 3.0 series
[05:42:04] <SWPadnos> which sort of worked, but sometimes tiny SMT pads would end up as 60-mil pads with 39-mil holes
[05:42:14] <SWPadnos> which is big enought o fit the 0603 dual-LED into :)
[05:43:25] <SWPadnos> on the ARM thing: Atmel has similarly priced chips to NXP, and they actually provide gcc/GNU tools with their devkits
[05:43:40] <SWPadnos> I'm pretty sure there's a Linux config for them as well
[05:43:56] <SWPadnos> (I know Linux will run, it's a question of how much and how easy it is to get there)
[05:43:58] <elson> I had Tango from the original mostly DOS, Protel-written Tango, up until their abominable rewrite from the ground up, then switched to Protel Adv PCB for windows, P95. I demoed P98, it was a total bomb, and we didn't buy it. P99 was also bad, I can't recall, but maybe we skipped that too, until the first cut at P99SE came out.
[05:44:47] <SWPadnos> heh - similar at my company. Tango from the very early days (late /80s?), then on to P-Cad when the terrible rewrite happened
[05:45:14] <elson> There's a Linux gcc compiler for the NXP line, I don't know if they suport all processors in the family.
[05:46:21] <elson> I guess I will have to look into the Atmel line, too, just to know what is available. I was getting real close to ordering some of the NXP chips.
[05:46:57] <SWPadnos> There's also a line from Micrel which is apparently pretty inexpensive
[05:47:10] <SWPadnos> that's what's on the Messa 4C81
[05:47:14] <elson> This shrinking of the US electronics industry is a total black disaster! Every time I look up a part, suddenly there's a 5000 piece minimum order!
[05:47:28] <SWPadnos> it has several ethernet ports and other stuff
[05:47:31] <SWPadnos> heh
[05:47:42] <SWPadnos> http://www.atmel.com/dyn/products/product_card.asp?part_id=3754
[05:47:48] <SWPadnos> http://search.digikey.com/scripts/DkSearch/dksus.dll?Cat=2556109;keywords=at91sam7x
[05:48:03] <fenn> better move to china :P
[05:48:19] <elson> Ugh, I don't think I could ever learn the language.
[05:48:27] <SWPadnos> just point and eat ;)
[05:49:41] <fenn> how did you get that digikey search url?
[05:49:52] <SWPadnos> from the URL in Mozilla
[05:50:10] <SWPadnos> does it work?
[05:50:25] <elson> Well, I've just had a couple incidents this year where I bought 10 pieces of something from Digi-Key, had prototype boards made, debugged them, and then 2-3 months later, went to order a few hundred pieces for small production, and they won't sell me less than 5000 of whatever it was! Scary!
[05:50:35] <fenn> oh, i see. the arguments go away when you use the parametric filters
[05:51:17] <elson> Yeah, digikey's search stuff, and the on-line availability of practically every datasheet is a big plus! Keeps me coming back!
[05:52:00] <fenn> you can't get a url to point to the result of your careful narrowing down of 50,000 results to 20 or 30
[05:52:22] <SWPadnos> that's about as annoying as sending a complete parts order to a quick-turn house, having them ignore the fact that you already had enough parts for 10 boards, come back with a $35000 parts cost (for those same 10 boards), then send it back to Digikey where they neglect to combine identical parts, so you get an order with qty. 11 of a part 40 times, rather than qty. 400 once
[05:52:40] <SWPadnos> and then all this takes so long that one of the precision parts you need goes out of stock, which it still is
[05:52:49] <elson> Well, thanks for the info, Steve, and I need to try this before I hit the sack. Good to see you, Fenn, too.
[05:52:58] <SWPadnos> sure. good luck :)
[05:53:42] <SWPadnos> Atmel is available from Avnet though, so there are multiple vendors :)
[05:53:50] <elson> Ugh, that's why I build everything myself, and why I'm slowly going blind!
[05:54:06] <SWPadnos> yes, that's why I've been thinking about P&P lately ;)
[05:55:06] <elson> I can highly recommend the Philips CSM84. There are a LOT of them around, I got mine, with 50 feeders, manuals, etc. for $1500! A total steal!
[05:55:24] <SWPadnos> I only have one garage
[05:57:44] <elson> Well, I had to do a SERIOUS rearranging of my basement, throw out a bunch of old crap, and restack the entire rest of the shop, to make room for it. It was WORTH IT, though. Damn, It did the back of these boards with out nuclear signal ASIC boards with 138 parts in 3.5 minutes! I never did time the front because I was having a lot of feeder problems, and hand-feeding it some parts, but it wasn't much slower on that side. Shees
[05:57:44] <elson> h, I did 18 boards in ONE EVENING!
[05:58:55] <SWPadnos> yeah. these boards have 264 parts on them
[05:59:05] <SWPadnos> many are 0603, which I can hand-solder very easily
[05:59:24] <SWPadnos> there are 7 0.5-mm pitch chips though
[05:59:35] <SWPadnos> one is a 64-pin TQFP, which is not trivial
[05:59:52] <SWPadnos> and then the 6 10-pin tiny ones
[06:00:16] <SWPadnos> on the bright side, I only got 1/3 of the tantalums backwards in the design :)
[06:00:17] <elson> If you get the feeders for the most-often used parts close to where the board sits, it can do better than one a second. If you can have two nozzles available, it will pick two, then move to the board and place two at almost the same time.
[06:00:35] <SWPadnos> yep - I've seen that in action
[06:02:37] <elson> The nuclear ASIC board has 2 128-pin 10x14 mm chips at 0.5mm, and a bunch of other SSOP and CSP parts. The machine aligns the big ones in the mechanical aligner, and visual inspection after mounting shows they are DEAD on. I have been getting too much solder paste on the board, and the chips float away on a lake of solder. I've been using 0.005" shim stock for solder stencils, and have to go to .003" on the next ones I make.
[06:03:36] <SWPadnos> yeah. I think the angle of the stencil cutouts is important as well
[06:03:44] <SWPadnos> I don't remember which way it's supposed to go though
[06:04:01] <elson> I did a bunch of my stepper/PWM controller boards with the 144-pin TQFP, and it did those real well.
[06:05:34] <elson> Well, I made mirror-image films straight from Protel on my laser photoplotter, and then laminated dry-film PCB resist to the shim stock, and exposed and developed it like it was a double-sided PCB. There was a lot of etchback, and the side walls of the apertures look like hell, but the solder paste applies just beautifully.
[06:05:52] <SWPadnos> well, I think it may be getting towards bedtime for me. good night, good luck with the machine
[06:06:21] <SWPadnos> hmmm. I think the conversation I had about stencil shapes was ~8 years ago, so it's a little hazy now :)
[06:06:24] <elson> OK, thanks, and if you want to discuss this P&P stuff some more, a have learned a fair bit on this journey.
[06:06:43] <SWPadnos> cool. I'll look around for one of the Philips units - thanks for the model number
[06:07:30] <elson> There are a bunch of variants - VZ has vision and computer controlled Z on the vision head. Mine has none of that stuff, probably why it was so cheap.
[06:07:43] <elson> Good night!
[12:46:20] <jepler> hm .. it appears that git-cvsimport has some trouble with files created on branches before being created on TRUNK
[12:46:32] <jepler> some stuff in debian/extras is missing from the git repository
[12:46:49] <jepler> but I'm *this close* to having a gutsy gibbon package set (kernel, rtai, emc2)
[12:52:43] <skunkworks> gutsy gibbon? what the heck is gutsy gibbon?
[12:52:52] <jepler> ubuntu 7.10
[12:52:54] <jepler> the next one
[12:53:28] <skunkworks> yikes - I am out of the loop. I thought we were still on fiesty fawn.. :)
[12:54:17] <jepler> we are .. for the next week or two
[12:59:35] <alex_joni> jepler: aren't we going to wait for 8.04 LTS ?
[13:03:31] <skunkworks> alex_joni: hush
[13:03:33] <skunkworks> ;)
[13:14:01] <skunkworks> jepler: if you need someone to test.. I like doing that sort of thing.
[13:34:46] <jepler> cradek: fenn: I am unsure about the change to emcTrajSetAxes. With trivkins the highest used axis.N will depend on the highest axis letter.
[13:36:13] <jepler> take an XZ lathe for instance. It looks like you get axes=3 deduced_axes=2
[13:39:09] <jepler> while you can use a kinematics module to make axis.0 and axis.1 be the only axes used in HAL, I suspect you'll hit more UI bugs, such as axis looking at the [AXIS_2] ini section for Z soft travel limits but emc looking in [AXIS_1]
[13:39:12] <alex_joni> I think he said it doesn't get called for trivkins, or something like that
[13:40:07] <alex_joni> 06:49 < SWPadnos> I wonder how XYUV works then ... ??
[13:40:09] <alex_joni> 06:50 < fenn> SWPadnos: it uses trivial kinematics so it never calls
[13:40:09] <alex_joni> emcTrajSetAxes
[13:40:43] <jepler> I am surprised to hear that.
[13:41:05] <jepler> emc configs/sim/lathe.ini
[13:41:06] <jepler> emcTrajSetAxes failing: axes=3 axismask=5
[13:41:51] <jepler> (presumably, deduced_axes=2 here)
[13:42:57] <SWPadnos> I guess the question is, is it possible to make an XZ, XYUV, or XYZC setup with fenn's change?
[13:43:06] <SWPadnos> even if the ini needs to be a little different
[13:43:33] <SWPadnos> I'm hoping he loaded the scara config as a test before checking in :)
[13:46:05] <jepler> I think the more important question is: what benefit does the existing emc user with a lathe get in return for the changes required to his ini and hal files?
[13:46:34] <SWPadnos> oooh. that is a good question
[14:37:47] <fenn> there's only 2 axes so why would you say axes=3?
[14:39:45] <fenn> maybe i should have looked at this a bit more, i thought it was simple
[14:40:16] <cradek> AXES was used to give the highest active axis number in the order XYZABCUVW
[14:40:42] <cradek> if it's a simple count of the number of active axes, it's not needed at all
[14:41:15] <fenn> would it hurt anything if i got rid of the axes == deduced_axes check?
[14:41:50] <cradek> well I don't understand the issues or the change you made, but I had previously read the docs about how to set AXES=
[14:44:15] <cradek> http://www.linuxcnc.org/docs/devel/html/config/ini_config/index.html#hue432
[14:48:58] <fenn> i started giggling when i saw this: localEmcAxisAxisType[axis] = axisType
[14:49:24] <cradek> yargh
[14:49:24] <fenn> considering they're joints anyway
[14:49:41] <SWPadnos> localEmcProgrammerLookingForAJob
[14:52:16] <cradek> fenn: if you have changed the semantics please be sure to change the docs to match
[14:53:53] <fenn> i didnt mean to change the semantics
[14:54:46] <SWPadnos> the semantics may not work for other kins like puma/scara
[14:54:52] <SWPadnos> (the old ones)
[14:54:59] <fenn> no, i think it works, i just didnt know what AXES= did
[14:55:12] <SWPadnos> ok
[14:56:15] <fenn> i'm not saying i like the semantics..
[14:56:47] <SWPadnos> it does seem more "natural" to say you have 2 axes for your XZ lathe
[14:56:54] <cradek> the way AXES is described in that help, I can't imagine any reason why the user has to figure it out
[14:57:19] <cradek> "something = X Z"
[14:57:39] <cradek> then if emc has to count to 2 or 3 or 9 for something or other, whatever
[14:58:37] <fenn> well, on the scara say you have X Y Z C and AXES=6
[14:58:52] <fenn> then you get axis.0 axis.1 axis.2 axis.5
[15:00:28] <fenn> hopefully
[15:02:17] <cradek> hal "axes" are joints, and I don't see why they should be numbered 0 1 2 5
[15:04:17] <fenn> ok, you get axis.0 axis.1 axis.2 axis.3 axis.4 axis.5
[15:04:38] <fenn> and following error on joint 3
[15:04:59] <cradek> what a cluster
[15:05:15] <fenn> i think the axes declaration is crap
[15:05:28] <fenn> if you type in X Z it should make joints 0 and 2
[15:05:39] <SWPadnos> not necessarily
[15:05:43] <cradek> why 0 and 2?
[15:05:44] <fenn> or 0 and 1
[15:05:56] <SWPadnos> if you as a user have XZ, that has no relationship to the HAL joint numbering
[15:06:02] <SWPadnos> they could be 347 and 199
[15:06:17] <SWPadnos> except that you need to be able to configure them
[15:06:44] <SWPadnos> for trivkins, this is simple - put an axis label in the AXIS_N section
[15:07:09] <SWPadnos> for non-trivkins, it's not so easy (and I don't have a solution there)
[15:08:19] <SWPadnos> oh, and rename AXIS_N to JOINT_N
[15:08:35] <fenn> hmm
[15:08:47] <fenn> i agree with you in theory
[15:08:48] <cradek> no, the limits in there (vel, accel, min, max, etc) are axis limits
[15:09:10] <SWPadnos> for non-trivkins, there need to be 2 sets of limits
[15:09:27] <fenn> no, you only really need joint limits
[15:09:31] <SWPadnos> there are still joint limits, and also machine limits that can't be derived from them
[15:09:36] <SWPadnos> no, you need both
[15:09:51] <fenn> you need to be able to define a work envelope
[15:10:03] <fenn> i dont think defining max cartesian velocities/accels is very important
[15:10:19] <fenn> except for an overall vector velocity limit
[15:10:22] <SWPadnos> it sure is
[15:10:45] <SWPadnos> ok, an overall vector limit may be all that's needed, but I'm not sure of that
[15:11:06] <fenn> if the user needs something complicated they can hack it together in hal or a C module
[15:12:11] <fenn> if ((moon == full) && (gyre == widdershins)) { double bubble = toil(trouble);}
[15:12:41] <SWPadnos> I think that's double dubble = toil(trouble); :)
[15:13:24] <fenn> Fillet of a fenny snake, In the caldron boil and bake
[15:13:34] <SWPadnos> heh - you looked that up
[15:13:49] <skunkworks> fastest google in the west
[15:14:15] <SWPadnos> but that's got to be a couple of lines later, because "fire burn and cauldron bubble" is the next line I remember
[15:15:23] <skunkworks> I don't think shakespeare and emc2 mix very will
[15:15:43] <SWPadnos> yea, verily
[15:26:40] <fenn> shouldnt trivkins be the one exporting axis.* pins?
[15:27:19] <SWPadnos> that would be an excellent and far-reaching change ...
[15:27:43] <fenn> far-reaching?
[15:28:00] <SWPadnos> the problem is, the TP needs intimate knowledge of the kins limits to be able to do its job
[15:28:13] <SWPadnos> so you can't make kins a separate HAL module very easily
[16:10:27] <fenn> well i'd love to play but it seems i should be working today, so i guess i'll just revert my change so as not to get in everyone's way
[18:25:40] <skunkworks> * skunkworks is staring at a gutsy gibbon live cd.
[18:28:39] <jepler> skunkworks: I'll put the packages somewhere you can get them, if you really are wanting to try it
[18:28:54] <skunkworks> sure - I have a few computers here to play with.
[18:30:23] <jepler> it has been tested on a grand sample of 1 computers controlling 0 machines
[18:31:34] <skunkworks> heh
[18:32:13] <jepler> for a total of 12 minutes
[18:32:35] <skunkworks> ship it!
[18:40:44] <alex_joni> heh
[18:40:49] <alex_joni> who needs testing, eh?
[18:41:07] <alex_joni> jepler: is that 2.6.20 based?
[19:20:52] <highoctane> highoctane is now known as highoctanexp
[19:21:16] <highoctanexp> highoctanexp is now known as highoctane
[19:52:08] <skunkworks> logger_dev: bookmark
[19:52:08] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-09-21.txt
[20:02:04] <jepler> alex_joni: 2.6.22.6
[20:02:35] <jepler> the uploads to linuxcnc.org/experimental/gutsy/ are in progress but will probably run for an hour or more
[20:07:14] <skunkworks> the install is up to 122% done ;)
[20:08:10] <skunkworks> which I think is a bit odd.
[20:32:31] <skunkgibbin> so - I install the 2 debs? then build the emc2 from the gz?
[20:33:10] <skunkgibbin> 3 debs I mean
[20:34:01] <cradek> looks like the 3 debs will give you a prebuilt install of emc
[20:34:10] <cradek> the tar.gz is just the corresponding source package
[20:34:17] <skunkworks> ah
[20:34:18] <skunkworks> ok
[20:35:50] <jepler> skunkworks: you'll need to eventually install kernel-image, rtai-modules, and emc2
[20:35:54] <jepler> but they're not all uploaded yet
[20:36:02] <skunkgibbin> ah
[20:36:18] <jepler> but my upload seems to be stuck
[20:36:27] <jepler> 74% on linux-source
[20:36:27] <skunkgibbin> I just tried to install the magma and it said it was corrupted - that make sense
[20:36:55] <cradek> jepler: this rtai seems to work right for you?
[20:37:23] <jepler> cradek: yes, it ran the rtai latency testsuite, the emc latency-test, emc 'sim', and emc/hal testsuite
[20:37:32] <cradek> is it smp?
[20:37:34] <jepler> no
[20:37:40] <jepler> once I turned off smp it started working reliably :-P
[20:37:43] <cradek> haha
[20:37:54] <cradek> that sucks but I sure sympathize
[20:38:21] <cradek> does it boot with the splash screen?
[20:38:28] <jepler> I turn that off everytime
[20:38:34] <jepler> also I think it doesn't have any 'firmware's
[20:40:10] <jepler> there's /lib/firmware/2.6.22-11-generic (the current gutsy kernel) but no /lib/firmware/2.6.22.6-magma
[20:41:02] <cradek> alex might know something about that stuff
[20:47:04] <skunkworks> can you install rip the same way (wiki directions?)
[20:48:46] <jepler> skunkworks: yes sure
[20:49:02] <jepler> but in that case you'll need linux-image, linux-headers, rtai-modules, none of which are uploading yet
[20:49:03] <skunkworks> how big is the magma deb? I see it is 40mb so far
[20:49:09] <skunkworks> ah
[20:49:13] <skunkworks> no rush.
[20:49:15] <jepler> looks like another 3 minutes on the linux-source
[20:49:28] <skunkworks> I just had some time
[20:49:30] <jepler> (which you don't even "need"; I just include it so that I discharge my GPL oblications)
[20:50:42] <cradek> jepler: a lot fewer bytes in a "written" offer
[20:51:14] <SWPadnos> where are the files going right now?
[20:51:39] <jepler> linuxcnc.org/experimental/gutsy
[20:51:39] <cradek> linuxcnc.org/experimental/gutsy/
[20:51:44] <cradek> gusty?
[20:51:54] <jepler> ubuntu 7.10 codename gutsy gibbon
[20:51:55] <SWPadnos> oh - heh
[20:52:11] <SWPadnos> I didn't see the dir name because it's dark blue on a black background :)
[20:56:33] <SWPadnos> jepler, can you upload the kernel .config also?
[20:56:49] <jepler> SWPadnos: you mean separately from the kernel-source?
[20:56:52] <SWPadnos> yes
[21:01:19] <fenn> i think the .config is the more important of the two
[21:01:57] <SWPadnos> yep. it provides a nice starting point for other kernel versions
[21:02:09] <SWPadnos> or if you already have the K-O source
[21:09:49] <jepler> http://linuxcnc.org/experimental/gutsy/linux-2.6.22.6-magma.config
[21:09:57] <jepler> K-O?
[21:10:19] <SWPadnos> Kernel Org
[21:10:24] <jepler> ah
[21:10:42] <SWPadnos> I considered after writing that that I should have just written "vanilla" instead
[21:11:40] <skunkworks> this 1.3ghz rambus machine isn't the quickest on the block
[21:11:59] <skunkworks> granted - it only has 256mb
[21:19:16] <jepler> did I say "an hour"? I meant "hours"
[21:19:49] <SWPadnos> you have 384k uploads, right?
[21:20:09] <jepler> yeah
[21:20:22] <jepler> `linux-image-2.6.22.6-magma_0.linuxcnc.1_i386.deb' at 50808713 (26%) 39.9K/s eta:62m [Sending data]
[21:20:46] <SWPadnos> that's not too bad - max is 48kB/sec
[22:04:27] <jepler> and now I got the firmware and ubuntu-provided modules to (mostly) build but that's another 16 megs to upload
[22:21:31] <jepler> skunkworks: I'll let you know when linux-image is done transferring
[22:21:37] <jepler> still not quite done, about 5 minutes
[22:22:09] <jepler> to repeat, I think you need: linux-image, rtai-modules (not uploaded yet) and emc2 .deb packages
[22:22:55] <jepler> there will probably be other packages which you'll be told about when you try to install those, but they should come from standard repos (remember to enable universe)
[22:23:57] <jepler> skunkworks: linux-image complete
[22:25:38] <skunkworks> thanks
[22:28:14] <jepler> rtai-modules complete
[22:28:33] <jepler> I think that's everything you need that you can't get from ubuntu repos
[22:44:34] <SWPadnos> hmmm. so a generic modbus driver isn't the easiest thing to design
[22:52:36] <jepler> be back later
[22:52:52] <jepler> SWPadnos: I just assumed there was something about modbus I didn't understand
[23:04:55] <SWPadnos> heh
[23:05:23] <SWPadnos> I have a relatively recent version of libmodbus (one of them at any rate - there are two projects of that name)
[23:05:40] <alex_joni> 'lo
[23:05:49] <SWPadnos> I have a program that can read and write registers on a GE/Fanuc PLC via modbus over serial line
[23:05:52] <SWPadnos> hi Alex
[23:06:08] <alex_joni> * alex_joni blames the afternoon sleep
[23:06:29] <SWPadnos> it's pretty easy to get the data over the wire, but how to define what's expected to be at the other end - that's a bit of a problem
[23:09:41] <SWPadnos> argh.
[23:09:53] <SWPadnos> for steppers, it should be OUTPUT_SCALE, not INPUT_SCALE
[23:10:00] <SWPadnos> </end rant>
[23:10:04] <alex_joni> * alex_joni looks away
[23:26:33] <fenn> SWPadnos: do servos even use OUTPUT_SCALE anymore? why not just name it SCALE and be done with it
[23:26:55] <alex_joni> fenn: I think TRUNK already supports it
[23:27:25] <alex_joni> otoh, it's always a thing to remember not to make config changes lightly
[23:27:46] <SWPadnos> servos should use it, there's no guarantee you'll be using step output for a servo
[23:27:58] <SWPadnos> that would be the analog scale for an analog drive
[23:29:26] <fenn> i dont see why scale is in .ini and not in hal
[23:29:48] <alex_joni> because all settings are in the ini
[23:29:55] <alex_joni> even scale which gets used in the hal file
[23:30:04] <SWPadnos> the only reasons to have that stuff in the ini are so it's easier to port EMC configs, and so all the settings are in one place
[23:30:21] <SWPadnos> that's why the variable replacement stuff was done in halcmd
[23:31:01] <fenn> ok, so hal is more like 'code' and ini is 'data'
[23:31:06] <SWPadnos> no
[23:31:17] <SWPadnos> well, no, not really
[23:31:45] <SWPadnos> halcmd setp stepgen.0.scale [AXIS_0]SCALE
[23:32:01] <SWPadnos> sure, the halcmd "command" is soing the work, and the data comes from the ini
[23:32:05] <SWPadnos> doing
[23:32:48] <SWPadnos> hal files have the arrangement of things, and the ini has numbers that make the arrangements work well
[23:33:34] <fenn> i'm thinking, a "stepper based mill" is a somewhat generic abstraction and that's what makes it code-like; you can run various specific setups through this layout without changing any of the hal wiring
[23:33:59] <fenn> i think that's why programmers like hal and users like .ini's
[23:36:13] <SWPadnos> heh
[23:36:15] <SWPadnos> could be
[23:36:22] <SWPadnos> that's a fair way to think of partitioning it
[23:37:29] <SWPadnos> that was another reason for adding the variable replacement stuff - it allowed users to not have to think about the machine is set up, they only have to think about the things that are different from machine to machine
[23:38:14] <fenn> well, to be fair, you could just put all the setp's in their own hal file
[23:38:59] <SWPadnos> true
[23:39:10] <fenn> i think hal needs to have more layers of discovery before that can happen
[23:39:19] <SWPadnos> and that has the advantage of causing EMC to not load if the user makes a typo
