Back
[00:00:11] <dmessier> trust me swap.... i got room for a few more bodies i'm sure...
[00:00:18] <SWPadnos> about the smae as on Earth, I think
[00:00:31] <dmessier> but NO water...
[00:00:33] <SWPadnos> Canada has a much lower population per area
[00:00:39] <giacus> dmessier: ICE
[00:00:49] <SWPadnos> but all the references I've seen list Russia as the largest country
[00:00:50] <dmessier> not proven..
[00:00:51] <giacus> an italian probe found ice
[00:00:58] <giacus> sure
[00:01:28] <dmessier> is it solid h2o... or solid Ni
[00:01:32] <dmessier> N
[00:01:47] <giacus> is enough to start ..
[00:02:01] <giacus> we just need to hack mars !
[00:02:05] <giacus> hahah
[00:02:17] <dmessier> not if your thirsty... you can only go 3 days without water...
[00:02:37] <robin_sz> and about 3 minutes without air ...
[00:02:39] <dmessier> 3 weeks without food
[00:02:55] <dmessier> 3 hrs in extreme weather
[00:03:22] <dmessier> see a common rule of 3's for survivability
[00:03:55] <giacus> dmessier: if we have the source code, we can change the universe
[00:04:23] <dmessier> but only i have that... ; )
[00:04:39] <SWPadnos> ah - her ewe go
[00:04:45] <SWPadnos> no - here we go
[00:04:49] <SWPadnos> http://www.cia.gov/cia/publications/factbook/rankorder/2147rank.html
[00:04:57] <SWPadnos> if you can't trust the CIA, who can you trust
[00:05:01] <A-L-P-H-A> dmessier... hey, can I get the info on how to apply for that position you mention?
[00:05:02] <SWPadnos> (don't answer that)
[00:05:28] <dmessier> which one..
[00:05:36] <SWPadnos> about the CIA :)
[00:05:50] <A-L-P-H-A> dmessier? who are you referring to?
[00:06:00] <dmessier> you alpha...
[00:07:11] <A-L-P-H-A> dmessier the emergency response thing.
[00:07:13] <A-L-P-H-A> redshirts?
[00:07:16] <dmessier> we are currently looking for the necessary invesmet capital to put the roof over the machines heads... then the work will follow.
[00:07:21] <A-L-P-H-A> the team you wereputting together.
[00:07:49] <dmessier> we'll wear BLACK shirts for sure.. NOT red
[00:08:08] <A-L-P-H-A> :)
[00:08:10] <A-L-P-H-A> good.
[00:08:23] <A-L-P-H-A> as long as it's not pink... I could live with REd... not pink.
[00:08:29] <dmessier> your at whites rd ???
[00:08:33] <A-L-P-H-A> or any other gay color... Red is borderline gay.
[00:08:35] <SWPadnos> you wouldn't want to be eliminated to prove the situation is dangerous, after all
[00:08:41] <A-L-P-H-A> dmessier, I'm at liverpool and finch.
[00:09:01] <A-L-P-H-A> SWPadnos. hehe... ST I get it.
[00:09:11] <SWPadnos> Stone Trek :)
[00:09:17] <SWPadnos> (or GalaxyQuest)
[00:09:24] <dmessier> close enuf... were thinkin Witby location... are you currently workin'
[00:09:49] <A-L-P-H-A> Nope. I'm in school... Tuesdays to Thursdays, from 4:15pm to 10pm
[00:10:14] <dmessier> you could cover night shift though...
[00:11:01] <dave-e> SWP??
[00:11:03] <A-L-P-H-A> now? later?
[00:12:08] <dmessier> later...
[00:12:43] <SWPadnos> you rang?
[00:12:48] <dave-e> yep
[00:12:54] <dave-e> finally got an axis going
[00:12:58] <SWPadnos> cool!
[00:13:00] <dave-e> wild....p = 8
[00:13:07] <SWPadnos> interesting
[00:13:11] <dmessier> i have to go till about 9:00 .. son's soccer game call me 723-5085
[00:13:15] <dave-e> ff1 = 1
[00:13:18] <dmessier> later..
[00:13:25] <SWPadnos> see you dmessier
[00:13:32] <cradek> dave-e: yay
[00:13:37] <dave-e> indeed
[00:13:45] <SWPadnos> ff1=1 makes sense. what kind of amps do you have?
[00:13:59] <dave-e> still pretty uneven...especially on jog
[00:14:06] <dave-e> Servo Dynamics
[00:14:19] <dave-e> like the ones at Cardinal used on the Mazak
[00:14:30] <SWPadnos> ok - velocity mode?
[00:14:33] <dmessier> Alpha.. you famoliar with mazatrol t32??
[00:14:36] <SWPadnos> (or torque)
[00:14:38] <dave-e> yes...
[00:14:39] <cradek> dave-e: did you keep your tuning parameters you were using in emc1? I thought they could be copied right over (could be wrong!)
[00:14:39] <dave-e> velo
[00:14:49] <dave-e> not even close
[00:14:59] <SWPadnos> cradek, they should change, since emc2 uses user units throughout
[00:15:00] <dmessier> or will i have to learn ya???
[00:15:01] <dave-e> p = 150 and ff1 = 2.5
[00:15:21] <cradek> SWPadnos: ok shows what I know
[00:15:30] <SWPadnos> heh - you use steppers :)
[00:15:39] <cradek> yep
[00:16:00] <dave-e> will probably upgrade to newest cvs since I understand the blending is better.
[00:16:23] <dave-e> and John's changes to stg should also be there?
[00:16:39] <cradek> yeah blending was pretty broken in some ways in the version I think you have
[00:16:55] <dave-e> 2-19
[00:17:21] <dave-e> we'll see how it goes after I convert to inches
[00:17:36] <SWPadnos> if you do a CVS checkout and compile, then John's changes will be there
[00:17:37] <cradek> yes blending changed between TESTING-02-19 and TESTING-02-26
[00:17:40] <dave-e> 300 mm/min is not nice at this point...but better under mdi than jog
[00:19:09] <dave-e> I will ask explicitly when I get ready to do that...
[00:19:33] <dave-e> have to download to desktop then keystick it to the shop
[00:20:13] <dave-e> It is nice to have one axis going....tomorrow will do the other two.
[00:20:16] <cradek> there are three significant changes since TESTING-02-26: stg changes, M6 fix, mini font fix
[00:20:35] <dave-e> all sound good
[00:21:03] <cradek> if you're transferring on a memory stick it would be much (MUCH) easier for me to build TESTING-02-28 and you could put that one deb file on your stick.
[00:21:11] <dave-e> I've been trying synergy....and finding some interesting problems in the emc interp
[00:21:42] <dave-e> cradek....that sound really good...and nice
[00:22:10] <cradek> let me know when you get to that point
[00:22:19] <cradek> if I haven't done a new build already, I mean
[00:22:20] <dave-e> gotta go...see ya later..
[00:22:35] <cradek> you think you are finding interp bugs?
[00:22:39] <cradek> ok later
[00:22:50] <dave-e> yep...need to do more testing..
[00:23:04] <dave-e> should probably try skeleton on it.
[00:23:23] <dave-e> sorry got to run....later
[00:25:43] <cradek> it's good to have version strings now
[00:26:56] <SWPadnos> heh, I often notice that they're good when I don't have them
[00:27:43] <SWPadnos> man - Opteron 265s are down in the $300-$350 range now. cool!
[00:28:43] <SWPadnos> uh-oh. gotta run or I won't have any coffee for tomorrow morning
[00:28:48] <SWPadnos> back in a bit
[00:28:52] <cradek> bye
[00:44:31] <cncuser> hmmm
[00:54:24] <cncuser> does anyone use the supermount patch with rtai ?
[00:54:40] <cncuser> id like to use it but dont know how this may affect rt
[00:57:53] <dmessier> ALPHA...
[00:58:00] <cncuser> BETA
[00:58:10] <dmessier> CAPA
[00:58:24] <cncuser> hmmm, DURANDURAN?
[00:58:43] <dmessier> DURHAMDURHAM
[00:59:03] <dmessier> REGION THAT IS
[00:59:03] <cncuser> EMF
[00:59:08] <dmessier> sorry
[00:59:26] <cncuser> damn, you broke the alphabet ;)
[00:59:44] <cncuser> its gonna take years to fix that
[01:00:25] <dmessier> not for me
[01:00:36] <cncuser> hu
[01:00:50] <cncuser> so you know some alphabet magic or what ?
[01:01:25] <cncuser> it takes 200 elephants alone to move the R back to its place
[01:01:46] <dmessier> no.... we have the POWER
[01:02:40] <cncuser> dont even know how to lift EMF
[01:03:00] <dmessier> in the region of DURHAMDURHAM
[01:03:04] <cncuser> maybe some nuclear fusion or something may help providing the necessary power
[01:03:22] <dmessier> i know how to lift ME... if that helps
[01:03:44] <cncuser> hehe
[01:03:45] <dmessier> no dont wait for that...
[01:04:00] <dmessier> whats FREE
[01:04:08] <dmessier> ???
[01:04:11] <dmessier> to ALL
[01:04:15] <dmessier> ???
[01:04:20] <cncuser> to all
[01:04:21] <cncuser> hmmm
[01:04:38] <cncuser> youre free to die someday or later, or maybe sooner
[01:04:46] <cncuser> but you maybe forced too
[01:04:54] <dmessier> what else.. i dont agree...
[01:04:59] <cncuser> hmmm
[01:05:36] <dmessier> we have been missing the obvious for yrs...
[01:05:59] <cncuser> there peolple not free to say what they want. do what they want. eat or drink what they want.
[01:06:01] <cncuser> hmmm
[01:06:27] <cncuser> goto where they want.
[01:06:44] <cncuser> hmm
[01:06:51] <dmessier> i have denied it.. exploited it... thrived on it... been hurt by it... and plan on $$$ from it htis time...
[01:06:53] <cncuser> no, i dont see it
[01:07:22] <cncuser> whats free to all ?
[01:08:09] <dmessier> whats the differance between wieght and mass???
[01:08:19] <cncuser> none
[01:08:25] <cradek> uh??
[01:08:29] <cncuser> but im no physic ;)
[01:08:35] <cradek> big difference
[01:08:39] <dmessier> WRONG
[01:08:40] <cncuser> hehe
[01:08:41] <cncuser> :
[01:08:45] <cncuser> tell me :)
[01:08:50] <cradek> without gravity, you have no weight, but mass is unchanged
[01:08:55] <dmessier> pls cradek
[01:08:58] <cncuser> hmm, ok :)
[01:09:00] <cncuser> got it ;)
[01:09:01] <cradek> go to the moon, weight changes, mass doesn't
[01:09:05] <cncuser> tricky ;)
[01:09:13] <dmessier> magic word HAS bees spoken
[01:09:28] <cradek> sorry for the butt-in
[01:09:30] <cradek> haha
[01:09:32] <cncuser> yes, i know that story back from school... obviously i didnt reference to it ;)
[01:09:43] <dmessier> pls partake...
[01:09:44] <cncuser> cradek: haha, thanks. :)
[01:10:14] <dmessier> its the ONLY THEING THATS FREE
[01:10:22] <cncuser> whats free ?
[01:11:02] <dmessier> FACK..shite poop fart stinker....GRAVITY......... sorry
[01:11:07] <giacus> http://www.gnu.org
[01:11:28] <cncuser> giacus: doesnt count
[01:11:35] <giacus> ok
[01:11:45] <giacus> www.microsoft.com
[01:11:49] <giacus> :D
[01:12:20] <cncuser> giacus: you know that internet and computerusers are only a small part of worlds population ;)
[01:12:47] <giacus> yes
[01:12:58] <giacus> the best part :)
[01:13:19] <cncuser> depends
[01:13:20] <cncuser> ;)
[01:13:32] <giacus> yes
[01:13:40] <dmessier> new machine design ... expliots gravity to produce single family dwelling off grid for under 50 K US
[01:13:40] <giacus> depend on
[01:13:46] <cncuser> mass :)
[01:13:50] <cncuser> it depends on mass
[01:14:10] <dmessier> hmmm
[01:14:15] <giacus> bush is not pope reizinger
[01:14:21] <dmessier> are you thinkin yet??
[01:14:28] <giacus> bill gates is not stallman
[01:14:38] <giacus> depend ..
[01:14:38] <cncuser> stakkman is not stalin
[01:14:47] <cncuser> s/kk/ll/
[01:14:48] <giacus> but we not depend on
[01:14:51] <giacus> :D
[01:15:08] <dmessier> i KNOW guys who have peed on bill gates' house .... ;) i love it
[01:15:11] <cncuser> bill gates = bobby winton
[01:15:29] <giacus> internet is the power
[01:15:35] <giacus> as emc is the power
[01:15:46] <cncuser> giacus:it should read: internet uses much power
[01:15:50] <giacus> that's what I believe in
[01:15:57] <dmessier> rfom a hang glider .. out of Torrey pines glider port
[01:16:05] <giacus> cncuser: we are internet
[01:16:14] <giacus> we are the power
[01:16:25] <cncuser> giacus: i shutdown internet everymorning when i go to sleep
[01:16:30] <dmessier> use the force WISELY...
[01:16:46] <giacus> cncuser: I do the same
[01:16:59] <cncuser> rather unstable thingy this internet ;)
[01:17:01] <giacus> bt Internet is part of your life
[01:17:16] <giacus> your life is knowledge
[01:17:23] <giacus> not other..
[01:17:36] <cncuser> hmmm
[01:18:42] <dmessier> we hacke a local college computer with a 1200 bps modem in 1979... and it hasnt stopped since
[01:18:45] <cncuser> well, dunno much about the internet. i turn it on, shut it down. sometime my isp sends me fair use warnings because i raped the internet...again.
[01:18:48] <giacus> anyone can have his point of view
[01:19:22] <dmessier> i RAPE gravity... i win
[01:19:34] <cncuser> dmessier: you rule ;)
[01:19:59] <dmessier> you'll see... remember the name...
[01:20:06] <cncuser> hehe :)
[01:20:31] <dmessier> i thought i was wrong once buti was mistaken...
[01:21:50] <cncuser> dmessier: whats that story all about ?:) could you reduce the mass of my 6pack beer so that i ca easily carry 20 of them upstairs to my flat and then reverse the process (for i dont want no light beer)
[01:22:51] <dmessier> no but i could power you flat for a 6-pack a week...
[01:22:55] <cncuser> a ok, is exploit gravity. so nothing with ass. i learned something today ;)
[01:23:21] <dmessier> ive been screwed enuf thx
[01:23:35] <cncuser> haha
[01:24:02] <cncuser> dmessier: so you power your house with your gravopowerthing ?
[01:24:22] <dmessier> wait for it...
[01:24:30] <cncuser> dmessier: i allready have atheory
[01:25:03] <dmessier> shoot.. try me... i wont admit or deny... but i love the theories...
[01:25:26] <dmessier> means your all thinkin'
[01:25:32] <cncuser> dmessier: its not the gravity its the pressure of a bag of rice toppling down. on the other side of the earth
[01:26:09] <dmessier> that one i'LL deny right off...
[01:26:17] <cncuser> dmessier: ifrst try ;)
[01:26:28] <cncuser> dmessier: but can you prove it ?
[01:26:34] <dmessier> no chinese or iraqi involved
[01:26:48] <cncuser> austrians do eat rice too
[01:26:53] <cncuser> or australians
[01:26:58] <cncuser> all the same ;)
[01:27:18] <dmessier> im a prototype maker... there is only "one" for me to make...
[01:27:37] <cncuser> ic
[01:27:59] <dmessier> the rest i will GIVE to mankind... anything less would be selfish
[01:28:11] <cncuser> dmessier: very noble.
[01:28:21] <dmessier> thats the plan
[01:28:39] <cncuser> dmessier: well, hold on to it :) but dont get mad on it ;)
[01:28:41] <dmessier> you heard it here first...
[01:29:03] <dmessier> but I am MAD on it.. t PERFECT
[01:29:13] <dmessier> ITS
[01:29:38] <dmessier> many YRS of dreaming...
[01:30:36] <cncuser> best would be you opensource the thought right away, make a opn hardware project.
[01:31:59] <dmessier> not till the prototype... them.. we sign onto contract deal.. and royalties are ours...
[01:32:05] <cncuser> for it would be selfish of you not thinking about the possibility of a cowmad karibou hunting you down in the parkhouse ;)
[01:32:26] <dmessier> i like cariboo
[01:32:36] <dmessier> they taste great
[01:32:54] <cncuser> dmessier: you can build the machine anyways
[01:33:14] <dmessier> you think its close by..LOL idiot savant... pas
[01:33:27] <dmessier> and I WILL
[01:33:37] <cncuser> haha, dont get you ;)
[01:34:56] <dmessier> but as a secret pollution free ... FREE... electrical generator..... i WILL certainly LIKE having the ONLY one
[01:34:58] <cncuser> hmm 2:35
[01:35:40] <cncuser> cu tomorrow
[01:36:22] <dmessier> FYI....it cant be patented... apply.. and die... go figure
[01:36:56] <dmessier> its a GOD damned conspiricy
[01:42:15] <dmessier> any theories??
[01:44:23] <Jymmm> dmessier: See: theology
[01:46:19] <dmessier> i've crossed the borders of theology and technology .. they hav blended to become me and mine... WE have the power... and will learn to use it wisely..
[01:49:01] <dmessier> Jymmm ... have you ever read "The Celesien Phrophecy" or "Conversations With God"
[01:49:20] <dmessier> Celestine
[01:49:22] <Jymmm> * Jymmm dont read, unless it's tech docs
[01:49:50] <dmessier> hmm my wife read it to me.... the first time
[01:50:02] <Jymmm> "Tell me a story..."
[01:50:06] <Jymmm> lol
[01:50:19] <dmessier> its all about US
[01:50:27] <Jymmm> U.S. ?
[01:50:31] <dmessier> and how WE are !
[01:50:35] <dmessier> 1
[01:50:40] <dmessier> one
[01:50:44] <dmessier> the same
[01:50:52] <dmessier> together
[01:51:05] <dmessier> linked
[01:51:17] <Jymmm> let me know when it comes out on dvd.
[01:51:44] <dmessier> if you wanna change THE PLANET ... YOU CAn
[01:52:15] <dmessier> its out on audio... do you drive much?
[01:52:26] <dmessier> learn a little
[01:52:56] <Jymmm> not into audio books or AM broadcast =)
[01:53:29] <dmessier> im a Twinless-twin from birth... AND all STUFF wiERD...SEEMS TO STICK TO me
[01:53:38] <Jymmm> lol
[01:53:51] <dmessier> MUST BE THE FILLINGS
[01:54:05] <Jymmm> you musta got a defective tin foil hat.
[01:54:18] <dmessier> this isnt a hrd read
[01:55:17] <dmessier> no there was no son for mu dad... until the After birth had a heartbeat
[01:55:50] <dmessier> 4 lbs
[02:04:06] <giacus> night all
[02:04:45] <giacus> *_* time to sleep ..
[02:12:07] <dmessier> absolutly
[02:23:23] <dmessier> call from a mom of a friend of my 9yr old daughter... odd MSZ stuf... can any one help SUKEMEKIC34@hotmail.com
[02:23:39] <dmessier> msn
[02:24:06] <dmessier> i fi have to bury him.... I will
[02:25:28] <dmessier> all i want is addy , phone # and next of kin
[02:28:17] <dmessier> who's into IP trackin'
[02:37:41] <CIA-8> 03jmkasunich * 10emc2/src/hal/ (hal_lib.c hal_priv.h utils/halcmd.c):
[02:37:41] <CIA-8> Fixed bug that caused segfaults on HAL 'save comp' or 'save' commands. All
[02:37:41] <CIA-8> pointers into shmem stored inside the shmem must be offsets from the base of the
[02:37:41] <CIA-8> shmem block, not actual pointers, because every process will map the shmem block
[02:37:41] <CIA-8> to a different address.
[02:38:11] <jmkasunich> amazing that went unnoticed, its been in there for months
[02:38:18] <jmkasunich> guess nobody uses halcmd save
[02:45:12] <CIA-8> 03jmkasunich * 10emc2/src/hal/hal_priv.h: fixed type in comment
[02:53:30] <dmessier> kudos <CIA-8> hats off
[02:54:22] <dmessier> i love it when a GUY fixes a BOO BOO
[02:55:45] <dmessier> i got a 1st of on cmm on a hawker 400 main fitting,, yeee ha... release 2 more...
[02:56:01] <dmessier> 1 st OFFF
[02:58:05] <dmessier> party time... EXCELENT... : 0=====~~~~
[02:59:06] <dmessier> opps tooo much infoagain.... ineed moremeds..
[02:59:07] <jmkasunich> sounds like it
[03:02:01] <dmessier> but the DREAM always works... and the fuel is GRAVITY
[03:02:53] <dmessier> dream a life... live a dream....
[03:04:31] <dmessier> welcome to my party.... you're the finests ON THE INTENET.
[03:30:24] <SWPadnos> uh-oh - he's back
[03:30:31] <dave-e> indeed
[03:30:52] <dave-e> let's see ... what kind of chaos can I cause
[03:31:12] <SWPadnos> * SWPadnos thinks it's time for bed or something
[03:31:24] <dave-e> ah...safety in retreat
[03:31:38] <dave-e> swp... alone"
[03:31:44] <dave-e> swp... alone?
[03:31:47] <SWPadnos> in the immortal words of Monty Python - "Run Away!!!"
[03:31:59] <SWPadnos> that would be the "or something"
[03:32:20] <dave-e> was going to ask john about homing...
[03:32:44] <SWPadnos> ah
[03:32:53] <SWPadnos> several methods to choose from, as I recall
[03:33:05] <SWPadnos> don't remember which is which though
[03:33:25] <dave-e> well with a slight shift in cams I can go with the stuff done at Cardinal
[03:33:36] <dave-e> fast approach....decel and home
[03:34:06] <dave-e> which params to set and how is the question
[03:34:26] <SWPadnos> that would definitely be a jmk (or source browsing) question
[03:34:37] <SWPadnos> or possibly documentation
[03:34:46] <jmkasunich> hi dave
[03:35:00] <dave-e> jmk is probably safer than browsing....after C is a write only language
[03:35:15] <jmkasunich> not as bad as some languages
[03:35:18] <SWPadnos> APL
[03:35:24] <dave-e> depends
[03:35:31] <SWPadnos> that one can't even be written though
[03:35:35] <jmkasunich> the place for homing info tho, is a document called "EMC2_Code_Notes.pdf"
[03:35:40] <dave-e> ugh.... inbed everthing in parens
[03:35:44] <SWPadnos> APL perms are ---x--x--x
[03:36:01] <jmkasunich> url as soon as I find it ;-)
[03:36:14] <dave-e> thanks john I'll check it out.
[03:36:22] <jmkasunich> http://linuxcnc.org/EMC2_Code_Notes.pdf
[03:36:26] <dave-e> was a bit shocked by the P I had to use...
[03:36:41] <dave-e> emc = 150 emc2 is more like 8
[03:36:43] <jmkasunich> see pages 19-22 or so
[03:36:48] <dave-e> ok
[03:37:06] <jmkasunich> if the scaling is right in emc2., everything uses engineering units
[03:37:17] <dave-e> I hope the new stuff helps the smoothness or maybe I'm really badly tuned.
[03:37:17] <jmkasunich> position command, feedback, and error are all in inches
[03:37:24] <jmkasunich> velocity command to dacs is in inches/second
[03:37:32] <SWPadnos> what's the most recent version of that doc?
[03:37:57] <SWPadnos> nevermind
[03:38:14] <jmkasunich> so Pgain of 20 means if I'm 0.002" away from where I should be, the P term will cause it to move at 0.002*20 = 0.04 inches/sec toward where I should be
[03:38:15] <dave-e> 300 mm/min was really rough s but jogging at the same speed was awful....sounded like the short segment stuff on emc1
[03:38:56] <jmkasunich> your DAC scaling is probalby screwed up
[03:38:56] <dave-e> 15 caused osc
[03:39:14] <jmkasunich> (simply because it is machine dependent, unlikely to be right for your machine)
[03:39:22] <dave-e> amps are Servo Dynamics like at Cardinal
[03:39:23] <jmkasunich> are your amps torque or velocity?
[03:39:25] <dave-e> velo
[03:39:41] <dave-e> set for 10 v = max velo
[03:39:42] <jmkasunich> so X volts results in approx Y inches per second, right?
[03:39:52] <jmkasunich> what is the max velo?
[03:40:06] <dave-e> 3.25 in/sec
[03:40:38] <dave-e> well that was emc1 but I will dup that because I don't want to drive thngs too hard
[03:40:49] <jmkasunich> so you want the velocity command (from PID to DAC) to be 3.25 in/sec, when the DAC is putting out 10V
[03:40:59] <dave-e> yep
[03:41:15] <dave-e> or ya sure
[03:41:16] <jmkasunich> so DAC gain (output scale) should be either 10/3.25, or 3.25/10 (I can never remember which one)
[03:41:28] <jmkasunich> huh?
[03:41:35] <jmkasunich> this has nothing to do with emc1 or emc2
[03:41:48] <dave-e> so 8 is still high
[03:41:55] <jmkasunich> stop, stop
[03:42:01] <jmkasunich> we're not even on the same page
[03:42:14] <dave-e> opps!
[03:42:20] <jmkasunich> before you even think about tuning you gotta get the scaling right
[03:42:38] <dave-e> which scaling
[03:42:46] <jmkasunich> input and output
[03:42:54] <jmkasunich> I assume you have input right
[03:43:19] <jmkasunich> HAL pin stg.0.position should track the table position
[03:43:22] <dave-e> until I get your update input is 0.001
[03:43:42] <jmkasunich> move table 1 inch manually, that HAL pin (and emc's display) move by 1 inch
[03:44:12] <dave-e> and now the I have things moving I will change the whole ini to inches
[03:44:21] <jmkasunich> do that
[03:44:26] <dave-e> scale isnow right in mm
[03:44:42] <jmkasunich> picking the units for the ini file is the very very first step
[03:45:00] <jmkasunich> never change that unless you want to change a whole lot of other crap
[03:45:01] <dave-e> tomorrows task is to move the ini to inches and get y and z running
[03:45:16] <jmkasunich> here's my steps for startup
[03:45:23] <jmkasunich> set ini units
[03:45:57] <jmkasunich> set input scaling, so that the HAL signal coming from the encoder block is correct - move axis +1 inch, HAL signal goes +1
[03:46:04] <jmkasunich> direction and scale need to be right
[03:46:18] <dave-e> i'm ok there in mm
[03:46:28] <jmkasunich> next step, set output scaling
[03:46:32] <dave-e> just need to change to in
[03:46:41] <jmkasunich> there is a HAL signal that goes from the PID to the DAC
[03:46:49] <jmkasunich> that is supposed to be in inches/sec
[03:47:08] <jmkasunich> to make it correct, you need to set the dac scaling, to suit your amps
[03:47:11] <dave-e> name?
[03:47:24] <jmkasunich> if you put a 1.5V battery on the amp input, how fast does the table move?
[03:47:33] <jmkasunich> you can use that to determine the scaling
[03:48:05] <dave-e> ok ... so (1.5/10)*3.25 /sec
[03:48:14] <jmkasunich> no
[03:48:33] <jmkasunich> where is 3.25 coming from - is that what the amps do open loop with 10V on them?
[03:48:43] <jmkasunich> or is that some limit you want to set?
[03:48:55] <dave-e> both
[03:49:13] <jmkasunich> well we don't care about limits yet
[03:49:17] <dave-e> 3.25 ips at 10 v to amps
[03:49:29] <jmkasunich> huh?
[03:49:44] <jmkasunich> what does "to amps" mean?
[03:49:55] <dave-e> into the SD amps
[03:50:07] <dave-e> eg. output of the dacs
[03:50:17] <jmkasunich> oh, amps as in amplifiers.... sorry, when I hear amps I think amperes ;-)
[03:50:36] <jmkasunich> lol
[03:50:41] <dave-e> sorry amperes are 'A'
[03:50:51] <jmkasunich> this can be a painfull communications method sometimes
[03:51:00] <dave-e> different channel
[03:51:08] <jmkasunich> ok, 10V to amplifiers = 3.25 in/sec
[03:51:14] <dave-e> assumptions are alway difficult
[03:51:20] <dave-e> yes
[03:51:23] <jmkasunich> so 1 V to amps = 0.325 in/sec
[03:51:35] <dave-e> ok
[03:51:35] <jmkasunich> now I can never remember whether the dac scaling is * or /
[03:51:41] <jmkasunich> I think its *
[03:52:10] <dave-e> is this the line at the top of the pid stuff that is set to 1.0?
[03:52:36] <jmkasunich> so if the HAL signal to the DAC is 0.325 in/sec, and you want to get 1.0V out, the scale factor needst to be 1/0.325 = something around 3.xxx
[03:52:48] <jmkasunich> that is too vague a question to answer
[03:53:04] <jmkasunich> hang on a sec while I look at the STG ini file
[03:53:21] <dave-e> oh, sorry....right above P in the ini
[03:53:50] <SWPadnos> scaling and PID are different things
[03:53:58] <SWPadnos> you have to get the scaling right before you can tune PID
[03:54:07] <dave-e> keep going
[03:54:22] <jmkasunich> OUTPUT_SCALE = in the ini file
[03:54:29] <SWPadnos> waiting for jmk - he's doing OK here - it just looked like there was a little disconnect there
[03:54:58] <dave-e> I think output scale is set to 1.000 0
[03:55:12] <jmkasunich> yeah, and thats wrong
[03:55:29] <jmkasunich> that value is machine specific
[03:55:33] <dave-e> that could make a difference... ;-)
[03:55:50] <jmkasunich> for you it should be 1/0.325 (or 10/3.25, same result)
[03:56:06] <dave-e> ok that should make a real difference
[03:56:41] <jmkasunich> if the output scale is right, you should be able to force the HAL control signal to 0.1, and the table should move at about 0.1 inches per second
[03:56:47] <jmkasunich> (this is open loop, no PID at all)
[03:57:12] <jmkasunich> If I was doing it, I wouldn't even be running EMC at this point - this is one step past your "battery and pot" test
[03:57:32] <jmkasunich> (I really need to write up a wiki page describing this procedure)
[03:58:01] <jmkasunich> once you have the input and output scales right, then you can begin to tune PID
[03:58:21] <jmkasunich> ONLY after the scales are right, because changing scales will change everything else
[03:58:25] <jmkasunich> same with units
[03:58:31] <dave-e> what's the name of the signal?
[03:58:51] <jmkasunich> hang on
[03:59:10] <dave-e> I've done the battery box stuff to verify polarity and servo amp gain
[03:59:26] <jmkasunich> Xoutput, Youtput, Zoutput are the signals from PID to DAC
[04:00:03] <dave-e> so I set one of those and verify velocity
[04:00:25] <jmkasunich> Xpos-fb, Ypos-fb, and Zpos-fb are the signals from encoder to PID (and to EMC)
[04:01:15] <jmkasunich> if you set Xoutput to +0.1, you should see the table moving at 0.1 inches per second (in the positive direction) and you should see Xpos-fb increasing at 0.1 per second
[04:01:33] <dave-e> too logical
[04:01:56] <jmkasunich> that is the equivalent of the battery test, but extended inside the computer so you check HAL signals, encoder scaling and DAC scaling
[04:02:02] <dave-e> <grin>
[04:02:29] <dave-e> nice , think I'm going to like this system
[04:02:59] <jmkasunich> nice is when you're looking at those signals with halscope
[04:03:29] <dave-e> I brought up halscope today but could not figure out how to specify signal input
[04:03:45] <jmkasunich> click on a number below the screen (those are channel numbers)
[04:03:59] <jmkasunich> it will bring up a dialog, with three tabs
[04:04:07] <jmkasunich> one tab is pins, one signals, one parameters
[04:04:22] <dave-e> ah guess I didn't poke enough
[04:04:26] <jmkasunich> each tab lists lots of possible choices, click one, click ok
[04:04:50] <jmkasunich> its fairly intuitive, _after_ you've done it a couple times
[04:05:07] <jmkasunich> but the first time, its kinda confusing
[04:05:07] <dave-e> first time or two is alway difficult
[04:05:32] <jmkasunich> with Roland's Mazak, my gains were quite high
[04:05:43] <jmkasunich> P = 5000, I = 6400, D = 15
[04:05:56] <jmkasunich> P = 4000 (typo the first time)
[04:06:15] <dave-e> the vital stuff takes really high numbers...
[04:06:34] <jmkasunich> P gain of 4000 means that if you have 0.001 of error, there will be 4 inches/sec of correction taking place due to the P term
[04:06:44] <jmkasunich> 0.001 inches of error
[04:07:10] <jmkasunich> if the scaling is done right, it shouldn't matter what kind of hardware you are using
[04:07:38] <jmkasunich> vital, stg, motenc, all are the same, because position feedback and command are always in inches, and velocity command from PID is always in inches per second
[04:07:38] <dave-e> you set the servo amps for 10 v in = 12.5 A or so
[04:07:56] <jmkasunich> I thought you said the amps were VELOCITY mode?
[04:08:07] <dave-e> no ... the ones at cardinal
[04:08:22] <jmkasunich> I'm pretty sure they are velocity mode too
[04:08:44] <dave-e> I understood they were torque... and not tach for feedback
[04:08:52] <dave-e> no tach
[04:08:59] <jmkasunich> no tach true
[04:09:25] <jmkasunich> dunno if they had armature voltage feedback, or if it truly was torque mode
[04:09:28] <dave-e> we'll see what my system looks like in inch mode
[04:09:52] <jmkasunich> there is no way I can possibly remember that kind of detail, I can barely remember my name lately
[04:10:01] <jmkasunich> lemme look at roland's files
[04:10:20] <dave-e> the older we get the better we used to be... and I've got a lot of years on you
[04:10:48] <dave-e> lets see 8*25...
[04:10:53] <dave-e> close
[04:11:16] <dave-e> ballpark maybe a little hot
[04:11:20] <SWPadnos> 200
[04:11:33] <SWPadnos> (how's that for fast math?)
[04:11:44] <dave-e> acceptable
[04:11:59] <SWPadnos> well - I didn't notice the problem for a while ;)
[04:12:21] <jmkasunich> hmm, it seems OUTPUT_SCALE on rolands's mill is 1.0
[04:12:31] <jmkasunich> I really DON'T remember that!
[04:12:37] <SWPadnos> OUTPUT_SCALE was always rewritten by emc
[04:12:41] <SWPadnos> butnever read
[04:12:53] <jmkasunich> that's just plain fscked
[04:13:10] <SWPadnos> it was. Chris finally removed the ini save stuff fairly recently (I htink)
[04:13:11] <jmkasunich> EMC should keep its blasted hands off the ini file
[04:13:17] <SWPadnos> it does now
[04:13:43] <jmkasunich> so how the heck did I get Rolands' mill to work?
[04:14:03] <dave-e> hmmmm
[04:14:21] <SWPadnos> were some parameters set in the hal files?
[04:14:30] <jmkasunich> no, just looked
[04:14:39] <SWPadnos> odd
[04:14:40] <jmkasunich> (I committed rolands HAL files to CVS)
[04:14:44] <dave-e> spooky
[04:14:55] <jmkasunich> maybe they are torque mode
[04:15:12] <jmkasunich> output scale is 1.0, and max_output is 10
[04:15:22] <jmkasunich> max_output sets the limits of the PID output
[04:16:40] <jmkasunich> well, it looks like the tuning gains in the demo_mazak.ini file are for torque mode, so they WON'T be helpfull for dave
[04:16:50] <jmkasunich> (you do have VELOCITY mode, right?)
[04:16:55] <dave-e> yes
[04:17:26] <jmkasunich> unfortunatley that Maxak is one of only two servo systems I've tuned
[04:17:47] <jmkasunich> the other one used voltage mode amps (which is similar to velocity mode) and was scaled properly
[04:17:58] <jmkasunich> so in theory the gains would transfer
[04:18:14] <jmkasunich> IF the motors and machine were anywhere near similar
[04:18:19] <jmkasunich> unfortunatley they're not
[04:18:23] <dave-e> tomorrow evening I should know more
[04:18:39] <jmkasunich> this system was a 2-wheeled robot weighing about 10 lbs, and using 20 watt motors ;-)
[04:19:09] <dave-e> a bit different than moving > 1K Kg
[04:19:17] <jmkasunich> yeah, just a little
[04:20:30] <jmkasunich> I would tune using halscope and small jogs
[04:20:35] <dave-e> If I get the scale factor right I'll be surprised if p isn't about 150 and ff1 1-3
[04:20:48] <jmkasunich> (incremental, start with 0.1 inch, then go to 1 inch)
[04:20:55] <jmkasunich> ff1 should be 1.0, always
[04:21:14] <dave-e> ok
[04:21:29] <dave-e> so play with p
[04:21:46] <jmkasunich> (bacause the scaling is correct, if the commanded position is changing at 2.5 inches per second, the PID output should be 2.5, because that's what will make the DAC/amps run at 2.5 inches./sec
[04:21:51] <jmkasunich> P and I
[04:22:33] <jmkasunich> I initially set FF1 to zero, tune as best as possible PI and maybe D, then add FF1
[04:22:45] <dave-e> so far I've not found that I (emc1) made much difference
[04:23:18] <jmkasunich> YMMV, I found it important in my limited experience
[04:23:52] <SWPadnos> I shouldn't have a lot of effect in an otherwise properly tuned system
[04:24:00] <dave-e> well at least in emc1 one had to really careful with D and I was almost useless
[04:24:17] <jmkasunich> SWP: I would strongly disagree
[04:24:29] <jmkasunich> a system with only P can never reach zero steady state error
[04:24:29] <SWPadnos> that would be useful for something like a driven knee for Z, where it may tend to slowly drift downward over time
[04:24:37] <SWPadnos> true
[04:25:25] <jmkasunich> dave: about an hour ago you asked about homing ;-)
[04:25:28] <jmkasunich> that should come after tuning
[04:25:47] <dave-e> I understand what you are saying....gnuplot just didn't show much, if any, improvement with I and only a little with D
[04:25:58] <dave-e> yes I did
[04:26:26] <jmkasunich> halscope puts gnuplot to shame (if I may boast a little)
[04:26:40] <jmkasunich> you can view just about anything
[04:26:45] <dave-e> you may
[04:27:02] <jmkasunich> in this case I'd view commanded position, position error, and PID output
[04:27:22] <jmkasunich> trigger on commanded position crossing zero, and jog from -0.05 to +0.05
[04:28:05] <dave-e> ah .. you are a scope person
[04:28:13] <jmkasunich> of course
[04:28:25] <dave-e> ;-)
[04:28:51] <dave-e> I think this is going to be fun!!!
[04:29:08] <jmkasunich> just make sure you have an estop handy ;-)
[04:29:31] <dave-e> always within reach
[04:31:01] <dave-e> I think I've absorbed about enough for one night....
[04:31:15] <dave-e> will check back tomorrow evening with a progrss report
[04:31:27] <dave-e> progress
[04:31:29] <jmkasunich> ok
[04:31:33] <jmkasunich> good luck
[04:31:44] <dave-e> thanks a bunch!
[04:33:07] <SWPadnos> I suppose this points out a place where the hal configurator could come in very handy
[04:33:16] <SWPadnos> "tuning mode"
[04:37:25] <jmkasunich> yeah
[04:38:09] <SWPadnos> I wonder - do you think it's feasible to have a "servo_tuning.hal" file?
[04:38:38] <jmkasunich> one that replaces emc with a signal generator and a PID loop? sure
[04:38:41] <SWPadnos> something that you load after the driver_motion.hal file, and possibly instead of core_servo (or in addition)
[04:39:08] <SWPadnos> driver independent though
[04:39:23] <jmkasunich> the whole config file mess needs sorted out
[04:39:31] <SWPadnos> indeed
[04:39:49] <jmkasunich> driver_motion.hal as you say should handle only board specific stuff
[04:39:49] <SWPadnos> maybe halcmd should also have a "load" command added - to load .hal files
[04:40:07] <SWPadnos> yes, and connecting I/Os to the corerct signals
[04:40:10] <jmkasunich> in essence an include faciility
[04:40:13] <SWPadnos> (motion related I/Os)
[04:40:16] <SWPadnos> yep
[04:40:26] <SWPadnos> there's aloadrt and loadusr, why not load for .hal files
[04:40:44] <jmkasunich> I wouldnt call it that I'd just call it include
[04:40:58] <SWPadnos> user or programmer centric is the question ... :)
[04:41:06] <jmkasunich> well
[04:41:35] <jmkasunich> we already have the ability to load multiple hal files in the run script
[04:41:52] <SWPadnos> yep, I'm thinking for this kind of tuning
[04:41:52] <jmkasunich> duh, you're talking about not using the run script
[04:42:02] <SWPadnos> right
[04:42:23] <jmkasunich> bash is your friend
[04:42:30] <SWPadnos> bin/halcmd -kf / load stg_motion / load blah blah
[04:42:37] <jmkasunich> echo bin/halcmd -f "first file" >tune
[04:42:43] <jmkasunich> echo bin/halcmd -f "second file" >tune
[04:42:49] <jmkasunich> oops
[04:42:55] <jmkasunich> echo bin/halcmd -f "second file" >>tune
[04:42:55] <SWPadnos> cat ...
[04:42:56] <jmkasunich> ;-)
[04:42:59] <SWPadnos> right
[04:43:09] <SWPadnos> chmod +x tune :)
[04:43:10] <jmkasunich> I do that all the time
[04:43:17] <jmkasunich> I usually start with
[04:43:31] <jmkasunich> echo "scripts/realtime start"
[04:43:39] <ccjoe_> ccjoe_ is now known as ccjoe
[04:43:51] <SWPadnos> yep. I made a similar file for ppmc testing
[04:43:51] <jmkasunich> and I make another one, stop, that does halcmd unloadrt all ; scripts/realtime stop
[04:44:06] <SWPadnos> it did all that, loaded a few halmeters, then ran an interactive halcmd
[04:44:21] <SWPadnos> and unloaded everything once I exited from that halcmd
[04:44:39] <jmkasunich> I don't like interactive halcmd yet - I tend to use command line history a LOT
[04:44:55] <SWPadnos> double-click / middle-click is my friend ;)
[04:45:07] <SWPadnos> or just drag / middle-click
[04:45:11] <jmkasunich> once readline or whatever its called is added then it will be better
[04:45:18] <jmkasunich> I have a 2 button mouse
[04:45:24] <SWPadnos> ah - that makes it harder
[04:45:25] <jmkasunich> (I know, I can click both, but...)
[04:45:33] <SWPadnos> it rarely works well
[04:45:58] <SWPadnos> I think that regexp inhalcmd should be right up there with readline for near-term improvements
[04:46:04] <SWPadnos> ... in halcmd ...
[04:46:23] <jmkasunich> right after 2.0 there is quite a list
[04:46:36] <SWPadnos> that could be done easily by running a copy of grep on the output ;)
[04:46:40] <jmkasunich> I was very surprised to find a segfaulting bug in halcmd the other day
[04:46:51] <SWPadnos> that was odd - I hadn't run into it
[04:46:56] <jmkasunich> I do halcmd show pin | grep blah all the time
[04:47:03] <SWPadnos> I suppose most people don't use save
[04:47:18] <SWPadnos> me too, because I can't use the interactive halcmd that way
[04:47:20] <jmkasunich> save comp, only if a component was loaded with loadrt
[04:47:34] <SWPadnos> doing things lke show param *tmax would be nice
[04:48:00] <jmkasunich> yeah, I use grep for that now, but built in would be better
[04:48:02] <SWPadnos> even better, setp *tmax 0
[04:48:16] <jmkasunich> ooohhhhhh
[04:48:21] <SWPadnos> heh
[04:49:27] <SWPadnos> you would also get the headers and such still, whereas grep filters them out
[04:51:26] <jmkasunich> yeah
[04:52:04] <jmkasunich> halcmd.c is getting pretty big
[04:52:15] <jmkasunich> and this kind of stuff will just make it bigger
[04:52:16] <SWPadnos> yep
[04:52:24] <SWPadnos> true, but not by too much
[04:52:30] <SWPadnos> it's the added includes that'll get you
[04:52:54] <jmkasunich> in the long term, I want to have a core API, and a user interface, that are decoupled mode
[04:52:58] <jmkasunich> s/mode/more
[04:53:17] <SWPadnos> yep
[04:53:36] <jmkasunich> the regexp case would be interesting
[04:53:44] <SWPadnos> hal.lib is used by both RT and userspace code, right?
[04:53:45] <jmkasunich> one approach (which I think I prefer):
[04:54:08] <jmkasunich> have an api that gets all the names of the selected type (pin, param, etc)
[04:54:31] <jmkasunich> and another api for doing things to/getting info about a single instance, by nane
[04:54:58] <SWPadnos> hmmm - sounds simple, but makes for some lengthy transactions
[04:55:02] <jmkasunich> call the first funct, do the regexp on the returned list, the call the second api for each matching name
[04:55:05] <jmkasunich> yes
[04:55:23] <jmkasunich> the alternative is to put regexp code in every damned api
[04:55:48] <SWPadnos> yes, the name can be a regexp (which can also match a single name)
[04:55:53] <jmkasunich> and I really dont want that - then you penalize the single entry case to benefit the regexp case
[04:55:56] <SWPadnos> but it's one implementation of the regexp code
[04:56:18] <SWPadnos> it adds one strspn (I think) to look for regexp characters, else use simple comparison
[04:56:22] <jmkasunich> there is still a heavy penalty
[04:56:38] <jmkasunich> in the next iteration, names will be stored in trees, not linear lists
[04:56:53] <jmkasunich> looking up one will be order log(n)
[04:57:07] <SWPadnos> I think the regexp code actually uses optimized search algorithms as well, which may already default to a simple search if no special chars are used
[04:57:10] <jmkasunich> running the entire list (so you can apply the regexp to each one) is order N
[04:57:12] <SWPadnos> cool
[04:57:31] <SWPadnos> it's the same with halcmd | grep
[04:57:45] <SWPadnos> (actually, 2N)
[04:58:11] <jmkasunich> for show, its not so bad, you get info about everything, then only display some of it
[04:58:22] <jmkasunich> but for something like setp, you can't set everything
[04:58:59] <SWPadnos> right
[04:59:12] <SWPadnos> not that it's that useful in general
[04:59:17] <SWPadnos> but it does have some good uses
[04:59:26] <SWPadnos> actually, I take that back
[04:59:44] <SWPadnos> I'd also like to be able to set all P terms to some K
[04:59:49] <SWPadnos> etc
[05:00:18] <jmkasunich> I was planning on using AVL trees., so find(name), next(name), and prev(name) will be pretty quick (order log(N))
[05:00:23] <SWPadnos> the trouble is that '.' is a special regexp character
[05:00:46] <jmkasunich> but traversing the entire list will be slower than now (n log(n))
[05:00:49] <SWPadnos> ok, but that assumes that the lists are stored in order (alphabetical in this case), right?
[05:01:01] <jmkasunich> yeah, who was the genius that thought that up?
[05:01:17] <SWPadnos> it depends on how the data is accessed
[05:01:17] <jmkasunich> today the linear lists are sorted, later the trees will be sorted
[05:01:51] <jmkasunich> I was assuming a naive implementation of running the entire list
[05:02:19] <jmkasunich> name = first(); while ( name ) { name = next(name) }
[05:02:35] <SWPadnos> I'm referring to the genius who thought of that - it depends on how they expected to access their data (how smart the guy was) :)
[05:02:57] <SWPadnos> yep - that would do it
[05:02:58] <jmkasunich> I think the conversation forked
[05:03:05] <SWPadnos> heh
[05:03:24] <jmkasunich> my genius comment was about . as a wildcard.... it is used in filenames, don't overload it
[05:03:36] <SWPadnos> ah
[05:03:46] <SWPadnos> now I get it :)
[05:04:21] <SWPadnos> it's also heavily used in HAL names ;)
[05:04:23] <jmkasunich> where did the DOS filename wildcards come from? (CP/M, or even earlier)
[05:04:35] <SWPadnos> yep - CP/M
[05:04:35] <jmkasunich> * and ? for multiple and single "any char"
[05:04:47] <jmkasunich> ? is better than . IMHO
[05:05:16] <SWPadnos> yep, but * is "any multiple" in regexp, not "any string of 0 or more chars"
[05:05:59] <jmkasunich> huh? foo* matches foo, foot, and football (I think)
[05:06:17] <SWPadnos> yes, using shell globbing
[05:06:34] <SWPadnos> but regexp would only match foo, fooo, foooo, foooooooooo etc
[05:06:35] <jmkasunich> but not regexp?
[05:06:43] <jmkasunich> oh
[05:06:51] <SWPadnos> it means "any multiple of the last character or group"
[05:07:06] <SWPadnos> so foo.* would match all those other ones
[05:07:08] <jmkasunich> what about .*
[05:07:15] <SWPadnos> that would work :)
[05:07:27] <jmkasunich> we digress
[05:07:34] <SWPadnos> so we do (often)
[05:07:42] <jmkasunich> back to trees
[05:08:05] <jmkasunich> remember that next time around, halcmd isn't going to be wading thru the HAL metadata itself
[05:08:10] <SWPadnos> right - do the AVL functions "search" for the next in the list, or are there left/right/parent pointers?
[05:08:24] <jmkasunich> search
[05:08:29] <jmkasunich> let me explain
[05:08:58] <jmkasunich> most (all?) of the HAL metadata is going to be in kernel space, not shmem (making shmem a must less used resource)
[05:09:07] <SWPadnos> ok
[05:09:09] <jmkasunich> the core APIs will be implemented in kernel space
[05:09:18] <jmkasunich> as ioctls, or system calls, or whatnot
[05:09:58] <jmkasunich> its non-trivial to pass an arbitrarily long list (of names for example) to or from kernel space
[05:10:29] <jmkasunich> so I was gonna have functions that act on only one item, but I would include next() and prev() among them to traverse the list
[05:10:52] <SWPadnos> that'll be odd for multithreaded kernel functions
[05:10:58] <jmkasunich> mutex's would be released on each call, so in theory the list could change between getting item 1, and getting next(item1)
[05:11:18] <jmkasunich> so next always searches from the root of the tree
[05:11:30] <SWPadnos> also, item1 could go away, so next(item1) could be invalid
[05:11:50] <jmkasunich> if item1 is no longer there, next has no problem finding the item that follows it in lexical order
[05:11:58] <SWPadnos> true
[05:12:24] <SWPadnos> that's a lot of string processing for kernelspace
[05:12:52] <jmkasunich> thats why I don't want regexp, or command line parsing, as part of the core API
[05:13:01] <jmkasunich> name searches yes
[05:13:07] <jmkasunich> but that isn't really that bad
[05:13:44] <SWPadnos> a long list shouldn't be too hard to pass - read() does it all the time
[05:13:57] <SWPadnos> it's the arbitrarily part that gets you, I guess
[05:14:02] <jmkasunich> no it doesn't
[05:14:16] <jmkasunich> read passes a fixed size buffer (fixed when you make the call)
[05:14:29] <SWPadnos> sure, but that buffer cn be large
[05:14:30] <jmkasunich> right
[05:14:31] <SWPadnos> can
[05:14:48] <jmkasunich> large enough to hold potentially several thousand names each 30 chars long?
[05:14:51] <jmkasunich> ewww\
[05:14:55] <jmkasunich> wwww
[05:14:59] <SWPadnos> heh
[05:15:09] <SWPadnos> had to have another line of www huh
[05:15:14] <SWPadnos> wwww even
[05:15:27] <jmkasunich> the \ was an accident, but I figured I'd run with it ;-)
[05:15:33] <SWPadnos> but yes - even that's only ~100k or so
[05:15:39] <jmkasunich> only 100K
[05:15:41] <jmkasunich> ???
[05:15:56] <jmkasunich> how often do you see a program call read with a 100K buffer?
[05:16:03] <SWPadnos> yes - one call, one large buffer passed, with the exact data requested
[05:16:12] <SWPadnos> not often
[05:16:31] <jmkasunich> that huge list is still potentially out of date the instant its returned
[05:16:47] <SWPadnos> yep
[05:16:49] <jmkasunich> and if you are doing a show command, the buffer needs to be even bigger
[05:17:07] <jmkasunich> you either get every last bit of data at once, then regexp it
[05:17:24] <SWPadnos> well, if you use a device node for this info, hathe kernel can just return EOF when it's done
[05:17:31] <jmkasunich> or you get just the list of names, then call back to the API with a subset of the names for the details
[05:17:33] <SWPadnos> the user program can read in blocks or lines
[05:18:05] <SWPadnos> the list of names is what needs the 100k buffer
[05:18:09] <jmkasunich> would that work if two instances of the user program were both reading at the same time?
[05:18:18] <jmkasunich> the data can be worse
[05:18:35] <jmkasunich> think of signals - the data that goes with a signal includes the pins attached to it
[05:18:36] <SWPadnos> I'm not sure how that would work, but I suspect that the kernel knows the pid of the process accessing the device node
[05:18:44] <jmkasunich> another arbitrarily large list
[05:18:48] <SWPadnos> yes
[05:19:11] <jmkasunich> so you have an arbitrarily large list of arbitrarly large items
[05:19:24] <SWPadnos> yep
[05:19:27] <jmkasunich> not something to be passin' in a fixed size buffer
[05:19:44] <SWPadnos> unless there's a way of indicating that the buffer-full isn't the whole story
[05:19:48] <SWPadnos> like EOF
[05:19:53] <SWPadnos> (oe lack thereof)
[05:19:56] <SWPadnos> or
[05:20:37] <jmkasunich> if two user programs open the same file and start reading, each gets the entire file
[05:20:43] <SWPadnos> the kernel code should at least return a whole chunk of data at a time (like the fill pin list for a signal)
[05:21:08] <SWPadnos> s/fill/full/
[05:21:18] <jmkasunich> if two user programs open /dev/keyboard or some other inherently single stream device, and start reading, who gets what?
[05:21:28] <SWPadnos> good question
[05:22:04] <jmkasunich> I'm afraid that the read() approach would also require open() and close()
[05:22:18] <jmkasunich> and open() would have to take a mutex, not to released it until close()
[05:22:32] <jmkasunich> _that_ is a long time to hold the HAL mutex
[05:23:11] <SWPadnos> hmmm
[05:24:03] <SWPadnos> the userspace code shouldn't be dealing with mutexes - that should be done by the kernel code when it's asked to change something
[05:24:13] <jmkasunich> I know
[05:24:30] <jmkasunich> the user calls open(/dev/hal) and the kernel takes the mutex
[05:24:43] <SWPadnos> why at that time?
[05:24:57] <SWPadnos> it only needs the mutex when it's acting on a user request
[05:24:57] <jmkasunich> I dunno ;-)
[05:25:01] <SWPadnos> heh
[05:25:17] <SWPadnos> so the user writes a command to the file (for example)
[05:25:44] <SWPadnos> the kernel sees the command, takes the mutes, does the command action (possibly filling a buffer with results), then releases the mutex
[05:26:02] <SWPadnos> when the user reads the file, the result buffer(s) are returned
[05:26:13] <jmkasunich> but if the buffer isn't big enough, what does the kernel do ?
[05:26:30] <jmkasunich> needs to wait for the user to read it, then continue the action refilling the buffer, possibly several times
[05:26:30] <SWPadnos> it should make a buffer that's big enough (which could be a problem)
[05:26:54] <SWPadnos> then return it in user-request-sized chunks
[05:27:01] <jmkasunich> you're just moving the "pick a big enough buffer" problem into kernel space from user space
[05:27:14] <SWPadnos> in a way, yes
[05:27:31] <jmkasunich> I want all operations that the kernel is asked to do to be completely atomic
[05:27:53] <jmkasunich> and if that means multiple requests when processing lists of stuff, so be it - one request per item, each request is atomic
[05:28:38] <SWPadnos> well, that';s OK, but it makes it so that every user program has to duplicate the routines for searching and filtering
[05:28:59] <SWPadnos> and concatenating output, and providing headers, etc.
[05:29:06] <SWPadnos> look here, by the way:
[05:29:10] <SWPadnos> http://www.linuxjournal.com/article/1220
[05:29:12] <jmkasunich> those are user program tasks anyway
[05:29:28] <SWPadnos> under the heading "Multiple or single open", 80% of the way down or so
[05:29:36] <jmkasunich> halcmd will want to do that differently than halgui or whatever
[05:29:45] <SWPadnos> true
[05:32:50] <jmkasunich> I really want to avoid the entire open() read() write() close() model for this
[05:33:00] <SWPadnos> ok. it's just one option
[05:33:15] <SWPadnos> the better one is probably a syscall, but there are issues with that (as you know)
[05:33:18] <jmkasunich> actually, let me put that differnetly
[05:33:41] <jmkasunich> if I do the open/read/write/close model, I want to have the full halcmd inside the box
[05:33:54] <jmkasunich> cat foo.hal >/dev/hal
[05:34:04] <SWPadnos> yep
[05:34:12] <jmkasunich> but that is strictly a one way pipe
[05:34:15] <jmkasunich> no way to get output
[05:34:19] <SWPadnos> cat foo.hal > /dev/hal && cat /dev/hal
[05:34:46] <SWPadnos> hm - actually, just a ; is better than &&
[05:35:15] <jmkasunich> and if I do echo show all >/dev/hal, and DON'T do the cat /dev/hal?
[05:35:29] <SWPadnos> you get squat ;)
[05:35:46] <SWPadnos> but there would be problems there, since the two cats would have different PIDs
[05:36:05] <jmkasunich> is all that crap going to spew in the face of the next guy who does "echo setp foo 0 >/dev/hal ; cat /dev/hal"
[05:36:26] <SWPadnos> just load up the proc filesystem with a separate node for every pin, param, and signal ;)
[05:36:34] <jmkasunich> that has been mentioned
[05:36:51] <jmkasunich> show all becomes ls -R
[05:36:54] <SWPadnos> yep
[05:37:19] <SWPadnos> fin /proc/hal -name *tmax | xargs cat
[05:37:21] <SWPadnos> find
[05:37:37] <SWPadnos> or something like that
[05:37:50] <SWPadnos> (never quite got the syntax of xargs down)
[05:38:29] <jmkasunich> I wonder how bad the overhead for that would be?
[05:38:53] <jmkasunich> and what is the long term viability of /proc? is /sys supposed to replace it?
[05:39:01] <SWPadnos> dunno. the names would be pretty static, so there shouldn't be a lot of problems there
[05:39:08] <SWPadnos> could be
[05:43:02] <jmkasunich> /proc/hal/stg0/enc0/position
[05:43:24] <jmkasunich> I can just hear Paul scoffing
[05:43:28] <SWPadnos> heh
[05:44:01] <jmkasunich> have to think on this
[05:44:17] <jmkasunich> but I still favor a small core API
[05:44:27] <jmkasunich> with every operation atomic
[05:44:32] <SWPadnos> yep - that would be good
[05:44:49] <SWPadnos> but to paraphrasr Einstien - "it should be as small as possible, but no smaller"
[05:44:52] <SWPadnos> paraphrase
[05:45:51] <SWPadnos> well. bedtime for bonzo here
[05:45:57] <SWPadnos> good night
[05:46:00] <jmkasunich> getting late here too
[05:46:09] <SWPadnos> about the same, I think
[05:46:42] <SWPadnos> SWPadnos is now known as SWP_Away
[13:38:00] <CIA-8> 03cradek 07simple_tp * 10emc2/src/emc/kinematics/ (tp.c Makefile):
[13:38:00] <CIA-8> fix transient bug caused by uninitialized variable, remove unused Makefile
[13:38:00] <CIA-8> from old build system.
[14:03:44] <cncuser> hello :)
[14:06:12] <alex_joni> hello
[14:07:43] <cncuser> hi alex_joni
[16:13:28] <les_w> morning all....I taking the day off since temps are in the 70s F
[16:29:47] <jepler> anybody know anything about this software?
http://rss.freshmeat.net/freshmeat/feeds/fm-releases-global?m=14996
[16:30:13] <jepler> "
[16:30:13] <jepler> gCAD3D is a 3D CAD-CAM application that features an integrated 3D OpenGL viewer, a program interpreter for geometry and NC-commands in 3D, an integrated NC-processor, and a programming interface for user programs. It has support for importing Step files and support for both importing and exporting Iges, DXF, and VRML-1 files."
[16:36:29] <alex_joni> jepler: I have the doze version installed
[16:36:37] <alex_joni> but I couldn't get it to load step recently
[16:36:45] <alex_joni> wanted to do just that..
[16:36:53] <alex_joni> but I gave up, found another free one instead
[16:37:36] <alex_joni> * alex_joni goes away for a while
[16:54:52] <skunkworks> wow - the linux boot loader holds on for dear life. Had to do a fdisk /mbr
[17:31:29] <SWP_Away> cat /dev/zero bs=512 count=1 > /dev/hda will also do the trick
[17:31:52] <jepler> use /dev/urandom, it's better
[17:32:10] <SWP_Away> oops, I meant dd
[17:32:15] <SWP_Away> SWP_Away is now known as SWPadnos
[17:32:19] <jepler> (though I suppose there's a small chance you'll get the same bootsector again)
[17:32:33] <SWPadnos> heh - that would be funny
[17:37:14] <alex_joni> jepler: or an improved one
[17:37:38] <SWPadnos> that would be even funnier
[17:38:10] <alex_joni> maybe a different picture..
[17:38:21] <alex_joni> or an OsX bootloader :D
[17:38:29] <alex_joni> funny, but not probable
[17:39:28] <SWPadnos> dd/dev/infinite_improbability_drive > /dev/hda
[17:39:55] <alex_joni> sounds like h2g2
[17:40:03] <SWPadnos> indeed it does
[17:40:25] <alex_joni> ok, then it's not just me ;)
[17:40:35] <SWPadnos> nope, it's Zaphod or Trillian
[17:40:44] <alex_joni> how's cncgear.com/joomla ?
[17:41:02] <SWPadnos> seems OK to me
[17:41:12] <alex_joni> still some stuff missing
[17:41:16] <SWPadnos> more stuff going in, I see
[17:41:50] <bill2or3> that's sharp looking.
[17:42:00] <alex_joni> I'm thinking of an About (info about EMC, the board, versions, etc)
[17:42:19] <SWPadnos> yep, and copy most of the links from the linuxcnc site as well
[17:42:22] <bill2or3> * bill2or3 has a tiny suggestion.
[17:42:29] <SWPadnos> * SWPadnos closes his ears
[17:42:37] <alex_joni> bill2or3: shoot
[17:43:08] <alex_joni> SWPadnos: right, those were in the Links section on dsplabs, didn't get them over here yet
[17:43:20] <bill2or3> all the cnc pages seem to be written for machinists, I could have really used a page that explained the pieces, without assuming I allready knew everything aobut the machine side.
[17:43:24] <SWPadnos> no rush
[17:43:50] <alex_joni> well.. this is no cnc page ;)
[17:43:51] <bill2or3> although I guess not too many people say to them selves "I've never used a mill, but I think I'll build a CNC system!"
[17:43:59] <bill2or3> yeah, true.
[17:44:08] <alex_joni> it's a page about the emc software
[17:44:15] <alex_joni> and people who use it or ponder using it
[17:44:18] <bill2or3> maybe just link to some good 'basics' pages.
[17:44:26] <alex_joni> and it will provide lots of links to basic cnc places
[17:44:31] <bill2or3> cool.
[17:44:32] <alex_joni> I think ;)
[17:44:55] <bill2or3> cuttingedgecnc.com was one that really helped me grasp all the pieces of the puzzle.
[17:45:23] <bill2or3> also, anyone know of any good reading on gantry design/building?
[17:46:49] <alex_joni> bill2or3: try
http://www.mendonet.com/cnclinks/
[17:47:32] <bill2or3> thanks.
[17:48:04] <bill2or3> I have almost all the subsystems kind of vaguely sketched out in my mind, time to actually make some detailed plans.
[18:37:37] <skunkworks> was away - thanks for the info.
[18:38:17] <skunkworks> and remember - flying is easy - just throw yourself at the ground and miss.
[18:43:56] <Jymmm> lol
[18:44:35] <Jymmm> so every time I trip and fall I've been flying... I'll be damn, never knew that!
[18:45:50] <bill2or3> only until you "land"
[19:15:51] <skunkworks> bill - cnczone.com forum is an interesting read
[19:17:12] <CIA-8> 03cradek 07simple_tp * 10emc2/src/emc/kinematics/ (tc.h tp.c): better trapezoidal profile
[19:18:35] <skunkworks> I can't believe this
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=4442423301&rd=1&sspagename=STRK%3AMEWA%3AIT&rd=1
[19:18:55] <skunkworks> cradek: how is the math going?
[19:19:33] <cradek> ok but during my tp testing I found a bug in task
[19:19:51] <cradek> only shows up if you have axes with different accelerations
[19:20:22] <skunkworks> that is what I have. - what kind of bug?
[19:20:30] <cradek> accel constraint violation
[19:21:17] <skunkworks> what you had fixed was in the tp? (a while ago - got indiviual accels for each axis working decent)
[19:21:40] <cradek> yeah I think it's not quite right when mixing coordinated and noncoordinated moves
[19:22:17] <jepler> What makes a move "noncoordinated"?
[19:22:36] <cradek> I think just a jog
[19:22:48] <cradek> I'm trying to figure out the exact pattern
[19:23:13] <skunkworks> going from a single axis move to a multible axis move?
[19:23:23] <jepler> btw playing with axis+emc2 on ubuntu I've noticed that the first G0 after a jog can be too slow...
[19:23:26] <cradek> ok say x is slow acc, y is fast acc
[19:23:51] <cradek> start at x0y0, MDI y1, jog to ~ x1, MDI x0y0 -> following error
[19:24:10] <cradek> the second MDI does not account for the X axis needing to move
[19:24:27] <cradek> task uses the last *programmed* (coordinated) point
[19:24:43] <skunkworks> jepler - I think there is still some oddity with the default feeds at startup. When you do a g0 move it sets the feed to the maxumum. then when you do a g1 without a feed it lets you do it once - then sets the feed to zero.
[19:24:58] <skunkworks> I think - don't have it exactly down yet.
[19:25:02] <cradek> I thought alex fixed that?
[19:25:28] <SWPadnos> theoretically, G0 can be non-coordinated (I think)
[19:25:45] <skunkworks> I think the problem moved to a differnt one now. ;) I have not figured out the pattern yet.
[19:25:48] <SWPadnos> also homing isn't coordinated
[19:26:50] <cradek> SWPadnos: g0 always goes through the TP, jogs and homing don't
[19:27:15] <cradek> SWPadnos: I think that's the difference, or if it's not, it's the difference I mean (which might not have an exact name)
[19:27:21] <SWPadnos> just (possibly mis-)remembering some comments in the RS274 manual
[19:27:26] <SWPadnos> ok
[19:35:23] <cradek> forget it, I fixed it
[19:35:30] <cradek> I think
[19:36:22] <CIA-8> 03cradek 07simple_tp * 10emc2/src/emc/kinematics/tp.c: fiddly things needed for switching between coordinated and non-coordinated
[19:51:34] <skunkworks> ok - in axis - if when axis first starts I type in g0x1 -> then g1x0 (at this point the feed rate in the modal list changes to 150ipm) it goes back to zero. now if I do a g1x1 - I get a "cannot do a g1 with zero feed rate". when I hit ok the feed rate changes back to zero.
[19:52:33] <cradek> skunkworks: if you would, please update (or re-open) the bug report in the tracker
[19:52:51] <cradek> skunkworks: I don't want to get sidetracked on an interp problem right now, but I don't want it to get lost
[19:55:43] <skunkworks> ok - no problem - just pointing it out - I would rather you get the tp working better ;)
[19:56:30] <cncuser> hi
[19:57:22] <alex_joni> hello
[19:57:28] <cncuser> hi alex
[19:57:32] <alex_joni> skunkworks: can you tell me what the problem is?
[19:57:43] <alex_joni> we'll let cradek worry about TP, and I'll look into it.. ok?
[19:57:47] <alex_joni> hi cncuser
[20:21:06] <CIA-8> 03cradek 07simple_tp * 10emc2/src/emc/kinematics/tp.c: documentation only
[20:25:39] <skunkworks> yes
[20:25:55] <skunkworks> did you see what I had wrote? did it make sense?
[20:28:10] <alex_joni> somehow, but I was able to replicate it
[20:28:19] <skunkworks> it is in mdi.
[20:28:20] <alex_joni> any G0 leaves some feedrate for the next G1
[20:28:27] <alex_joni> max_feedrate
[20:28:33] <alex_joni> * alex_joni looks for his previous fixes..
[20:28:37] <skunkworks> right
[20:29:04] <SWPadnos> isn't the issue that the feedarte gets set to 0 for zero-length moves?
[20:29:07] <SWPadnos> feedrate
[20:29:30] <alex_joni> no
[20:30:18] <skunkworks> that was a differnt issue. I think that was fixed.
[20:31:03] <SWPadnos> but the error you got was "cannot do G1 with zero feedrate"
[20:31:17] <SWPadnos> that implies that there's something setting the feedrate to 0
[20:32:32] <skunkworks> alex - and it is repeatable. like you said any g0 move puts the feed rate in for the next g1 move
[20:32:41] <jepler> skunkworks: for MDI only?
[20:32:46] <skunkworks> if you give it a f then it is fine.
[20:32:51] <skunkworks> mdi so far
[20:33:04] <skunkworks> have not tried it in proram yet
[20:34:08] <alex_joni> it's MDI only
[20:34:38] <jepler> in emc1 this program (not mdi) gives weird results:
[20:34:38] <jepler> g0 x1
[20:34:38] <jepler> g1 x0
[20:34:38] <jepler> m2
[20:34:48] <jepler> half the time it errors due to zero feedrate, the other half it goes (back) to x0
[20:35:01] <alex_joni> jepler: ewww
[20:35:09] <SWPadnos> even if you manually move to x0 between runs?
[20:35:19] <SWPadnos> (or to X1, for that matter)
[20:37:08] <jepler> whether I g0x0 between runs seems to make no difference
[20:37:13] <jepler> every other time, the g1x0 is accepted
[20:37:23] <jepler> emc1 so maybe nobody cares
[20:37:31] <alex_joni> jepler: I think it's dependent on the last command
[20:37:35] <alex_joni> if it was a G0 or not
[20:37:53] <alex_joni> if the last one was G0 (e.g. the G1 faulted) then it will work
[20:38:13] <alex_joni> but the next time when it works, it will execute both G0 and G1, and the next G1 won't
[20:38:30] <alex_joni> try putting an G0 at the end of the program, see if that changes things
[20:38:57] <skunkworks> also if you set the feed rate - do a g0 move - the next g1 move has the feed as the g0 move though it seems to move at the right rate.
[20:39:32] <alex_joni> skunkworks: easy now, let me fix the first one ;) then we'll look for new bugs :P
[20:43:06] <skunkworks> I thought it was related
[20:43:10] <skunkworks> ;)
[20:43:31] <skunkworks> it is just if you don't have a feed rate specified it actually goes at the g0 rate.
[20:43:51] <skunkworks> for the first g1 move after the g0
[20:45:34] <alex_joni> yes, I know.. figuring out (again) how the dataflow works ;)
[20:45:52] <alex_joni> gui->task->interp->canon->task->motion->etc
[20:46:01] <alex_joni> not that easy to follow ;)
[20:46:32] <skunkworks> yes that is exactly what I was thinking. gui->task->interp->canon->task->motion->etc exactly ;) (not really - just kidding)
[20:48:04] <alex_joni> lol
[20:48:24] <alex_joni> and the problem is in canon somewhere, just need to figure out what gets called from where ;)
[20:52:58] <alex_joni> or not..
[20:53:28] <Jymmm> les_w: You alive? Sober? Awake?
[20:55:49] <alex_joni> skunkworks: interpreter.. darn I like this :/
[20:58:19] <skunkworks> isn't that really written funny?
[20:58:39] <skunkworks> if's without endif's and such
[21:04:06] <alex_joni> jepler: did I thank you for the new buildsystem?
[21:12:59] <Jymmm> alex_joni No, and you still havne't!
[21:15:34] <cncuser> ok
[21:15:55] <alex_joni> well.. I wanted to thank him personally
[21:15:56] <alex_joni> :P
[21:15:58] <cncuser> i definitly shouldnt stare into this screen anymore
[21:16:33] <cncuser> i cant even run a while loop on a textfilelisting anymore
[21:17:22] <bill2or3> * bill2or3 got his z-axis assembly
[21:17:46] <alex_joni> skunkworks: I got it..
[21:18:00] <alex_joni> I mean.. I know what's wrong
[21:18:29] <cncuser> arghl
[21:18:33] <alex_joni> now I need to find a way to fix it without busting anything else
[21:18:35] <alex_joni> :/
[21:18:38] <cncuser> one should not use file as a variable in shellscripts ;)
[21:19:20] <skunkworks> sweet
[21:19:38] <skunkworks> that is the hardest part- fixing it without breaking anything else
[21:20:19] <bill2or3> ugh
[21:20:34] <bill2or3> now that I look at this, I realize I still need to make some rails for Z
[21:21:09] <bill2or3> * bill2or3 grumbles
[21:21:26] <alex_joni> skunkworks: it seems to be running ok.. I'll commit
[21:21:35] <alex_joni> if people complain.. eh, that's life ;)
[21:21:53] <alex_joni> kidding, this was wrong from the beginning
[21:22:45] <cncuser> bye folks
[21:26:09] <skunkworks> nice job alex
[21:30:28] <CIA-8> 03alex_joni * 10emc2/src/emc/task/emccanon.cc: fix to the bug discovered by skunkworks, G1 with no feedrate works after G0, that was possible because interp used the emcStatus->motion.traj.velocity as a vel. check, but that one also gets updated on G0's
[21:30:30] <alex_joni> skunkworks: you can test soon ;)
[21:31:11] <alex_joni> btw, that's one of those bugs where you look half an hour in a dozen of files & places, and in the end it's a line that needed changing
[21:32:19] <alex_joni> skunkworks: you were running debs? or from CVS, compiled by yourself?
[21:37:50] <skunkworks> I am running ubuntu with cradeks wizardry
[21:38:48] <alex_joni> ok, then it'll be a while till this propagates to you
[21:40:05] <cradek> thanks for finding that one alex
[21:40:08] <skunkworks> no problem
[21:40:17] <cradek> sometimes the one-line fixes are the hardest ones
[21:45:53] <CIA-8> 03cradek * 10emc2/src/Makefile: more make clean massaging
[21:49:08] <alex_joni> cradek: hope I didn't bust anything..
[21:49:19] <alex_joni> I'm not very sure about angular axes
[21:49:21] <cradek> it's why we call it testing
[21:49:54] <cradek> I agree the different units are really confusing
[21:50:22] <alex_joni> but that code I just looked at is pretty crazy..
[21:50:29] <alex_joni> it's all over the place
[21:50:34] <alex_joni> as I said..
[21:50:45] <alex_joni> gui->task->interp->canon->task->motion->etc
[21:51:53] <cradek> ugh
[21:52:29] <cradek> too many layers
[21:53:02] <alex_joni> yup, and this one was interp reading a velocity out of the motion controller
[21:53:26] <alex_joni> through emcStatus (actually emcmotStatus sent through NML) .. ugh
[21:54:13] <alex_joni> http://hytaipan.home.comcast.net/hubble640.html <- nice pictures
[21:54:26] <cradek> http://news.bbc.co.uk/2/hi/americas/4761294.stm
[21:55:24] <alex_joni> lol.. think I fit in :D
[21:55:50] <alex_joni> * alex_joni knows little about the 5 amendaments
[21:56:01] <cradek> well you're not from around here
[21:56:13] <cradek> you have an excuse
[21:56:29] <alex_joni> yeah, so-called ;)
[21:59:24] <alex_joni> cradek: just looked over the code a bit more, and I think the change I just did is harmless, it shouldn't affect anything
[21:59:34] <cradek> great
[21:59:38] <alex_joni> it gets only tested as a condition
[22:00:18] <alex_joni> so the worst case might be some setting of feedrate only for circular, and g1x not working (but I don't see how you could set only the circ. velocity)
[22:00:48] <alex_joni> SET_FEED_RATE sets them both
[22:01:10] <alex_joni> the only place where they get changed..
[22:01:27] <alex_joni> ok, enough feed_rate stuff :D
[22:17:49] <alex_joni> g'night all
[22:18:19] <alex_joni> * alex_joni is done for today (yesterday actually, as it's 00:18 over here)
[22:19:17] <Jymmm> G'Night alex_joni
[23:06:10] <lilo> [Global Notice] Hi all. One of our projects of which you may have heard, wikipedia, has almost reached its one millionth article. You may want to go help them with the countdown on #wikipedia-countdown .... congratulations to all concerned. :)
[23:07:27] <lilo> [Global Notice] Whoops, that may have been unclear. Wikipedia uses freenode, but they're run by Wikimedia Foundation, not us. ;) The channel is #wikipedia-countdown :)
[23:14:36] <skunkworks> jepler / cradek?
[23:16:16] <cradek> yes
[23:20:51] <skunkworks> Hi - when axis is zipping around showing cutter path - that is actaul machine cutting path isn't it?
[23:21:30] <cradek> it is the commanded position so it's within +- following-error of the actual cutter
[23:21:45] <cradek> so it does show the blends etc.
[23:21:48] <skunkworks> ok - so it is showing blending
[23:21:52] <cradek> yes
[23:21:53] <skunkworks> ;)
[23:21:54] <cradek> definitely
[23:24:42] <cradek> http://timeguy.com/cradek-files/emc/nasty-blend.png
[23:25:10] <cradek> now that I understand this more, I can find the really bad cases...
[23:28:26] <skunkworks> wow - that is crappy
[23:28:57] <cradek> yeah, with low accel we can have really bad blends right now.
[23:30:31] <jepler> cradek: that looks like what I got with "etch" on emc1
[23:30:45] <jepler> well, maybe..
[23:31:28] <cradek> I have a fix in mind for simple_tp - SMOP
[23:31:41] <cradek> simple_tp is close to blending...
[23:33:36] <skunkworks> great work
[23:44:51] <skunkworks> so the tp is not real time right now correct? It assumes it can read in the next bunch of lines before they are actually cut to figure out the path?
[23:45:53] <skunkworks> read enough lines ahead to keep ahead of the motion
[23:46:49] <cradek> the tp is realtime code, but it depends on non-realtime code to keep its incoming queue full.
[23:46:59] <skunkworks> ah
[23:47:26] <skunkworks> there was talk of que starvation - do you think that has actually happened?
[23:47:45] <Jymmm> Jymmm is now known as Red70sShow
[23:47:45] <Red70sShow> Red70sShow is now known as Jymmm
[23:48:03] <cradek> it's possible on a slow machine running a program with extremely short segments
[23:48:24] <skunkworks> ok
[23:48:38] <cradek> simple_tp actually stops the machine if the queue empties. I don't know whether that's a feature.
[23:49:13] <skunkworks> ;) microsofts favorite saying - "feature by design"
[23:50:43] <cradek> well it seems there are two bad things you can do: 1) abort 2) keep going, with intermittent stops, while the segments dribble in
[23:50:56] <cradek> I think the old planner does #2, I chose #1
[23:51:53] <skunkworks> would you pop up an error then?
[23:52:59] <cradek> could, but it doesn't currently (I think it would just stop and put a message in syslog)
[23:53:23] <cradek> friendly and feature-complete both come in phase II
[23:54:42] <skunkworks> hmmm. I like #2 but I am not the one that can do the programing. (if there isn't enough in the q then it goes into exact stop mode until the point that there is enough to start blending again.)
[23:55:09] <skunkworks> but I would rather have a tp that works ;)
[23:55:15] <cradek> yeah we would have to argue that out I guess
[23:55:28] <cradek> I think I'm in favor of a full abort with spindle off
[23:55:48] <cradek> because a lot of materials/tools can be ruined when the tool stops for no apparent reason; I think it's an error condition.
[23:56:05] <skunkworks> and an error - "upgrade your hardware."
[23:56:10] <cradek> it's definitely a "choose your poison" situation
[23:56:23] <cradek> or, fix the gcode. could be either problem.
[23:56:26] <skunkworks> I didn't think of that - good idea
