#emc | Logs for 2008-05-26

[00:41:15] <^Fritz> * ^Fritz steps back into the shop
[00:41:25] <^Fritz> Somebody needed to figure how to size resistors?
[00:50:16] <^Fritz> Yeow...she's gonna need 4.7 ohm rated 120W
[00:52:50] <^Fritz> I've got some nice Ohmite resistors, adjustable tap...but I think they're only 50W
[00:54:54] <^Fritz> WTH do they show a resistor for each coil? put one between the common and the power supply.
[00:58:11] <toastydeath> blebleble
[00:58:48] <^Fritz> toasty: Speaking french, are you?
[00:58:57] <toastydeath> I MAY
[01:01:03] <^Fritz> I didn't say simon says
[01:01:49] <cradek> logger_emc: bookmark
[01:01:49] <cradek> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2008-05-26.txt
[01:39:05] <cradek> looks like phoenix made it!
[01:41:40] <jepler> cool
[01:43:23] <cradek> "Sojourner landed on Mars as part of the Mars Pathfinder mission on July 4, 1997."
[01:43:36] <cradek> I can't believe that was 11 years ago.
[01:46:49] <jmkasunich> the older you get the faster time goes
[01:50:11] <cradek> I wasn't very old then...
[01:51:13] <^Fritz> * ^Fritz added brief explanation of computing L/R resistor values in wiki
[01:51:41] <^Fritz> ..under the "stepper formulas" page
[01:56:10] <cradek> thanks, that would have helped jessica earlier
[02:02:04] <^Fritz> Yeah, and I used her values as an example :)
[02:26:30] <jepler> I'm a little surprised to see modern big stepper drivers that use simple L/R design. I guess the price looks attractive (4 10A axes for less than 2 7A axes in geckos) but I'm not sure the results would be that great.
[02:34:00] <^Fritz> It wouldn't take much to add a chopper in place of the resistor
[02:34:40] <^Fritz> ...and let's not forget that it's unipolar, limited to single or half step
[04:41:48] <toastydeath> thundercats, ho
[05:13:30] <^Fritz> Sword of Omens, come to my hand!
[05:13:38] <^Fritz> No, my *other* hand!
[05:29:13] <toastydeath> you know who i don't get
[05:29:16] <toastydeath> simian mobile disco
[05:29:27] <toastydeath> i have listened to their popular stuff several times and i just don't get it
[05:30:54] <^Fritz> never heard of them
[05:31:00] <toastydeath> be glad, i guess
[05:31:07] <toastydeath> they're a weird garage/electro band
[05:31:52] <^Fritz> what part of the world are you in?
[05:32:02] <toastydeath> the delaware, USA part
[05:32:40] <^Fritz> I'm in Ohio; we take all your garbage and put it in our landfills
[05:32:51] <^Fritz> I'm sure they'll come here eventually
[05:33:59] <toastydeath> they're not from around here
[05:34:22] <toastydeath> but ty for taking our trash
[05:37:19] <^Fritz> Man, I just love emc2
[05:37:40] <^Fritz> I've got my Taig facing material off a block of plastic right now
[05:38:11] <^Fritz> ...and the program doing the facing was generated by a python script with a GUI :)
[05:50:22] <^Fritz> making a renshaw(sp?) probe
[05:54:51] <toastydeath> renishaw
[05:55:02] <toastydeath> but cool
[06:02:28] <klickrr> I finally got my PID tuned in properly, utilizing FF1 set to 0.2, I can hold a position down to one thousandth of an inch during moves upto 240 inches per minutes, it's pretty cool to me... loving this... my machine isn't quite ready, but very close at this point.
[06:04:09] <toastydeath> contours or straight lines
[06:04:33] <toastydeath> either way a+
[06:06:45] <klickrr> well technically at this point straight lines, although each axis was tested independantly, I would assume (at least somewhat) that their accuracty dependant upon acceleration curves would continue, however yes I havne' ttest it thouroughly yet though, I still have no limit switches and one axis is not really engaged, but 2 axis's are working and based upon initial results I see no reason as to why accuracy wouldn't continue. I can't wa
[06:06:45] <klickrr> it to cut the first piece though
[06:07:17] <toastydeath> the only reason i bring it up is the whole step limitation + emc doesn't do lookahead
[06:07:29] <klickrr> I still need to test mechanical backlash, which initial rough testing shows to be lower then 2/1000 th's of an inch, and i'm hoping for 1/1000th's, but we'll see
[06:07:36] <toastydeath> ballscrews?
[06:09:05] <klickrr> nah, acme lead screws, based upon my implementation they made more sense to me, obviously I have anti-backlash nuts, my gauge that I initially test backlash with is accurate down to a ten thousandth of an inch, and it seemed to show less then 1 thousandth of an inch in backlash, but I really need to test that more to be sure
[06:09:26] <toastydeath> .001" and .0001" are faster to type, fyi =)
[06:09:35] <klickrr> true :)
[06:09:42] <toastydeath> that's awesome though, .001" indicators are usually good to a couple tenths
[06:10:04] <toastydeath> and i very much doubt that under a dynamic cutting condition that you'll get the same results at that resolution
[06:10:14] <toastydeath> so i wouldn't bother chasing it out that far
[06:10:25] <klickrr> honestly, i just wanted .01 accuracy, although I spent the money to get more (at least i thought) and i'm getting it.. however the verdict isn't in yet, but my initial tests everywhere have been great
[06:10:31] <toastydeath> but that you got it to follow at 240 ipm is awesome
[06:10:39] <toastydeath> what are you cutting with it
[06:10:41] <toastydeath> or going to cut
[06:11:11] <klickrr> mostly wood, plastic, although aluminum is in the realm of materials to cut
[06:11:31] <klickrr> if you saw my old machine, you wouldn't belive i cut aluminum with it eheh
[06:12:05] <toastydeath> hahah
[06:12:20] <klickrr> this new machien though is all aluminum (8020) and much sturdier (compared to wood obviously) and the only question is how much depth per pass of aluminum that i'll be able to cut
[06:12:55] <toastydeath> indeed
[06:12:58] <klickrr> i have no intensions of ever dealing with steel
[06:13:07] <klickrr> not something i plan to work with
[06:13:13] <toastydeath> steel is way different to cut
[06:13:22] <klickrr> yea, and i dont' want to know eheh
[06:13:24] <toastydeath> lol
[06:13:30] <toastydeath> it's not difficult, it's just different
[06:13:35] <toastydeath> i like it more than alum, it's way more zen
[06:13:47] <klickrr> yea, well i like aluminum, so i'll stick with that :)
[06:13:51] <toastydeath> hahah
[06:13:56] <klickrr> really, interesting
[06:13:57] <toastydeath> A+
[06:14:04] <toastydeath> yeah man!
[06:14:08] <klickrr> heeh
[06:14:09] <toastydeath> aluminum to me is real frantic
[06:14:13] <toastydeath> how fast can you cut, faster faster faster
[06:14:16] <toastydeath> load the spindle down
[06:14:21] <toastydeath> and you wind up at huge feeds and speeds
[06:14:24] <toastydeath> and stuff happens real fast
[06:14:40] <klickrr> well this is my hobby, so i don't need it to be that fast ehe
[06:14:46] <toastydeath> a 5" facemill at 6k rpm will throw a lot of metal
[06:14:56] <toastydeath> but in steel the speeds and feeds are slow
[06:14:57] <klickrr> yea
[06:15:04] <toastydeath> gotta think it out more
[06:15:14] <klickrr> i cut slow :) i just wanted to rapid at 240 ipm eheh
[06:15:20] <toastydeath> you can load up a 20 hp machine fast in steel
[06:15:28] <toastydeath> in aluminum it's hard to do without a hsm spindle
[06:15:32] <klickrr> my new workspace is liek 48" by 24" by 6 inch depth
[06:15:43] <toastydeath> haha
[06:15:47] <toastydeath> cool man
[06:16:00] <toastydeath> that's the sheet size you work with most?
[06:16:48] <klickrr> well, i like working with 1/4 inch aluminu,m the reason i choosed 6 inch depth on my design is because I do carve foam 3d wise, to make molds for fiberglass contstruction
[06:16:58] <klickrr> wood i work with any depth i guess
[06:17:04] <toastydeath> nice, that's something i always wanted to do but i don't have a home shop =(
[06:17:09] <toastydeath> the foam carving thing
[06:17:47] <klickrr> yea, it can be fun, although really i haven't done anything useful that method yet ehhe... but i hope to in the future :)
[06:18:14] <klickrr> the only things i've made that I actually use are out of wood so far
[06:18:34] <klickrr> well, i made aluminum parts for my new cnc machine with my old cnc machine
[06:18:36] <toastydeath> what do you make?
[06:18:39] <klickrr> so i guess those count
[06:18:41] <toastydeath> haha
[06:18:52] <klickrr> otu of wood, and airplane wind
[06:18:53] <klickrr> wing
[06:18:59] <toastydeath> do you have a variable speed spindle, by the way?
[06:19:04] <toastydeath> and what range
[06:19:10] <klickrr> nah, nothing fancy, standard router
[06:19:14] <toastydeath> ah
[06:19:18] <klickrr> 2-7k rpm i think
[06:19:20] <toastydeath> i was going to say if you run into chatter at depth
[06:19:23] <toastydeath> change the rpm
[06:19:44] <klickrr> well my old machine had major chatter problems based upon the fact that it wasn't very sturdy
[06:19:47] <toastydeath> if you get like .3" deep and it starts to chatter, spin it both up and down and see it it gets better
[06:19:50] <klickrr> a problem that plagued me forever
[06:19:59] <klickrr> ok
[06:20:08] <toastydeath> machines are more dynamically rigid at certain frequencies
[06:20:22] <toastydeath> and changing the number of flutes on the cutter and the spindle rpm changes the operating frequency of the machine
[06:20:46] <toastydeath> you can find a band of spindle speeds where you can take deep cuts - you'll have a LOT of spindle deflection, but it will cut nice
[06:20:51] <klickrr> yea, you would laugh if you saw how much you could move my old machine by hand.. probably 1/4 an inch if you just grabbed the bit and pushed it around... it was wood afterall :) i built it 4 years ago eheh
[06:21:06] <toastydeath> whatever makes the parts, man
[06:21:13] <klickrr> yea, i learned how to work with it
[06:21:15] <toastydeath> 1/4 of deflection is better than no parts
[06:22:08] <klickrr> but the new machien... man, it's sturdy, and clearly faster as well, and more accurate, so basically better in every way possible :) and has realtime feedback into EMC so that it can determine if the part is being accurately cut.. can't wait to get it 100%
[06:22:13] <klickrr> yea
[06:22:21] <toastydeath> hey and now you have two machines
[06:22:26] <klickrr> but 0.001 deflection is better :)
[06:22:30] <toastydeath> tru
[06:23:31] <klickrr> what type of machine do you run?
[06:23:59] <toastydeath> three machines lately
[06:24:02] <klickrr> yea
[06:24:03] <toastydeath> all mills
[06:24:28] <toastydeath> mostly i've been running an old school OKK horizontal with an indexing table
[06:24:56] <klickrr> you do that professionally or as hobby?
[06:24:58] <toastydeath> the others i use less but one is a Mori Seiki MV-65A, and the other is a Chevalier
[06:25:01] <toastydeath> professionally
[06:25:08] <toastydeath> the mori is large.
[06:25:18] <toastydeath> 60x30 table, 50x20 workspace
[06:25:20] <klickrr> yea, based on the picture i pulled up that's a hell of a machine
[06:25:26] <toastydeath> gotta climb up onto the table to do anything
[06:25:32] <klickrr> hehe
[06:25:42] <toastydeath> the OKK and Mori are fun machines
[06:25:48] <toastydeath> they both have geared heads and have a lot of grunt
[06:26:06] <klickrr> yea, so what do you cut on them mainly? all custom things, or a lot of the same thing?
[06:26:08] <toastydeath> the chevy is not so bad, i was suprised
[06:26:20] <toastydeath> the shop as a whole cuts mostly the same crap
[06:26:25] <klickrr> yea
[06:26:30] <toastydeath> but I am lucky in that the two I run mostly do a lot of custom jobs
[06:26:34] <toastydeath> so there's a good mix.
[06:26:47] <toastydeath> i am kind of new at this, a year and a half
[06:26:52] <klickrr> oh cool
[06:26:56] <klickrr> you liking it?
[06:27:00] <toastydeath> like it a lot
[06:27:06] <toastydeath> trying to persue it as a hardcore career
[06:27:13] <klickrr> you do any of the cam programming? or just running the machines?
[06:27:14] <klickrr> ya
[06:27:19] <toastydeath> i program by hand
[06:27:23] <toastydeath> at the control
[06:27:23] <klickrr> ahh ok
[06:27:33] <klickrr> writing g-code by hand?
[06:27:44] <toastydeath> i do a lot of solidworks modeling for manufacturing eng.
[06:27:46] <toastydeath> but no cam
[06:27:52] <toastydeath> yep
[06:28:02] <klickrr> yea
[06:28:17] <toastydeath> we have an oollllld copy of mastercam, like version 8
[06:28:25] <klickrr> so is it a large machine shop? like how many people work there?
[06:28:26] <toastydeath> they use it for stuff that would be a pain to program
[06:28:32] <klickrr> right
[06:28:33] <toastydeath> 70 people, total, in the whole company
[06:28:39] <toastydeath> machinists, probably 12-16
[06:28:41] <klickrr> well that's pretty big yea
[06:28:42] <toastydeath> somewhere in there
[06:29:22] <toastydeath> most of the employees are in assembly
[06:29:26] <klickrr> so they run EMC on those machines you listed?
[06:29:35] <toastydeath> nope, they all use commecial controls
[06:29:40] <klickrr> oh ok eheh
[06:29:47] <toastydeath> i've actually never touched EMC except in passing
[06:29:49] <klickrr> gotta convince them to use emc :)
[06:29:52] <klickrr> yea
[06:30:04] <toastydeath> haha, it would be neat but emc isn't ready to take the place of those controls
[06:30:28] <klickrr> i wrote my own g-code interpretter initially, then realized emc was a much better choice, i was spending so much time re-inventing the wheeling programming sometihng that already existed
[06:30:41] <toastydeath> yep
[06:30:48] <toastydeath> there is a TON of stuff there
[06:30:51] <klickrr> yea
[06:30:57] <toastydeath> and modern controls now have all sorts of crazy codes
[06:31:16] <toastydeath> high speed machining routines, crazy roughing macros
[06:31:29] <toastydeath> 5 axis stuff
[06:31:31] <klickrr> i can't even imagine, I realized I do pretty simple stuff and it still keeps my attention, I enjoy it
[06:32:06] <toastydeath> simple stuff is cool
[06:32:12] <klickrr> yea, not sure i'm gonna break 3 axis, i've though about a 4th, maybe as a lathe like index, I gotta complete my machine as is though before i do that ehhe
[06:32:21] <toastydeath> once you get too complicated you're in cam turf and it doesn't matter anymore
[06:32:35] <toastydeath> i really like 4th axis horizontal machines
[06:32:50] <toastydeath> i was uncomfortable at first because all the work is sideways
[06:33:06] <toastydeath> but now I look at stuff and I'm like, i'd rather do this on the okk
[06:33:10] <klickrr> well i made a wing with a 3 axis machine, having a fourth axis might be interesting in consturcting a wing out of foam...
[06:33:12] <toastydeath> because you can touch 3 sides at once
[06:33:17] <klickrr> many other things I could do as well
[06:33:26] <klickrr> yea
[06:33:48] <toastydeath> it's good times
[06:33:56] <klickrr> yea, it's just fun to me
[06:34:05] <toastydeath> putting 4th on a vertical machine is a little harder to fixture and stuff
[06:34:17] <toastydeath> but it still opens up new machining oppertunities
[06:34:18] <klickrr> i prototype my crazy ideas that don't go anywhere, but thats how i entertain myself :)
[06:34:22] <toastydeath> hahah.
[06:34:40] <klickrr> yea
[06:35:01] <klickrr> i'm just looking forward to milling aluminum at more then 1/100th of an inch per pass
[06:35:11] <toastydeath> hahan yeah
[06:35:13] <klickrr> i'm hoping for a tenth of an inch per pass ehhe
[06:35:19] <toastydeath> nah you should be able to get more
[06:35:37] <toastydeath> itty bitty endmills are a big problem in that though
[06:35:37] <klickrr> i'm pretty sure I will, but as I said, i'm a hobbyiest and i'm patient
[06:35:41] <toastydeath> tru
[06:35:45] <toastydeath> i'm not saying don't be paitient
[06:35:49] <klickrr> yea
[06:36:14] <klickrr> i generally use a 1/4 inch upspiral 2 flute cutter with aluminum
[06:36:43] <toastydeath> full slotting?
[06:36:51] <klickrr> i have no idea what that means
[06:36:59] <toastydeath> the whole cutter is engaged in the cut
[06:37:06] <toastydeath> like, plunge down, and plowing through metal
[06:37:18] <klickrr> my old machien moved 1/4 of an inch if you grabbed the bit and pushed it back and forth.. not rigid at all
[06:37:31] <klickrr> oh no, 1/100th of an inch per pass
[06:37:36] <klickrr> i'm patient :)
[06:37:38] <toastydeath> no no no
[06:37:49] <toastydeath> i mean like, you know if you are going to cut a pocket in something?
[06:37:56] <klickrr> yea
[06:38:00] <toastydeath> you have to make that first pass where the whole cutter radius is cutting
[06:38:19] <toastydeath> before you can back off and only use part of the cutter's diameter to do the cutting rather than the whole thing
[06:38:36] <klickrr> ok, well i never did that
[06:38:49] <klickrr> maybe why i did 1/100th of an inch depth per pass
[06:38:52] <toastydeath> you've never made pocketed?
[06:38:56] <toastydeath> *done
[06:39:08] <toastydeath> wow that's a botched sentence
[06:39:11] <klickrr> well i've pocketed very little, i generally want to cut something out
[06:39:33] <toastydeath> a recommendation i have for you is to use a bigger endmill
[06:39:40] <klickrr> yes
[06:39:42] <toastydeath> not necessarily taking any deeper of a cut than you want
[06:39:46] <toastydeath> or were
[06:39:59] <toastydeath> but the biggest tool you can use is going to be the most rigid.
[06:40:16] <klickrr> well the new machien I think is going to be a different story, I plan to take it slow, but it should be able to cut much better
[06:40:23] <klickrr> yea
[06:40:25] <toastydeath> it should, yeah
[06:40:31] <toastydeath> but the machine is only part of the equation.
[06:40:59] <toastydeath> there's a hundred other factors that are going to determine if even a very rigid, 10k lb machine is going to cut well.
[06:41:10] <klickrr> right
[06:41:13] <klickrr> i agree
[06:41:33] <toastydeath> it was cool talking to you dude!
[06:41:35] <toastydeath> i am going to bed
[06:41:40] <klickrr> yea, me too man
[06:41:46] <klickrr> have a good night, ttyl :)
[06:45:42] <poutine> poutine is now known as emc
[06:45:56] <emc> emc is now known as poutine
[06:46:28] <poutine> poutine is now known as rayh
[06:48:15] <rayh> rayh has kicked ^Fritz from #emc
[06:48:15] <rayh> rayh has kicked a-l-p-h-a from #emc
[06:48:15] <rayh> rayh has kicked alex_joni from #emc
[06:48:15] <rayh> rayh has kicked anonimasu from #emc
[06:48:15] <rayh> rayh has kicked archivist from #emc
[06:48:16] <rayh> rayh has kicked cradek from #emc
[06:48:18] <rayh> rayh has kicked crotchetyGuy from #emc
[06:48:20] <rayh> rayh has kicked DanielFalck from #emc
[06:48:22] <rayh> rayh has kicked dimas from #emc
[06:48:24] <rayh> rayh has kicked dmess from #emc
[06:48:26] <rayh> rayh has kicked ds2 from #emc
[06:48:28] <rayh> rayh has kicked eric_U from #emc
[06:48:30] <rayh> rayh has kicked fenn from #emc
[06:48:32] <rayh> rayh has kicked Gamma-X from #emc
[06:48:34] <rayh> rayh has kicked GNieport1 from #emc
[06:48:36] <rayh> rayh has kicked IRSeekBot3 from #emc
[06:48:38] <rayh> rayh has kicked jepler from #emc
[06:48:40] <rayh> rayh has kicked jmkasunich from #emc
[06:48:42] <rayh> rayh has kicked jtr from #emc
[06:48:44] <rayh> rayh has kicked jymm from #emc
[06:48:46] <rayh> rayh has kicked JymmmEMC from #emc
[06:48:48] <rayh> rayh has kicked klickrr from #emc
[06:48:50] <rayh> rayh has kicked lerman from #emc
[06:48:52] <rayh> rayh has kicked lewing from #emc
[06:48:54] <rayh> rayh has kicked logger_emc from #emc
[07:30:09] <alex_joni> hang on..
[07:30:12] <ChanServ> [#emc] "This is the #emc channel - talk related to the Enhanced Machine Controller and general machining. Website: http://www.linuxcnc.org/, wiki at http://wiki.linuxcnc.org/"
[07:30:31] <alex_joni> alex_joni has changed the topic to: "hang on .. coming now"
[07:30:58] <^Fritz> ^Fritz has changed the topic to: "Who's driving this thing?"
[07:30:58] <ChanServ> ChanServ has changed the topic to: "hang on .. coming now"
[07:31:05] <Sweeper> ah
[07:31:21] <alex_joni> alex_joni has changed the topic to: "Welcome! EMC (Enhanced Machine Controller) is a linux-based opensource CNC control. | Latest release: EMC 2.2.5 | http://www.linuxcnc.org | http://wiki.linuxcnc.org"
[07:31:54] <^Fritz> You forgot to add, "...and poutine is a dweeb"
[07:32:03] <poutine> ?
[07:32:07] <poutine> what did I do?
[07:32:14] <^Fritz> Huh
[07:32:32] <alex_joni> 09:38 -!- poutine is now known as rayh
[07:32:39] <^Fritz> in my log here, you became rayh, and then booted everyone
[07:32:56] <poutine> your log is incorrect, I did no such thing
[07:34:29] <^Fritz> ...'kay, now I feel like I'm in a scooby doo mystery
[07:34:37] <alex_joni> poutine: looks the same here
[07:35:06] <Vq^> 08:46 -!- rayh [n=rayh@tnmi-18-197-54-69.ip.telnetww.com] has quit [Nick collision from services.]
[07:35:06] <^Fritz> We'd better see if Red Herring has an alibi
[07:35:09] <Vq^> 08:46 -!- poutine is now known as rayh
[07:35:11] <Vq^> 08:46 -!- rayh_ [n=rayh@tnmi-18-197-54-69.ip.telnetww.com] has joined #emc
[07:35:14] <Vq^> 08:47 -!- mode/#emc [+o rayh] by ChanServ
[07:35:17] <Vq^> 08:48 -!- mode/#emc [+b *!*ChanServ@*.] by rayh
[07:35:25] <alex_joni> http://pastebin.ca/1029673
[07:36:20] <poutine> ok, maybe I did do that then
[07:36:22] <alex_joni> not sure who restored it all..
[07:36:48] <fenn> ^Fritz: i found a clue! http://fennetic.net/pub/irc/peach_icecream.jpg
[07:37:13] <poutine> that is disgusting
[07:37:29] <Vq^> looks like someone got rayh's password
[07:37:36] <fenn> ha! see, only an evil hacker could hate peach ice cream
[07:38:44] <Sweeper> http://www.sfw-porn.com/ <-- vaguely true, but very funny
[07:38:53] <poutine> it wasn't really hacking, his password was in a log
[07:39:10] <poutine> I'm actually a C programmer that dabbles in EE
[07:39:16] <poutine> but I couldn't help myself
[07:39:34] <poutine> I hope you will forgive me
[07:40:01] <Vq^> poutine: what did you do?
[07:40:09] <poutine> I really do despise peach ice cream, I love all races, and I don't mind if men like other men
[07:41:06] <^Fritz> http://www.villainsource.com/ <-- Best. Link. Ever. I'm gonna be their biggest purchaser.
[07:41:06] <Sweeper> there are more sensible ways to go
[07:41:27] <Sweeper> there are more sensible ways to go "lolol I have your password" than kicking everyone and changing the chan topic...
[07:42:28] <poutine> That is very true
[07:44:06] <fenn> so, welcome to freenode, the civilized irc network
[07:44:17] <fenn> it may be hard to believe, but it's true
[07:44:21] <fenn> for the most part
[07:45:05] <fenn> or, as toastydeath likes to say, "we're all friends here you asshole"
[07:45:42] <poutine> I've been on freenode for quite some time
[07:45:58] <poutine> I think it takes on an uglier persona than the IRC networks that predate it with the OT nazis
[07:46:21] <fenn> how's that?
[07:47:40] <poutine> all work and no play makes jack a dull boy
[07:56:33] <JanVanGilsen> hi, i'm still workin ol the tlo,
[07:57:29] <JanVanGilsen> i got tlo_is_along_w working, but wen I add pos->W to my kinematics it doen's have effect on joint[2]
[08:12:09] <alex_joni> how does your kins look?
[08:17:46] <JanVanGilsen> http://pastebin.ca/1029682
[08:20:03] <JanVanGilsen> i added result = hal_pin_float_new("tablekins.tooloffs .... from the 5axiskins on line 124 but that doesn't seem to do anything ..
[08:33:00] <alex_joni> JanVanGilsen: it will take a while for me to look over it.. (sorry)
[08:38:08] <JanVanGilsen> no problem, i'm verry happy you'r trying to help me
[08:40:52] <alex_joni> work is really pushy atm
[09:27:45] <supermedo> hello! i need help. i would like emc to use a pci parallel port card (netmos 9835) instead of the motherboard's. i've installed the card following the manufacturer's instructions - just had to use modprobe parport_pc ... i would like to know how to configure emc now, because setting a different address in .hal file (standard_pinout.hal) is not working. any advice would be greatly appreciated!
[09:29:10] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?NetMos
[09:30:08] <supermedo> thank you very much!
[09:31:26] <fenn> dont you love the easy questions
[09:35:52] <supermedo> i run emc, go to hal configuration and write loadrt hal_parport cfg="0x378 0xa400" and get an error: systemv failed returned 1 insmod failed, returned -1
[09:36:13] <supermedo> oh yeah, and i'm a linux newbie so don't be too harsh
[09:40:09] <fenn> when you type 'dmesg' the last couple lines should have the real error in it
[09:41:29] <fenn> are you running the realtime kernel? (have you rebooted since installing emc2)
[09:42:38] <supermedo> i'll try rebooting
[09:42:41] <supermedo> thank you for now
[09:53:08] <alex_joni> fenn: that probably means that he got an address conflict
[09:53:30] <alex_joni> he did try modprobe parport_pc for the netmos, which would register the driver, then hal_parport won't load
[09:53:39] <supermedo> hello
[09:53:41] <supermedo> again
[09:53:50] <alex_joni> supermedo: when you load the parport_pac driver, you won't be able to load hal_parport afterwards
[09:53:56] <alex_joni> parport_pc even
[09:54:02] <supermedo> everything ok now - i had one problem
[09:54:07] <supermedo> yes - rebooted
[09:54:20] <alex_joni> (you can also use sudo rmmod parport_pc to remove it)
[09:54:34] <alex_joni> in linux the problems very rarely need a reboot
[09:55:07] <supermedo> and one more thing, the parallel port was on a different address than i though - the third in the list (lspci -vv), and not the sixth on the card
[09:55:35] <supermedo> it says on the link you gave me, that it was the same there - found by trial and error
[09:55:52] <supermedo> thank you again, everything ok now!
[09:56:45] <alex_joni> supermedo: great
[09:56:52] <alex_joni> we love people with such simple problems :D
[09:57:00] <alex_joni> JanVanGilsen: I looked at your kinematics file
[09:57:05] <alex_joni> there is a bit of a problem
[09:57:24] <alex_joni> you need to change it so that the W position is moved along with the spindle
[09:57:39] <alex_joni> so if you tilt the head (I assume axis A) then W needs to change accordingly
[09:57:56] <alex_joni> only then the tlo_along_w will work
[10:02:36] <JanVanGilsen> alex_joni: atm pos->w and joints[8] are the length of my tool
[10:02:55] <JanVanGilsen> i don't see what id have to change
[10:04:15] <JanVanGilsen> also the tool is always in the joints[2] direction, because the tool doesn't rotate but the workpiece does
[10:04:29] <alex_joni> then tlo_along_w is useless for you
[10:06:03] <JanVanGilsen> i really can't understand why
[10:06:52] <JanVanGilsen> i assume pos->w neverchanges, unles there is a tooloffset change...
[10:07:13] <alex_joni> W is another axis
[10:07:15] <alex_joni> just like X
[10:07:25] <alex_joni> if your g-code commands W movement then it will change
[10:07:53] <alex_joni> what people do for 5 axis kins (where the tool tilts/rotates) is they attach UVW at the tip of the spindle
[10:08:07] <alex_joni> then when you move ABC, UVW will be tilted/rotated accordingly
[10:08:26] <alex_joni> if you then command a move only in W basicly the machine will move along the W axis (which is the spindle direction)
[10:08:34] <alex_joni> so it makes sense to have the TLO along W
[10:08:38] <JanVanGilsen> yes, but is isn't conneted to a real motor :), i only use the value of pos->W to move the tool in the joints[2] direction
[10:08:49] <alex_joni> then use a simple Z TLO offset
[10:08:53] <alex_joni> the default in emc2
[10:08:56] <alex_joni> you don't need W
[10:09:53] <JanVanGilsen> ill tested that but that didn't work, the tool ofsee has to be along joint2 and not along the Z-axis
[10:12:37] <JanVanGilsen> *i've
[10:25:37] <JanVanGilsen> how can I print somethin to the terminal when debuging kinematics? i tried rtapi_print_msg but it's only printed at the RTAPI_MSG_ERR level. or is it posible to view the results of RTAPI_MSG_DBG in logfile?
[10:26:43] <fenn> i think it shows up in dmesg
[10:30:20] <JanVanGilsen> it doesn't
[10:33:23] <micges> hi all
[10:39:08] <alex_joni> JanVanGilsen: you need to echo "5" /proc/rtapi/debug
[10:39:12] <alex_joni> JanVanGilsen: you need to echo "5" > /proc/rtapi/debug
[10:39:20] <alex_joni> then you'll get debug messages in dmesg too
[10:39:42] <JanVanGilsen> thx
[10:39:43] <alex_joni> where is joint2?
[10:39:51] <alex_joni> you said the head doesn't tilt/turn?
[10:39:58] <alex_joni> then imo joint2 is always along Z
[10:40:07] <JanVanGilsen> yes, its a tilting roary table
[10:40:32] <JanVanGilsen> no if the table is turned, the z-axis turs along with it
[10:40:58] <alex_joni> JanVanGilsen: try to talk to cradek later, when he's around..
[10:41:08] <JanVanGilsen> i'll do that :)
[10:43:33] <JanVanGilsen> echo undeclared, do i have to #include something ?
[10:44:24] <alex_joni> I meant from a commandline
[10:44:29] <alex_joni> not from the kinematics..
[10:44:34] <alex_joni> you start emc2
[10:44:37] <JanVanGilsen> oh thx :)
[10:44:37] <alex_joni> then you open a terminal
[10:44:41] <alex_joni> and do "echo ..."
[10:44:48] <alex_joni> then tail -f /var/log/messages
[10:52:04] <JanVanGilsen> rtapi_print_msg(RTAPI_MSG_DBG, "joint8: %f", joint[8]);
[10:52:34] <JanVanGilsen> it just keeps printing "joint8: %f"
[10:53:39] <JanVanGilsen> shouldn't %f be replaces by the value of joints[8] ?
[10:55:15] <alex_joni> there is no %f
[10:55:22] <JanVanGilsen> ah
[10:55:34] <alex_joni> I think it's %g, but not sure if it works in kernel space
[10:55:53] <alex_joni> but you know that you can test the kinematics if you build a simulation package?
[10:55:59] <alex_joni> ./configure --enable-simulator
[10:57:37] <JanVanGilsen> kinematics work, i'm only tring to get the tlo working
[10:57:53] <alex_joni> I still don't understand what you want to do
[10:58:19] <alex_joni> if your spindle is always in the same direction (Z) then TLO should be regarding to that
[10:59:42] <JanVanGilsen> no, it isn't, if the table turns the z direction isn't trival with joint[2]
[11:00:26] <JanVanGilsen> the tlo is not via z but via joint2, thats the problem
[11:00:56] <alex_joni> JanVanGilsen: sorry.. without a picture/explanation I'm not understanding..
[11:01:22] <JanVanGilsen> i'll try to work on that
[11:02:17] <alex_joni> the way it usually is done is that you create a coordinate system (called UVW), and you attach it to where you want TLO to happen
[11:02:35] <alex_joni> so if you rotate A,B or C or whatever else you rotate, UVW will have to rotate aswell
[11:03:13] <alex_joni> that happens in your kins..
[11:03:55] <BigJohnT> alex what is a TLO?
[11:04:34] <alex_joni> BigJohnT: tool length override
[11:04:39] <alex_joni> err.. offset
[11:05:06] <BigJohnT> ok
[11:12:40] <alex_joni> JanVanGilsen: if you want a relative distance from spindle to workpiece, then you would have to use W for that
[11:12:57] <alex_joni> and update the kinematics accordingly, then use TLO_ALONG_W
[11:13:11] <alex_joni> (that's what I would try.. but like I said.. talk to cradek, he knows more about this)
[11:14:38] <JanVanGilsen> http://imagebin.org/18885
[11:14:45] <alex_joni> JanVanGilsen: I assume you saw this: http://cvs.linuxcnc.org/cvs/emc2/src/emc/kinematics/maxkins.c?rev=1.2
[11:15:30] <alex_joni> JanVanGilsen: ok, so you assume XYZ always attached to the workpiece
[11:15:58] <alex_joni> then your spindle is not moving along Z.. (the move along joint2)
[11:17:29] <JanVanGilsen> indeed
[11:18:02] <JanVanGilsen> %g doesn't work
[11:30:00] <JanVanGilsen> when i change w, the z axis moves, but when i chang the toolofset, the w coordinate changes but the z coordinate doesn't
[11:30:36] <JanVanGilsen> verry confusing, joints and axes
[11:30:37] <alex_joni> what do you understand with axis Z ?
[11:30:48] <alex_joni> it's not confusing at all, if you keep the names separate
[11:30:55] <JanVanGilsen> atm A=0 so joint2=z
[11:30:55] <alex_joni> axes are virtual, joints are motors
[11:31:15] <alex_joni> the z axis can't move
[11:31:20] <alex_joni> the joint 2 can move
[11:31:27] <JanVanGilsen> okey my error :)
[11:31:34] <alex_joni> well.. in your case the Z axis gets moved by tilting A
[11:32:35] <alex_joni> I'm not sure the notations you used are correct
[11:32:46] <alex_joni> A is always assumed around X
[11:32:58] <alex_joni> right?
[11:33:25] <JanVanGilsen> if i change w, joint 2 and 8 change. But if I do a tool offset, only W changes
[11:33:39] <JanVanGilsen> A is always around X
[11:33:48] <alex_joni> ok.. so what happens if you rotate C?
[11:34:21] <JanVanGilsen> the workpiece rotates around its z axis
[11:34:41] <JanVanGilsen> a C rotation is useles if A=0
[11:36:55] <JanVanGilsen> The only thing I want is a variable in my kinematicsfile thats equal to the current tlo :)
[11:39:21] <JanVanGilsen> there are motion.toolofset.z (x and w) pins; but I don't know how to read them in the kinematics file
[11:40:27] <alex_joni> reading them is like this: http://cvs.linuxcnc.org/cvs/emc2/src/emc/kinematics/maxkins.c?rev=1.2
[11:40:37] <JanVanGilsen> I think thats the only thing I need motion.toolofset.w to a pin i.e. tablekins.tlo
[11:42:44] <JanVanGilsen> i only see a pivot_length parameter thats imported, not a pin
[11:45:14] <JanVanGilsen> result = hal_pin_float_new("tablekins.tool-length", HAL_IN, &(haldata->tool_length), comp_id);
[11:46:37] <JanVanGilsen> struct haldata { hal_float_t tool_length; } *haldata;
[11:59:03] <Sweeper> * Sweeper just made a 5v->54v boost converter :D
[12:04:49] <JanVanGilsen> alex_joni: can you take a look at: http://pastebin.ca/1029839
[12:05:24] <JanVanGilsen> there seems to be some pointer problem, and i know nothing about poiters :)
[12:49:47] <JanVanGilsen> when i compile that kinematics file, the z-coordinate becomes -1842303673040697.25
[12:50:32] <JanVanGilsen> i assume ist some type conflict
[12:50:36] <rayh_> That is a pretty long Z in most any unit system
[12:51:10] <JanVanGilsen> rayh: http://pastebin.ca/1029839
[12:51:47] <JanVanGilsen> i'm tring to acces the motion.w halpin in my kinematics file
[12:52:16] <JanVanGilsen> sorry; motion.tooloffset.w
[12:57:22] <rayh_> rayh_ is now known as rayh1
[13:02:35] <rayh1> JanVanGilsen, I don't know enough about kins setup to help much.
[13:03:51] <JanVanGilsen> i don't need help on kins but help on creating a hal_pin
[13:04:24] <rayh1> Are you working from trunk?
[13:04:55] <JanVanGilsen> yes
[13:06:54] <JanVanGilsen> i sucseeded in making a parameter, bu i need to make a pin.
[13:06:58] <JanVanGilsen> *but
[13:15:01] <rayh1> What do you want this pin to do for you?
[13:18:00] <jepler> JanVanGilsen: you delcare the pin as a pointer, for example: hal_float_t *example
[13:18:33] <jepler> JanVanGilsen: then when creating it you take the address of 'example' as the argument in hal_pin_float_new: hal_pin_float_new("example.pin", HAL_IN, &example, comp_id);
[13:18:47] <jepler> JanVanGilsen: then to read the value on it, you dereference the pointer: double tmp = *example;
[13:19:49] <jepler> (this is if you're writing a .c file, which I believe you are. When using comp to create components, all those stars are hidden from you)
[13:20:18] <JanVanGilsen> i'm using a c file
[13:21:18] <JanVanGilsen> i'll give it another go :)
[13:22:42] <JanVanGilsen> souldn't the varialbe be refferenced with hal_malloc?
[13:23:14] <jepler> JanVanGilsen: er, yes -- usually it will be put in a struct
[13:23:26] <jepler> I usually write with comp, so my c is a bit rusty when it comes to hal components
[13:30:58] <jepler> JanVanGilsen: here's a full example which creates a pin: http://pastebin.ca/1029918
[13:37:22] <JymmmEMC> ug
[13:56:25] <rayh> Sorry for all of the inconvenience caused by our buddy poutine.
[13:56:46] <JymmmEMC> rayh: clear the ban list please
[13:56:58] <rayh> How do I do that?
[13:57:05] <JymmmEMC> op yourself
[13:57:16] <rayh> same question
[13:57:17] <JymmmEMC> then /mode #emc *!*@*
[13:57:34] <JymmmEMC> hang on my client sucks
[13:57:47] <JymmmEMC> JymmmEMC is now known as Jymmmm
[14:21:59] <JymmmEMC> JymmmEMC has kicked poutine from #emc
[14:22:10] <jepler> JanVanGilsen: any luck? did you try my example?
[14:24:53] <JymmmEMC> JymmmEMC is now known as Jymm
[14:31:55] <Jymmmm> Jymmmm is now known as JymmmEMC
[14:32:12] <JanVanGilsen> yes, i'm at a breaking poit
[14:33:40] <Poincare> *crack*
[14:35:27] <JanVanGilsen> lol
[15:01:07] <skunkworks> logger_emc: bookmark
[15:01:07] <skunkworks> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2008-05-26.txt
[15:23:51] <cradek> logger_emc: bookmark
[15:23:51] <cradek> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2008-05-26.txt
[15:28:44] <JymmmEMC> oh, that's much better
[15:29:42] <micges> what's happened on IRC ?
[15:30:00] <Jymm> some dumbass though he'd be funny is all.
[15:30:09] <cradek> some jerk found rayh's password
[15:30:50] <micges> oh
[15:31:23] <cradek> fixed now
[15:34:39] <skunkworks> $hit happens.
[15:35:09] <Jymm> skunkworks: But the cleanup is such a pita
[15:35:42] <skunkworks> * skunkworks doesn't really know mechanics behind irs
[15:35:48] <skunkworks> irc even
[15:37:11] <Jymm> skunkworks: There are many ways to exploit once a pw is known. Even after the fact. Sadlt enough I've had to learn them all. But, eh, par for the course.
[15:37:21] <JanVanGilsen> I got the tlo working, even without tool_is_along_w=1 setting!
[15:37:32] <tomp2> cool
[15:38:36] <cradek> JanVanGilsen: I scanned the earlier conversation - it was confusing
[15:38:44] <JanVanGilsen> thanx, jepler and alex_joini for helping me today :)
[15:39:22] <cradek> JanVanGilsen: W should always be up so it moves your joint 2, Z is on the workpiece and changes direction with A
[15:39:47] <tomp2> is there docs or just code for tool_is_along_w? (like why the tool is on a parallel slide to Z, or what 'along_w' means physically)
[15:40:13] <cradek> tomp2: not sure.
[15:40:25] <tomp2> where is it implemented then
[15:40:29] <JanVanGilsen> if you want, ill pastebin the kinematics again, the best is that ther's no w-axis needed anymore
[15:40:47] <cradek> JanVanGilsen: I'm dubious, yes I'd like to see it
[15:40:53] <tomp2> we'd all like to see, maybe a wiki page would be handy
[15:41:09] <cradek> did you use a hal pin to read the tlo?
[15:41:17] <JanVanGilsen> yes
[15:41:42] <cradek> but that jumps instantaneously
[15:41:54] <cradek> you need to apply the new tlo over a move
[15:43:04] <JanVanGilsen> then i removed the tooloffset that EMC does by stubstracting it from the pos->z and joint[2]
[15:43:31] <JanVanGilsen> atm, it works just fine =), have no constan changes in the tlo...
[15:43:37] <JanVanGilsen> *constant
[15:43:51] <cradek> that might work if A=0 whenever you change tools
[15:44:02] <cradek> otherwise you will get a position jump/following error
[15:44:35] <JanVanGilsen> indeed, i'll make a=0 on toolchange
[15:44:40] <cradek> having W also lets you use drill cycles at an angle
[15:44:59] <cradek> ok, as long as you are happy with it :-)
[15:45:04] <JanVanGilsen> i didn't get the W stuff to work...
[15:45:22] <cradek> do you want help with that or are you happy?
[15:45:29] <skunkworks> JanVanGilsen: don't forget about making a video.. :)
[15:46:24] <cradek> sounds like you were close. you said changing tlo made W change on the screen. that is correct.
[15:46:41] <JanVanGilsen> yes i'm getting to that. but first I want to make sure i get my grades.
[15:46:59] <cradek> grades?
[15:47:16] <JanVanGilsen> its my final work (college)
[15:47:48] <tomp2> EMC110 (4 credits)
[15:48:31] <JanVanGilsen> I think the correct therminology is a "master disertation", but i'm not shure
[15:49:21] <tomp2> just teasing, best of luck
[15:49:34] <JanVanGilsen> thanks
[15:51:10] <JanVanGilsen> cradek, it's possible i need your help on the w-axis stuff, but atm i'm happy with my results
[15:51:52] <JanVanGilsen> maybe I'll look into that again next week ..
[16:05:32] <BigJohnT> JymmmEMC you around?
[16:06:55] <JanVanGilsen> Bye bye, I'm going home
[16:19:11] <lerman> I was just looking at providing gcode access to the tool tables at runtime. Looking at the tool table stuff was not a pleasant experience.
[16:21:26] <micges> lerman: confusing source code?
[16:21:49] <jmkasunich> lerman: what did you have in mind? making the tool table be a bunch of #variables?
[16:22:00] <lerman> Not too bad; but there are two types of tool tables: lathe tables and mill tables.
[16:22:29] <lerman> jmkasunich: yup. Something to discuss at the "fest". The general subject of introspection.
[16:22:53] <lerman> And the opposite (is that extrospection?).
[16:23:03] <jmkasunich> I'm in favor of making a lot of emc's "state" information (like offsets and such) available as #vars
[16:23:10] <jmkasunich> many controls do that
[16:23:25] <lerman> I would make "all" of the state visible.
[16:23:27] <jmkasunich> there are complications involved when you consider the effect of queuing
[16:23:55] <lerman> True. There are two types of state: interpreter state and canon state.
[16:24:12] <jmkasunich> for instance if a move changes some state, then you can't execute or queue any operation that uses that particular state till the move is actually completed
[16:24:35] <jmkasunich> I had some thoughts on the queuing issue a while back, I should wikify them
[16:24:53] <lerman> If it isn't in the wiki; it doesn't exist. :-)
[16:24:56] <jmkasunich> I wrote them down, lemme find
[16:25:03] <micges> jmkasunich: state information in varables and easy access to varaibles from interface by NML - that would be great
[16:25:54] <lerman> Again, the issue is interpreter vs. canon state. Since the interpreter runs ahead of the hardware, they are not the same.
[16:25:58] <jmkasunich> lerman: is there already a wiki page that touches on similar topics?
[16:26:09] <lerman> I don't know.
[16:26:32] <jmkasunich> 299 pages found - we need a better index
[16:26:44] <micges> lerman: what is canon ?
[16:27:02] <jmkasunich> an index page for "concepts" would be good
[16:27:08] <micges> errr canon state ?
[16:28:28] <jmkasunich> ah, we have one: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EMC2_Development
[16:29:17] <lerman> EMC defines a canonical machine (or more precisely, rs274ngc defines it). I used the term to mean the view of the hardware at the lowest level. There is a source file called emccanon.cc (I think I got that right). The interpreter generates commands that control the canonical machine.
[16:30:36] <lerman> If we allow the program to access a tool length, do we also allow a program to set the tool length? I think we should; but that's a lot harder.
[16:30:59] <jmkasunich> set the tool length as in "modify the tool's entry in the tool table"?
[16:31:10] <tomp2> or send a tool table?
[16:31:12] <jmkasunich> or set a dynamic length that isn't associated with a specific tool?
[16:31:20] <jmkasunich> because I think the latter can be done now
[16:31:39] <lerman> Yup. If we can measure a tool with some type of probe, we should be able to save it so that the next program doesn't have to measure it.
[16:31:59] <jmkasunich> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Introspection
[16:32:16] <lerman> jmkasunich: the Yup was for you. "modify the tool's entry in the tool table".
[16:32:35] <jmkasunich> I'm going to edit it some - in that text, I propose something, find a problem, and propose something else - I want to skip the first one and go right to the one that might actually be workable
[16:33:33] <lerman> jmkasunich: Are you sure you aren't named lerman. Named Parameters proposal, then a sequel that actually got implemented.
[16:33:59] <jmkasunich> nothing implemented yet
[16:34:03] <lerman> Sometimes things need to sit, get some comments, sit some more... before they are cooked.
[16:35:47] <kirk_wallace> Sorry, I haven't been following this, but does it help the state problem by putting off the length or radius change until the next part?
[16:37:03] <lerman> I think we can just force synchronization either manually (by gcode command) or automatically (in the interpreter).
[16:37:27] <jmkasunich> manual sync seems like a nightmare
[16:37:35] <lerman> Yes it does.
[16:37:42] <lerman> But it's easy to do.
[16:38:09] <kirk_wallace> It's good but it's bad????
[16:38:22] <jmkasunich> I think my concept for auto-sync is workable, but it needs some review
[16:38:23] <lerman> An alternative is to force a sync when certain "parameters" are changed.
[16:38:57] <jmkasunich> I'm basically tagging each parameter with enough data to tell when it is up to date
[16:39:15] <lerman> I'm reading it now...
[16:39:24] <jmkasunich> and each command with a list of which params need to be up to date before the command is allowed to run
[16:39:49] <jmkasunich> its a little stream-of-conciousness right now, I'm touching it up
[16:41:26] <lerman> ...done reading.
[16:42:59] <lerman> It seems to have a model that everything (such as tool tables) is a parameter. Canon reads the parameter; not the tool table.
[16:43:16] <jmkasunich> I think that is where it is going
[16:43:51] <jmkasunich> many commercial controls work that way - in the back of the manual is a list of a few hundred high-numbered params that correspond to the various states of the machine
[16:44:08] <lerman> There is too way communication: the interp changes parameters that are read by itself and by canon. Canon changes parameters that are fed back to the interp.
[16:44:09] <jmkasunich> I have a hunch that they implement "read only" params, else all hell could break loose
[16:44:25] <lerman> Are there any params that are changed by both interp and canon?
[16:44:40] <jmkasunich> I don't know
[16:44:48] <jmkasunich> there are actually three things that can change stuff
[16:44:55] <lerman> Always a safe answer. :-)
[16:45:30] <jmkasunich> I tend to lump canon and interp together - both run in the same thread, at least today, and I don't know if there is much (any?) queuing between the two
[16:45:34] <jmkasunich> the third thing is realtime
[16:45:59] <lerman> I think we need a rule that there are none that are changed by both. [You are right... what I was calling canon is actually realtime.]
[16:46:02] <jmkasunich> 200 moves can be queued in the motion controller, anything (like a probe result) that depends on the result of a move can be delayed quite a long time
[16:46:35] <lerman> ...Days if you have a feedrate of .001 inch per minute... :-)
[16:46:49] <jmkasunich> heh
[16:47:49] <JymmmEMC> lerman: wouldn't just be faster to teach a cockroach to make the moves you wanted?
[16:48:08] <lerman> Having params that are changed in both will cause race conditions. Therefore the rule is that params are "owned" by either RT or interp. If we ever find somthing that needs to be changed by both, we can have RT change a mirror of the one you wanted changed, then interp would actually change it.
[16:48:38] <lerman> Nope. I don't speak roach. :-)
[16:48:39] <jmkasunich> yeah
[16:49:24] <jmkasunich> if the interp changes a param, there is really no tracking needed
[16:50:00] <lerman> So, we have three groups of params. Those that are owned both read/write by interp; those that are read/write by interp, read by RT; and those that are read/write by RT, read by interp.
[16:50:16] <jmkasunich> hmm, I wasn't thinking about it that way
[16:51:06] <jmkasunich> I was thinking in terms of each command having a (small) number of params that it reads, a small number that it writes, and not worrying about what code actually did the reading or writing
[16:51:28] <jmkasunich> for many commands both of those lists would be empty
[16:51:36] <lerman> I'm trying to come up with a simple cheat. The block that can be read by RT can have the current values of all passed to each (by a pointer).
[16:52:14] <lerman> I hate lists because they are too easy to screw up, they vary from command to command and are too hard to maintain, they tend to generate memory leaks.
[16:52:34] <jmkasunich> and I just realized a major obstacle to my plan - I was assuming that motion and task had equal access to the params (shared memory, etc), but in a distributed system that might not be true
[16:52:35] <lerman> hate is too strong a word... dislike.
[16:52:59] <jmkasunich> I didn't neccessarily mean "lists" as in the computer data structures
[16:53:02] <jepler> let me get one word in here and then I'll get back out of the way. Whatever you do in the interp, do it through a function call interface like canon is now. if the interp directly uses hal (creates pins, etc) then it can't be embedded in axis.
[16:53:06] <jmkasunich> these lists would be constant
[16:53:36] <jmkasunich> jepler: don't back out - more brains is good
[16:53:44] <jmkasunich> we should probably take this to -devel anyway
[16:53:46] <jepler> yeah but I don't actually want to tackle this problem
[16:53:51] <lerman> Thanks jepler ... axis is the center of our world. :-)
[16:53:51] <jepler> just make sure it doesn't make life hard or impossible for axis
[16:54:23] <jmkasunich> some things will be hard or impossible for axis (or the preview anyway, which is what I think you mean)
[16:54:36] <jmkasunich> you can't preview the result of a probing move
[16:54:40] <jmkasunich> (for example)
[16:54:48] <lerman> Axis can't hanle pro... beat me to it.
[16:55:07] <jepler> yes but at least with the canon interface I can do something
[16:55:19] <jmkasunich> this scheme could concievably let you write g-code that would probe the blank and decide how many roughing passes are needed
[16:55:26] <jepler> imagine if the interpreter created a hal pin and read the probe input directly; I couldn't make that fake in axis
[16:55:34] <jmkasunich> agreed
[16:55:40] <jepler> the preview can't be right in these cases, but some kind of preview should still be possible
[16:55:51] <jmkasunich> interp has no business interacting with HAL, I think we're all agreed there
[16:55:53] <jepler> (in the case of probes, I show the greatest distance that the probe could go)
[16:56:15] <lerman> I'm sure I don't want to create pins. But I might want to set them.
[16:56:29] <jmkasunich> from the interp?
[16:56:40] <lerman> Or, more likely, read them. Yup from interp.
[16:56:50] <jmkasunich> a "set pin" g-code should be passed to motion, and motion would set the pin
[16:56:53] <jepler> no, you want to make canon calls that get or set information in the abstract machine
[16:57:00] <lerman> Let the user select which size part to generate by setting a knob.
[16:57:02] <anonimasu_> hm, that opens up a whole lot of cute stuff you can do
[16:57:11] <jmkasunich> that command would in all likelyhood be queued, so the setting would be synchronous with moves
[16:57:15] <jepler> (in fact this is about 3/4 implemented thanks to alex)
[16:57:40] <jmkasunich> another g-code would do "read pin"
[16:57:51] <jmkasunich> and again, it would be a command issued to motion (by way of a canon call)
[16:58:04] <lerman> I think we need to ship alex a few kilos of coffee or other caffeinated beverage so he can stay awake during fest.
[16:58:19] <jmkasunich> lerman: are you coming to the fest?
[16:58:25] <lerman> Yes.
[16:58:27] <jmkasunich> cool
[16:58:40] <lerman> Arrive Sunday, leave Thursday.
[16:59:10] <lerman> Flying via Chicago and driving from there.
[16:59:24] <lerman> via -> to
[17:00:04] <jmkasunich> I'm looking forward to meeting you
[17:00:17] <lerman> Also.
[17:00:38] <jmkasunich> it seems a shame to have to rent a car for the week just to make the legs to/from Chicago
[17:00:55] <lerman> A simple approach to sync would be to say that it it is writable by RT, to wait until we are synched before reading by interp.
[17:00:58] <jmkasunich> there are plenty of cars to make runs between hotel and shop
[17:01:22] <alex_joni> lerman: caffeinated beverage sounds good :)
[17:01:28] <lerman> Is there an easy way to get from MDW to Galesburg and back.
[17:02:02] <lerman> Rayh owes me my favorite beverage, so I'll have him ship my Dr. Pepper to you.
[17:02:11] <jmkasunich> not that I know of - I drive past chicago on my way, but I'll be going on Sat and returning the following Sun, so I can't offer you a ride
[17:02:40] <alex_joni> lerman: I usually stay up pretty late ;)
[17:02:45] <JymmmEMC> lerman: Got Thumbs?
[17:03:08] <alex_joni> well.. pretty late here is in roughly 6-7 hours from now
[17:03:24] <lerman> alex_joni: I've noticed.
[17:03:39] <tomp2> check archives, i listed public transport from ohare to galesburg, and theres shuttle from mdw to ord
[17:03:57] <tomp2> plan on a really long day
[17:04:02] <jmkasunich> heh - during the workshop, I have a bad habit of staying up late and getting up late - I usually arrive at the shop very late in the morning
[17:04:49] <jmkasunich> I think by car it is something like 3-4 hours from Chi? not sure, the whole trip is 9-10 hours for me and tends to blur together
[17:05:17] <jtr> lerman: There's also Quad City International airport (MLI) in Moline. About 40 miles from Galesburg, IIRC.
[17:05:20] <lerman> I think google told me that it's 3:18 from MDW.
[17:06:06] <jmkasunich> quad city or peoria are a lot closer, but the connecting flight probably costs as much as the rental car (and you still need the car, unless somebody drives over from galesburg)
[17:06:23] <lerman> The flying problem is connections (and pricing). Orbitz had a cheap flight for me that had a layover in Atlanta. Eleven hours and 45 minutes is a bit much for a layover.
[17:06:26] <JymmmEMC> lerman: Just shave your legs and stick out your thumb. You're bound to get a ride from "someone" eventually =)
[17:06:30] <jmkasunich> I bet it costs less to get from wherever (calif?) to chi than from chi to peoria
[17:07:04] <lerman> I'm in CT; but will fly from LGA (LaGuardia, New York).
[17:07:09] <anonimasu_> :)
[17:07:20] <tomp2> ? windsor locks
[17:07:22] <jmkasunich> duh, I thought you were west coast
[17:07:40] <jmkasunich> swp is in VT, you should bum a ride with him
[17:07:48] <lerman> Even that is a pita. Yup. Windsor Locks is fine to fly from; but they don't have flights to anywhere useful.
[17:07:54] <alex_joni> lerman: M66 deos read HAL pins
[17:07:59] <alex_joni> does*
[17:08:05] <alex_joni> * alex_joni finished reading back
[17:08:10] <lerman> Yes. It does.
[17:08:23] <alex_joni> I think there are a couple of different topics you were discussing simultaneous
[17:08:27] <jmkasunich> yeah
[17:08:39] <jmkasunich> where does M66 place its results? in a param?
[17:08:44] <alex_joni> 1. I agree with jepler stating that everything from/to interp should go through canon
[17:08:47] <alex_joni> jmkasunich: yeah
[17:09:01] <lerman> We started with the subject of introspection (reading tool tables) and then went on to extrospection (writing tool tables).
[17:09:19] <alex_joni> motion always updates the pins to status, and interp grabs them through canon from task/status
[17:09:46] <alex_joni> lerman: I think all params should be accessible at different levels (interp/canon/task/motion)
[17:09:57] <alex_joni> accessible = reading and possibly even writing
[17:10:11] <lerman> Yes. I was just about to say that there should be a clean way of doing this.
[17:10:36] <alex_joni> but like jmk said the ones that can be written by RT for example should be sync points for interp
[17:10:37] <jmkasunich> so if you have M66; G1F0.1X20 ; M66; more code, _both_ M66's will return the same value, from a time before the G1 move
[17:10:42] <alex_joni> no
[17:10:50] <lerman> And we come back to the problem of sync.
[17:10:52] <alex_joni> M66 adds a disruptive process to interp
[17:11:05] <alex_joni> it simply stops interpreting ahead when it found an M66
[17:11:18] <lerman> OK. So M66 does a sync.
[17:11:21] <alex_joni> it won't know that there is a G1 until after it finished the M66
[17:11:33] <alex_joni> there are params for M66 to make it wait for an event
[17:11:38] <jmkasunich> ok, I see the main difference between what you guys have in mind and what I have in mind....
[17:11:45] <jmkasunich> your sync point is global
[17:11:46] <alex_joni> M66P1Exx (or something like that)
[17:11:51] <alex_joni> jmkasunich: atm yes
[17:12:11] <lerman> Global sync is cheap (in terms of implementation).
[17:12:13] <jmkasunich> that works as long as you have a very limited number of commands that need sync
[17:12:21] <alex_joni> jmkasunich: in the case of M66 there are 2 things that are interesting
[17:12:28] <gezr> howdy yall
[17:12:33] <jmkasunich> but suppose for example that we made a parameter that was "current X position in machine coords"
[17:12:36] <jmkasunich> every move would update it
[17:12:39] <alex_joni> 1. waiting for a bit to turn true/false (in that case it's simply a dwell until..)
[17:12:45] <jmkasunich> every move would then becomes a sync point - not good
[17:12:55] <alex_joni> 2. doing some branch based on the result from M66
[17:13:13] <alex_joni> the #2 would fit nicely in your concept I think
[17:13:23] <jmkasunich> 3. doing math based on the result from M66, then doing a branch on the result of the math, and so on
[17:13:40] <alex_joni> jmkasunich: whenever #5399 (the param written by M66) is encountered the interp waits for it to have been written
[17:13:41] <lerman> We would only want to sync when we read the param. So I'm back to three sets of params. If I use one that is writable by RT, then I have to sync.
[17:14:03] <alex_joni> lerman: right
[17:14:17] <alex_joni> but M66 also has a blocking mode
[17:14:18] <jmkasunich> I think that should be "if I use one that is writable by RT, and has a write pending, then I have to sync"
[17:14:40] <alex_joni> you say M66 P1 E1 Q10 (then it waits up to 10s for pin foo-01 to turn true)
[17:15:03] <alex_joni> or it returns -1
[17:15:09] <jmkasunich> so M66 does far more than just read pins
[17:15:12] <lerman> jmkasunich: that's more expensive to implement. How do we know that it has a write pending? By a flag with each param? Or by one flag for all params?
[17:15:14] <alex_joni> yes
[17:15:27] <jmkasunich> flag per param - per my proposal
[17:16:01] <jmkasunich> it has a fixed memory overhead per param, and is O(n) where n is the number of params that a particular command wants to read or write
[17:16:13] <alex_joni> http://www.linuxcnc.org/docview/html//gcode_main.html#sec:M66:
[17:17:14] <lerman> jmkasunich: All we need is one bit per param, then. RT sets it. When interp needs to use the param, it pauses till the queue is flushed, gets the param, and clears the bits of ALL params.
[17:17:54] <jmkasunich> I don't follow
[17:18:00] <alex_joni> s/pauses/stops interpreting further/
[17:18:10] <lerman> alex_joni: yes.
[17:18:16] <jmkasunich> rt sets it when? when it gets the command, or when it finishes executing the command?
[17:18:27] <alex_joni> finishes doing it's thing
[17:18:43] <lerman> Whenever RT sets a parameter, it can set the bit associated with it (first).
[17:18:54] <jmkasunich> I really don't get it
[17:19:23] <jmkasunich> what does the bit mean? "a write is pending on this param"? "this param is up to date"?
[17:19:37] <jmkasunich> for the former, it would have to be set when the command is issued
[17:19:39] <alex_joni> is not up to date
[17:19:48] <jmkasunich> for the latter, it should be set _after_ the write
[17:20:43] <lerman> I was trying to set them atomically.
[17:21:03] <jmkasunich> we need some concrete examples to talk about....
[17:21:08] <pjm_> ello
[17:21:39] <alex_joni> jmkasunich: agreed
[17:22:06] <alex_joni> but otoh, I think users/integrators beeing able to overload g/m-codes is a far more useful feature than reading/writing params
[17:22:09] <gezr> what is M66 anyway?
[17:22:19] <alex_joni> < alex_joni> http://www.linuxcnc.org/docview/html//gcode_main.html#sec:M66:
[17:22:52] <lerman> alex_joni: Is that a message for ME? I know how to do that; I just have to do it.
[17:23:10] <jmkasunich> the overloading thing?
[17:23:15] <lerman> Yup.
[17:23:16] <jmkasunich> what is that all about
[17:23:20] <gezr> oh thats a nasty one
[17:23:26] <jmkasunich> (is there a wiki page describing it or anything)
[17:23:45] <lerman> I'm not sure if I ever wrote a wiki page>
[17:24:08] <lerman> Damn. If it's not in the wiki it doesn't exist. Didn't I just say that?
[17:24:15] <jmkasunich> is it kind of like a named subroutine, where the name is "G30" ?
[17:24:44] <jmkasunich> and the possible args are A thru Z except G and M?
[17:25:08] <lerman> jmkasunich: yes. Exactly. But the parameters look like: X123.2 Y234.5 L12 etc.
[17:25:40] <gezr> those almost look like macro calls?
[17:25:44] <lerman> The idea is that whenever an X word is seen it will be stored in the named parameter <_x>, etc.
[17:26:30] <jmkasunich> "whenever" meaning any time (even in previous lines) or whenever in the line that is making the call?
[17:26:31] <lerman> The G30 will call a sub named <G30> after the rest of the line is parsed. The sub will be able to access those variables.
[17:27:08] <lerman> I'd probably store it for all lines because it is cheap and would let you have implied values for variables.
[17:27:26] <lerman> (variables whose values stick around from previous lines)
[17:27:37] <jmkasunich> today, I think you can get errors like "G30 without P value specified" (I'm pulling both 30 and P out of my rear)
[17:27:56] <jmkasunich> your approach would use a P from many lines ago, or even a default from the start of the program
[17:28:17] <jmkasunich> you lose some error checking that way, but it may not be practical to do it any other way
[17:28:19] <lerman> That's why I need to get the wiki page up; so I could be told that I'm ignorant in a more formal context. :-)
[17:28:42] <jmkasunich> I'm not saying you are ignorant
[17:29:01] <lerman> One of my alternatives was to have a flag to tell me that the variable had been set.
[17:29:07] <jmkasunich> the error message I'm describing is currently part of the interp, which knows exactly what args G30 should have, and can decide whether implicit values are OK
[17:29:10] <alex_joni> jmkasunich: there are certainly a couple of hidden biests
[17:29:20] <lerman> jmkasunich: no, you are not telling me that. I'm smart enough to figure it out myself.
[17:29:22] <jmkasunich> a user written replacement for G30 probably should specify the same info, but how
[17:29:45] <alex_joni> jmkasunich: right, that's something we need (needed params/values for them, etc)
[17:30:00] <lerman> By having flags with each _a_b_c, etc, the G30 sub could detect which ones had been specified on the current line.
[17:30:03] <alex_joni> doing param checking with Oif is not a real solution
[17:30:26] <lerman> alex_joni: why not?
[17:30:35] <alex_joni> jmkasunich: but this would easily allow some very smart configuration..
[17:31:03] <lerman> Have one bit for each of the _a, _b, etc. Then we could use masking, etc to tell if all the right ones were set.
[17:31:10] <alex_joni> lerman: hmm.. it's maybe harder to read.. but O100 if <_x_not_present> O100 (Err, fooo..)
[17:31:56] <alex_joni> jmkasunich: think M6 toolchanger (for a racktype one simply does a G1x[_P*<whatever>]
[17:32:18] <jmkasunich> ?
[17:32:28] <jmkasunich> I know there are many ways this would be usefull
[17:32:50] <jmkasunich> btw, that one won't work
[17:33:20] <lerman> The idea is that we have a general purpose language; how can we use it to grab tools and do other things.
[17:33:24] <gezr> let me ask this, do all existing canned cycles use parameters to store all included/omited programed values, or are they simply passed?
[17:33:52] <jmkasunich> damn, my head is starting to spin
[17:34:02] <jmkasunich> existing canned cycles are hard coded - they do what they do
[17:34:04] <alex_joni> gezr: on a canned cycle it errors out if a needed param is not supplied
[17:34:13] <lerman> I think canned cycles use inlined values.
[17:34:28] <lerman> On some machines, threading canned cycles take two lines.
[17:34:43] <gezr> exactly
[17:34:59] <jmkasunich> in some cases, the words needed for a canned cycle depend on the value of other word on the same line
[17:35:18] <lerman> One issue I find is making it so that an override gcode can call the hardwired gcode.
[17:35:34] <alex_joni> that way you can add additional error checking
[17:36:08] <jmkasunich> lerman - thats sort of a scope issue - calling a G or M named sub from within itself should get the original one
[17:36:13] <lerman> That would let us implement a rotated axis by reimplementing G1, G2, G3 to use rotational parameters. They would then have to be able to call the original gcodes to do the motion.
[17:36:18] <jmkasunich> although that rules out recursion
[17:36:25] <lerman> jmkasunich: correct.
[17:36:50] <alex_joni> how about allowing calling _Gxx for the userdefined one
[17:37:09] <lerman> Or use a special code to get the original. Yes alex_joni .
[17:37:09] <gezr> thats starting to sound like too much involvemnt, those types of calls should be restricted to macro programing, which is different then sub program type calls
[17:37:30] <jmkasunich> gezr: please describe the difference between a macro and a subroutine
[17:37:40] <jmkasunich> (because in this conversation, they are the same thing)
[17:37:43] <alex_joni> gezr: in the case of emc2 the macro language is the extension of g-code
[17:38:15] <gezr> a subroutine is typically called via a command to perform the sub, with a number of times to perform it, a macro call, contains parameter values that the macro can use
[17:38:53] <gezr> ie, a sub is just typical G code with defined values within the sub, a macro however
[17:38:54] <alex_joni> then we don't have sub's in emc2, only macro calls by your definition
[17:39:09] <jmkasunich> when you use the word "parameter" do you mean #parameters, like #100, or do you mean G60 L10, where L is a parameter?
[17:39:25] <gezr> #100
[17:40:37] <alex_joni> * alex_joni goes home...
[17:41:00] <jmkasunich> we have subroutines (thats what we call them anyway) that work like this: "O200 call [23] [16.2]"
[17:41:10] <jmkasunich> that calls subroutine O200
[17:41:27] <jmkasunich> and in that sub, #1 is 23, and #2 is 16.2
[17:41:51] <gezr> thats macro then
[17:41:57] <gezr> no problem with that
[17:42:06] <lerman> jmkasunich: I'm already home, but I think I'll sign off for a while. When you mentioned recursion, I think my brain cells took too big a hit.
[17:42:19] <jmkasunich> I'm having the same problem
[17:42:20] <lerman> I'll "see" you later.
[17:42:30] <jmkasunich> I'll update that wiki page when my brain cools down
[17:42:53] <gezr> I see, there is no M98 p100 l10
[17:42:56] <jmkasunich> I'll also try to put some examples of both #vars used for state, and "interesting" g0-code sequences, with N numbers
[17:43:03] <jmkasunich> so we can talk using the examples
[17:43:43] <jmkasunich> gezr: we have canned cycles like G76, those take arguments with letters in front of them
[17:43:56] <gezr> yeah I know that, but there is no sub program call routine
[17:44:02] <jmkasunich> and we have subroutines like O200, which take arguments in [] and based on position
[17:44:08] <gezr> your using macros
[17:44:35] <jmkasunich> what is M98 P100 L10 supposed to do?
[17:45:03] <gezr> it would call program 100 10 times
[17:45:10] <jmkasunich> what is program 100?
[17:45:22] <gezr> standard G/M coded program
[17:45:24] <jmkasunich> a completely different g-code file?
[17:45:27] <gezr> yep
[17:45:33] <gezr> just like on a fanuc
[17:45:43] <gezr> which is sepertat from a macro
[17:45:59] <jmkasunich> if I wanted to do something 10 times I would write a loop
[17:46:01] <gezr> fagor handles subs and macros differently but they are still seperate entities
[17:46:13] <jmkasunich> if that something is running a different file, I _think_ emc has a way to do that
[17:47:04] <gezr> all im trying to say is that a macro is more of a "programing" language, where a sub should be standard g/m code type stuff,
[17:47:07] <jmkasunich> you M98 line has two independent functions - looping N times, and calling a separate program
[17:47:12] <gezr> yeah
[17:47:53] <jmkasunich> I agree that EMC should be able to do both of those things, but I don't see why they should be tied into the same g-code
[17:48:15] <gezr> say your wantint to make a pocket, and not make it with macros, so you write a "sub" with the dimentions and stuff for the pocket from a center point, then you G(positon) M98 P100 G(position) M98 P100
[17:48:17] <jmkasunich> what if I want to do something other than call an independent program, but I still want to do it 10 times
[17:49:09] <jmkasunich> what is the difference between writing a program that makes a pocket centered on the current location, and writing a macro that makes a pocket centered on the current location
[17:49:18] <gezr> you omit the L on fanuc OT controls its M98 Pxxxxll where the xxxx is the program number, and the ll is times
[17:50:18] <gezr> there isnt a difference, however, it is easier to write a simple cycle to repeate X times or at multiple positions, then it is to write a #100 type parameter controled macro for some people
[17:50:53] <jmkasunich> they are exactly the same thing
[17:51:41] <gezr> to you and I they are the same thing
[17:51:53] <jmkasunich> you can write a program that is "G91; G1....... G92", or you can write the exact same stuff and call it a macro
[17:51:58] <crotchetyGuy> gezr: jmkasunich: macros (variables) can have debug problems. You often don't want to find a bug the hard way:)
[17:52:14] <jmkasunich> you don't have to use variables in a macro
[17:52:23] <jmkasunich> I assume gezr
[17:52:52] <jmkasunich> I assume gezr's pocket program uses G91 relative coords - you go to the center of the pocket, call the program, then go to the next pocket
[17:52:55] <gezr> no macros use variables or not, where as a sub, there is no use of macros
[17:53:11] <gezr> shoot, that didnt come out right at all
[17:53:15] <jmkasunich> ;-)
[17:53:23] <jmkasunich> no use of vars you mean?
[17:53:35] <gezr> macros can or can omit the use of vars, where as subs are defined points, g91 or g92
[17:53:41] <gezr> yeah
[17:53:48] <jmkasunich> now you lost me
[17:53:56] <jmkasunich> subs are defined points?
[17:54:26] <gezr> so like if someone didnt feel comfortable with setting a parameter, and that parm, is #100 and #100=z10.0, thats easy for us to understand right?
[17:54:58] <gezr> we could call that as you guys call it a sub that goes to #100
[17:54:59] <jmkasunich> #100 can't be Z10
[17:55:02] <jmkasunich> it can be 10
[17:55:04] <gezr> yeah, I mean 10
[17:55:16] <gezr> but lets say that were going to use it as a Z clear position of 10"
[17:56:02] <gezr> if a user was uncomfortable with setting a parameter they could just call a sub with a m98 command that has the command g0 g91 z10. m99
[17:56:03] <jmkasunich> ok, I'm completely lost
[17:56:42] <gezr> Im not trying to lose you, think in terms of wanting to do something really simple thats really easy to understand
[17:56:47] <jmkasunich> that subroutine means "from wherever you are now, move Z up 10"
[17:56:51] <gezr> yeah
[17:56:57] <gezr> the M99 exits the sub
[17:56:59] <crotchetyGuy> parameter subs require debugging and considerably more proofing- I consider them best for standard oft-repeated tasks, like soft jaw fixturing and the like. For production parts, I want no part of them.
[17:57:15] <jmkasunich> I would write that as: (please don't interrupt till I get all the lines down)
[17:57:22] <jmkasunich> O200 sub
[17:57:28] <jmkasunich> G1 G91 Z10
[17:57:34] <jmkasunich> O200 endsub
[17:57:51] <jmkasunich> and when they want to call it, they do: "O200 call"
[17:58:02] <jmkasunich> that's it - no #vars, nothing to hurt their little heads
[17:59:19] <gezr> okay, yeah, I see
[17:59:27] <jmkasunich> I just don't get the distinction between subs and macros.... yes, you _can_ pass params to macros, but you don't have to. why invent a completley different thing called a sub for that case
[18:00:11] <jmkasunich> maybe subs were invented first, so when the wanted to do something with params they needed a new name
[18:00:11] <gezr> im just going off machine experience, thats all, I see what your saying now
[18:00:43] <gezr> yeah, it was also a way to milk money from a customer, "you want to do custom macros too? okay, that will be X$ more"
[18:00:46] <jmkasunich> heh, and I have no machine experience (with commercial CNC) so I'm not looking at the history
[18:00:55] <gezr> oh
[18:01:29] <jmkasunich> its easy to find ourselves talking at the same problem from two different directions that way
[18:01:35] <Sweeper> NO U
[18:02:11] <Sweeper> also, I look with dread to the day when my cnc project is far enough along that I have to learn to write gcode D:
[18:02:50] <Sweeper> why can't I just do it in ruby? :P
[18:03:20] <gezr> back to the original issue though, checking wether a parameter is set or not. while wanting to do that sort of check can be beneficial, maybe send outputs to a little green or red led bank, thats not supposed to be the function of a "control" system, the difference is landing on mars and bouncing off the surface
[18:03:25] <BigJohnT> I do it with python
[18:04:17] <jmkasunich> well, right now EMC (actually Axis) can catch a lot of common programming errors when it pre-processes the g-code to do the preview
[18:04:17] <gezr> jmkasunich: does that make any sence?
[18:04:41] <gezr> sense
[18:04:51] <gezr> its called Axis now?
[18:05:06] <jmkasunich> I'd much rather have it tell me that I forgot to give my arc a radius _before_ I run the 500 lines that precede that arc
[18:05:18] <jmkasunich> Axis is one of the GUIs for EMC - the only one that does a preview
[18:05:23] <gezr> yeah, thats true
[18:05:55] <gezr> sigh, 7 more days and summer school starts
[18:05:56] <jmkasunich> Axis is the newest GUI and the one that most new users run
[18:06:13] <gezr> yeah, I havn't been that far detatched
[18:06:31] <gezr> My C programming is comming along nicely and ill be ready to start working on things really soon
[18:07:29] <lerman> jmkasunich: See: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?User_Defined_Gcodes
[18:07:31] <gezr> Im just seeing a lot of things come down the lists, and I wanted to get on and see whats been going on
[18:07:44] <lerman> I took a first cut at defining this facility.
[18:13:26] <BigJohnT> how does the M100/199 differ from all this?
[18:16:53] <lerman> Where is M100/199 defined?
[18:17:22] <BigJohnT> http://linuxcnc.org/docs/2.2/html/gcode_main.html#sec:M100-to-M199:
[18:18:42] <jmkasunich> M100-199 is an older approach to user defined code
[18:18:53] <lerman> M100 to M199 are very limited. They refer to an external program. They do not replace gcodes or mcodes.
[18:18:57] <BigJohnT> ok didn't know
[18:19:10] <lerman> Thanks jmkasunich for supplying the context I was lacking.
[18:19:12] <jmkasunich> they are both limited and unliminted
[18:19:36] <jmkasunich> because they can run an external program, they can do lots of weird stuff
[18:19:41] <lerman> Limited in the number of parameters supplied. Unlimited in that they call external programs.
[18:20:02] <BigJohnT> by external program do you me a g code file or something else?
[18:20:20] <lerman> Something else. C, python, snobol, whatever.
[18:20:22] <jmkasunich> for example, you could do a real hack, where g-code drives a robot to load a blank CD into a drive, the M101 executes a "burn the CD" command, then g-code unloads and stacks the disks
[18:20:36] <BigJohnT> ok
[18:22:35] <BigJohnT> I've been using o<dothis> call with a file called dothis.ngc for a while and it works well
[18:24:20] <lerman> BigJohnT: Glad to hear that you are on the bleeding edge. I tend to write a lot more C code for EMC than I write Gcode.
[18:25:05] <BigJohnT> lerman: it actually made it easier to run my plasma torch
[18:25:20] <BigJohnT> and yea I'm running pre-2.3
[18:29:10] <BigJohnT> if you could just make EMC transition from a line to an arc without taking a nap that would be great :)
[18:29:28] <anonimasu_> uh that shouldnt happen
[18:29:36] <anonimasu_> unless you are in exact stop mode
[18:29:39] <BigJohnT> it does
[18:30:38] <anonimasu_> even when not in exact stop mode?
[18:30:47] <BigJohnT> nope and G61/4 AFAIK are only for lines
[18:30:48] <anonimasu_> ie G64
[18:30:57] <anonimasu_> hm odd
[18:31:13] <BigJohnT> that's what I thought
[18:31:38] <BigJohnT> of course you can only see it when your going fast
[18:31:50] <anonimasu_> how fast is fast?
[18:31:54] <BigJohnT> like > 100 IPM
[18:32:14] <anonimasu_> only 2.5m/min
[18:32:15] <anonimasu_> :/
[18:32:42] <BigJohnT> yep that's all it takes
[18:33:28] <gefink> BigJohnT: depends the "naptime" to the PC-speed?
[18:33:51] <BigJohnT> if you have a zillion short lines it runs smooth as silk up to 450 IPM as far as I testes
[18:33:54] <BigJohnT> tested
[18:34:18] <BigJohnT> p4 2.4 GHz machine
[18:34:58] <gefink> thats good
[18:35:18] <lerman> Is the line tangent to the arc?
[18:35:36] <BigJohnT> yes and no tried both
[18:35:48] <BigJohnT> I could not tell the difference
[18:36:13] <lerman> I'm not a halscope person, but have you looked at what is happening with halscope?
[18:36:35] <BigJohnT> no, I don't know what pin to try and monitor
[18:36:53] <BigJohnT> I have used halscope before so I understand that part
[18:36:59] <anonimasu_> velocity perhaps
[18:37:28] <gefink> the positon cmd would be a good startingpoint
[18:37:32] <lerman> If you are zipping along the X axis and hit the curve, look at X velocity and position.
[18:38:07] <BigJohnT> * BigJohnT looking at hal config now
[18:38:34] <BigJohnT> I don't see a velocity
[18:38:43] <anonimasu_> might be called vel
[18:38:47] <anonimasu_> or something..
[18:38:56] <BigJohnT> I see stepgen.0.position-cmd
[18:38:58] <anonimasu_> ot it might not be there(I dont know anything about halscope)
[18:38:58] <anonimasu_> :p
[18:39:38] <BigJohnT> I looked for a velocity a while back for something else but could not find any
[18:40:08] <jepler> emc special-cases "lots of tiny lines" in the G64 P- mode, but it doesn't do this for arcs. "lots of tiny arcs" is a known bad performance case, because emc's trajectory planner will always plan in such a way that it could come to an exact stop at the end of the arc it is currently milling.
[18:40:29] <skunkworks> you (I think) can see this behavior going from spiral.ngc and arcspiral.ngc. You can run spiral a lot faster (assuming because it make multible lines into 1). When I run arcspiral.ngc - I have to have accelleration set very high to get it to run 500ipm - like 1000in/s/s
[18:40:35] <jepler> to create a velocity signal, you have to load a "ddt" component and then hook the position signal up to it. this is done for you in the sim/axis configuration but not in most others.
[18:40:36] <BigJohnT> jepler: it's not just tiny arcs
[18:41:12] <BigJohnT> ok I've done that before
[18:42:04] <jepler> does arcspiral.ngc have bad performance for you? is it bad through the whole run, or just near the center?
[18:42:13] <BigJohnT> jepler does it come to an exact stop at the end each arc?
[18:42:41] <BigJohnT> I didn't try that on my machine
[18:42:42] <anonimasu_> hm, so for 3d contouring you shouldnt use arcs..
[18:42:59] <jepler> BigJohnT: no, it blends
[18:43:09] <jepler> if the arc is not short, it should keep speed up just fine
[18:43:22] <anonimasu_> what happens on small arcs?
[18:43:28] <anonimasu_> do you run into acceleration limits?
[18:44:19] <jepler> anonimasu_: yes, the acceleration + the "always able to stop at the end of this <line or arc>" is what generally gives low contouring speed. G64 P- throws out some lines when they are close to colinear and improves this problem, but does nothing to arcs
[18:45:07] <BigJohnT> jepler: at high speeds with a 90 degree arc with .5 radius in each corner with a line connecting each arc .5 long it slows down at each line/arc transition
[18:45:08] <anonimasu_> * anonimasu_ nods
[18:45:51] <jmkasunich> BigJohnT: what is your accel limit? and how fast were you going for this test?
[18:46:02] <jmkasunich> IOW, "at high speed" = what?
[18:46:11] <anonimasu_> * anonimasu_ nods
[18:46:26] <BigJohnT> my accel is set at 400 and I started at 25 IPM and went up to 400 IPM
[18:46:50] <BigJohnT> at 75 IPM you could just see it starting
[18:46:53] <jepler> here's what my speed looks like in the outer part of arcspiral, on the sim machine http://emergent.unpy.net/index.cgi-files/sandbox/velocity-during-arcspiral-outer.png (acceleration 20 in/s^2)
[18:46:58] <jmkasunich> ok, lemme do some math
[18:47:02] <BigJohnT> and it got worse as you went faster
[18:47:11] <jmkasunich> 0.5" radius arc 90 degrees = 0.785 inches of travel
[18:47:30] <jmkasunich> 75 ipm = 1.25 in/sec
[18:47:52] <anonimasu_> that's alot of acceleration
[18:48:04] <jepler> and here's the inner portion of the program at the point where the arcs are each smaller than the critical acceleration distance: http://emergent.unpy.net/index.cgi-files/sandbox/velocity-during-arcspiral-inner.png
[18:48:39] <jmkasunich> 75ipm to zero is 1.25 in/sec to zero, at 400 ips/sec is 3.125mS, so you should be able to stop in about 0.002"
[18:50:08] <jmkasunich> can you add two ddt blocks to calc X and Y velocity, and a hypot block to calc the tangential velocity?
[18:50:09] <jepler> planner only uses 1/2 acceleration during blends
[18:50:13] <jmkasunich> then scope them
[18:50:32] <jmkasunich> still, 0.004 is a long way from the 0.78" long arc
[18:50:51] <BigJohnT> ok it will take a while the machine is in the shop
[18:51:19] <jmkasunich> whenever convenient - then imagebin the scope traces (I have to do outside for a couple hours anyway)
[18:51:21] <BigJohnT> how does the 0.004 relate to the length of the arc?
[18:51:29] <jepler> we give you permission to buy fancy wifi bridges in order to get network in the shop
[18:52:06] <jmkasunich> if the decel distance was about the same as (or longer than) the length of the arc, EMC would have to slow down - it assumes that it might have to stop at the end of the next segment (1 segment look-ahead)
[18:52:21] <jmkasunich> but with the decel distance so much less than the arc length, that can't be the problem
[18:52:51] <BigJohnT> jepler: if I would get off my lazy ass and start the backhoe up and bury some conduit I could have that and more out there
[18:53:06] <BigJohnT> jmkasunich: ok I understand that part now
[18:54:32] <BigJohnT> let me see if I remember I hook the position-cmd to the ddt block?
[18:54:39] <jmkasunich> yeah
[18:54:53] <jmkasunich> the output of the ddt block will be velocity, for X or Y
[18:55:09] <BigJohnT> then hook the output of the two ddt to the hypot
[18:55:23] <jmkasunich> both outputs goe to the hypot and it combines them to give you tangential velocity
[18:55:27] <jmkasunich> yep
[18:55:43] <BigJohnT> ok, then I remembered YEA!
[18:55:47] <jmkasunich> you'll want to scope all three velocities
[18:55:55] <gefink> BigJohnT: you can check how smooth the position-cmd is generated. Then you see if axis or stepgen makes the problem.
[18:55:57] <jmkasunich> and maybe one position, to trigger on
[18:57:14] <BigJohnT> ok
[19:00:00] <jepler> running on sim http://emergent.unpy.net/index.cgi-files/sandbox/rbox.ngc I got a nice velocity trace http://emergent.unpy.net/index.cgi-files/sandbox/halscope-rbox.png
[19:02:13] <jepler> zooming in and changing the scale, I can see that there is a 8 milli inch per second speed decrease that lasts for about 25ms: http://emergent.unpy.net/index.cgi-files/sandbox/halscope-rbox-zoomed-scaled.png
[19:05:34] <jepler> it's about the same if I specify G64 or G64 P.001
[19:05:52] <jepler> this is about what I would expect to see..
[19:08:52] <gefink> looks very good. if that by BigJohnT is the same additional the output of stepgen would be interesting
[19:17:53] <alex_joni> lerman: still around?
[19:18:15] <lerman> yup. but on the phone.
[19:18:38] <alex_joni> ok.. when you get back.. I read your page
[19:18:57] <alex_joni> but was wondering if it wouldn't be easier to have <_A> set to true of A was present on the line
[19:19:03] <alex_joni> then use <__A> to get to the value
[19:19:11] <alex_joni> (using masks is quite hard for g-code people ;)
[19:22:10] <OoBIGeye> what was it with that rayh guy?
[19:22:20] <SWPadnos> it wasn't rayh
[19:22:30] <SWPadnos> someone found his password and got juvenile and stupid
[19:22:38] <SWPadnos> oh look, he's still here
[19:22:46] <alex_joni> who? ray?
[19:22:52] <SWPadnos> no, the idiot
[19:24:07] <alex_joni> poutine?
[19:24:19] <SWPadnos> oh right - I guess he isn
[19:24:24] <SWPadnos> isn't here any more :)
[19:35:43] <crotchetyGuy> hello guys- probably a dumb question, but how do I get axis to recognize the A-B axis? I am trying to change the 5 axis example to a 5 axis vertical with AB head.
[19:36:07] <alex_joni> first of all you load the proper config
[19:36:26] <crotchetyGuy> yeah, I changed the config files
[19:36:42] <crotchetyGuy> I didn't see a place for axis changes-
[19:37:13] <crotchetyGuy> I thought maybe axis_3 was hard coded for a, but no go
[19:37:23] <alex_joni> you don't have to do any special axis changes
[19:37:37] <alex_joni> what does it show now?
[19:38:35] <crotchetyGuy> it gives me a "bad character 'a' used"
[19:38:48] <alex_joni> you tried loading g-code with A words?
[19:39:07] <crotchetyGuy> yes
[19:39:38] <alex_joni> before loading.. what does it show?
[19:39:45] <alex_joni> in the position readout
[19:39:57] <crotchetyGuy> um...all zeros.
[19:40:12] <alex_joni> X 0.000
[19:40:15] <alex_joni> Y 0.000
[19:40:19] <alex_joni> .. <- what?
[19:40:49] <alex_joni> Z, A, B ?
[19:40:56] <crotchetyGuy> ok, if I reload, it shows b and c axis, with z=100
[19:41:03] <crotchetyGuy> b=c=0
[19:41:09] <alex_joni> ok.. so you don't have A
[19:41:19] <alex_joni> check the ini file for "COORDINATES"
[19:41:22] <crotchetyGuy> copied the 5 axis example
[19:41:57] <crotchetyGuy> oops...thanks...shoulda looked closer...
[19:42:33] <lerman> alex_joni: Im back.
[19:42:54] <alex_joni> lerman: great.. seen my comments above?
[19:43:19] <lerman> Using a separate flag for each letter? Yes.
[19:43:37] <alex_joni> I think it's easier for the users/integrators writing these things
[19:43:44] <alex_joni> (maybe in extension to the _mask)
[19:43:49] <lerman> The downside is that each letter must then be tested for separately. I guess the answer is to provide both ways.
[19:44:10] <alex_joni> right
[19:44:18] <alex_joni> usually you only test the ones you want
[19:44:31] <lerman> if[ #<_mask> AND #<__A]
[19:44:32] <alex_joni> maybe O<missingword> call <_A>
[19:44:35] <SWPadnos> how about <A?> to test for the existence of A ?
[19:45:02] <lerman> Nope. That requires new syntax and a change to the language grammar.
[19:45:11] <alex_joni> <missingword> would check if <_A> is ok, and if not throw an error
[19:45:12] <crotchetyGuy> hmm...that's interesting- the axis display shows the tool tilt now. Didn't in the BC example
[19:45:15] <SWPadnos> in fact, test any name that way: <fred?>
[19:45:24] <SWPadnos> is '?' already used?
[19:45:33] <alex_joni> <SWPadnos?>
[19:45:40] <SWPadnos> ?
[19:45:44] <SWPadnos> (do I exist? :) )
[19:45:45] <lerman> No. ? is not used. As far as I know.
[19:46:03] <SWPadnos> oh - was the syntax comment aimed at me or Alex?
[19:46:13] <alex_joni> to you SWPadnos
[19:46:28] <lerman> Good idea to provide a fn that tests and throws an error. Might also have args of max and min value.
[19:46:42] <alex_joni> right, that's what I was thinking
[19:46:43] <SWPadnos> it doesn't seem different to use <A?> rather than <_A>
[19:47:00] <SWPadnos> except that the latter prevents the use of variables named _A
[19:47:04] <alex_joni> SWPadnos: <_A> fits under named parameters with a reserved meaning
[19:47:04] <SWPadnos> (and so on)
[19:47:17] <alex_joni> SWPadnos: so it's already documented :)
[19:47:33] <SWPadnos> sort of - what if I assign _A=37 ?
[19:47:41] <SWPadnos> or are _ not allowed at the moment?
[19:47:54] <alex_joni> you get a /kickban if you do that
[19:48:00] <SWPadnos> done, next!
[19:48:06] <lerman> Name space clashes are a problem. Names beginning with _ are global. Others are local.
[19:48:32] <lerman> No good way to reserve names or have multiple name spaces.
[19:48:41] <SWPadnos> I guess I'm generalizing the "existence check" to other variables also
[19:49:06] <SWPadnos> like "#if [<1009?>]" could test for numbered parameter 1009
[19:49:35] <SWPadnos> (though those sort of exist all the time)
[19:49:40] <lerman> Sort of.
[19:50:22] <lerman> alex_joni: What did you think of the requirement the user defined gcodes must be specified in the .ini file?
[19:50:43] <SWPadnos> I think I'd require those to be set in the ini
[19:50:59] <SWPadnos> maybe as a directory with (possibly) separate files for each code
[19:51:11] <SWPadnos> you can just link the some standard ones if you have a "central library"
[19:51:15] <SWPadnos> s/the/to/
[19:54:02] <alex_joni> lerman: I liked it
[19:54:03] <lerman> Oops. Gotta run. An ambulance call.
[19:54:08] <SWPadnos> bye
[19:54:12] <alex_joni> but I would keep them each in a file
[19:54:18] <alex_joni> lerman: oops.. hope it turns out well
[19:54:32] <lerman> Yes. The commands are each in a separate file.
[19:54:34] <lerman> bye
[20:07:43] <crotchetyGuy> alex_joni: the a words tilt the tool in Axis, but not b- is there something I need to do?
[20:11:08] <alex_joni> crotchetyGuy: edit AXIS I guess
[20:11:22] <alex_joni> I think jepler only added tilting for A
[20:12:07] <crotchetyGuy> ok- just wondering- thanks.
[20:38:43] <toastydeath> why did rayh kick everyone
[20:39:33] <anonimasu_> because some idiot stole he's account
[20:39:38] <BigJohnT> it was an imposter
[20:39:51] <toastydeath> but why did he kick everyone
[20:40:07] <anonimasu_> I dont know
[20:40:11] <toastydeath> k
[20:41:08] <BigJohnT> jmkasunich: here is what I got http://i47.photobucket.com/albums/f163/johnplctech/bumpy.png
[20:41:51] <BigJohnT> It took me a while as I'm not that good with halscope but the white line is the hypot out
[20:43:21] <BigJohnT> it looks like at every change of direction there is a bump...
[20:44:40] <BigJohnT> * BigJohnT is going to make little pieces of wood out of big ones...
[20:44:55] <micges> BigJohnT: that picture what is it about?
[20:46:52] <lerman> Why are there two white lines?
[20:47:20] <lerman> Instead of one?
[20:47:41] <alex_joni> hmm.. hypot is pretty constant
[20:51:59] <jmkasunich> it is slowing down, but only by a very tiny bit
[20:52:12] <jmkasunich> BigJohnT has good ears/eyes if he can see or hear that
[20:52:40] <anonimasu_> with steppers you should be able to hear it
[20:52:44] <jmkasunich> (well, I'm not sure where the zero line is - if that trace is poorly scaled or positioned those little dips might be bigger than they look
[20:52:54] <anonimasu_> :p
[20:53:33] <jmkasunich> anonimasu_: but there will be a pitch change at that spot anyway, since you are beginning a curve and an axis that was stopped is starting to move
[20:57:13] <jmkasunich> BigJohnT: I hope you're not using the plasma to make those little pieces
[20:57:26] <alex_joni> good night all
[20:57:31] <jmkasunich> good night alex
[21:08:36] <skunkworks> anonimasu_: you're in sweeden - right?
[21:08:52] <skunkworks> sweden
[21:30:17] <BigJohnT> jmkasunich: no, I'm using the dado blade on the radial arm saw to cut notches in pt 4x4 for railings on my deck
[21:30:50] <jmkasunich> ;-)
[21:31:15] <BigJohnT> chips everywhere and I mean everywhere
[21:31:20] <jmkasunich> I've almost finished a wood project - hope to have pics tonight
[21:31:27] <jmkasunich> I know exactly what you mean
[21:31:28] <BigJohnT> cool
[21:32:29] <BigJohnT> I built a deck around my house on 3 sides (it's on a hill) about 6 years ago. Boss Lady said we will put up the handrails this summer!
[21:34:18] <BigJohnT> I'm puzzled as to why if I cut a zillion lines that make up a circle that the speed stays constant? Is EMC just making a circle out of the lines?
[21:35:21] <tomp2> any suggestions for an OP07 replacement? ( that isnt weirdo OPxx ;)
[21:35:44] <BigJohnT> what is an OP07?
[21:35:49] <SWPadnos> op-amp
[21:35:50] <tomp2> opamp
[21:35:58] <SWPadnos> define "weird" for OPxxx
[21:36:07] <SWPadnos> they're available at digikey, in some forms
[21:36:13] <tomp2> sheriif taylor's 7th sun
[21:36:43] <tomp2> got some op27's on order, but even next day is morning of demo :(
[21:36:53] <SWPadnos> oh
[21:37:20] <jmkasunich> what special characteristics of the 07 do you need?
[21:37:34] <jmkasunich> if its just a demo, maybe you can get away with a lesser opamp
[21:37:58] <jmkasunich> for example, drift might not matter in a 1hr demo
[21:38:08] <tomp2> hah, the guy in spain didnt say, we just finished id'ing the chip ( it's the one stuck at 5.6V no matter what the input is )
[21:38:29] <SWPadnos> maybe it's a regulator ;)
[21:38:48] <tomp2> hahaha , i neede that ( been here over 20hrs )
[21:39:10] <jmkasunich> odds are any op-amp will do in a pinch, unless the circult is really finicky
[21:39:27] <jmkasunich> without knowing anything more about the circuit, might as well try it
[21:40:00] <tomp2> generic suggestion? it feeds a 3 tier window comparator, sez this porridge isjust right .....
[21:40:33] <tomp2> wait a mo
[21:43:52] <tomp2> http://imagebin.ca/view/LktkT9W.html the op at 'integrator'
[21:44:23] <tomp2> 741 pinout
[21:51:38] <tomp1> sorry power failure
[21:58:05] <tomp1> lm318 goin in... and replace the lm339 that it feeds too wth!
[22:22:01] <dmess> hi all
[22:23:06] <BigJohnT> dmess: your everywhere
[22:23:30] <BigJohnT> Gamma-X: you making parts yet?
[22:24:02] <dmess> http://afp.google.com/article/ALeqM5h8e2_2N1_t8D2YPqSh8tw8qxQBig
[22:24:12] <dmess> yes i try to be...LOL
[22:24:50] <dmess> WTF... happened to that plane...???
[22:25:42] <dmess> it is definitely BROKEN
[22:26:11] <BigJohnT> dunno but glad that never happened to me when I use to fly a lot
[22:26:31] <dmess> you a pilot??
[22:27:11] <BigJohnT> kinda, but I use to travel a lot on 747's and the like
[22:27:27] <BigJohnT> use to work in west africa
[22:28:17] <dmess> kinda??? like me im kinda a pilot.. i fly non powered a/c so i dont expect an engine to start up...
[22:28:50] <BigJohnT> well I can fly I just never got a license
[22:29:08] <BigJohnT> biggest I flew was a cessna 310 twin
[22:29:35] <dmess> same here... i have 12 hrs or so with a close friend a/c cessna 182
[22:29:45] <BigJohnT> i expect a sailplane pilot to have more skills than a powered pilot
[22:30:10] <dmess> hang and para gliders are m thing
[22:30:21] <BigJohnT> cool
[22:30:30] <BigJohnT> you must live near some hills and wind
[22:30:33] <dmess> fly by instinct
[22:30:54] <dmess> no we tow using a hydrostatic winch
[22:31:21] <BigJohnT> really! how does that work?
[22:31:29] <dmess> 4000 foot release from 2000' pull
[22:31:44] <dmess> just like a kid running a kit into the air
[22:31:59] <dmess> www.uflyontario.com
[22:33:39] <dmess> then once over the winch... you turn and head d/wind.... as he feeds you line.... you pull out 2-3 thousand feet of rope or to 750 AGL and you turn... and start a new pull to the sky... repeat.. and climb some more
[22:34:39] <BigJohnT> cool!
[22:35:07] <dmess> ive designed and built 2 winches so far... maintained the other 2 that have the capability on occasion.
[22:35:44] <BigJohnT> power feed in both directions I guess
[22:36:09] <dmess> absolutly... pushing a rope is someting we do often...
[22:36:29] <BigJohnT> lol
[22:36:54] <BigJohnT> looks like a small wireline winch that is used on oil wells
[22:37:09] <dmess> drum size and roller set-up is important or you throw birdsnests that make the pilot face DOWN... straight DOWN...
[22:37:29] <BigJohnT> now that's got to suck
[22:37:33] <dmess> no specialty shit i get mage... 3mm spectra
[22:37:49] <dmess> you gotta love your OLD weaklinks
[22:38:32] <dmess> ive been there...
[22:39:23] <dmess> i have dummy flew more new rigs or new winch operators than i really care to count...
[22:39:37] <BigJohnT> so you got an aw shit handle and a weak link on the tow line
[22:41:09] <dmess> we use 3 loops of mason twine as our w/l
[22:41:29] <dmess> between the carabiner and the tow line
[22:42:15] <dmess> its about 250 lb break away ... but i'm only 150lbs.. so i usually need to whack it
[22:42:57] <dmess> 30 foot wings mack whacking it easier..
[22:44:49] <dmess> funny you should mention wireline winch.. i used to diamond drill for gold in a previous life
[22:45:31] <BigJohnT> I use to drill for oil in another lifetime too...
[22:46:09] <dmess> cool... ever seen a hole turned 90 degrees... and still drillable??
[22:47:02] <BigJohnT> not in an oil well maybe 15 degrees but we use 5 1/2" drill pipe too...
[22:47:15] <BigJohnT> and 12" drill collars
[22:48:04] <dmess> good point... this was only 2 7/8" core so 3.25 tube...
[22:49:03] <BigJohnT> deepest I've ever drilled it just over 5 miles deep in the Gulf
[22:49:15] <BigJohnT> that's lots of pipe...
[22:50:31] <dmess> had a 2 week stint off my hole..... my cross shifter turned it 90 in under 1200'.... i flipped... the geo.. said.. "he was reporting good #'s"... did you look where he was going....NO... so we pulled 5000' a rod moved over 15' and started over
[22:51:06] <dmess> you dont wanna lose a bit at that depth.. thats bottom...
[22:51:12] <BigJohnT> I've seen some dumb things too
[22:52:17] <dmess> ive mined shaft too.... macassa #3 - kirkland lake ontario negative 8380'...
[22:52:55] <BigJohnT> only been inside the earth a few times, prefer on top :)
[22:53:19] <BigJohnT> * BigJohnT hears the dinner bell
[22:53:36] <dmess> i was undergournd at the age of 4 so inside the earth im ok with
[22:53:58] <dmess> l8r
[23:22:59] <toastydeath> i like tea
[23:41:15] <tomp1> i like the java jive and it likes me
[23:44:24] <toastydeath> do you also like ladytron
[23:44:27] <toastydeath> because i think i do
[23:44:30] <toastydeath> we can be friends.
[23:45:16] <toastydeath> -=friends=-
[23:45:41] <tomp1> dunno ladytron, that was a song by the InkSpots in 190
[23:45:47] <tomp1> 1940
[23:45:57] <toastydeath> i would believe it!
[23:46:05] <toastydeath> but the only reason i know about the ink spots is fallout