Back
[00:10:26] <mozmck2> argh! this gets aggravating!
[00:10:30] <mozmck2> ubuntu-lucid/drivers/usb/core/hcd.c:144: error: expected expression before '>>' token
[00:10:32] <SWPadnos> heh
[00:10:45] <SWPadnos> patch gone wrong
[00:11:02] <mozmck2> I compiled this fine the other day and now it does this!
[00:11:10] <SWPadnos> did you patch in between?
[00:11:26] <mozmck2> no, changed one measly little config option!
[00:11:29] <SWPadnos> that's the kind of error you get when a patch doesn't quite work
[00:11:32] <SWPadnos> huh
[00:12:01] <SWPadnos> what kernel version is that? 2.6.32.soemthing>?
[00:12:36] <mozmck2> I had this problem on Karmic as well, just when I created a branch. I redid everything on master and it worked fine.
[00:12:49] <mozmck2> then I tried making a branch again and it worked fine that time!
[00:12:59] <mozmck2> 2.6.32.something
[00:13:34] <SWPadnos> oh. the KERNEL_VER or KERNEL_REL may have spaces in them
[00:13:50] <SWPadnos> somewhere in the make/config files
[00:14:39] <mozmck2> thanks. I'll take a look. right now I've got to go to the shop for a while. take some frustration out on some wood! :)
[00:14:44] <SWPadnos> heh
[00:14:52] <SWPadnos> ever get that IO board working?
[00:15:12] <mozmck2> no, got side-tracked.
[00:15:20] <SWPadnos> ah. happens to the best of us
[00:15:25] <SWPadnos> or at least the rest of us :)
[00:15:26] <mozmck2> hopefully I'll work on it tonight (late)
[00:15:38] <mozmck2> bbl
[00:15:50] <SWPadnos> see you
[02:51:59] <mozmck2> SWPadnos: thanks for the tip about KERNEL_VER or KERNEL_REL.
[02:52:08] <SWPadnos> sure
[02:52:16] <SWPadnos> that was what was on the line you mentioned :)
[02:52:29] <mozmck2> I had added -rtai to the version in the changelog, so I changed it to .rtai and it seems to be working
[02:53:26] <mozmck2> yeah, I had seen that before but I couldn't figure out anything. The mention of spaces made me think it could be my extension on the changlog version
[02:53:36] <SWPadnos> ah
[04:56:40] <mozmck2> does emc need rtai_shm?
[06:57:53] <alex_joni> mozmck_work: yes
[06:58:15] <alex_joni> it "might" work with rtai_shm compiled in, but during testing I found having it separate is a bit easier to test with
[07:19:10] <alex_joni> mozmck_work: hi, you looked for me last night?
[07:19:30] <alex_joni> err.. right, mozmck was it ;)
[07:19:34] <alex_joni> sorry.. was tired ..
[07:35:04] <micges_work> hi alex_joni
[08:16:59] <CIA-2> EMC: 03micges 07joints_axes3 * r8bd148a74f5f 10/src/emc/motion/ (motion.c motion_debug.h usrmotintf.cc): Remove motion debug structure fields used to debug TP before HAL was introduced
[11:43:52] <micges_work> alex_joni: re joints_axes3: I think that it should be possible to teleoperating jogging UVW axes
[11:45:12] <micges_work> cradek: around?
[11:45:48] <micges_work> I want to merge master into ja3 and I wonder if it caouse flood of commit messages?
[12:19:39] <cradek> I don't think it will cause more than a few - do it and see :-)
[12:20:32] <micges_work> ok :)
[12:20:59] <aystarik> cradek, did you see my e-mail about velocity calcs?
[12:21:53] <cradek> yes but I don't know the answer, sorry. looks like you are on the right track.
[12:22:00] <cradek> bbl, getting ready for work
[12:23:29] <CIA-2> EMC: 03micges 07joints_axes3 * r42e9d0b09c04 10/src/emc/motion/ (command.c control.c motion.c motion_debug.h): Rename coord mode trajectory planner structure according to new naming convention
[12:41:13] <alex_joni> mozmck_work: cool
[12:46:55] <alex_joni> I meant micges_work who timed out
[13:23:04] <CIA-2> EMC: 03micges 07joints_axes3 * r8b543dc77baf 10/ (334 files in 69 dirs): Merge branch 'master' into joints_axes3
[13:44:08] <mozmck> hey alex_joni. That was in the morning here! I thought it would be daytime there.
[13:45:44] <mozmck> emc compiled and ran without the rtai_shm module.
[13:50:07] <JT-Work> Ouch! a replacement tank for my way lube on the Hardinge cost $506
[14:01:07] <alex_joni> 16:45 < mozmck> emc compiled and ran without the rtai_shm module.
[14:01:11] <alex_joni> for time reference
[14:02:05] <cradek> yay, the merge must have worked out
[14:06:50] <mozmck2> alex_joni: 8:44 here
[14:08:42] <mozmck2> I had to recompile the kernel with MODVERSIONS disabled to get it to run. It may be a regression in rtai magma
[14:09:27] <SWPadnos> I thought that was in the RTAI building instructions - you had to disable MODVERSIONS before too
[14:09:38] <SWPadnos> (our wiki page, not their instructions)
[14:11:19] <mozmck2> used to be, but not supposed to have to do that as of 3.7 I believe
[14:11:28] <SWPadnos> huh
[14:12:12] <mozmck2> I have done several kernels with MODVERSIONS using rtai 3.7.1 and 3.8 without any problem
[15:05:50] <micges> hi seb_kuzminsky
[15:09:41] <micges> cradek: merge was little complicated but I managed to solve all conflicts
[15:09:54] <cradek> yay
[15:10:07] <micges> I'm glad that it is one commit not ~300 :D
[15:10:29] <cradek> yep that's nice
[15:10:44] <cradek> wish you could come to cnc workshop in june
[15:11:27] <micges> it would be cool
[15:12:21] <skunkworks_> micges: have you been this side of the pond?
[15:12:32] <micges> we could make huge progress in many areas
[15:12:37] <micges> nope
[15:13:59] <micges> skunkworks_: I never travelled by plane yet
[15:14:14] <micges> I like car driving better (but longer)
[15:14:20] <cradek> I do too
[15:14:48] <skunkworks_> oh - well my first time was only a few years ago.. And it was a 7hour flight to ireland :)
[15:15:10] <micges> skunkworks_: and how old are you?
[15:15:14] <skunkworks_> 37
[15:15:37] <micges> oh so I have time :) I have 26
[15:15:46] <skunkworks_> heh
[15:16:16] <skunkworks_> wait - 36
[15:16:41] <cradek> heh, I have that problem too
[15:17:11] <skunkworks_> we could bring the puma - but I doubt if it will be anyway close to being something moveable.
[15:17:26] <skunkworks_> The k&t is getting the focus.
[15:18:25] <skunkworks_> we have all the drives we need - but we still have not looked to see if the encoders are quadature
[15:43:47] <skunkworks_> how hard is it to increase the number of tools?
[15:44:16] <skunkworks_> I remember it being defined somewhere - but I also remember there being an issue with a size limit between emc layers.
[15:44:45] <cradek> there is no longer a limit on tool numbers
[15:45:08] <cradek> do you mean pockets or tools?
[15:46:27] <skunkworks_> well - We can have tool numbers up to 32767 (only 60 pockets)
[15:47:03] <skunkworks_> oh - so if it is in the tool table - emc can pick it?
[15:47:28] <cradek> yes, no problem with any of those tool numbers
[15:47:58] <skunkworks_> ok - for now - I am going with the tool chain finding the tool - vs emc knowing what pocket it is in.
[15:48:17] <cradek> if you want emc to keep track of what tool is in what pocket, though, you need 60 pockets
[15:48:36] <cradek> currently it looks like emc can deal with 56 pockets. you can increase it if you want.
[15:48:42] <cradek> (you would have to recompile)
[15:49:03] <cradek> ok, with your scheme, it doesn't matter and you can use any tool numbers you want.
[15:49:18] <skunkworks_> this is going to be cool :)
[15:53:54] <skunkworks_> and it looks like the idea of latching the fingers - then readin them on the rising edge of the prox/reseting on the falling edge is going to work also.
[15:54:52] <cradek> cool, that sounds like a very robust way of doing it.
[15:59:14] <skunkworks_> so - it reads each tool - compares it to the tool prep number - then when if finds it - move ahead 2 pockets - clamp. (seems easy enough ;)
[16:01:20] <cradek> yep sounds simple. but I notice you can't just put the tools in order in adjacent pockets and have it work well - you'd need to interleave them 3 or 4 apart
[16:01:27] <cradek> which is kinda freaky
[16:01:55] <skunkworks_> what do you mean?
[16:02:19] <skunkworks_> oh - you mean evenly space all the tools around the chain?
[16:05:09] <cradek> yes if it uses up 3 pockets to find the tool and load it, you'd want to space them 3 apart or so
[16:06:00] <cradek> otherwise it would always have to make a complete circle
[16:10:07] <cradek> http://en.wikipedia.org/wiki/Interleave
[16:10:38] <cradek> gotta love "Writting Worst Case Pattrn."
[16:22:16] <skunkworks_> heh
[16:24:14] <skunkworks_> the maching operations just need to be long enough that there is time for the chain to make a complete cycle ;)
[16:24:45] <cradek> true but my way is better!
[16:25:14] <skunkworks_> of course! :)
[16:25:23] <cradek> you could always have it back up three before it searches again...
[16:25:34] <skunkworks_> oh - interesting...
[16:25:35] <cradek> that would be a simple hack that would help a lot
[16:26:18] <skunkworks_> that would require some plumbing.. (the hydraulics is only setup to run one dirction)
[16:26:31] <cradek> haha, hydraulics
[16:26:53] <cradek> do you mean that would require tearing out some hydraulic crap and putting a motor there? :-)
[16:27:23] <skunkworks_> well - that is one solution... We are always going to need hydraulics though...
[16:27:32] <cradek> ah
[16:28:37] <skunkworks_> pallet clamping, table rotation lift, gear shifting, counterbalance, tool change arm, pallet stations.
[16:29:59] <cradek> how long do you think until it moves and homes?
[16:30:17] <skunkworks_> month (I hope)
[16:31:03] <skunkworks_> depends on how much dad works on it. Hi dad! ;)
[16:31:25] <skunkworks_> retirement has made him soft ;)
[16:31:37] <cradek> ha
[17:55:40] <KimK> Hi cradek , Hi skunkworks
[17:56:46] <cradek> hey
[17:57:15] <LawrenceG> ho
[17:58:21] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[18:00:48] <KimK> Not adding an encoder to the tool chain drive sprocket?
[18:02:23] <skunkworks_> KimK: not yet... I think it will work 'well' as it. (reading the rings)
[18:05:17] <skunkworks_> KimK: did you see this?
[18:05:18] <skunkworks_> http://electronicsam.com/images/KandT/conversion/Toolreader.JPG
[18:13:21] <awallin> mechanical bar-code?
[18:13:49] <skunkworks_> yes :)
[18:14:52] <skunkworks_> 15 rings
[18:57:51] <KimK> skunkworks: Yes, very impressive. But a good "comb" for chips and swarf, maybe? Are you sure you can't "observe" the tool chain instead in a more conventional manner? Just thinking out loud here.
[18:58:40] <alex_joni> hi skunkworks_'s dad
[18:58:48] <alex_joni> hi guys
[19:00:07] <micges> hi alex
[19:01:30] <alex_joni> "The truth may be out there, but lies are inside your head."
[19:02:06] <cradek> no, some lies are pretty out-there
[19:05:30] <alex_joni> AIRPORTS: A place where people hurry up and wait.
[19:05:30] <alex_joni> -- From A Scientific Encyclopedia for the Enquiring Young Nome
[19:05:30] <alex_joni> by Angalo de Haberdasheri
[19:07:42] <skunkworks_> KimK: I think air was blown thru the switch to clean the swarf off.
[19:07:50] <skunkworks_> (atleast there was a connection.)
[19:08:13] <skunkworks_> they are pretty hard to press.. I bet they would move the swarf out of the way
[19:08:14] <CIA-2> EMC: 03micges 07v2.4_branch * r4ca13e5d0674 10/src/emc/rs274ngc/rs274ngc_return.hh: Remove unused string after merge of tlo_all_axes
[19:11:57] <KimK> OK. Well, I was just thinking that if it knew that the next tool was in such-and-such pocket, it wouldn't have to search, just go there immediately. Do your pockets have a good place to put a pocket number?
[19:12:53] <cradek> KimK: we keep telling him and telling him that, but does he listen? no!
[19:13:31] <skunkworks_> heh - I really am taking the easy way out at the moment.
[19:14:04] <cradek> although I think the way he wants to do it is cool too. you can just put the tools wherever. you can write their number on them with a sharpie and it'll stay the same forever. extremely simple.
[19:14:34] <alex_joni> why write a number?
[19:14:43] <alex_joni> I'm sure most in here read binary just fine
[19:14:55] <cradek> those look a little hard to read...
[19:15:29] <cradek> I need a biggish end mill - what's in the machine - ok there's one - it says 12345 on it
[19:15:30] <alex_joni> hmm.. get stricky without a reference
[19:15:43] <cradek> I do that all the time
[19:15:53] <KimK> Sure, hi-lo-lo-hi-hi... oops, I mean one-zero-zero-one-one...
[19:16:07] <cradek> but I have to count pockets - then look in the tool table and find the tool number for that pocket - then load the tool
[19:16:08] <skunkworks_> anything over 4 bits and i get confused.
[19:16:52] <skunkworks_> There is actually a little card from K&T that you would hold up to the rings to calculate the tool number. We need to find that agian.
[19:16:57] <skunkworks_> cheat sheet
[19:17:01] <alex_joni> skunkworks_: but at least you're used to it
[19:17:01] <cradek> neat
[19:17:33] <cradek> you could keep your tool numbers in octal - might be a bit easier to read them.
[19:17:39] <alex_joni> you could also build a small hand reader
[19:17:39] <cradek> can't do hex unfortunately, since they have to be integers.
[19:17:53] <alex_joni> couple switches + led's, and a micro which displays the number
[19:18:11] <skunkworks_> cradek: I 'think' that is how it was setup on the k&t - 5 sets of 3 rignts
[19:18:12] <skunkworks_> rings
[19:18:30] <cradek> yeah I can see how that'd be easy to read
[19:18:30] <KimK> Hey, maybe you could use one of those point-of-sale laser scanners?
[19:18:32] <skunkworks_> alex_joni: we have another readhead..
[19:18:46] <alex_joni> skunkworks_: one that you can easily carry?
[19:18:54] <alex_joni> KimK: heh, that's a neat idea
[19:18:55] <cradek> so you'd have tools 00000 to 77777
[19:19:15] <skunkworks_> right (I would have to look at the manual)
[19:19:24] <alex_joni> but going from that, you can just mill barcode on the holder
[19:19:27] <alex_joni> or numbers ;)
[19:19:33] <cradek> well one of those would be invalid, else you couldn't tell if a pocket is empty
[19:20:04] <skunkworks_> heh - right
[19:24:52] <KimK> I vote for making tool 00000 empty, LOL. If tool 77777 (-37777 ?) was empty, well, that's just wrong.
[19:27:35] <cradek> interesting that if you ask for T00000 you could have the ladder say it's already there. you know the pocket right above the spindle is going to be empty
[19:28:32] <cradek> er, duh, no you don't
[19:28:36] <cradek> forget it
[19:31:13] <KimK> Sam, how many of those straight-shank toolholders do you have over there? Anything especially impressive? (6 inch indexable insert facemill maybe?)
[19:33:10] <KimK> And are most of the usual sizes some type of collet holders or more like weldon shanks?
[19:40:32] <skunkworks_> KimK:
http://www.electronicsam.com/images/KandT/conversion/Shellmill.JPG
[19:40:41] <skunkworks_> we have probably 200 holders
[19:43:37] <seb_kuzminsky> mmm, mountain dew
[19:43:58] <skunkworks_> heh - I don't drink it..
[19:44:09] <skunkworks_> plus they would be easy to make...
[19:44:17] <skunkworks_> strait shank tooling
[19:44:19] <CIA-2> EMC: 03micges 07v2.4_branch * r15b145450f4d 10/src/po/pl.po: Updated Polish translations
[19:45:02] <micges> err should be small letter :P
[19:46:29] <cradek> yay for up-to-date translations
[19:49:30] <micges> many peoples here asked for up-to-date translation, not shitty one like polish m.ch version
[19:52:16] <KimK> skunkworks: have you got a big tombstone fixture for it? If not, that should be your first project. Horizontal milling has some advantages.
[19:53:23] <skunkworks_> KimK: this is the one we use a lot - we have some actual box ones also..
[19:53:24] <skunkworks_> http://www.electronicsam.com/images/KandT/DSCCurrent.JPG
[19:53:40] <skunkworks_> horizontals are great for chip removal
[19:53:56] <cradek> that looks wobbly - not enough depth
[19:54:53] <skunkworks_> well - we don't do heavy stuff on it. :)
[19:55:00] <skunkworks_> but it is pretty solid
[19:58:02] <skunkworks_> that was tapped with a floating tap holder. worked ok :) rigid tapping is cooler.
[20:47:31] <micges> cradek: re emc bug report: that is strange:
http://imagebin.ca/view/Ogncx2eT.html
[20:47:41] <micges> running his program
[20:49:28] <alex_joni> micges: using 2.3.5?
[20:49:47] <SWPadnos> 2.5.0~pre
[20:50:19] <alex_joni> err.. right, can't read :/
[20:50:19] <seb_kuzminsky> micges: inconsistent accel being applied?
[20:50:31] <alex_joni> inconsistent blending more likely
[20:50:40] <micges> I think blending conditions
[20:51:08] <alex_joni> from the picture those look like line-arcs to me
[20:51:25] <alex_joni> is it arc or lots of lines?
[20:51:37] <micges> only lines
[20:51:42] <alex_joni> * alex_joni kinda remembers micges touch line-arc blending lately
[20:51:47] <alex_joni> ah, hmm
[20:52:04] <alex_joni> I'd try before that fix
[20:52:12] <micges> ok
[20:53:37] <micges> here it was 2.4 branch, but even after make clean Axis displays wrong emc version
[20:54:02] <micges> so long before blending patch
[20:55:03] <alex_joni> ah, ok
[20:57:55] <alex_joni> micges: is g64 Pxx set?
[20:58:00] <micges> nope
[20:58:13] <micges> building 2.3 for tests
[20:58:47] <micges> it was run emc -> homing -> load program -> run
[20:59:11] <micges> no G64 in ngc
[21:01:41] <micges> ah - ./configure after make clean fixes Axis dispalyed version
[21:02:40] <micges> one thing: in 2.4 branch tool was not visible on Axis preview, in 2.3 it is
[21:10:00] <alex_joni> no G64 means max blending
[21:10:05] <alex_joni> so it depends on the segment size
[21:10:14] <alex_joni> I bet some of those lines are shorter, some longer
[21:10:23] <alex_joni> on the shorter lines blending will be more exact
[21:11:06] <skunkworks_> that makes sense
[21:12:01] <skunkworks_> it has to touch each segment - but if the segment is long - the blend will be bigger - if accel is low reletively
[21:12:58] <micges> alex_joni: you're right
[21:13:24] <alex_joni> sometimes I still am
[21:14:15] <micges> so for now no clue what it was
[21:16:01] <micges> I've got few such incorrect path errors like (it was like some vecotrs was skipped) but I was unable to reproduce them :|
[21:17:04] <micges> here problem was solved by adding G4 P0.001 after few G1 lines, but no idea why :|
[21:17:14] <micges> maybe those two problems are related
