Back
[00:00:30] <les> What evolutionary mechanism causes you to lose stomach contents because of forces?
[00:00:37] <les> I don't get it
[00:00:55] <les> what measure does that response serve?
[00:00:57] <Jymmm> http://cgi.ebay.com/3-Electro-Craft-Nema-42-Servo-Motor-CNC-E722-Brush-34_W0QQitemZ7533400611QQcategoryZ78195QQrdZ1QQcmdZViewItem
[00:02:29] <LawrenceG> nice motors
[00:02:41] <les> ok deal jymmm but bigger than you need
[00:04:03] <les> 1475 would send your gantry flying off at about 5 g
[00:04:16] <les> big inertia mismatch
[00:04:35] <Jymmm> Couldn't I turn them down, so to speak?
[00:04:42] <les> sure.
[00:04:56] <les> can't turn down the price though!
[00:05:45] <Jymmm> though I dont know if my machien could handle nema42
[00:06:07] <les> ebay price NOS motors/encoders for yor machine ought to be about $300
[00:06:21] <Jymmm> what tourque?
[00:06:46] <les> just a guess...100 in oz cont 500 peak
[00:07:03] <Jymmm> hmmmm
[00:07:30] <Jymmm> I now have 5TPI ballscrews on 2:1 gears and linear rails
[00:07:38] <les> I bought some that size from servo systems with 100 line encoders for $100 each
[00:08:04] <les> 100 line sorry
[00:08:08] <les> 1000
[00:08:15] <les> this keyboard is going
[00:09:15] <Jymmm> heh, my gf has a closet full of new kybds
[00:09:28] <anonimasu> works nicely now
[00:09:29] <anonimasu> :D
[00:09:51] <Jymmm> this kybd of mine is 12 yrs old
[00:10:02] <les> I do too. I am beta testing a friend's product. I have a case of them. Not doing very well.
[00:10:10] <Jymmm> lol
[00:10:37] <les> keys are sticking and opening after a couple months.
[00:11:20] <les> He needs to pick another chinese factory.
[00:13:01] <Jymmm> no doubt
[00:14:43] <Jacky^> night
[00:15:25] <Jymmm> nite Jacky^
[00:16:15] <les> dinner time for me...
[00:16:41] <Jymmm> pit roasted beef les ?
[00:16:42] <anonimasu> enjoy
[00:17:02] <Jymmm> les gotta break in that new tractor properly... with a side of beef!
[00:17:42] <les> haha
[00:17:46] <les> later
[00:19:07] <anonimasu> *yawns*
[00:19:09] <anonimasu> bloody tp.�#!"
[00:30:58] <SWPadnos> SWPadnos is now known as SWP_Away
[00:47:53] <robin_sz> oops,
[00:48:08] <robin_sz> I seem to have stirred jmk on the geckodrive list
[00:58:23] <Jymmm> what did you do this time?
[00:59:03] <robin_sz> oh .. nuffin ;)
[00:59:14] <Jymmm> you're horns are showing robin_sz
[01:26:04] <les> incredible misty mountain sunset here
[01:26:52] <les> you know this is damn nice country....if only the girls had teeth.
[01:27:18] <les> uh...I could use a few meself
[01:27:34] <les> girls or teeth? both.
[01:41:21] <Jymmm> lol
[01:41:47] <Jymmm> les maybe you shoudl do some volunteer work at the women's free clinic!
[01:42:04] <les> aw they are all fat and old.
[01:42:44] <Jymmm> ok, then the ob/gyn clinic... at least you know they're fertal and willing =)
[01:42:53] <les> I am in serious sticks here...and I am from the big city...chicago.
[01:43:15] <les> it is a little too quiet for a saturday night
[01:43:36] <Jymmm> no moonshire's daughters around huh?
[01:43:36] <les> pop. density here: 10 per square mile.
[01:43:45] <Jymmm> moonshiners
[01:43:58] <les> I already married one....that was enough
[01:44:09] <Jymmm> you dont have to marry her
[01:44:22] <Jymmm> say it with me.... " I Don't"
[01:45:12] <les> they are barefoot...and want to be pregnant. Tjey look good too. Easy to get talked intop things you really don't wanna do.
[01:45:36] <les> this keyboard is just about gone
[01:45:42] <Jymmm> uh oh, I think my dvd drive is dieing on me
[01:45:52] <les> oh no!
[01:46:19] <Jymmm> it's a couple years old,
[01:46:54] <Jymmm> I'm REALLY putting it thru it's paces too
[01:47:20] <Jymmm> copying over 800K SMALL files to hdd
[01:47:31] <les> hmmm
[01:47:55] <les> hard drives are so big now...
[01:48:09] <Jymmm> one day two of gawd only knows how many to go
[01:48:19] <les> could put entire cd music collection on one
[01:48:42] <Jymmm> I need to buy a 200 to 400 GB hdd too, so I can edit some video I have
[01:48:58] <les> I am running 240G of raid drives
[01:49:46] <Jymmm> I'm going to buy an ext USB case so I can move it anywhere.
[01:50:04] <Jymmm> I was/am considering a NAS box, but I need the USB (or FW) too
[01:51:18] <Jymmm> you should see how slow it is to just browse these files.... would take you a few hours.
[01:51:33] <Jymmm> movign to hdd will dramaticaaly improve that.
[01:52:46] <Jymmm> Just to dump raw footage to the computer takes up about 40GB
[01:52:53] <Jymmm> of video that is
[01:53:04] <Jymmm> on one freaking tape too!
[02:02:31] <les> I am running closed loop steppers with usb
[02:02:50] <les> for a test rig
[02:04:42] <les> slow though
[02:08:07] <Jymmm> you running the encoders back to the controller?
[02:08:17] <les> yup
[02:08:33] <Jymmm> USB? MAriss' new doohickey?
[02:08:33] <les> in this case I wrote the controller
[02:08:45] <les> no this is mine
[02:08:46] <Jymmm> ah, very cool.
[02:08:58] <les> well for a corporation
[02:09:00] <Jymmm> what drives?
[02:09:05] <les> contract dtuff
[02:09:19] <les> allegro
[02:09:26] <Jymmm> ah
[02:09:50] <Jymmm> slow huh, what voltage are you driving them at?
[02:10:00] <les> I used an allegro chip and a step multiplier of my own design
[02:10:06] <les> about 30v
[02:10:23] <Jymmm> oh, I think that's the same one that Xylotex board use.
[02:10:24] <les> slow because of usb
[02:11:17] <les> usb would be no good for cnc...packet rate way too slow
[02:11:29] <les> data rate is ok
[02:11:44] <Jymmm> it's usually the USB polling to be an issue I've found.
[02:12:22] <les> it was enough for this stuff...needed to work from a laptop
[02:12:28] <Jymmm> For raw data collection, my GPS hates USB, but loves serial.
[02:12:52] <Jymmm> There are PCMCIA I/O cards
[02:12:56] <les> I use GPS in aircraft
[02:13:06] <les> has come in pretty handy
[02:13:39] <Jymmm> I use my GPS for photography and my radio.
[02:13:55] <les> I had a bad oil leak once...you know...all over the windshield
[02:14:19] <Jymmm> http://web.usna.navy.mil/~bruninga/aprs.html
[02:14:20] <les> punched nearest airport in gps and it gave me vectors
[02:14:37] <les> was able to land quickly and fix it
[02:14:44] <Jymmm> cool =)
[02:15:21] <Jymmm> this is my radio -->
http://www.universal-radio.com/catalog/fm_txvrs/4116.html
[02:15:24] <les> was just a leaky magneto seal
[02:15:51] <les> cool
[02:19:52] <Jymmm> Then when I take a roadtrip, I just give my friends this url and they can see where I'm at -->
http://findu.com/
[02:23:19] <les> neat
[02:24:05] <Jymmm> Very slick, plus my HT has APRS as well, so I could go hicking and ppl see me
[02:24:35] <les> explain hicking haha
[02:25:01] <Jymmm> lol ok.... Step 1. Get toothless female....
[02:25:06] <Jymmm> hiking =)
[02:25:32] <les> oh...you can do that real good here
[02:25:39] <Jymmm> I bet =)
[02:26:01] <les> the hillbilly girls really like Paul and his Brit accent
[02:26:30] <Jymmm> whats the age limit of these hillbilly gals?
[02:26:38] <les> 13.
[02:26:39] <Jymmm> s/limit/range/
[02:26:43] <Jymmm> nah, really?
[02:26:50] <les> haha
[02:27:05] <Jymmm> I wouldn't be surprised I guess, I've heard worse
[02:27:11] <les> by twenty they are all old and pruned out
[02:27:28] <les> aw not all
[02:27:40] <Jymmm> just most of em, huh?
[02:27:59] <les> that moonshiner's daughter was 28
[02:28:10] <les> I was fifty
[02:28:12] <Jymmm> but acted 40 huh?
[02:28:16] <Jymmm> her, not you
[02:28:31] <les> I was draggin' my feet bad I have to tell you
[02:28:38] <Jymmm> (physical) age is just an attitude
[02:28:43] <Jymmm> lol
[02:28:55] <les> oh no it isn't hahaha
[02:29:12] <Jymmm> you must not have the proper drugs then =)
[02:29:22] <Jymmm> go visit a mexico pharmacy =)
[02:29:26] <les> Thought I was gonna fall over from exaustion
[02:30:50] <les> you know you are getting old when you have to take a break and rest a while
[02:31:14] <les> don't need pills though tyvm
[02:31:21] <les> not yet
[02:32:49] <les> I was trying to climb a tree to top it before Icut it down today
[02:33:06] <les> physical age is not just an attitude!
[02:35:58] <les> hey I went to town and picked up a teeny bottle of somethig called "cuervo gold"
[02:36:15] <les> what is it for? what should I do with it?
[02:43:18] <Jymmm> lime and salt
[02:43:36] <les> heh
[02:43:59] <Jymmm> I have a bottle JUST above my monitor
[02:44:03] <RonB> ruins good tequila... help Cuervo
[02:45:46] <les> does the eletron flux from the monitor disrupt the tequila?
[02:46:08] <les> the um...tequila molecule?
[02:46:17] <Jymmm> Well it's evamproted a bit, but that's about it
[02:46:57] <les> evamporatred? hey your keyboard is bad too?
[02:48:09] <les> actually I like that. I noe pronounce "evamproted" an offiicial word.
[02:48:15] <les> now
[02:48:17] <les> hahaha
[02:51:30] <les> I wanted to plea not guilty but the judge evamproted my request.
[02:51:37] <les> yeah I like that
[02:59:25] <Jymmm> lol
[02:59:29] <les> so shall it be written, so shall it be done.
[02:59:37] <Jymmm> Nah, that's my fingers, not the kybd
[02:59:55] <les> haha
[03:00:12] <Jymmm> hey, how much flat land you have for your goldcourse?
[03:00:15] <Jymmm> golf
[03:00:59] <les> well have to go cook...perogies (sp?) good polish food.
[03:01:09] <les> the land/
[03:01:24] <les> about a mile in one direction
[03:01:28] <Jymmm> Maybe you can put in a mini clubhouse and have parties on the weekends... then invite all the ladies
[03:02:03] <les> remember...10 people per square mile...
[03:02:33] <Jymmm> That's ok, I suspect that ppl will travel distances for entertainment
[03:02:47] <les> could be
[03:02:54] <Jymmm> are you zoned for it?
[03:03:14] <les> no. I am zoned agricultural
[03:03:25] <les> (no tax)
[03:03:34] <Jymmm> can you get a temp permit?
[03:03:43] <Jymmm> (whatever it's called)
[03:03:47] <les> what permit?
[03:03:54] <les> this is the sticks
[03:04:02] <les> no permits
[03:04:08] <les> no inspectors
[03:04:09] <Jymmm> zoning greviance
[03:04:17] <Jymmm> zoning (something)
[03:04:20] <les> you can do whatever you want
[03:04:38] <Jymmm> Well hell, put up an club house!
[03:04:46] <les> yeah
[03:04:46] <Jymmm> have bands on the weekends
[03:04:57] <Jymmm> charge admision
[03:05:09] <les> in chicago you needed to have a permit for a dog house
[03:05:21] <Jymmm> really?
[03:05:32] <les> but here..really...you can just do what you want
[03:06:10] <Jymmm> there ya go... put up a tent, string some lights, a small stage and your set!
[03:06:18] <les> My machine shop was built with no permits or inspection whatever
[03:06:46] <les> I made it to code though
[03:06:56] <les> I'm an engineer.
[03:06:58] <Jymmm> yeah, electrical fires are bad things
[03:07:51] <les> oops have to take out the perogies! yum
[03:07:57] <Jymmm> c ya
[03:07:57] <les> later!
[04:48:50] <Jymmm> boo!
[08:57:25] <anonimasu> morning
[09:00:39] <anonimasu> hm
[09:00:56] <anonimasu> the hsm speed range is from 1200m/min for aluminium
[09:00:57] <anonimasu> :)
[09:05:09] <A-L-P-H-A> hsm?
[09:05:13] <A-L-P-H-A> oh
[09:05:16] <A-L-P-H-A> highspeed milling
[09:06:17] <anonimasu> machining
[09:20:05] <A-L-P-H-A> :)
[09:20:06] <A-L-P-H-A> yeah.
[09:41:13] <fenn> 1200m/min - that's bullshit
[09:42:13] <fenn> and if it isn't i wanna see how they did it
[09:45:32] <fenn> oh, that's surface speed, nevermind
[09:53:05] <anonimasu> fenn: it's from my machinery handbook so it's not bullshit ;)
[09:55:05] <fenn> anon i thought you meant feedrate
[09:55:20] <anonimasu> * anonimasu nods
[09:55:23] <anonimasu> although this is strange
[09:55:42] <anonimasu> at 0.05 per tooth
[09:55:53] <anonimasu> and 20krpm
[09:56:10] <anonimasu> it ends up at 3m/min in real cutting speed..
[09:56:20] <fenn> that's why it's called high speed :)
[09:56:24] <anonimasu> 3m/min?
[09:56:24] <anonimasu> heh
[09:56:32] <anonimasu> that's not extremely fast..
[09:56:52] <fenn> oh i guess not
[09:57:05] <anonimasu> I think les machine would do 16m/min ;)
[09:57:23] <anonimasu> but well it puts hsm in the right ballpark if you have enough spindle..
[09:57:33] <anonimasu> and a control that will work at thoose speeds..
[09:58:22] <fenn> still, it's fast for a milling machine
[09:58:35] <anonimasu> yeah 16m/min is fast..
[09:58:40] <anonimasu> but 3m/min isnt :)
[09:58:54] <anonimasu> most commercial machines run way faster
[09:58:58] <fenn> guess i'm ig'nant
[09:59:19] <anonimasu> or well the cheaper machines will run at 10m/min..
[09:59:51] <fenn> manufacturers dont tend to advertise how fast their machines actually cut
[10:00:02] <fenn> one of my pet peeves
[10:00:38] <fenn> you'd think some time in the last 100 years or so they'd have come up with a way of rating machining performance
[10:00:45] <anonimasu> yeah..
[10:25:58] <anonimasu> * anonimasu yawns
[10:26:13] <anonimasu> shower time, then I need to head to work to saw this workpiece up
[10:26:15] <anonimasu> a bit..
[10:26:43] <anonimasu> hello alex
[10:26:50] <alex_joni> morning
[10:27:07] <alex_joni> wot's up?
[10:27:20] <anonimasu> not much
[10:27:28] <alex_joni> nice
[10:27:33] <anonimasu> going to go to work and saw the piece for my toolchange
[10:27:34] <anonimasu> r
[10:34:05] <alex_joni> any news on tp?
[10:35:09] <anonimasu> no
[10:35:19] <anonimasu> I'll print the papers out when I go to work
[10:35:22] <anonimasu> in a bit
[10:37:03] <alex_joni> nice
[10:45:03] <anonimasu> did you see the paper pasted here yesterday
[10:45:31] <anonimasu> http://batman.mech.ubc.ca/~ial/publication/theses/sonja.pdf
[10:51:21] <alex_joni> I've read the sonja paper a while ag
[10:51:25] <alex_joni> ago
[10:51:34] <anonimasu> nice isnt it=
[10:51:35] <alex_joni> even printed it out a few months ago
[10:51:41] <alex_joni> yeah.. up to a point
[10:52:06] <anonimasu> ?
[11:02:50] <alex_joni> later
[12:08:50] <alex_joni> * alex_joni is back
[12:09:13] <alex_joni> uname -a : Linux centrino 2.6.12.3-magma #1 Thu Jul 21 14:01:03 BST 2005 i686 GNU/Linux
[12:09:20] <alex_joni> and emc2 works ok ;)
[12:09:42] <alex_joni> anonimasu: still around?
[12:35:23] <robin_sz> meep?
[12:35:30] <alex_joni> indeed
[12:35:55] <robin_sz> how the tp today?
[12:35:55] <alex_joni> wot's up?
[12:35:58] <robin_sz> fixed yet?
[12:36:04] <alex_joni> dunno.. ask someone that knows ;)
[12:36:48] <alex_joni> still buggy I think ;)
[12:37:24] <robin_sz> I've been playing with the G200X again ... first time in months
[12:37:32] <robin_sz> forgotten most of what I knew about it
[12:38:11] <alex_joni> heh
[12:38:20] <alex_joni> that seems to be a common thing ;)
[12:39:01] <robin_sz> I have a nice job in that would really benefit from robot tig
[12:39:19] <alex_joni> hmm.. I'm not that found of tig ;)
[12:39:21] <alex_joni> too slow for me
[12:39:26] <alex_joni> but on certain stuff it's ok
[12:39:32] <alex_joni> how's your setup?
[12:39:40] <robin_sz> this is high quality stainless for aerospace
[12:39:48] <alex_joni> right
[12:39:57] <alex_joni> TIG with cold wire?
[12:40:03] <robin_sz> yeah
[12:40:08] <robin_sz> I suspect thats the way
[12:40:09] <alex_joni> pretty ok
[12:40:15] <alex_joni> what gaps do you have to weld
[12:40:19] <robin_sz> will need very little filler
[12:40:23] <robin_sz> oh, tiny
[12:40:26] <robin_sz> 1.6sheet
[12:40:35] <alex_joni> and distance between sheets?
[12:40:37] <robin_sz> corner butt with half overlap
[12:40:44] <alex_joni> ahhh.. overlap ;)
[12:40:48] <alex_joni> that sounds ok :P
[12:41:02] <alex_joni> then you probably can make without filler
[12:41:03] <robin_sz> should be able to just melt the corner in
[12:41:06] <alex_joni> right
[12:41:16] <alex_joni> but you need good accuracy
[12:41:19] <robin_sz> or laser weld it ;)
[12:41:21] <alex_joni> the robot does that
[12:41:33] <alex_joni> still gotta make sure the preparation of the sheets is ok
[12:41:38] <robin_sz> yeah
[12:41:41] <alex_joni> 1.6 mm sheet?
[12:41:53] <alex_joni> or 1.6" ?
[12:42:21] <dpy> hi
[12:42:27] <alex_joni> hello dan_falck
[12:42:30] <alex_joni> hello dpy
[12:42:35] <alex_joni> darn autocompletion ;)
[12:42:58] <dpy> what would be the absolute cheapest way to drive 3 stepper motors (unipolar) safely ?
[12:43:09] <alex_joni> depends on the size
[12:43:26] <alex_joni> how much current?
[12:43:30] <dpy> they are in expensive hobby motors 0,35-0,7 Nm
[12:43:49] <alex_joni> probably a L297/L298 combo drive would be ok
[12:43:49] <dpy> I don't know, I think 1A max
[12:44:00] <alex_joni> you can build that on your own
[12:44:06] <alex_joni> lots of schematics out there
[12:44:11] <dpy> yes, but I've looked and these kost 24 EUR per motor
[12:44:18] <dpy> in total parts
[12:44:25] <alex_joni> nah.. lots less
[12:44:38] <alex_joni> or L293D and drive it directly from emc
[12:44:44] <dpy> I've read L297 costs 9 euro orso
[12:44:52] <alex_joni> unipolar is 2 wires?
[12:44:59] <robin_sz> alex_joni1.6mm
[12:45:06] <dpy> well I'd rather not connect the parallel port directly
[12:45:10] <alex_joni> robin_sz: then heat will be an issue
[12:45:14] <dpy> maybe I blow it up if something goes wrong
[12:45:27] <alex_joni> dpy: not directly, through a L293D (that's just a power amplifier)
[12:45:27] <robin_sz> alex_joni I have pulsing on the tig
[12:45:36] <dpy> unipolar = 5,6,8 wires
[12:45:40] <dpy> 4 = bipolar
[12:45:44] <alex_joni> right
[12:45:58] <alex_joni> then you don't have space on the parport for 3 motors
[12:46:20] <alex_joni> gotta do step/dir to fit 3 on the parport
[12:46:21] <dpy> sure I have
[12:46:24] <dpy> dir/stip
[12:46:37] <alex_joni> yeah but that means that the driver will have some logic in it
[12:46:39] <dpy> well technically you can have 12 outs on a parallel port
[12:46:42] <alex_joni> -> nto cheap ;)
[12:46:56] <alex_joni> not
[12:47:31] <robin_sz> dpy: really, you want modern bipolar drivem and microstepping ... it make the older systems look really old and slow
[12:47:48] <alex_joni> but 20-25 EUR/drive is OK
[12:48:10] <dpy> robin_sz: I want old and slow to begin with
[12:48:16] <robin_sz> L297/L298 is sort of OK then
[12:48:26] <robin_sz> or the Xylotoex thing .. 3 drives on a card
[12:48:55] <robin_sz> if you have money to burn, you could always build your own
[12:48:57] <dpy> I want 20-30 euro 3axis driving (total cost) and I don't give a damn if it's old and cranky and slow
[12:49:03] <dpy> as long as it works
[12:49:27] <dpy> http://engraving.majosoft.com/html/body_stepper_driver_board_with_uln2803.html
[12:49:32] <dpy> this looks very cheap
[12:49:51] <dpy> but It also looks as if the parport is directly connected
[12:49:57] <dpy> without any protection
[12:50:00] <robin_sz> yeah
[12:50:20] <robin_sz> I cant think how you can do it for $30 eur
[12:50:44] <dpy> pls look at that URL
[12:51:12] <dpy> will something like that do
[12:51:20] <dpy> without blowing up the parallel port
[12:51:26] <dpy> to start with, I mean
[12:51:27] <alex_joni> ULN2803 is kinda like an L293D
[12:51:29] <alex_joni> sure
[12:51:33] <alex_joni> it'll probably work
[12:51:41] <alex_joni> but.. I wouldn't do it ;)
[12:51:47] <dpy> why not ?
[12:52:14] <alex_joni> dunno.. would go with a L297/L298
[12:52:18] <alex_joni> I like how that works
[12:52:21] <alex_joni> with halfstepping
[12:53:00] <robin_sz> * robin_sz nods
[12:53:01] <dpy> does halfstepping give you more torque ?
[12:53:13] <alex_joni> better position
[12:53:14] <robin_sz> sigh .. cant figure out how to open URLs from Mirc
[12:53:19] <dpy> I have 3x L298 here
[12:53:23] <dpy> but no L297
[12:53:34] <alex_joni> robin_sz: I select them, then go to Firefox and paste-and-go
[12:53:35] <robin_sz> well, L297s are cheap enough
[12:54:09] <dpy> I don't know, it looks REALLY cheap to build a 15 euro 3axis thing, with a room for 3 limit switches
[12:54:14] <robin_sz> ah, auto coppy
[12:54:17] <dpy> and then if it works, I'll upgrade
[12:54:30] <robin_sz> ugh ... that design sucks
[12:54:37] <robin_sz> dont do it
[12:54:47] <dpy> okay, If I google I find lots of links for L297/L298
[12:54:54] <dpy> *which* one do you suggest then ?
[12:54:58] <alex_joni> L297 is about 6 EUR's here
[12:55:01] <dpy> I can't tell the difference
[12:55:07] <robin_sz> L297/298
[12:55:17] <dpy> I want to etch my own board etc..
[12:55:34] <robin_sz> get the application note for the L297/L298 ... the circuit is in there
[12:56:15] <robin_sz> that URL you posted wont work
[12:56:20] <robin_sz> no current limiting
[12:56:24] <robin_sz> forget it
[12:56:32] <dpy> ok
[12:57:14] <robin_sz> note you need 6 fast diodes in the L298 design ... worth getting good ones
[12:58:31] <robin_sz> it will work out more expensive than buying finished units though, but so long as you enjoy building stuff, thats OK
[12:58:41] <dpy> ok
[12:58:48] <dpy> the application note is NOT what I want
[12:59:10] <robin_sz> why not?
[12:59:21] <dpy> I want a site with PCB layout board, a schematic and 3 motor output, 3+ switches input
[12:59:31] <dpy> the application note is too much: do it yourself
[13:00:05] <dpy> for me, building the stepper driver is only a side project, it's not my main goal
[13:00:15] <dpy> so it has to be as easy as possible
[13:00:44] <robin_sz> ahh .. thats easy then
[13:00:50] <robin_sz> you want easy as possible?
[13:00:58] <dpy> and I need to have PCB design that works before I start on it, without buying a kit, so to speak
[13:01:19] <robin_sz> and you want reliable, proven design?
[13:01:29] <dpy> just a site with: etch this, put these components on it and it works, done
[13:01:40] <robin_sz> hmmm ...
[13:01:43] <dpy> robin_sz: right
[13:02:03] <robin_sz> so, your goal is to build a machine, not spend ages messing around with stepper drives right?
[13:02:53] <robin_sz> then buy a pre-built Xylotex card or some geckodrives
[13:03:39] <robin_sz> or spend hours searching the web for L297.L298 designs ... thats probably the easiest way
[13:04:45] <dpy> well, consider this
[13:05:01] <dpy> once I find this design and build the board
[13:05:12] <dpy> then I'll put the info on the web
[13:05:51] <dpy> and just state: if you want a no hassle cheap 3 axis out 3 switches in stepper driver: just etch this, put these components and it, hook it up to the PC and you are done
[13:06:08] <dpy> and I'm only hoping that someone has already done this, i.e. I'm not the first
[13:06:16] <robin_sz> mmmm
[13:06:24] <robin_sz> well, Im sure you are not the first
[13:06:29] <robin_sz> I did this myself
[13:06:34] <robin_sz> before I reallised the real answer
[13:07:07] <robin_sz> I wasted *lots* of money and even more time building stepper boards
[13:07:24] <robin_sz> then I bought geckos and got on with building the machines instead
[13:08:20] <robin_sz> http://www.xylotex.com/#3axis
[13:08:28] <robin_sz> thats good value, no hassle and works
[13:09:42] <robin_sz> lets say, with etching and all the rest your system costs you 100 eur (it wont be less)
[13:09:58] <robin_sz> just work $50 eur at your local shop stacking shelves
[13:10:05] <robin_sz> and buy the xylotex
[13:10:12] <robin_sz> same cost, half the time
[13:10:25] <robin_sz> and you have a better driver at the end?
[13:12:01] <alex_joni> or even geckos
[13:12:09] <alex_joni> even if they are a bit more expensive
[13:13:52] <alex_joni> I have bought some G340, and never looked back
[13:14:02] <alex_joni> before that I built my own DC drives
[13:15:33] <robin_sz> yeah
[13:15:45] <robin_sz> geckos are what I should have done in the first place ..
[13:16:02] <robin_sz> I remember I wasted weeks and weeks making my own drive .. I was stoopid
[13:16:18] <alex_joni> wasted a "few" MOS-FET's ;)
[13:16:27] <alex_joni> and IR2111 or smthg
[13:16:27] <robin_sz> no
[13:16:31] <robin_sz> not mosfets
[13:16:34] <alex_joni> I did
[13:16:39] <robin_sz> but lots of drivers
[13:16:51] <robin_sz> combined hi/low side drivers
[13:16:52] <alex_joni> I built mine from scratch
[13:16:56] <alex_joni> finally got it working
[13:17:11] <robin_sz> eyah
[13:17:16] <robin_sz> I got mine working
[13:17:23] <robin_sz> but it missed steps once in a while
[13:17:30] <robin_sz> and it wasnt microstepped
[13:17:32] <alex_joni> I got mine working ok
[13:17:38] <alex_joni> but it was DC
[13:17:44] <alex_joni> and PWM was a bit hicky
[13:29:32] <robin_sz> right, things to do ...
[13:35:13] <alex_joni_> same here
[13:35:16] <alex_joni_> laters
[13:55:57] <dpy> has anyone here ever built the hans wedemeyer drivers ?
[13:56:02] <dpy> stepper drivers ?
[14:05:23] <fenn> dpy check out pminmo.com if you haven't already
[14:08:31] <RonB> fenn - what a nice set of links... thanks
[14:15:44] <fenn> y'welcome
[14:15:52] <fenn> bedtime for me
[14:33:00] <anonimasu_> iab
[14:33:12] <anonimasu_> I am facemilling :)
[14:50:06] <anonimasu_> scary
[14:50:50] <RonB> check your mirroe for proper results
[14:50:59] <RonB> mirror
[14:52:41] <anonimasu_> it's not mirror finish..
[14:52:45] <anonimasu_> but it's flat enough..
[14:52:57] <anonimasu_> my facemill is way too bad :)
[14:53:07] <anonimasu_> I wonder if I should flycut the contact surface
[15:13:05] <dan_falck> hi steve
[15:13:28] <anonimasu_> * anonimasu_ just had a bad experience
[15:13:31] <steve_stallings> hi dan, quiet today, thought there would be more discussion of blending
[15:13:37] <anonimasu_> something screwed up
[15:13:43] <anonimasu_> during a g2 making all my axis:es run off.
[15:15:04] <dan_falck> I haven't seen Paul here in a long time
[15:15:37] <dan_falck> he sent me an email last week, so I know he's still alive
[15:16:05] <anonimasu_> he's noline but not here
[15:18:02] <steve_stallings> either he is tired of us, or he is off doing something intense
[15:18:18] <steve_stallings> hopefully the latter, maybe that NML restructure that was discussed
[15:23:22] <anonimasu_> might eb..
[15:27:48] <anonimasu_> is anyone here right now good with HAL?
[15:54:30] <steves_logging> morning John
[15:54:35] <jmkasunich> morning
[15:55:00] <anonimasu_> hello jmk
[15:55:08] <steves_logging> steves_logging is now known as steve_stallings2
[15:59:31] <dave-e> les...you there?
[16:02:38] <dave-e> anyone awake or am i just talking to myself?
[16:03:49] <dave-e> be back
[16:04:01] <jmkasunich> a few are awake ;-)
[16:08:12] <steve_stallings2> steve_stallings2 is now known as steve_stallings
[16:09:42] <les> I'm here
[16:10:02] <les> I was studying jon's data that he posted
[16:11:25] <les> emc is doing vector calcs in tp/tc I think...I see dot products and such
[16:12:13] <les> if two directed segments are colinear their dot product should be ONE
[16:12:51] <les> if also they are desired to be the same speed the blend time (se my paper) should be ZERO
[16:13:08] <jmkasunich> your paper?
[16:13:36] <steve_stallings> I missed the paper announcement, where is it?
[16:13:48] <les> yeah John I did write it
[16:14:14] <les> I was gonna clean it up a little first but may not have time
[16:14:20] <les> so, here it is:
[16:14:40] <les> http://www.lmwatts.com/traj/traptp.html
[16:15:05] <les> But let me finish this thought....
[16:15:17] <anonimasu_> hm
[16:15:20] <anonimasu_> brb, going inside now
[16:15:37] <anonimasu_> gotabout half done with the toolchanegr
[16:15:40] <anonimasu_> changer.. :)
[16:15:45] <les> I think dot or another dotproduct operator may be incorrectly ZERO not ONE in these blends
[16:16:00] <anonimasu_> just need to bore the hole for the shaft..
[16:16:31] <les> that would initiate a wrong blend.
[16:18:19] <dave-e> I'm back ... just posted to dev-list
[16:18:58] <anonimasu> iab
[16:19:41] <les> hi dave
[16:19:50] <dave-e> hi les
[16:20:04] <jmkasunich> les: gonna start looking at the tp in a bit
[16:20:21] <jmkasunich> got a couple questions about the paper
[16:20:31] <les> sure..
[16:20:40] <jmkasunich> I follow everything down to:
[16:20:48] <jmkasunich> cruisetime jk= tmjk - 1/2 tj - 1/2 tk
[16:20:55] <jmkasunich> what are tj and tk?
[16:21:11] <les> did I not define that?
[16:21:23] <jmkasunich> maybe I missed it
[16:21:32] <les> time at point Xj and Xk
[16:21:45] <jmkasunich> absolute time?
[16:21:46] <les> maybe I didn't define it!
[16:22:13] <jmkasunich> that would have been my guess based on the notation, but it didn't seem to make sense using that definition
[16:22:14] <les> elapsed time since the first part of the coordinated move sequence
[16:22:31] <jmkasunich> since Xi then (in the pic)
[16:22:43] <les> well the rotation is just a cylindrical coordinate form
[16:23:06] <jmkasunich> huh? where did rotation come from?
[16:23:06] <les> remember this happens with coliners straight joined segments as well
[16:23:24] <les> colinear
[16:23:52] <les> in fact I think this happens with ALL joined segments
[16:23:56] <jmkasunich> two lines ago you said something about rotation, sounds like a completely different conversation
[16:24:28] <jmkasunich> all I'm trying to do right now is read the paper
[16:24:31] <les> oh...sorry to confuse
[16:24:50] <les> circular motion would be a better term
[16:24:58] <les> anyway read on
[16:25:00] <jmkasunich> and I still don't get the cruisetime calculation
[16:25:27] <les> let me check...might have typo
[16:25:36] <jmkasunich> if tj and tk are times since the start of the sequence, then both are positive, and if the sequence is long, both can be large
[16:25:55] <jmkasunich> that would result in negative cruisetime
[16:26:23] <jmkasunich> actually, it would result in cruisetime verying with the length of the previous portion of the sequence, which can't be right
[16:27:17] <les> it's verbatem out of the book...but the book often has typos
[16:27:31] <les> I'll recalculate and check it out
[16:28:04] <dave-e> so far I cannot demostrate a glitch in line to line joining....tried about a 10 degree angle between segments
[16:28:37] <les> A sign is wrong in the book JMK
[16:28:42] <les> I think
[16:29:21] <les> dave, it has only been seen in colinear line segments
[16:29:33] <les> small angle effect is unknown
[16:29:34] <jmkasunich> seems like cruisetime = tmjk - ( start_blendtime + end_blendtime) / 2
[16:29:47] <dave-e> ok]
[16:29:55] <les> thats why I think a dot product is wrongly set to zero
[16:30:44] <les> that makes sense jmk but I will derive it here in a bit
[16:30:50] <jmkasunich> ok
[16:31:13] <dave-e> be back in a bit
[16:31:32] <les> note the blend time calc...
[16:31:53] <les> if the two segments are the same velocity blendtime=0
[16:32:03] <jmkasunich> yep
[16:33:13] <jmkasunich> the paper describes only the easy case where segments are long enough to do a complete accel/decel and then cruise
[16:33:20] <les> derived it..your cruisetime math is correct
[16:33:27] <les> typo in book
[16:33:34] <les> I will change the page
[16:33:44] <jmkasunich> if that is busted in EMC, we need to fix it asap.. but that doesn't address the more serious lookahead issue when cruisetime becomes negative
[16:33:47] <anonimasu> hm, if the time is < the time it takes to do a optimal decel..
[16:34:15] <anonimasu> then you divide the deceleration with the time.. to get a controlled ramp
[16:34:37] <les> I did not cover clamping issues in the paper
[16:34:59] <les> in general the blend accel is always the .ini max accel
[16:35:41] <les> although I can't say that emc does that for sure
[16:36:08] <anonimasu> btw, I printed the sonja paper.. so I'll have a look at it before I go to bed also..
[16:36:15] <les> k
[16:37:39] <les> In multi axis moves there is some merit to having the fastest axis only at max accel....and other blend accel proportional to a dot product
[16:37:42] <CIA-9> 03jmkasunich * 10emc2/src/libnml/Makefile.lib: fixed an annoying little error in make clean
[16:38:50] <les> however this glitch occurs when only one axis is moving...so that is not an issue.
[16:39:18] <jmkasunich> right - but its not just "some merit", the accels must be proportional
[16:39:51] <jmkasunich> imagine two collinear straight lines, at a slight angle to one cartesean axis
[16:40:00] <jmkasunich> first line has a high feed, second one a slow feed
[16:40:02] <les> ok
[16:40:31] <jmkasunich> one axis is barely moving, and barely needs to decel, the other one needs to decel a lot
[16:40:52] <jmkasunich> if both decel at their max rates, the slow one will finish it's decel first - net result, no longer a straight line
[16:40:58] <les> all right jmk..."a LOT of merit" ;)
[16:41:38] <jmkasunich> ;-)
[16:42:12] <anonimasu> Error in startup script: bad pad value "2m": must be positive screen distance
[16:42:12] <anonimasu> while executing
[16:42:15] <anonimasu> have anyone seen that before?
[16:42:30] <jmkasunich> nope
[16:42:33] <jmkasunich> where in the script?
[16:42:57] <anonimasu> pack .runmark.buttons -side bottom -fill x -pady 2m
[16:44:35] <jmkasunich> that doesn't look like bash, it looks like tcl
[16:44:36] <anonimasu> I'll replace it with a new tkemc.. ;)
[16:47:25] <anonimasu> hm didnt help
[16:51:39] <les> comment on Dave's email...
[16:52:43] <les> MAX_ACCELERATION setting and sub interpolation amount (trajectory priod/servo peroid) will prob affect this a lot.
[16:52:51] <les> period
[16:52:53] <les> geez
[16:53:23] <les> oh and the peculiar inflection at zero crossing...
[16:53:36] <dave-e> I'm sure Jon's accel is set low like 4 to 6 ... mine is at 20
[16:53:39] <les> sub interpolation I think. It's cubic.
[16:54:03] <anonimasu> http://jelinux.pico-systems.com/images/vel1inch.png
[16:54:07] <les> Paul reported a huge difference with accel value.
[16:54:11] <anonimasu> les: you have a problem.. you are running way too slow ;)
[16:54:14] <les> lower=worse
[16:54:36] <les> I am running at 30 usually
[16:54:56] <les> and unfortunately
[16:55:17] <anonimasu> les: I am just joking
[16:55:23] <les> I know
[16:55:25] <les> heh
[16:55:40] <CIA-9> 03jmkasunich * 10emc2/configs/core_sim.hal: added a .hal file that simply loops position command back to position feedback, for simulation purposes
[16:56:16] <les> I say unfortunately because my machine can easily do 200 in/sec^2
[16:56:57] <dave-e> a half g would be impresive1
[16:57:02] <dave-e> !
[16:57:24] <anonimasu> * anonimasu sighs
[16:57:29] <les> I did one machine that ran at 100g...but that's another story.
[16:57:34] <anonimasu> why the hell wont this work :/
[16:57:53] <les> The glitches and stutter in the emc tp forces me to go slow.
[16:58:43] <anonimasu> yep
[16:59:08] <anonimasu> *grabs a fresh emc*
[16:59:57] <jmkasunich> has anyone posted a sample G-code program that they're using for this TP stuff?
[17:00:08] <dave-e> Jon did
[17:00:14] <jmkasunich> thanks
[17:01:07] <dave-e> all I had to do was add g59.3 to get it on scale....also I mod if F value in the program rather than use the slider for feed
[17:01:17] <dave-e> mod the F value
[17:02:17] <dave-e> because of only skipping 1 in logging it is a pain to try and catch the transition
[17:04:42] <dave-e> les ... did you ever get around to putting up a psuedocode for tp?
[17:08:19] <les> yes dave...it has a typo on it though that I am changing now
[17:08:51] <les> http://www.lmwatts.com/traj/traptp.html
[17:09:04] <dave-e> tnx
[17:13:31] <dave-e> btw...jon's circle is pretty small. ...tried the same thing with a 4" circle and 40 ipm and the velo went almost to zero at at the transition!
[17:18:24] <jmkasunich> * jmkasunich can't remember G61 vds G64... which is blend and which is exact stop?
[17:18:37] <dave-e> 61 = stop
[17:18:47] <jmkasunich> thanks
[17:22:52] <dave-e> back in a while
[17:31:11] <les> was on the phone
[17:31:20] <les> g61 exact stop
[17:31:31] <les> g64 blend
[17:32:15] <les> We have been checking whether this thing is a 61/64 flag mis set
[17:32:22] <les> pretty sure it is not.
[17:32:47] <les> G61 works and looks a lot different from the nasy blip.
[17:32:58] <les> nasty
[17:34:19] <steve_stallings> not if the job is drilling holes at the right place 8-)
[17:35:08] <steve_stallings> oops, nasty was a spelling correction, not a comment about G61
[17:38:59] <les> hehyep
[17:39:34] <les> just fixed th error on the traj page...ftp uploading now
[17:40:47] <steve_stallings> What was the book you referenced earlier in TP discussion? Is it readable by a layman?
[17:42:23] <les> It is my old textbokk...Fred used it in school as well. It is (aws) for a first year mech engineering grad course
[17:42:38] <les> "Introduction to Robotics"
[17:43:25] <les> bit of math...jacobeans and such
[17:43:42] <les> inverse kinematics
[17:43:49] <les> trajectory planners
[17:43:50] <les> etc
[17:46:29] <steve_stallings> getting too many hits on that title, author?
[17:53:22] <les> Author is John J. Craig
[17:54:04] <les> oh the site is fixed
[17:54:19] <les> change in cruise calc
[17:55:09] <jmkasunich> hi paul
[17:55:24] <paul_c> anything happening ?
[17:55:35] <jmkasunich> distributed debugging
[17:56:03] <les> I wrote a little intro to trap planning site and put it up
[17:56:04] <paul_c> more HAL bugs ?
[17:56:10] <jmkasunich> no, TP stuff
[17:56:22] <jmkasunich> watta mean more hal bugs anyway ;-)
[17:57:50] <paul_c> do_gettimeofday()
[17:58:07] <les> Starting to look for a dotproduct clamped improperly to zero in tpp/tc
[17:58:14] <les> just a hunch
[17:59:47] <jmkasunich> what about do_gettimeofday()?
[18:00:10] <Imperator_> Hi
[18:00:16] <jmkasunich> hi martin
[18:00:21] <Imperator_> a lot of people onlone today !!
[18:00:25] <Imperator_> Hi John
[18:00:35] <Imperator_> online
[18:00:41] <jmkasunich> yeah
[18:00:56] <anonimasu> * anonimasu nods
[18:04:10] <anonimasu> Error in startup script: bad pad value "2m": must be positive screen distance
[18:04:13] <anonimasu> * anonimasu sighs
[18:04:22] <anonimasu> maybe it's time to restart my mill..
[18:17:50] <jmkasunich> damn he didn't stay long
[18:20:24] <steve_stallings> at least we know he is still alive 8-)
[18:26:40] <jmkasunich> ok, got a few results:
[18:26:48] <jmkasunich> doing two coliniar lines, same feedrate
[18:27:06] <jmkasunich> machine config is 1.2ips max vel (72ipm), 20 max accel
[18:27:22] <jmkasunich> at feeds of 10 and 60 ipm, no blip
[18:27:32] <jmkasunich> at 20, 30, 40, and 50 there is a blip
[18:27:57] <jmkasunich> prog is basically this:
[18:27:58] <jmkasunich> N0020 G01 X0.2 F60
[18:27:58] <jmkasunich> N0030 G01 X0.4 F60
[18:28:15] <les> hmm
[18:28:42] <jmkasunich> I'm using emc2, with halscope to look at the output
[18:28:55] <les> same tp and tc right?
[18:29:01] <les> must be
[18:29:06] <jmkasunich> added a couple stages of differentiator to the position command outputs to generate vel and acc signals to scope
[18:29:18] <jmkasunich> to the best of my knowledge, the tp and tc are the same
[18:29:19] <les> ok
[18:30:00] <jmkasunich> no it gets hairy.. I'm gonna try diving into tp.c and tc.c, and add some HAL signals so I can scope the internals
[18:30:10] <les> great
[18:30:28] <jmkasunich> I really wish scope had the ability to save and restore it's front panel settings
[18:30:41] <jmkasunich> every time I restart I have to do all that manually
[18:31:01] <jmkasunich> * jmkasunich adds a feature request for scope
[18:31:16] <les> I have to buy a physical scope still
[18:31:30] <les> Moving the electronics lab to another location
[18:31:36] <les> I need more romm in there
[18:31:45] <les> room
[18:35:13] <les> well we have looked at terminal condition flags and are beginning to suspect dot product clamping
[18:35:32] <les> Suspect strongly tcruncycle()
[18:35:56] <les> or tpruncycle()...forgot which
[18:36:57] <CIA-9> 03jmkasunich * 10emc2/configs/core_sim.hal: added differentiators to create velocity and acceleration signals when running simulations
[18:37:19] <les> also keep in mind that two colinear adjacent segments should have a blend region if the specified feeds are different
[18:37:35] <les> parabolic ramp to new speed in time
[18:37:37] <jmkasunich> right - I'll try that later, right now the feeds are the same
[18:37:42] <les> ok
[18:53:01] <jmkasunich> gawd that code is hard to read
[18:56:28] <les> haha isn't it?
[18:56:35] <les> even the rems
[18:57:15] <les> I am bringing up tc.c again here
[19:00:35] <jmkasunich> * jmkasunich begins "studying ode by adding printfs" (printk's actually)
[19:00:42] <jmkasunich> s/ode/code
[19:07:58] <les> perhaps something is flagging a deccel
[19:08:08] <les> That seems to trigger a blend
[19:23:28] <robin_sz> meep?
[19:23:35] <jmkasunich> les: do you have any idea what a "tc" actually is?
[19:23:37] <jmkasunich> peem
[19:23:57] <jmkasunich> actually, should be qeem
[19:28:23] <les> tc "trajectory calculations" seems to be a determinate based set of functions used by tp
[19:28:30] <les> and some queue stuff
[19:29:10] <les> lots of posemath stuff
[19:29:10] <Jacky^> hi
[19:29:25] <les> this is vector based...not in joint space I think
[19:29:32] <les> hi jacky
[19:29:42] <jmkasunich> right - all in cartesean space, converted to joints later
[19:29:44] <robin_sz> phew ... another busy week
[19:29:51] <les> yeah?
[19:29:55] <robin_sz> yeah
[19:30:18] <robin_sz> finally got enough energy to look at a small plasma system again
[19:30:24] <jmkasunich> there are two structs of interest, TC_STRUCT and TP_STRUCT
[19:30:30] <robin_sz> hence the sudden interest in the Gwhatever
[19:30:41] <jmkasunich> lol
[19:30:51] <jmkasunich> that's the most activity I've seen on that list ever
[19:30:55] <les> I am going to have to get to it this coming week on the acoustic stuff...a little behind from messing with this tp thing
[19:31:06] <robin_sz> yeah and its all your fault yer git ;)
[19:31:15] <Jacky^> a tool has been broken during a job :\ anyone know a good brand of cnc tools ?
[19:31:15] <les> haha
[19:31:22] <jmkasunich> what can I say... I do my part to keep things interesting
[19:31:36] <robin_sz> if I see one more sodding naming contest, it will be too soon
[19:31:44] <jmkasunich> yeah, that is way out of hand
[19:32:05] <robin_sz> *apart* from the naming contest, i found the rest of it entertaining
[19:32:20] <les> I hope this gets solved once and for all. I think it is related to the stuttering and incorrect velocity adapting we have seen for so long
[19:32:40] <jmkasunich> we can hope les, but don't count on it
[19:32:51] <les> oh I know better
[19:33:00] <robin_sz> any progress yet, or is it still a mystery?
[19:33:10] <jmkasunich> the stutter between two long collinear moves is one bug that we should be able to hunt down
[19:33:26] <jmkasunich> but probs with short moves that choke the comms are another issue
[19:33:26] <les> just getting good data together
[19:34:05] <les> I think it might be related but we will see (I hope)
[19:34:42] <les> to avoid comms choke it has to velocity adapt properly
[19:34:46] <robin_sz> I liked the 'vetting' idea in the Sonja paper
[19:34:47] <les> that does not happen
[19:35:08] <les> don't remember it
[19:35:09] <jmkasunich> ok, think I'm starting to get the structs
[19:35:29] <jmkasunich> there is one TP_STRUCT, corresponds to the planner as a whole
[19:35:34] <les> ok
[19:35:38] <robin_sz> les: based on working out if points were reduntdant base don thee "tightness" of the quintic
[19:35:54] <les> oh
[19:36:40] <jmkasunich> that TP_STRUCT contains a queue of TC_STRUCTs
[19:36:46] <staggerlytom> * staggerlytom sez hello paul
[19:37:15] <les> lots of stuff in each queue element huh
[19:37:28] <jmkasunich> now just need to understand what a TC_STRUCT is...
[19:38:04] <jmkasunich> it's either a line/arc, or maybe it's actually an section of a line or arc, like the accel, coast, or decel phases
[19:38:12] <paul_c> TC_STRUCT is a buffer of end points & velocities for the trajectory planner.
[19:38:38] <jmkasunich> one-to-one mapping with lines and arcs?
[19:40:11] <les> have to have a conditionaltime test for cruise or blend phase somewhere
[19:43:20] <les> tcflag has accel, constant, deccel, done values
[19:44:24] <les> tcflag set to DECEL must trigger a blend?
[19:44:36] <paul_c> it should
[19:45:11] <les> yeah.
[19:45:20] <les> looking
[19:45:30] <mshaver_away> mshaver_away is now known as mshaver
[19:45:37] <paul_c> but blending is also subject to the term_cond.
[19:45:52] <mshaver> well, I see you're talking about the problem
[19:46:04] <mshaver> i''ll read back aways
[19:46:08] <SWPadnos> accel or decel should triggera blend
[19:47:19] <steve_stallings> what about mode test G61/G64? does this happen in the same bunch of code?
[19:47:54] <paul_c> The scope shows the same (type of) trace for all three modes.
[19:50:59] <steve_stallings> just as things get interesting I have to run a errand, back in couple of hours
[19:51:15] <steve_stallings> steve_stallings is now known as steves_logging
[19:51:39] <jmkasunich> I did a test with two collinear moves, G61 and G64 show distinctly different velocity and accel curves (the difference on the position curve is nearly impossible to see)
[19:52:04] <robin_sz> greeting mshaver
[19:52:23] <jmkasunich> with G61, velocity goes near but not to zero
[19:52:39] <jmkasunich> I suspect cubic rounding prevents it from going all the way to a full stop.
[19:52:43] <les> I noted different behavior in g61 than 64
[19:52:55] <jmkasunich> with G64, there is only a small bobble in velocity between the two lines
[19:53:10] <les> made me thing it wasn't a trem condition flag misset
[19:53:33] <les> think
[19:58:27] <les> I THINK all blends are done at MAX_ACCELERATION in this
[19:58:37] <les> only the blend time changes
[20:02:07] <les> and if two dircted segments have a dot product of 1 AND are the same specified velocity
[20:02:23] <les> then and only then blend time should be 0.
[20:04:12] <les> I wonder if there would be a sudden or gradual appearance of the glitch if one progressed gradually to colinear from small angles
[20:04:36] <jmkasunich> dunno
[20:05:17] <jmkasunich> have you located the dot product call in the code that is used to make this decision, or are you just speculating on how it ought to work?
[20:09:13] <les> I am looking
[20:09:36] <les> and talking about how it should work
[20:09:46] <SWPadnos> are you looking at emc1, emc2, or BDI source?
[20:09:52] <les> found typo in rem in tc
[20:09:54] <SWPadnos> (BDI4, that is)
[20:09:56] <les> /* The combined acceleration of this move and the next one
[20:09:56] <les> will be square root(currentAcceleration^2 + nextAccel^2 + 2*the dot product).
[20:09:56] <les> to prevent the combined move from exceeding vMax preVMax may need adjustment.
[20:09:56] <les> tcRunCycle will subtract preVMax from vMax and clamp the acceleration to
[20:09:56] <les> this value.
[20:10:14] <jmkasunich> SWP: I'm looking in emc2
[20:10:24] <SWPadnos> heh - I figured that :)
[20:10:31] <SWPadnos> was wondering about Les
[20:10:38] <jmkasunich> there are minor differences between them, mostly some stuff that is commented out
[20:10:45] <jmkasunich> expect les in in 1
[20:10:50] <les> I don't think tp and tc have changed for a long time
[20:10:57] <les> I am looking at emc1
[20:11:02] <SWPadnos> not much, from the look of it
[20:11:07] <mshaver> HEY!
[20:11:08] <SWPadnos> thanks
[20:11:18] <SWPadnos> WHAT?
[20:11:21] <mshaver> I called Fred Proctor at home
[20:11:23] <jmkasunich> HEY yourself!
[20:11:35] <mshaver> He's going to get on here & straighten us all out
[20:11:37] <les> Tell us Fred's words of wisdom
[20:11:40] <mshaver> I hope...
[20:11:43] <SWPadnos> and he was working on EMC this fine Sunday Afternoon?
[20:11:46] <les> now?
[20:11:57] <mshaver> No, he was bike riding
[20:12:00] <alex_joni> greetings all
[20:12:02] <mshaver> Yes, now
[20:12:04] <SWPadnos> heh
[20:12:08] <les> cool
[20:12:20] <mshaver> We need his help
[20:12:22] <mshaver> I think
[20:12:36] <mshaver> He at least know where all this stuff is in the code
[20:12:44] <SWPadnos> that's a help :)
[20:13:36] <mshaver> He's going to try to get on with xchat or ksirc - he's not a regular irc user - i'm to call back in 5 mins or so - unless he shows up i guess
[20:13:54] <SWPadnos> people are mostly looking at tpRunCycle for the culprit, right?
[20:14:04] <les> I am
[20:14:06] <jmkasunich> that and things that it calls
[20:14:13] <jmkasunich> including tcRunCycle
[20:14:31] <SWPadnos> I was thinking that the tpAdd* functions may also be a place to look
[20:14:45] <SWPadnos> it's gotta be in the provider or the consumer to that motion queue
[20:14:51] <jmkasunich> that puts things on the queue... I think it is OK, the blending is done as they are removed
[20:14:56] <alex_joni> what's up guys?
[20:14:57] <les> I was search "dot" in tc and found either a very wrong rem or very wrong math
[20:14:59] <SWPadnos> GIGO
[20:15:12] <jmkasunich> I've printk'ed the adds and removes so I can see them happening
[20:15:14] <les> I think it is just the rem
[20:15:17] <paul_c> tpAdd[Line|Circle] just put moves on the queue
[20:15:59] <jmkasunich> the loop in tpRunCycle that starts with for (t = 0; t < tcqLen(&tp->queue); t++) { is interesting
[20:16:09] <jmkasunich> the for nominally loops over the entire queue
[20:16:31] <les> hey fred!
[20:16:34] <SWPadnos> woohoo - he made it!
[20:16:38] <jmkasunich> but inside the loop, they use break, so that it actually only loops over the elements that are being blended (I think)
[20:16:39] <proctor> Hi everyone. Matt just called and here I am.
[20:16:42] <SWPadnos> (not you, Jymmm :) )
[20:16:59] <jmkasunich> hi fred
[20:17:07] <Jymmm> SWPadnos who made what / when / where / why / how ?
[20:17:13] <proctor> So what's going on? Matt said you all had plotted vel v. t and saw blips during the blending.
[20:17:15] <jmkasunich> fred made it onto IRC
[20:17:21] <jmkasunich> yes
[20:17:27] <jmkasunich> for example
[20:17:28] <Jymmm> Ah.... a miracle!
[20:17:34] <jmkasunich> starting from 0,0,0
[20:17:40] <jmkasunich> G1 X0.2 F20
[20:17:45] <jmkasunich> G1 X0.4 F20
[20:17:53] <jmkasunich> with G64 on, that should be smooth
[20:18:01] <proctor> Agreed.
[20:18:08] <jmkasunich> but it actually does a small decel and accel at the transition
[20:18:16] <jmkasunich> doesn't go to zero like it does with G61
[20:18:24] <jmkasunich> but it is a non-trivial blip
[20:18:33] <les> half way or so?
[20:18:37] <proctor> When moves are blended, the next move begins its accel when the current move begins its decel.
[20:18:44] <les> right
[20:18:47] <jmkasunich> in more general terms, we're trying to understand tp.c and tc.c
[20:18:53] <proctor> Halfway down, to half speed?
[20:19:04] <jmkasunich> nope, not that bad
[20:19:04] <les> show fred a chart
[20:19:25] <jmkasunich> I don't have any handy, you have a URL for Jon's?
[20:19:31] <SWPadnos> http://jelinux.pico-systems.com/images/vel48.png
[20:19:44] <SWPadnos> http://jelinux.pico-systems.com/images/circleglitch.png
[20:19:49] <SWPadnos> http://jelinux.pico-systems.com/images/vel20.png
[20:19:54] <SWPadnos> http://jelinux.pico-systems.com/images/vel10.png
[20:19:59] <SWPadnos> http://jelinux.pico-systems.com/images/vel5.png
[20:20:09] <jmkasunich> that plot shows circles made up of concatenated arcs
[20:20:18] <SWPadnos> different speeds - the number is the feed rate in IPM (I think)
[20:20:23] <SWPadnos> true
[20:20:27] <proctor> OK, I see a big mountain at T=1.5 with what looks to be about a 25% drop at the top
[20:20:30] <les> happens with arcs and lines
[20:20:49] <SWPadnos> the depth varies with feedrate
[20:20:52] <jmkasunich> the waveform should be a sine wave, since we are drawing a circle and this is one axis
[20:20:53] <proctor> What is the trajectory cycle time for this?
[20:21:07] <les> That is two equal speed blended arc moves
[20:21:22] <SWPadnos> good question
[20:21:26] <jmkasunich> not sure, but the default is 0.010 seconds, I suspect that is what Jon is using
[20:21:33] <les> I think Jon has .01
[20:22:00] <proctor> Is the independent axis the time axis, in seconds?
[20:22:11] <jmkasunich> yes
[20:23:15] <proctor> It looks like it drops down to 75% at about 150 milliseconds, t=1.6 to t=1.75. That's 15 trajectory cycles.
[20:23:20] <SWPadnos> here's another picture:
http://jelinux.pico-systems.com/images/vel1inch.png
[20:23:42] <SWPadnos> that's for a larger circle - 1 inch versus 0.44 for the others
[20:24:12] <les> I think paul sees it at servo time = traj time
[20:24:14] <SWPadnos> oh - and the others all used the same program, but Jon varied the speed with feedrate override
[20:24:17] <les> correct paul?
[20:24:35] <paul_c> hum.. er wot ?
[20:24:58] <les> you see the blip at 1:1 servo/trajectory time?
[20:25:33] <alex_joni> les: afaik all emc2 runs at 1:1 servo/traj time
[20:25:39] <alex_joni> s/runs/run/
[20:25:42] <paul_c> you mean the discontinuity in velocity ?
[20:25:48] <les> yeah
[20:25:56] <jmkasunich> alex: that's what I thought too, but I'm not so sure now, need to check
[20:26:12] <mshaver> another graph from dave engvall:
http://users.erols.com/mshaver/circle.10.png
[20:26:19] <paul_c> Yes, it is there with a 1:1 servo:traj timing
[20:26:26] <les> ok.
[20:26:45] <proctor> If you're plotting the trajectory vel, this is done independently of the servo level, so I think the problem would exist regardless of the ratio.
[20:26:52] <SWPadnos> note in Jon's 5 IPM plot that there is one point that's above the expected curve
[20:26:55] <paul_c> low accel "enhances" the problem, as does velocity.
[20:27:03] <mshaver> another:
http://users.erols.com/mshaver/circle.40.png
[20:27:14] <dave-e> thanks matt
[20:27:18] <SWPadnos> and that the 1 inch circle has the entire error "outside" the expected profile
[20:27:26] <mshaver> another:
http://users.erols.com/mshaver/circle.160.png
[20:27:37] <mshaver> another:
http://users.erols.com/mshaver/circle.225.png
[20:27:48] <dave-e> matt ... try the 2" rad at 40 ipm
[20:28:05] <mshaver> another:
http://users.erols.com/mshaver/circle.r2f40.png (really a good one)
[20:28:16] <dave-e> accel = 20 on all these
[20:28:24] <les> hmm the slopes of the "v" aren't the same
[20:28:28] <mshaver> ^that one^
[20:28:29] <les> different accel
[20:28:53] <SWPadnos> they aren't in Jon's images erither
[20:29:05] <SWPadnos> they go down slowly, but get back on track faster
[20:29:12] <les> hmm
[20:29:37] <SWPadnos> in fact, the 48 IPM plot has a two-slope dip, and a single slope recovery
[20:29:48] <les> oh yeah I saw that
[20:30:13] <SWPadnos> I wonder if these were run with a real machine or using sim?
[20:30:17] <mshaver> you know, there's a source file, testtp.c in emc1/src/emcmot that makes a user interface to tp for testing...
[20:30:28] <mshaver> real machine
[20:30:29] <SWPadnos> *now* he tells us! :)
[20:30:36] <les> it happens on my real machine
[20:30:56] <robin_sz> ooof.
[20:30:57] <proctor> This may be due to the first move finishing sometime within the final time interval, say halfway through a 10 millisecond period, and the next move not initiating until the end. I think the next move initiates in the middle, but I'm not sure. That would be in tp.c, the code that does the blending.
[20:31:04] <robin_sz> circle.225 .. thats some circle
[20:31:23] <les> tpruncycle()?
[20:31:30] <dave-e> my machine is the Mazak V5 ... Jon's is a bench top running his pwm setup
[20:32:32] <jmkasunich> and mine is simulated... motion controller position commands wrapped around and used as feedback, no PID or motors
[20:32:40] <proctor> Yes, in tpRunCycle, each trajectory element in tc.c is run according to a trapezoidal vel v. time profile. When the move begins its decel, the next move is pulled in and planned.
[20:32:54] <mshaver> i don't know how testtp works - haven't compiled it yet - it seems like it can read input files of moves & output tp data as text
[20:33:24] <robin_sz> wow ... now, that would be usefu;
[20:33:49] <les> So Fred trajectory period caused aliasing?
[20:33:56] <proctor> I think what should happen is that if a move begins to decel halfway through a cycle, that is, if the corner of the trapezoid doesn't line up with an exact period but should happen halfway, the next move should be initiated and a piece planned for the remainder of the interval.
[20:34:45] <jmkasunich> fred: a background question:
[20:34:52] <proctor> I wouldn't call it aliasing. I would say that the continuous time nature of the trapezoid doesn't map onto the discrete time nature of the trajectory planning.
[20:34:58] <jmkasunich> right
[20:35:10] <les> ok
[20:35:20] <les> quantization error.
[20:35:28] <jmkasunich> tcGetPos(someTc) returns the position of that individual element, relative to it's beginning?
[20:36:01] <mshaver> dave-e: what fred said about the corner of the trapeziod lining up with the traj period boundary - that's the case where a blend is ok - if not, you can see premature decel (or in Jon's plts premature accel)
[20:36:36] <jmkasunich> gonna test that theory here... I'll just slightly lengthen the move and see if anything changes
[20:36:40] <Jymmm> O know nothing, but would that hold true for lines as well?
[20:36:45] <Jymmm> s/O/I/
[20:37:00] <jmkasunich> I'm seeing it with lines, and I think they are easier to understand
[20:37:07] <SWPadnos> yep - you have a line that takes 105 ms to complete, and the traj cycle is 10 ms - oops
[20:37:08] <robin_sz> presumably a quintic planner would solve this as it is asymptotic at the endpoints?
[20:37:26] <proctor> Sorry, I was just looking through the tp.c code and have to catch up...
[20:37:38] <jmkasunich> nope - still quantizes things
[20:37:42] <les> Isn't this a velocity adaptation issue?
[20:37:43] <SWPadnos> (don't worry - you're still ahead :) )
[20:38:02] <robin_sz> * robin_sz is stunned at the sudden progress in understanding
[20:38:20] <SWPadnos> is there a problem with the planner running whenever needed, rather than on a set schedule?
[20:38:25] <SWPadnos> (or both)
[20:38:28] <proctor> The way the EMC trajectory planner works is through a two-level process. The lower level, in tc.c, implements trapezoidal vel v. time profiling of a move.
[20:38:30] <jmkasunich> gets ugly fast
[20:38:36] <mshaver> * mshaver thinks many of our problems result from the continuous nature or reality failing to map into the discrete time intervals of computers :)
[20:38:54] <mshaver> s/or/of
[20:39:20] <LawrenceG> http://members.shaw.ca/cncstuff/glitch.png glitches with collinear moves.... code on lhs
[20:39:37] <proctor> The move begins by accelerating for some time interval given by calculations on D, V and A. Say this is 1.234 seconds.
[20:40:40] <proctor> Say the trajectory planner runs at 10-millisecond periods. At 1.230 seconds we are still accelerating, but at 1.234 we should be coasting. If we didn't look into this interval, at 1.230 seconds we would have begun coasting too late.
[20:41:33] <proctor> At 1.240 seconds we check to see if this happened, and compute a distance increment for that interval that is part accel and part coasting.
[20:42:02] <SWPadnos> and this takes the actual position into account?
[20:42:21] <proctor> The blending algorithm in tp.c looks at the status of each TC element to see which are accelerating, which are done, which are coasting, etc.
[20:43:02] <proctor> If one is just seen to be decelerating, that means that sometime in the previous interval it began to decelerate.
[20:43:33] <proctor> The next move should begin, but in fact it should have begun earlier, in the middle of the previous time interval.
[20:43:54] <proctor> If it didn't, you would see short overall motion deceleration until the next move began.
[20:44:36] <mshaver> how does this explain Jon's plot showing premature accel rather than decel?
[20:44:50] <proctor> This would be evident in the simple G code program earlier. That would be the easiest way to bring out the problem.
[20:45:20] <les> Could this trigger a long misblend? the glitch seems many many trajectory cycles
[20:45:21] <proctor> It would be most pronounced with larger acceleration values.
[20:45:57] <proctor> Is the many-cycle glitch seen in a simple program, with two long and collinear moves blended together?
[20:46:10] <les> yes
[20:46:30] <jmkasunich> I'm not seing that here
[20:46:59] <les> let me look at the time duration of the glitch
[20:47:14] <jmkasunich> at 20mS/div (10ms traj period) it slows down for about 20mS
[20:47:23] <proctor> I would expect a glitch when the first move began decelerating, then the speed picking up when the second one begins accelerating at the beginning of the next interval.
[20:47:38] <jmkasunich> (I'm looking at the output at the servo period, it suffers from rounding due to the cubic interp
[20:47:53] <proctor> OK John K, that would look consistent.
[20:49:02] <proctor> The test would be to have a G code program with two long collinear moves, and varying the acceleration to see if the duration of the glitch is constant, say a cycle or two but not more, but the glitch is more pronounced with larger accel values.
[20:49:13] <les> I see some of Jon's glitches at 0.2 sec duration. It seems the lower MAX_ACCELERATION is , the longer the glitch interval.
[20:49:28] <les> ach
[20:49:30] <jmkasunich> oops
[20:49:30] <SWPadnos> heh - oops - wrong button :)
[20:49:47] <Jacky^> O_O
[20:50:22] <jmkasunich> welcome back ;-)
[20:50:29] <proctor> Oops, disconnected somehow. IRC newbie.
[20:50:34] <SWPadnos> hiFred, nice of you to drop in :)
[20:51:07] <proctor> I was checking if I mispelled J. Kasunich's name as John, I think it's Jon. True?
[20:51:19] <jmkasunich> no, I'm John
[20:51:23] <jmkasunich> Jon is Jon Elson
[20:51:26] <Jacky^> hi from another newbie proctor :)
[20:51:43] <Jacky^> 2 newbie is better than one
[20:51:45] <proctor> OK. Must be my name, I am really Frehd but changed it in college.
[20:51:56] <Jymmm> Jacky^ : Yeah, proctor is a newbie alright =)
[20:51:59] <SWPadnos> Phredd
[20:52:01] <mshaver> Jon E provided the 1st set of graphs
[20:52:27] <proctor> Back to the problem, is this an accurate description of the symptom?
[20:52:36] <mshaver> John K is apparently looking at traj output using halscope
[20:52:38] <jmkasunich> we have more than one set of symptoms
[20:52:48] <proctor> That's an understatement.
[20:52:51] <jmkasunich> your description fits my output, but not Jon E's
[20:52:58] <jmkasunich> JonE's is arcs, mine is lines
[20:53:03] <les> Fred, the glitch duration gets wider with LOWER accel
[20:53:12] <SWPadnos> fred, would you still expect a glitch on collinear, same feedrate moves?
[20:53:12] <dave-e> sure does
[20:53:42] <proctor> If the moves are not blended properly, I would expect a glitch on same feedrate collinear moves.
[20:54:06] <SWPadnos> ok
[20:54:40] <dave-e> but only on collinear segments no on an angle?
[20:54:46] <dave-e> not on
[20:55:10] <mshaver> how about this graph fred?
http://jelinux.pico-systems.com/images/vel1inch.png
[20:55:13] <SWPadnos> collinear, same feedrate should be a no-brainer for the TP - if there are problems there, there are sure to be bigger problems elsewhere
[20:55:30] <SWPadnos> (unless it's a divide-by-zero problem)
[20:55:54] <proctor> The angle is immaterial. What the vel v. time plots are showing is the tangential velocity. I think some show XYZ vel v. time.
[20:56:16] <proctor> The problem would be evident there also. But I don't think it's a function of the angle between the moves.
[20:56:43] <proctor> If anyone is seeing a glitch on same speed collinear moves, that's clearly a problem.
[20:56:53] <les> Some glitches of Jon's are perhaps 20+ trajectory cycles in duration
[20:57:06] <les> confirmed it does it on colinear moves Fred
[20:57:15] <jmkasunich> http://home.att.net/~jmkasunich/scratch/CollinearA.png
[20:57:21] <jmkasunich> http://home.att.net/~jmkasunich/scratch/CollinearB.png
[20:57:26] <SWPadnos> les: same feedrate?
[20:57:28] <jmkasunich> both are collinear moves
[20:57:31] <proctor> I don't know what is causing the 20+ cycle glitches.
[20:57:33] <dave-e> I tried a 10 degree angle and thought i got a bump at low speeds I did not duplicate... at least so far.
[20:57:34] <jmkasunich> same feedrate (20 ipm)
[20:57:52] <jmkasunich> first one is a 0.201 move, second one is a 0.202 move
[20:58:11] <alex_joni> les: some nice thing to read:
http://robotics.jpl.nasa.gov/people/volpe/papers/icra93.pdf
[20:58:42] <jmkasunich> ie: G1 X0.201 ; G1 X0.4 for the first pic, then G1 X0.202 ; G1 X0.4 for the second pic
[20:59:07] <les> thanks will read alex...Picking Fred proctor's brain right now...he is on
[20:59:11] <jmkasunich> green trace is position (there is a rapid back to 0 at the end
[20:59:30] <jmkasunich> rectangular red trace is vel, near zero red trace with spikes is acc
[20:59:32] <alex_joni> les: I know, just wanted to give you the link
[21:00:00] <SWPadnos> John - can you try a 0.210 move at 60 IPM?
[21:00:27] <proctor> I'll have a read of the Volpe paper and see if it triggers anything.
[21:00:28] <jmkasunich> ok
[21:00:49] <SWPadnos> 60 IPM gives you 1 mil per servo cycle, and 10 mils per traj cycle - just easier to look at :)
[21:01:02] <staggerlytom> please identify the 3 traces
[21:01:16] <staggerlytom> oh, thanks
[21:01:20] <jmkasunich> green trace is position
[21:01:42] <jmkasunich> red trace that is more-or-less square is velocity
[21:02:00] <jmkasunich> red trace that remains around zero except for momentary excursions is accel
[21:02:25] <jmkasunich> SWP: at 60 ipm, no vlitch
[21:02:30] <jmkasunich> glitch
[21:02:36] <SWPadnos> how many pixels (samples) per division there John?
[21:02:44] <staggerlytom> thanks, John, typed b4 I read
[21:02:46] <SWPadnos> interesting
[21:03:09] <les> I am trying to imagine a short discrete time error triggering a relatively long misblend
[21:03:23] <jmkasunich> SWL 200mS/div
[21:03:29] <proctor> Yes, I am trying to imagine that too.
[21:03:31] <SWPadnos> OK
[21:03:35] <jmkasunich> sampling at the servo rate, 1KHz
[21:04:21] <proctor> For these long misblends, are we sure that only two long moves are in the queue?
[21:04:38] <les> I am not sure
[21:04:41] <SWPadnos> but it goes way out of whack, then eventually starts to come back rapidly - that's an odd pattern for a small quantization error
[21:05:06] <SWPadnos> (thinking of Jon's plots, not John's)
[21:05:07] <jmkasunich> SWP - I did another 60ipm move, of 0.205, and got a significant glitch
[21:05:12] <SWPadnos> ok
[21:05:25] <SWPadnos> the accel time would throw off the exact move length
[21:05:29] <proctor> If the acceleration is such that you can go from 0 to V in less than one trajectory cycle, you'll see a glitch down to 0.
[21:05:30] <paul_c> http://81.100.211.99/emc_plot.ps http://81.100.211.99/emc_plot2.ps
[21:06:01] <proctor> That is, if the code has this bug in it. It may be something else.
[21:06:32] <les> sounds almost like tcflag shoud be low pass digitally filtered (fir)
[21:06:46] <jmkasunich> can someone take the wide glitches and actualy determine the accel/decel rate for each segment?
[21:06:58] <jmkasunich> IOW, measure velocity and time at two points on the screen
[21:07:03] <les> it's just the slope...
[21:07:08] <jmkasunich> exactly
[21:07:23] <les> and it's asymmetric
[21:07:31] <proctor> You can run a filter on the trajectory output but that will introduce unacceptable blending, I think. Better is to fix the underlying problem.
[21:07:31] <jmkasunich> I can do that with confidence here, but not on the gplot ones
[21:07:39] <les> ok
[21:08:38] <les> I was thinking of multiple tests for a decel condition...in case discrete time errors makes one of them a false reading
[21:08:55] <proctor> Can anyone run a test where two long collinear moves are blended, and a vel v. time plot is taken, for various values of accel?
[21:09:06] <jmkasunich> I can do that
[21:09:18] <proctor> I don't have EMC on my home system so I can't do it.
[21:09:18] <SWPadnos> paul_c, what are those plots from (what kind of G-code)
[21:09:19] <jmkasunich> what accel values would you like
[21:09:43] <robin_sz> a LP filter on the tp output would introduce some jerk limiting would it not, which would be nice to have
[21:09:45] <jmkasunich> current ini is 1.2 ips (72ipm) max vel and 20 ips^2 accel
[21:09:55] <proctor> Say low, medium and high. Half your normal .ini value, the same, and twice.
[21:10:02] <proctor> OK, so 10, 20, 40.
[21:10:03] <jmkasunich> robin - the cubic spline already does a bit of that
[21:10:07] <proctor> Or 2, 20, 200.
[21:10:18] <jmkasunich> I'll do 2, 20, 200
[21:10:19] <robin_sz> jmkasunich: ah yes, thats in the mix as well, I forgot
[21:10:24] <paul_c> plot 1 is a simple circle, and plot 2 a short spiral.
[21:10:33] <proctor> The cubic spline works to interpolate the servo points. It won't appear in the tp/tc level.
[21:10:45] <robin_sz> * robin_sz nods
[21:10:53] <SWPadnos> what does the data represent? (position, velocity, etc)
[21:11:06] <jmkasunich> I'm scoping the output of the whole motion controller, just prior to where it would normally go to the PID loop
[21:11:10] <mshaver> plot1 is a great picture of the problem!
[21:11:12] <jmkasunich> so I see the cubic effects
[21:11:14] <alex_joni> proctor: what jmk said is that the cubic spline interp. does some jerk limiting by smoothing things out
[21:11:30] <proctor> That's true.
[21:11:35] <jmkasunich> the actual problem at the TP output is worse than seen in my plots
[21:11:37] <SWPadnos> interesting that it's on a motonic slope, not a direction reversal
[21:11:38] <paul_c> mshaver: Plot 1, accel @ 5, vel @ 200
[21:11:51] <jmkasunich> I was thinking about adding a couple HAL pins at the TP output, before the interp
[21:12:01] <robin_sz> jmkasunich: so you're scoping after the cubic spline?
[21:12:05] <jmkasunich> yes
[21:12:16] <les> I think the inflection at zero crossing on the arc charts is a cubic sub interpolation effect and normal
[21:12:17] <mshaver> paul_c: that's why you got such a good pic - pathological case...
[21:12:21] <proctor> Scope the commanded velocity.
[21:12:32] <robin_sz> jmkasunich: yet there is no spline applied to the "glitch" ... doenst that imply its in the spline algo ?
[21:12:55] <paul_c> proctor: They are commanded vel.
[21:12:56] <robin_sz> or shall I shut up?
[21:13:02] <paul_c> please
[21:13:09] <alex_joni> heh
[21:13:18] <jmkasunich> the pics so far aren't zoomed in enough to see the splining
[21:13:23] <les> This glitch is on a much more gross scale that the sub interpolation
[21:13:23] <robin_sz> 'k
[21:13:38] <SWPadnos> robin_sz, there are 200 points per division on that plot - it's har dto tell what's there
[21:13:40] <jmkasunich> 200mS/div is 20 traj periods or 200 servo periods / division
[21:13:44] <SWPadnos> (like John said :) )
[21:13:48] <jmkasunich> I will zoom in on the next set
[21:13:48] <robin_sz> right ...
[21:14:08] <robin_sz> I had misred just how big the glitch was ..
[21:15:17] <les> 0.2 seconds wide on one of Jon's....
[21:16:25] <jmkasunich> well, can't do a test at 2 ips^2 accel
[21:16:37] <jmkasunich> it doesn't reach steady state before it has to decel again
[21:16:45] <proctor> Do a longer move
[21:16:53] <jmkasunich> dun
[21:16:59] <jmkasunich> duh
[21:17:10] <Jymmm> * Jymmm hands jmkasunich a pot of coffee
[21:17:29] <les> I am starting to see a scenario where a discrete timing glitch triggers a very long false blend
[21:17:50] <mshaver> les: elaborate...
[21:18:37] <les> If a decel is flagged at any time (exept for scaling) it can initiate a blend
[21:18:41] <les> right?
[21:18:41] <Jacky^> anyone know a good store online where to buy cnc tools ?? (europe)
[21:18:52] <proctor> right.
[21:19:04] <les> even if it is a transient little spike due to sampling
[21:19:24] <proctor> No, I think it has to be a legitimate decel.
[21:19:40] <les> hmm
[21:20:06] <proctor> The transient little spike may be the decel of the first move appearing before the accel of the next one.
[21:20:14] <robin_sz> so .. to solve the quatization problem .. adjusting the slope slightly to ensure that it did always end on a discrete point, rather than trying to fudge it on the last slice would seem the way to go?
[21:21:13] <proctor> Except that with three axes, you get to a point where each ends at a different time, say by 1 microsecond, and then you'd have to run traj at 1 microsecond periods for that.
[21:21:40] <proctor> Or you mean the accel?
[21:21:59] <proctor> Reduce the accel so that a move ends on a boundary?
[21:22:04] <robin_sz> I exactly
[21:22:16] <proctor> You could do this with 3 axes no problem.
[21:22:18] <robin_sz> that would be the same time point for all 3 axes
[21:22:20] <proctor> I have to think about this.
[21:22:42] <robin_sz> thats what I meant by "adjust the slope" ...
[21:22:47] <mshaver> could you solve this for multiple axis moves though?
[21:22:50] <proctor> I think it would be easy enough to bring in the accel of the second move when you see a mid-period decel of the current one.
[21:23:16] <alex_joni> mshaver: it shouldn't matter for angular moves.. that should be pretty easy
[21:23:22] <proctor> Matt, yes, you would change the accel value for each move when it is queued up.
[21:23:29] <robin_sz> mshaver: I tink so .. they should all end at the same tim point
[21:23:37] <robin_sz> * robin_sz nods
[21:23:43] <proctor> Angular moves are just linear moves around a circle, as far at TC is concerned.
[21:23:47] <les> Well that brings up whether a velocity clamping event could cause this
[21:23:57] <les> or the lack of it
[21:24:33] <les> I think not, because it is observed a very low speeds
[21:24:43] <robin_sz> there .. I knew i would contribute a useful suggestion eventually .. sorry for all the crap ones in between :)
[21:24:49] <les> haha
[21:25:10] <alex_joni> we should run robin_sz through a parser
[21:25:11] <alex_joni> lol
[21:25:13] <SWPadnos> hmmm - thinking about more than one axis for a second, when should the "next move's acceleration" start when the delta Acc is differnet for the differnet axes?
[21:25:18] <mshaver> change the accel value = reduce the accel value until the move end coincides with the traj period
[21:25:21] <proctor> What could be done is for a trapezoid, given the distance, speed, accel and traj interval, the vel and accel could be adjusted so that the distance is honored (it must be) and the end time of the move is exactly on a time interval.
[21:25:39] <SWPadnos> the vel should also be honored, if possible
[21:25:52] <robin_sz> we would be talking only *tiny* amounts of adjustment
[21:25:58] <SWPadnos> (which it should be, since the accel can be changed)
[21:26:01] <proctor> The trouble is that for short moves, like in one of Les' contouring programs, each move would be slowed to last a trajectory interval.
[21:26:22] <les> Right...a velocity adaptation to honor Nyqist criteria?
[21:26:44] <mshaver> i was going to say that running traj fast is a good thing...
[21:26:49] <robin_sz> surely moves less than one traj interval could be summed to a single event?
[21:27:11] <paul_c> tose two plots I did were with traj=0.001 Sec
[21:27:18] <proctor> How about 100 small moves each lasting 0.93 of a trajectory cycle?
[21:27:50] <les> Well high traj /servo period ratio makes less cubic sub interpolation right?
[21:28:26] <mshaver> in that case 100 @ .93, you could stretch the moves out to 1.00 traj cycle time
[21:28:33] <les> We have to be 2:1 or more to make Nyquist
[21:28:46] <robin_sz> * robin_sz nods
[21:29:12] <alex_joni> mshaver: you'll have 7% loss of speed
[21:29:18] <mshaver> over the whole 100 moves you would only be .7 traj cycle times slow
[21:29:25] <SWPadnos> what about 100 @ 0.57? you'll have a pretty big speed problem then
[21:29:27] <mshaver> yep, what aj said
[21:29:50] <SWPadnos> or 1000 at 0.15 (since you always have to round up)
[21:30:01] <alex_joni> SWPadnos: 0.15 would be really dull
[21:30:01] <robin_sz> [email protected] is easy
[21:30:06] <mshaver> in the case of .57, slow each to .5, then combine them in twos
[21:30:08] <alex_joni> that's 0.15 of 10 msecs
[21:30:15] <alex_joni> a bit over 1 msec move
[21:30:20] <alex_joni> not very common
[21:30:20] <robin_sz> youd sum 7 of them to make a single traj cycle
[21:30:32] <jmkasunich> at some point as the moves get shorter you are gonna starve the comm channel anyway
[21:30:37] <robin_sz> push the spare one out into the nest cycle
[21:30:43] <robin_sz> yep
[21:31:04] <SWPadnos> how are short moves (mis)handled now?
[21:31:05] <proctor> You could adjust each motion so that it takes an integer multiple (e.g., 3 traj cycles) or an integer sub-multiple (e.g., 1/3 of a cycle).
[21:31:12] <dave-e> back later
[21:31:24] <robin_sz> whatever ... if you are going to fit continuous moves into discrete time ... something has got to give
[21:31:29] <mshaver> plus these short time moves can't be very long (distace wise) - yet analyzing what to do "on the fly" could be complicated
[21:31:36] <proctor> The trouble is that if you slow one to say 1/3 of a cycle, you have to have subsequent ones that are also 1/3 of a cycle.
[21:31:43] <SWPadnos> that would lookweird to an operator - "sorry, you can't have 10 IPM, but 10.23 is OK"
[21:31:57] <proctor> If you have one at 1/3, one at 1.5, one at 1/7, these are nicely combinable.
[21:32:16] <robin_sz> SWPadnos: its never going to be that .. its going to be that far
[21:32:19] <jmkasunich> http://home.att.net/~jmkasunich/scratch/Collinear200ipss.png
[21:32:19] <proctor> that's 1/5
[21:32:20] <anonimasu> hello
[21:32:21] <robin_sz> 10.0001
[21:32:27] <jmkasunich> that is the one with accel set to 200
[21:32:29] <SWPadnos> you can always just aggregate enough moves to get a single traj cycle
[21:32:34] <les> Yes Fred...But in theeory if you are below the Nyquist frequency the original signal can be exactly reconstructed even in between the samples...right?
[21:32:35] <robin_sz> exactly
[21:32:38] <jmkasunich> make the obvious change for 20 and 2
[21:32:40] <mshaver> if there was a short move in the middle of longer ones, what is wrong with slowing the short move vel to last 1 traj cycle?
[21:33:09] <proctor> JoHn K, is that plot consistent with a 1- or 2-cycle glitch?
[21:33:43] <jmkasunich> sorry, forgot to zoom them.
[21:33:52] <SWPadnos> heh - you were supposed to zoom *in* :)
[21:33:54] <jmkasunich> the last one (200) is still up and I can soom
[21:34:06] <robin_sz> there is an alternative ....
[21:34:19] <alex_joni> logger_aj, bookmark
[21:34:19] <alex_joni> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emc/2005-07-31#T21-34-19
[21:34:38] <robin_sz> basically, the tp cycles will be 1000 or so "normal" lenght ones and then a "filler"
[21:35:04] <proctor> The alternative is to anticipate this and begin the next accel a fraction of a traj cycle early.
[21:35:07] <robin_sz> cant we just set the rt event at just the right time for that one cycle?
[21:35:12] <proctor> But I have to confirm this isn't being done already.
[21:35:33] <jmkasunich> http://home.att.net/~jmkasunich/scratch/Collinear200ipsszoom.png
[21:35:40] <jmkasunich> zoomed to 20ms/div
[21:35:43] <SWPadnos> It is a queue - you'd think that there would always be another segment available for the servo loop
[21:36:05] <proctor> So is that a 2-cycle glitch?
[21:36:15] <jmkasunich> looks that way to me
[21:36:21] <SWPadnos> so that's about 3 traj periods - one for each "corner" of the accel curve
[21:36:24] <jmkasunich> rounded off by the cubic I assume
[21:36:35] <les> yeah
[21:36:39] <SWPadnos> the slope is different on the center segment than the others
[21:36:43] <jmkasunich> note: for these pics, green is velocity
[21:36:44] <proctor> Crank up the accel and see if the glitch is bigger.
[21:36:54] <jmkasunich> that is at 200 accel
[21:37:22] <jmkasunich> there is a problem with just changing accel and looking for differnces in the glitch
[21:37:23] <proctor> How are you getting velocity points at less than 1 trajectory interval?
[21:37:29] <SWPadnos> looks like one period "oops go lower", one "oops go higher" and one "oops - go back on track"
[21:37:39] <jmkasunich> change accel, you chang ethe total time for the move, and thus the quantitazion
[21:37:46] <jmkasunich> can't spell for shit
[21:38:12] <mshaver> robin_sz: no we can't schedule rt events, only fixed periods - scheduling on a pc takes too much overhead reprogramming the 8254 - art sort of schedules by looping in the time stamp counter value when he gets close
[21:38:19] <jmkasunich> I'm taking position from the motion controller, differentiating once for velocity, again for accel (at the servo rate)
[21:38:30] <les> Paul did crank accel and the glitch was narrowed but about as deep (a little less from cubic smoothing)
[21:38:33] <proctor> The green vel curve is a curve: how many points are within the cycle?
[21:38:44] <alex_joni> mshaver: I think he didn't mean schedule as in RT scheduling
[21:38:47] <alex_joni> but inside the TP
[21:38:54] <proctor> Don't bring cubic smoothing into this!
[21:38:54] <SWPadnos> 20 points per div on that plot
[21:39:01] <proctor> Just plot the commanded trajectory vel!
[21:39:17] <robin_sz> mshaver: I thought the RT kerneal simply scheduled events at anytime you asked .. its just the we asked for them in slots of PERIOD or whatever ? no?
[21:39:17] <jmkasunich> servo rate is 1mS, and the scope is sampling at that rate
[21:39:33] <alex_joni> robin_sz: no it doesn't. at least not for fast things
[21:39:41] <alex_joni> it's a lot easier to program periodic tasks on RT
[21:39:51] <robin_sz> ok, keep going with the task in hand
[21:39:51] <jmkasunich> fred: I can only plot things that are exported as HAL variables
[21:40:07] <proctor> The RT kernel can schedule events any time we ask, up to some small amount, say 10 microseconds.
[21:40:23] <jmkasunich> but to date we do things in periodic mode, and it would be messy to change
[21:40:25] <proctor> But if the code takes 11 microseconds to run, you lock up the CPU.
[21:40:28] <jmkasunich> let's not go there yet
[21:40:35] <robin_sz> * robin_sz nods
[21:40:46] <robin_sz> so .. we re back to accel value modification
[21:41:07] <alex_joni> right
[21:41:11] <proctor> Or back at bringing in the accel when it should be brought in. That would be easiest.
[21:41:14] <jmkasunich> proctor: tell me what variables you want to see (file and name) and give me a few mins, and I can export them to HAL
[21:41:32] <alex_joni> jmkasunich: what's the vertical scale on those graphs ?
[21:41:43] <proctor> I want to see the commanded velocity output of the trajectory planner v. time.
[21:42:03] <jmkasunich> the green trace (the active one) is displayed in the vertical section of the screen, right of main image
[21:42:11] <jmkasunich> 0.5 per div in this case
[21:42:20] <proctor> File and name, give me a minute...
[21:42:24] <jmkasunich> the others aren't displayed (normally I would just select them to check)
[21:42:38] <jmkasunich> position is set to 0.2 per div, so the total 1 unit move goes to the top of the screen
[21:42:58] <jmkasunich> accel scaling was adjusted for each pic, to keep it on screen
[21:43:17] <alex_joni> let's talk 200ipss
[21:43:33] <alex_joni> http://home.att.net/~jmkasunich/scratch/Collinear200ipss.png
[21:43:55] <jmkasunich> proctor: I didn't think the tp actually outputted a velocity (although I can take new_pos - old_pos of course
[21:43:59] <jmkasunich> ok alex
[21:44:24] <jmkasunich> accel is at 20 per div
[21:44:25] <proctor> new_pos - old_pos is OK.
[21:45:09] <mshaver> I gotta go away for a while - will log & return
[21:45:10] <proctor> I had some Tk logging scripts that logged vel v. time, in EMC 1. This was done inside emcmot.c.
[21:45:10] <alex_joni> same for the zoomed one?
[21:45:20] <jmkasunich> yes
[21:45:46] <alex_joni> ok
[21:46:13] <mshaver> mshaver is now known as mshaver_away
[21:47:33] <jmkasunich> fred: near the end of tpRunCycle is a comment: /* increment current position with sum of increments */
[21:47:47] <jmkasunich> followed by: pmCartCartAdd(tp->currentPos.tran, sumPos.tran, &tp->currentPos.tran);
[21:48:44] <jmkasunich> can I use (sumPos.tran.x/traj_period) as the velocity command?
[21:49:22] <proctor> Yes, I think so. For a purely X move, that's the increment to be moved.
[21:49:31] <les> The glitch width is clearly a function of MAX_ ACCELERATION. There must be a false triggering of tcflag==DECEL. I see the filter for scaling triggering this. Does there need to be another?
[21:50:28] <steves_logging> steves_logging is now known as steve_stallings
[21:51:48] <proctor> Sorry guys, got to make dinner. BBQ night. Let's recap:
[21:52:02] <proctor> There is a glitch in the vel v. time curve.
[21:52:33] <proctor> I thought that this may be due to a late blending of the next move, due to the time period quantization.
[21:52:39] <paul_c> more than just a "glitch"
[21:52:54] <proctor> If so, it would be more pronounced with larger acceleration.
[21:53:14] <paul_c> also, G61/G61.1/G64 makes little difference to the transient.
[21:53:23] <proctor> It would also seem to me to last only one or two cycles. Les says this goes over many cycles.
[21:53:33] <les> in some cases
[21:53:42] <jmkasunich> we have more than one thing going on
[21:53:43] <paul_c> High velocity & low accel enhances the problem.
[21:53:45] <proctor> But I'm not sure that the many-cycle glitch/horrible problem is from two long collinear moves.
[21:54:10] <jmkasunich> with collinear lines it appears to be only one sample long (plus another sample for recovery)
[21:54:10] <alex_joni> fred: just 5 more mins
[21:54:14] <alex_joni> wanna ask you smthg
[21:54:20] <proctor> OK
[21:54:27] <robin_sz> proctor: thnaks for taking the time to stop by, more understanding and progress towards a solution has happened in the last hour or so than in the last two weeks ...
[21:54:28] <paul_c> that 2nd plot.... That was a spiral of very short straight line moves.
[21:54:32] <alex_joni> anonimasu tinkered with some values
[21:54:38] <alex_joni> and got it working a bit better
[21:54:44] <alex_joni> can you explain the following line:
[21:54:45] <alex_joni> tc->toGo = (newVel + tc->currentVel) * 0.5 * tc->cycleTime;
[21:55:05] <anonimasu> I changed it, to 0.40?
[21:55:06] <proctor> I suggest we focus on a problem that appears in the vel v. time trace for long collinear moves. If there is a problem there, it needs to be fixed.
[21:55:22] <jmkasunich> proctor: an easier question, I hope... can you come back online later tonight?
[21:55:30] <anonimasu> http://www.bojn.net/~an0n/tweak2.jpg
[21:55:42] <jmkasunich> I agree that we should start with simple cases and move on from there
[21:56:07] <proctor> That tc->toGo line looks to me like it computes the distance to go, for the current motion segment.
[21:56:09] <alex_joni> anonimasu: can you plot for collinear lines
[21:56:15] <alex_joni> and see what happens
[21:56:31] <anonimasu> alex_joni: I dont have emc working something broke on the box earlier..
[21:56:36] <alex_joni> ahh.. ok :)(
[21:56:37] <robin_sz> anonimasu: it could be that just hapened to move the endpoint nearer a time slice ... I suspect by teaking the value, you could get it to disappear for a *particular* move
[21:56:47] <proctor> John K, I may be able to come back later. Wife is driving back from dropping daughter off at dance camp 3 hours away. May need spa treatment.
[21:56:54] <les> Fred, thanks for getting on in a room full of glitched guys on a sunday afternoon. Go BBQ.
[21:57:13] <jmkasunich> ok, I'll be messing with this all evening, and would be gratefull for any help
[21:57:27] <anonimasu> fred: thanks for your time :)
[21:57:28] <mshaver_away> proctor: thanks from me too!
[21:57:34] <Jymmm> les : speak for yourself glitchboy! =)
[21:57:36] <alex_joni> ditto ;)
[21:57:38] <les> haha
[21:57:45] <proctor> John K, see if you can get various plots of vel, accel v. time for two long collinear moves.
[21:57:49] <proctor> Bye now.
[21:58:02] <robin_sz> well, that was fun
[21:58:07] <les> yeah.
[21:58:28] <robin_sz> for a momemnt or teo I almost felt I understood it
[21:58:43] <anonimasu> heh
[21:58:45] <les> Just speculation now, but I feel like this might have a chance of getting fixed.
[21:59:13] <anonimasu> robin_sz: that was the wrong plot btw..
[21:59:21] <Jymmm> It's all on jmkasunich to get those plots! (no pressure there)
[21:59:23] <anonimasu> http://www.bojn.net/~an0n/sc.jpg
[21:59:35] <anonimasu> http://www.bojn.net/~an0n/sc1.jpg
[21:59:44] <robin_sz> les: I think with "adjustment" combined with the "vetting" idea from the Sonja paper ... it could be fixed
[22:00:03] <les> well Fred is thinking aliasing
[22:00:13] <les> he said no at first but yes later
[22:00:32] <Jacky^> anonimasu: how proceed the toolchanger project ?
[22:00:40] <robin_sz> yeah
[22:00:43] <jmkasunich> I'm convinced Fred is absolutely correct about the collinear moves problem that I see
[22:01:00] <jmkasunich> but it may have little or nothing to do with the arcs problem that you guys are looking at
[22:01:09] <anonimasu> Jacky^: faced all sides of the cube, started to drill the hole that I need to boar later..
[22:01:10] <jmkasunich> we MUST deal with one problem at a time
[22:01:22] <robin_sz> anonimasu: bore
[22:01:25] <Jacky^> anonimasu: :-)
[22:01:46] <anonimasu> robin_sz: umm yeah....
[22:01:48] <robin_sz> boar is a wild pig :)
[22:01:56] <les> Well Fred did say arcs are just linear moves mapped onto cylindrical coordinates in emc
[22:02:00] <les> same calcs
[22:02:04] <robin_sz> * robin_sz ndos
[22:02:13] <robin_sz> so it might fix everything
[22:02:14] <anonimasu> I'd guess that if we solve one problem the other one will follow..
[22:02:15] <jmkasunich> not exactly the same
[22:02:40] <Jacky^> sorry.. maybe it's a stupid question, to use a toolchanger should I change the mandrel of my router or the router ?
[22:02:43] <anonimasu> if they are related solving the issue with the arc's should be relatively simple
[22:02:52] <les> Well I don't know...Fred wrote it. I guess he does.
[22:02:54] <anonimasu> Jacky^: I am working on a lathe toolchanger first I have no time
[22:03:04] <jmkasunich> somebody show me the code that "unwraps" arcs into 3d coords and then I'll believe you
[22:03:29] <alex_joni> les: regarding those arcs. I think he meant circular axes as in ABC...
[22:03:32] <jmkasunich> he may have been referring to angular axis moves, in which case I agree, but this isn't an angular axis
[22:03:43] <robin_sz> right .. I'm off to do my favourite job of the week ...
[22:03:43] <steve_stallings> TP - has anyone demonstrated the problem to exist for to colinear moves at the same feed rate? i.e. simplest possible case
[22:03:49] <robin_sz> invoicing customers :)
[22:03:49] <steve_stallings> two
[22:04:00] <alex_joni> steve_stallings: a few graphs from jmk
[22:04:05] <Jacky^> i was asking to myself if is possible to change mandrel with a differente type
[22:04:15] <jmkasunich> http://home.att.net/~jmkasunich/scratch/Collinear200ipssTPzoom1.png
[22:04:17] <alex_joni> steve_stallings:
http://home.att.net/~jmkasunich/scratch/Collinear200ipss.png
[22:04:24] <alex_joni> steve_stallings:
http://home.att.net/~jmkasunich/scratch/Collinear20ipss.png
[22:04:26] <alex_joni> steve_stallings:
http://home.att.net/~jmkasunich/scratch/Collinear2ipss.png
[22:05:07] <jmkasunich> my latest (right before alex popped up three) shows the TP output before cubic interp, as well as the final output
[22:05:07] <steve_stallings> OK, didn't realize that these were two moves at same feed rate
[22:05:10] <alex_joni> jmkasunich: that's a new one
[22:05:24] <alex_joni> jmkasunich: what's green?
[22:05:27] <jmkasunich> green is TP commanded velocity
[22:05:41] <jmkasunich> red that is the same but smoother is output velocity
[22:05:43] <alex_joni> and the red next to it is velocity after the cubic?
[22:05:49] <jmkasunich> yep
[22:05:55] <alex_joni> right
[22:05:57] <jmkasunich> the two angled reds are the position
[22:06:06] <alex_joni> above
[22:06:11] <jmkasunich> the one that steps every 10mS (1/2 div) is the TP out
[22:06:18] <alex_joni> and below is accel
[22:06:19] <anonimasu> alex_joni> my emc is so broken.. :D
[22:06:25] <jmkasunich> the one that lags a little behind is the main output position
[22:06:33] <jmkasunich> and bottom is accel (on output)
[22:06:49] <alex_joni> anonimasu: let's fix it in private, not to clutter things up ;)
[22:07:02] <anonimasu> alex_joni: yeah :)
[22:07:25] <les> jmk...Fred's quote:
[22:07:27] <les> <proctor> Angular moves are just linear moves around a circle, as far at TC is concerned.
[22:07:54] <jmkasunich> ok
[22:08:05] <les> took a while to find it.
[22:08:18] <jmkasunich> but there is at least some code that is completely different to handle them
[22:08:24] <jmkasunich> * jmkasunich looks at the code
[22:08:24] <les> yes
[22:08:40] <alex_joni> les: that was related to 3 axes vs 6 axes
[22:08:45] <alex_joni> couple of lines above
[22:09:15] <les> You know, Fred will be thinking about this while he cooks haha
[22:09:19] <mshaver_away> i tlked to fred on the phone just now - told him thanks - he will look at the problem - later today i'll try to get an emc1 system going & compile testtp.c to see if i can get data that way - now to mow grass and char cattle flesh !
[22:09:34] <les> yeah
[22:09:36] <les> great
[22:09:52] <les> great irc day
[22:10:06] <alex_joni> glad my logger didn't die ;)
[22:10:09] <mshaver_away> yep - fred said he liked it too
[22:10:16] <les> cool
[22:10:18] <alex_joni> think this one's worth putting on linuxcnc.org
[22:10:40] <mshaver_away> well, i'm really away now... for a while anyhow!
[22:10:54] <dave-e> ah matt, you're back
[22:11:00] <alex_joni> jmkasunich: still there?
[22:11:25] <jmkasunich> yeah
[22:12:20] <alex_joni> how are the verticle dotted lines related to trajectory rate?
[22:12:28] <alex_joni> any connection, or coincidence?
[22:12:35] <jmkasunich> they're just scope divisions
[22:12:59] <jmkasunich> I can move the traces WRT them using the position control
[22:13:16] <alex_joni> but not triggered by the begining of the traj cycle?
[22:13:17] <jmkasunich> if you are looking at the latest, the steps in the green trace are when the traj code runs
[22:13:24] <jmkasunich> nope
[22:13:43] <jmkasunich> sampling at servo rate, and triggered by non-zero velocity output
[22:14:23] <alex_joni> could you trigger at the beginning of the servo rate?
[22:14:28] <alex_joni> or output a debug pin
[22:14:34] <alex_joni> and grab it in the same graph
[22:14:37] <jmkasunich> don't understand
[22:14:43] <alex_joni> to see when the velocity changes
[22:14:55] <alex_joni> that green step
[22:14:57] <jmkasunich> I sample at the servo rate, there is no finer time resolution than that
[22:15:09] <alex_joni> I wanna know how it relates to traj rate
[22:15:37] <jmkasunich> the traj code runs at 0.01 seconds, when it runs it changes the value
[22:15:45] <jmkasunich> the scope is sampling 10 times faster
[22:15:51] <alex_joni> right
[22:15:56] <steve_stallings> with the proper time scale on the scope, each dotted vertical line could be servo cycle?
[22:16:09] <alex_joni> steve_stallings: that's what I wanted
[22:16:12] <jmkasunich> yeah, at 1mS/div that would happen
[22:16:15] <alex_joni> but you can't trigger that
[22:16:26] <jmkasunich> triggering has nothing to do with it
[22:17:16] <alex_joni> hmmm...
[22:17:20] <alex_joni> you have 20 msec/div
[22:17:22] <alex_joni> right?
[22:17:23] <jmkasunich> I could zoom to 10mS/div so that one traj period = 1 div
[22:17:28] <alex_joni> yeah
[22:17:47] <alex_joni> but you still wouldn't know if a traj period matches exactly with 1 division
[22:17:50] <alex_joni> right?
[22:18:14] <jmkasunich> the steps in the green trace tell you when the traj code ran
[22:18:24] <alex_joni> but if you would toggle a bit at the begining and at the end of the trah code you'll see it even better
[22:18:28] <alex_joni> traj
[22:18:30] <jmkasunich> you can use the position slider to line them up with the division lines if you want
[22:18:41] <jmkasunich> nope
[22:18:48] <alex_joni> why not?
[22:19:00] <jmkasunich> the traj code begins and ends between samples
[22:19:06] <jmkasunich> I'd never see the bit
[22:19:08] <alex_joni> oh I see now
[22:19:23] <alex_joni> sampling is done after the code already ended
[22:19:41] <jmkasunich> yep - the scope sample function is linked in at the end of the HAL servo thread
[22:19:51] <steve_stallings> last example posted by JMK looks pretty clear to me, traj output is in error for one traj cycle
[22:20:15] <alex_joni> steve_stallings: smthg like that
[22:20:16] <jmkasunich> yeah, that is consistent with fred's theory
[22:20:37] <jmkasunich> I'm not good with g-code arcs, or I'd try an arc test on this box
[22:21:01] <dave-e> use jon's code
[22:21:06] <alex_joni> jmkasunich: as fred said (and I agree) let's do it for lines first
[22:21:08] <anonimasu> jmkasunich: g2 x0 y0 i0 j2 f20
[22:21:12] <anonimasu> do it twice in a row ;)
[22:21:16] <steve_stallings> what about some G code contrived to put alternate splice points on traj boundary and in middle of traj period?
[22:21:17] <alex_joni> if that works.. we'll go on to arcs
[22:21:34] <paul_c> 2" radius @ 200ipm
[22:21:37] <jmkasunich> just got one from paul
[22:21:42] <anonimasu> yep..
[22:21:55] <paul_c> 45Degree joints
[22:22:03] <dave-e> jmk..when you have time check your email
[22:22:27] <alex_joni> and suddenly it's raining circles on jmkasunich
[22:22:33] <anonimasu> heh
[22:23:16] <jmkasunich> ok, I will try circles, and also slighly non-collinear lines
[22:23:27] <alex_joni> one more thing...
[22:23:27] <dave-e> no ... mine is a co-linear plot at 160/225 ipm
[22:23:39] <alex_joni> what happens to that graph if you change the traj time?
[22:23:56] <jmkasunich> too many fscking variables
[22:24:03] <steve_stallings> circles ? what happened to chasing the simplest case first?
[22:24:42] <jmkasunich> I chased the simplest case already, the plots are there, and it is obviously not the long disturbance that others are seeing
[22:24:56] <jmkasunich> yes, it needs to be fixed, and IMO should be fixed first
[22:25:15] <jmkasunich> but other folks aren't gonna drop the long glitch issue, so I want to see if I can replicate it
[22:25:23] <steve_stallings> k
[22:25:56] <jmkasunich> it is a heck of a lot easier for me to run 10 differnet g-code progs than ten or even two differnet machine configs
[22:26:19] <jmkasunich> cause when I restart emc, I have to redo the scope setup
[22:32:29] <alex_joni> right
[22:32:45] <alex_joni> maybe put a "load-settigns" on the wishlist
[22:32:48] <Jymmm> Eeeeesh, I've been away five minutes, though you all would have the problem fixed by now! Whats the hold up?! =)
[22:32:57] <alex_joni> you've been away
[22:33:09] <alex_joni> no sleazy comments on the channel to push us to work
[22:33:13] <alex_joni> lol
[22:33:33] <Jymmm> alex_joni : Well, if you didn't know I was away, I guess I can't expect 10 minute solutions
[22:33:42] <jmkasunich> alex: already did
[22:33:51] <alex_joni> jmkasunich: :)
[22:34:26] <Jymmm> paul_c : And you... what rock have you been hiding under?
[22:34:47] <alex_joni> Jymmm: walking on thin ice
[22:34:50] <paul_c> Jymmm: I can change the v to a b if you want...
[22:35:14] <Jymmm> paul_c : Quit avoiding the question... haven't seen you in a few weeks.
[22:35:38] <paul_c> been busy.
[22:35:45] <alex_joni> oh.. Jymmm has missed paul_c
[22:35:48] <alex_joni> how cute ;)
[22:36:00] <dave-e> back in a while
[22:36:27] <Jymmm> jmkasunich is hal scope part of emc builds?
[22:36:39] <jmkasunich> emc2
[22:36:40] <alex_joni> alex_joni is now known as paul_corner
[22:36:47] <paul_corner> :P
[22:36:49] <anonimasu> paul_c: comming back and acting all like that :D
[22:36:50] <Jymmm> jmkasunich ah, ok.
[22:36:53] <paul_corner> paul_corner is now known as alex_joni
[22:40:52] <jmkasunich> ok, I edited paul's 2" circle down to 0.2" and ran it... got a glitch 1 traj period lone
[22:41:14] <jmkasunich> the 2" one takes so long to run that it trails off the scope window
[22:41:48] <jmkasunich> oh, and I run it at 60 ipm, this config is limited to 72 ipm and I haven't restarted yet
[22:42:08] <paul_c> what accel ?
[22:42:13] <jmkasunich> 200
[22:42:32] <paul_c> reduce accel to, say 20
[22:42:59] <jmkasunich> in a bit (when I restart)... gonna try a few more things first
[22:45:05] <alex_joni> paul_c: is it possible to make a .c only implementation of NML?
[22:45:10] <alex_joni> actually of libNML
[22:45:39] <jmkasunich> ok, went back to the big circle, change scope to sample at traj rate so the whole thing would fit... two glitches at the two 45 degree points
[22:46:09] <jmkasunich> both glitches are 1-2 traj periods long
[22:46:29] <paul_c> alex_joni: You could do a C implementation of NML
[22:47:05] <paul_c> but it would get very messy...
[22:47:12] <anonimasu> :
[22:47:24] <anonimasu> paul_c: even a limited implementation?
[22:47:26] <alex_joni> why is that?
[22:47:44] <paul_c> function overloading.
[22:47:45] <alex_joni> I am thinking of a limited implementation
[22:47:47] <alex_joni> not all
[22:48:01] <alex_joni> also.. maybe limit NML to ASCII as transport
[22:48:10] <alex_joni> to get rid of nasty formats
[22:48:24] <jmkasunich> doing something embedded
[22:48:27] <jmkasunich> ?
[22:49:02] <paul_c> ASCII encoding is the slowest method.
[22:50:37] <alex_joni> jmkasunich: talked about a pendant
[22:51:50] <paul_c> As long as you keep your data structures small, you could code a minimal NML in plain C
[22:53:03] <alex_joni> was thinking of GUI-like actions
[22:53:14] <alex_joni> like jogging, velocity override
[22:53:18] <paul_c> All of them ?
[22:53:22] <alex_joni> some of them
[22:53:32] <alex_joni> about 10-15 NML messages
[22:54:31] <paul_c> <header><axis><velocity>
[22:54:57] <alex_joni> yeah
[22:55:59] <paul_c> If all the data structures were of the same format, a simple NML encoding routine wouldn't be too bad.
[22:56:16] <alex_joni> I wouldn't mind having a few of them
[22:56:26] <alex_joni> say an encoding function for jogging functions
[22:56:29] <paul_c> struct{int,double,double}
[22:56:33] <alex_joni> one for mist/lube/coolant/ etc
[22:56:52] <anonimasu> paul_c: is that how the messages will look at the pc also?
[22:57:42] <paul_c> anonimasu: At the simplest level, yes.
[22:57:50] <anonimasu> ok
[22:57:51] <anonimasu> :)
[22:57:57] <anonimasu> *yawns*
[22:57:58] <anonimasu> bedtime
[22:58:25] <paul_c> ditto - Have some threading routines to test tomorrow.
[23:03:14] <Jymmm> damn, he left before I had a chance to bag on him some more
[23:09:18] <Jacky^> * Jacky^ nods
[23:09:53] <Jacky^> I'm listening all but i not understood a word :\
[23:10:59] <Jacky^> too many technical terms :(
[23:11:33] <Jacky^> Jymmm: can you send me some good tool from there ? :P
[23:12:12] <Jacky^> can't find a simple ballnose here..
[23:12:46] <Jacky^> * Jacky^ umpf
[23:24:12] <anonimasu> Jacky^: you are looking at the wrong places
[23:24:32] <anonimasu> http://www.secotools.com/template/normal.asp?id=2313
[23:25:39] <anonimasu> but if you want cheap tools keep looking ;)
[23:26:01] <Jacky^> uh
[23:26:04] <Jacky^> :)
[23:26:28] <anonimasu> seco has everything from inserts to mills designed for HSM
[23:26:31] <anonimasu> err endmills
[23:26:37] <jmkasunich> alex, les: you guys still here?
[23:27:05] <anonimasu> Jacky^: but good stuff :D
[23:27:22] <anonimasu> I dont know for wood though ;)
[23:27:32] <anonimasu> for wood my best bet would be any hardware store
[23:27:41] <anonimasu> hardware/woodworking
[23:28:09] <Jacky^> nice
[23:32:04] <dave-e> look at hemlytools.com ...carbide endmills but tolerances are not tight...0.002 but again not for wood
[23:32:22] <jmkasunich> dave: they are looking for eu sources
[23:32:29] <anonimasu> I was going to order some carbide last week..
[23:32:32] <Jacky^> yeah..
[23:32:32] <anonimasu> but the price scared me off
[23:32:39] <dave-e> opps....naturally haven't a clue
[23:32:40] <anonimasu> 90eur for a 8mm endmill..
[23:32:59] <Jacky^> ouch :s
[23:33:16] <dave-e> still there must be some stuff that is good and not too expensive.
[23:33:25] <Jacky^> I bought oe for E. 24
[23:33:26] <anonimasu> yep
[23:33:31] <anonimasu> heh
[23:33:36] <Jacky^> but broken after a week :\
[23:33:38] <anonimasu> I've tried thoose only trouble is that they wont cut ;)
[23:33:50] <anonimasu> I use dormer ones they are a bit over ~20eur each
[23:34:44] <alex_joni> jmkasunich: I'm still here
[23:35:10] <jmkasunich> I was able to duplicate the "longer than 1-2 traj periods" glitches
[23:35:16] <alex_joni> yeah?
[23:35:22] <alex_joni> under what condition?
[23:35:35] <jmkasunich> running at 200ipm (3.33ips) feed, 20 ipss accel
[23:35:50] <jmkasunich> arcs or collinear lines
[23:36:21] <jmkasunich> also affected by feedrate override
[23:37:15] <alex_joni> right
[23:37:26] <alex_joni> think I'll head to sleep now
[23:37:32] <alex_joni> it's pretty late
[23:37:34] <jmkasunich> wimp!
[23:37:41] <jmkasunich> he he he
[23:37:45] <alex_joni> not doing anything constructive :D
[23:37:48] <jmkasunich> timezones make a difference
[23:37:55] <alex_joni> [01:51] <jmkasunich> timezones make a difference
[23:37:58] <alex_joni> you think?
[23:38:05] <jmkasunich> ya
[23:38:07] <anonimasu> I were going to bed a hour ago :/
[23:38:09] <anonimasu> almos
[23:38:09] <anonimasu> t
[23:38:11] <alex_joni> heh.. you might be right
[23:38:17] <alex_joni> but it was a good discussion today
[23:38:35] <anonimasu> yep
[23:38:51] <alex_joni> hope it'll get things somewhere
[23:38:51] <alex_joni> :D
[23:39:14] <anonimasu> yep
[23:39:26] <anonimasu> * anonimasu ponders if he should take the sonia.pdf printout to bed
[23:39:40] <jmkasunich> ohhh, sleeping with sonja
[23:39:44] <anonimasu> yeah
[23:40:04] <alex_joni> * alex_joni admits he did once too
[23:40:18] <anonimasu> with the paper or with wonja :D
[23:40:57] <anonimasu> sonja
[23:40:58] <anonimasu> ;)
[23:41:14] <alex_joni> guess you'll never know
[23:41:34] <anonimasu> well, since I've seen your picture I'll assume you are talking about the paper :D
[23:42:07] <alex_joni> :P
[23:42:44] <jmkasunich> but have you seen sonja's picture?
[23:42:49] <alex_joni> lol
[23:43:01] <jmkasunich> she might be uglier than me!
[23:43:07] <alex_joni> http://www.minigui.org/images/thhp.jpg
[23:43:28] <anonimasu> jmkasunich: well, if the can write that kind of papers it's possible..
[23:44:29] <alex_joni> http://www.mech.ubc.ca/~sonja/snowboarding.jpg
[23:44:33] <alex_joni> that's her
[23:44:48] <jmkasunich> real helpful
[23:45:00] <anonimasu> ;
[23:45:02] <anonimasu> ;)
[23:47:31] <anonimasu> alex_joni: what's that first pic?
[23:47:41] <alex_joni> some cnc gui
[23:47:52] <alex_joni> but you gotta translate it to get the joke
[23:47:59] <jmkasunich> http://www.nurturestudio.com.au/images/sonjaphoto.jpg
[23:48:23] <anonimasu> I've already seen that one..
[23:48:24] <anonimasu> :D
[23:48:26] <alex_joni> not her ;)
[23:48:33] <jmkasunich> (not really, same name, different person)
[23:48:52] <anonimasu> alex_joni: I must be way too stupid ;)
[23:49:06] <anonimasu> chineese I think
[23:49:31] <anonimasu> or japanese
[23:49:34] <alex_joni> heh
[23:49:41] <alex_joni> you'll figure it out eventually
[23:49:44] <alex_joni> I think
[23:49:55] <anonimasu> heh
[23:50:01] <anonimasu> japanese?
[23:50:08] <alex_joni> but till then.. it'll hunt you
[23:50:15] <alex_joni> you won't be able to sleep properly
[23:50:19] <jmkasunich> haunt even
[23:50:27] <alex_joni> yeah
[23:50:32] <alex_joni> that one :)
[23:50:35] <anonimasu> if it only were spoken ;)
[23:50:45] <alex_joni> my 2am english is not that great :D
[23:50:56] <alex_joni> half my neurons aren't spiking
[23:50:59] <jmkasunich> better than my romanian anytime
[23:51:07] <anonimasu> how do you think my 1am japnese?
[23:51:08] <alex_joni> and the other ones are asleep
[23:51:34] <anonimasu> heh
[23:51:40] <anonimasu> caffeine?
[23:51:50] <alex_joni> nah... it'll wake me
[23:52:02] <anonimasu> bah
[23:52:02] <alex_joni> and ruin my mood
[23:52:26] <anonimasu> if it does it's too weak :D
[23:52:55] <anonimasu> * anonimasu pokes alex's neurons
[23:53:39] <anonimasu> again, goodnight everyone
[23:54:19] <dave-e> hey alex just in case you get cold it is 36 here.
[23:54:19] <jmkasunich> night
[23:54:32] <alex_joni> celsius?
[23:54:35] <dave-e> yep
[23:54:39] <alex_joni> it's about 28 here
[23:54:42] <alex_joni> at 2 am
[23:54:53] <dave-e> ohhh...tooo hot
[23:54:56] <alex_joni> 38 during the day
[23:55:02] <dave-e> ouch
[23:55:34] <alex_joni> http://www.mech.ubc.ca/~ial/research/videoClips/demo1.avi
[23:55:36] <alex_joni> http://www.mech.ubc.ca/~ial/research/videoClips/demo2.avi
[23:55:39] <dave-e> good for some crops
[23:55:44] <dave-e> but not for people
[23:57:51] <alex_joni> I agree
[23:57:58] <alex_joni> well.. will try to get some sleep
[23:59:53] <alex_joni> night guys
