#emc | Logs for 2005-05-15

Back
[00:01:38] <paul_c> A little
[00:02:16] <alex_joni> what do you think?
[00:03:13] <alex_joni> paul_c: just read the logs.. should I mirror 4.21 ?
[00:03:30] <paul_c> 4.21 isn't ready yet.
[00:03:43] <alex_joni> test it?
[00:06:48] <alex_joni> * alex_joni wonders if jmk had any luck with that EXPORT_SYMBOL
[00:06:55] <alex_joni> my dev box is too away
[00:07:01] <jmkasunich> still working on it
[00:07:20] <alex_joni> hey John.. wasn't aware you're still arounf
[00:07:23] <alex_joni> around even
[00:07:31] <jmkasunich> I think the best solution is to make a "modversions.h" file on TNG boxes (in the configure script)
[00:08:01] <jmkasunich> the file is a one liner: #include <linux/modsetver.h>
[00:08:15] <alex_joni> make it where?
[00:09:06] <jmkasunich> configure sees that it's a TNG box, checks for modversions.h, if not present, does echo "#include <linux/modsetver.h>" >/usr/src...../modversions.h
[00:09:09] <alex_joni> how about adding the necesity for the kernel to be configured?
[00:09:14] <alex_joni> like rtai does?
[00:09:32] <alex_joni> you might not have access rights for that
[00:09:44] <jmkasunich> I don't expect they will on the first attempt
[00:09:58] <alex_joni> heh
[00:10:00] <alex_joni> :D
[00:10:14] <alex_joni> but ./configure should pretty much run without any problems
[00:10:20] <jmkasunich> I was gonna have configure check for access, if not it would say something like "run ./configure as root (you will only have to do this once)"
[00:10:25] <alex_joni> it might fail stating that the kernel is not configured
[00:10:37] <alex_joni> and it could output the command to fix it
[00:11:49] <jmkasunich> I wonder if it is possible to actually configure the kernel on a TNG box, or have some vital things been left out
[00:12:17] <jmkasunich> configure using the same configuration that was originally used when Paul built it, of course
[00:13:16] <alex_joni> too tired to think about that ;)
[00:13:21] <alex_joni> how about the tool stuff?
[00:13:34] <jmkasunich2> too tire to think about that ;-)
[00:13:40] <paul_c> catch you later
[00:13:42] <alex_joni> lol
[00:13:51] <alex_joni> night paul
[00:13:56] <jmkasunich2> * jmkasunich2 doesn't work well on multiple things...
[00:14:01] <alex_joni> [03:12] <alex_joni> too tired to think about that ;)
[00:14:06] <alex_joni> I agree ;)
[00:14:20] <jmkasunich2> gotta focus on this first
[00:14:43] <alex_joni> ok
[00:14:53] <alex_joni> I'll go and fix the Makefiles tomorrow
[00:14:58] <alex_joni> what do you think is best?
[00:15:08] <jmkasunich2> what part? you mean the EXPORT stuff"
[00:15:12] <jmkasunich2> s/"/?
[00:15:20] <alex_joni> I wanna move the copy of the modules to make modules (instead of make modules_install)
[00:15:29] <jmkasunich2> ok, I like that idea
[00:15:33] <alex_joni> and put the original make modules_install
[00:15:52] <alex_joni> but I wondered if a rule wouldn't be ok for copying the .ko to rtlib ?
[00:16:01] <alex_joni> like in Make.rule
[00:16:08] <jmkasunich2> not sure
[00:16:28] <alex_joni> well.. I'll try to clean stuff up a bit
[00:16:45] <alex_joni> and to run hal modules at low base_periods to see if they barf ;)
[00:17:06] <jmkasunich2> I've noticed a few other minor things in configure, I'll do a little cleanup too
[00:17:18] <alex_joni> go right ahead ;)
[00:17:33] <jmkasunich2> I'll commit before I go to bed, so you can see my changes and we don't duplicate effort
[00:18:47] <alex_joni> ok
[00:21:24] <daryl> bdi... Hah! lol. Like the penguin and the fly swatter
[00:21:36] <alex_joni> yeah
[00:21:39] <alex_joni> ;)
[00:37:09] <daryl> Nice. BDI works.
[00:37:28] <alex_joni> even emc?
[00:37:31] <daryl> Yup.
[00:37:47] <daryl> Remember period=0.000024 didn't work on my system before? now it does.
[00:38:29] <alex_joni> nice
[00:38:31] <daryl> Not sure... but I suspect the toolchain.
[00:38:36] <alex_joni> I go to bed
[00:38:41] <daryl> g'night.
[00:38:42] <jmkasunich> goodnight alex
[00:38:43] <alex_joni> on BDI paul_c used 2.95
[00:38:50] <alex_joni> night jmk et all
[00:38:58] <alex_joni> bonne nuit
[00:39:17] <alex_joni> nous on va domain
[00:39:34] <alex_joni> er.. aujourd'hui plus tard
[00:51:50] <Imperator_> g'night
[00:54:31] <Jymmm> Gawd I love (lust?) BBQing
[00:55:10] <Jymmm> nice lil rib eye steak... oh so tender, juicey, and flavorfull!!!!!!!!!!!!11
[05:05:11] <weyland> howdy boyz
[05:08:17] <weyland> no one ever awake this time of day/night?
[05:08:27] <weyland> or did I forget to shower again?
[05:11:47] <jmkasunich> busy
[05:12:16] <weyland> hey John~!
[05:12:21] <jmkasunich> hi
[05:12:43] <jmkasunich> I didn't understand your last email about backlash
[05:13:00] <weyland> sorry, what part wasn't clear?
[05:13:18] <weyland> I'm thinking it isn't backlkash any more, anyway
[05:13:36] <weyland> I've got problems that I can't track down and finger
[05:13:48] <jmkasunich> I think there is an issue with the backlash comp code
[05:13:59] <weyland> cr@p
[05:14:08] <weyland> I was really hoping NOT to hear that
[05:14:24] <weyland> that would explain things, expecially tonight
[05:14:30] <jmkasunich> it doesn't show up on the "normal" backlash test (a circle) because the axis that reverses is moving very slowly, and there are only two reversals per circle
[05:14:38] <weyland> YES~!
[05:14:40] <weyland> But...
[05:14:55] <weyland> when you've MANY moves back adn forth...? is that it?
[05:14:58] <jmkasunich> but on the dome test, there are hundreds of reversals, so a lost step here and there will add up
[05:15:04] <weyland> YES~!!
[05:15:08] <Jymmm> what about using a triangle
[05:15:10] <Jymmm> ?
[05:15:14] <weyland> I tried my hand at engraving today
[05:15:18] <weyland> What a mess that made
[05:15:29] <weyland> Some letters up, some letters down
[05:15:43] <weyland> looks like a three year old is writing
[05:15:46] <jmkasunich> I've been looking at the backlash code, but I'm afraid I can't come up with a quick fix
[05:16:00] <weyland> As long as I know it isn't my machine or me
[05:16:00] <jmkasunich> I would suggest setting backlash to zero
[05:16:09] <weyland> okay, it's a start
[05:16:46] <weyland> Alternatively, I made a somewhat complex part, full of radiuses and cutter comp and it seemingly cut very well
[05:16:46] <jmkasunich> there will be some errors because of the mechanical backlash that isn't being compensated for, but they should not accumulate, no matter how many direction changes there are
[05:17:01] <weyland> yes, this makes sense.
[05:17:19] <weyland> BIG question -
[05:17:39] <weyland> I've some small heds encoders and a mauch board...
[05:18:04] <weyland> would this help for the lost step part, or is it completely in the bl comp?
[05:18:20] <jmkasunich> the lost steps aren't in the bl comp
[05:18:28] <weyland> never mind, just thought that one out...
[05:18:42] <jmkasunich> the prob is that the code applies the compensation as a fast ramp
[05:19:00] <jmkasunich> the sudden accel/decel of that ramp can cause lost steps, depending on your motors, drives, etc
[05:19:15] <weyland> what if I set the accel very low?
[05:19:21] <weyland> in the ini
[05:19:32] <jmkasunich> unfortunately that ramp has no accel or decel
[05:19:39] <weyland> cr.p
[05:19:49] <weyland> is there any way to limit it?
[05:20:06] <jmkasunich> the "fix" fred and I did was a "damned if you do, damned if you don't kind of thing":
[05:20:12] <weyland> lol
[05:20:14] <jmkasunich> the old code did attempt to ramp the backlash
[05:20:38] <jmkasunich> but it was buggy - if you had another direction reversal while the first ramp was in progress, it got fscked up
[05:21:00] <jmkasunich> (could be many steps of error, and could accumulate on subsequent reversals)
[05:21:32] <jmkasunich> our new code will never generate errors itself, but it does generate fast accels that can cause lost steps depending on your motors, drives, and pid tuning
[05:21:47] <weyland> well.... while trying the engraving today and tonight, I've found it to be SOMEWHAT random on where and when it pccurs
[05:21:51] <weyland> new code?
[05:22:04] <jmkasunich> the stuff Fred and I did last year at Fest
[05:22:16] <weyland> sorry... been missing meetings...
[05:22:42] <weyland> did you see my ini?
[05:23:06] <jmkasunich> no - you sent me links to 3 photos and a movie, but no ini file
[05:23:14] <Jymmm> lol
[05:23:25] <weyland> it's in the directory there, if you back it up
[05:23:28] <jmkasunich> (a movie of the mill cutting)
[05:23:33] <weyland> lol
[05:23:51] <Jymmm> jmkasunich ya ya, is that what the kids are calling porn these days?
[05:24:32] <jmkasunich> http://solutionsmachining.com/images/cnc_mill/milling_circle.avi
[05:24:48] <weyland> warning four megabytes
[05:25:20] <weyland> back into the directory proper and you'll get the ini
[05:25:33] <jmkasunich> found it
[05:25:43] <weyland> might've changed by now, though... lol
[05:25:58] <weyland> you mention the PID tuning, and I'm wondering...
[05:26:07] <weyland> that's something that I never quite grasped, I think
[05:26:16] <Jymmm> weyland : are you X and Y leadscrews the same pitch?
[05:26:16] <weyland> and I'm wondering if mine might be contributing...
[05:26:20] <weyland> yes
[05:26:28] <jmkasunich> it's not something you normally associate with steppers
[05:26:55] <jmkasunich> X accel is set to 1, Y and Z to 5... any reason for that?
[05:26:57] <weyland> I keep hearing that, but changing it from 200 to 1000 really made a difference
[05:27:17] <jmkasunich> changing what from 200 to 1000?
[05:27:25] <weyland> the P value
[05:27:37] <weyland> I prolly screwed the X accel up
[05:27:43] <weyland> by accident
[05:27:48] <weyland> fat thumbs
[05:28:18] <jmkasunich> what difference did you notice when you changed from 200 to 1000 for P gain?
[05:28:32] <Jymmm> weyland : Silly question.... is the PS for the steppers plugged into the sam ecircuit as the mill itself?
[05:28:35] <weyland> ACtually, I seem to recall that my Z kept whirring but not moving (making servo sounds with no movement) until I changed it to 1000
[05:28:47] <weyland> yes it is... why?
[05:28:57] <Jymmm> weyland : what about the computer?
[05:29:03] <weyland> same
[05:29:19] <weyland> PS for steppers and computer run off same cord, actually
[05:29:20] <Jymmm> weyland : how "clean" is that ciruit?
[05:29:22] <jmkasunich> Jymmm is probably thinking about electrical noise
[05:29:31] <Jymmm> EMI or surging
[05:29:33] <weyland> In reality?
[05:29:36] <Jymmm> brownouts
[05:29:38] <weyland> I've no fscking clue
[05:29:46] <weyland> want me to tell you about it?
[05:29:49] <jmkasunich> Jymmm: look at picture http://www.solutionsmachining.com/images/cnc_mill/backlash1.jpg
[05:30:11] <jmkasunich> that distortion is too symmetrical to be random electrical noise
[05:30:37] <Jymmm> jmkasunich leasky cap?
[05:30:38] <jmkasunich> I think he's losing a step on each direction reversal, probably because the ramp which applies the backlash comp is too fast
[05:30:39] <Jymmm> leaky
[05:31:00] <weyland> I know this is gonna sound stupid,
[05:31:18] <Jymmm> jmkasunich what about using a simple test program?
[05:31:32] <weyland> but that's exactly what I'd considered last week - that I was losing a step or two at each direction change
[05:31:32] <Jymmm> jmkasunich at least that'll verify HW or SW
[05:31:45] <weyland> what prog?
[05:32:30] <Jymmm> Never used it, http://www.xylotex.com/steptest.exe
[05:32:47] <Jymmm> source code here --> http://www.xylotex.com/Steptest.c
[05:32:55] <jmkasunich> I'm about 99% sure it's not hardware
[05:33:28] <jmkasunich> look at the last test in that photo... just about perfect, because backlash comp was disabled (set to zero)
[05:33:39] <Jymmm> weyland : could you plug in the stepper PS and the computer into another circuit for testing purposes?
[05:33:55] <weyland> sure, I'll do it tomorrow (this) morning
[05:33:58] <Jymmm> weyland: one that doesn't have any or very little load on it
[05:34:08] <weyland> not a prob
[05:34:16] <weyland> 50 foot extension cord okay?
[05:34:26] <jmkasunich> that test is the dome program, BTW... it makes a cut from the edge of the circle toward the middle, then back out to the edge at a slightly different angle (like a clock hand)
[05:34:38] <jmkasunich> so many many direction reversals on both axis
[05:34:50] <weyland> the steppertest prog, or my pics?
[05:34:56] <Jymmm> jmkasunich so that test I pasted is good to try?
[05:35:06] <jmkasunich> your pics are the dome test
[05:35:10] <weyland> right
[05:35:20] <weyland> I didn't know if you meant that they were the same
[05:35:24] <weyland> thin
[05:35:26] <weyland> thing
[05:38:13] <jmkasunich> the xylotex stepper test is a DOS program... I have no idea what shape it does
[05:39:53] <Jymmm> heh
[05:39:54] <weyland> damn... gotta go find a dos disk now... lol
[05:39:54] <Jymmm> jmkasunich well, easy enough to try out at least.
[05:39:54] <jmkasunich> it probably has the step and direction pins reversed compared to the standard EMC pinout
[05:40:07] <jmkasunich> the Xylotex drives have the pins swapped
[05:40:07] <Jymmm> jmkasunich I'm thinking about getting his drive and the 269oz steppers, any thoughts?
[05:40:07] <jmkasunich> who's drive? xylotex?
[05:40:07] <Jymmm> jmkasunich yeah
[05:40:07] <jmkasunich> depends on the size of the machine... the drives are pretty good, but small (2.5A, 35V absolute max, 24-30 recommended)
[05:40:07] <jmkasunich> if that's enough for your machine, then it's great
[05:40:07] <jmkasunich> (it would be fine for a sherline size machine)
[05:40:07] <Jymmm> bootdisk.com
[05:40:23] <Jymmm> jmkasunich I'm makeing a 2'x4' gantry router
[05:40:43] <jmkasunich> weyland - if you're gonna run that xylotex program, you probably need to swap your step and dir pins (at a breakout board or something)
[05:40:48] <weyland> Ha. it's still around... good... thanks
[05:41:01] <weyland> okay, can do.
[05:41:34] <jmkasunich> jymmm: only you can determine what size motors you need
[05:42:28] <jmkasunich> geckos and NEMA 34 motors would make a router fly, but cost a lot more than Xylotex and NEMA 23 motors
[05:42:44] <Jymmm> jmkasunich I have no clue, seriously. He has some 269oz steppers for $50/ea. His driver can't fully drive them, but I can at least use them if I get geckos down the road.
[05:43:21] <Jymmm> they are only 4-wore bipolar, but seems ok for $50
[05:43:30] <Jymmm> s/wore/wire/
[05:44:43] <Jymmm> jmkasunich Oh maybe you know.... you think I get get away with a variac instead of a XFMR, or is the XFMR still needed for isolation?
[05:44:57] <weyland> I'm using a variac
[05:45:02] <weyland> works the charm~!
[05:45:57] <weyland> of course, I AM using a step down xfrmr too
[05:46:41] <jmkasunich> you need a transformer for isolation, or you'll toast your drives, computer, and maybe yourself
[05:47:10] <jmkasunich> you can use a variac ahead of the transformer if you want to adjust the voltage, but don't skip the transformer
[05:47:57] <weyland> that's how mine is
[05:48:14] <Jymmm> jmkasunich ok, not what I wanted to hear, but thanks =)
[05:48:44] <weyland> Jymm: I got both my xfrmr and variac for under $80
[05:48:44] <jmkasunich> gotta get back to coding
[05:49:01] <weyland> John, has this been listed as a bug?
[05:49:04] <weyland> Should it be?
[05:49:14] <jmkasunich> the variac is definitely optional... just get a transformer if you have budget restrictions
[05:49:23] <jmkasunich> not yet, but it probably should be
[05:49:30] <Jymmm> jmkasunich having a hard time finding XFMR
[05:49:45] <weyland> just wondering, so I can try and keep track of any progress on it
[05:50:11] <jmkasunich> http://www.linuxcnc.org/trackers/index.html
[05:50:17] <weyland> so, in the mean time, am I just screwed?
[05:50:20] <jmkasunich> go ahead and submit a bug report if you want
[05:50:22] <weyland> have to live w/bl?
[05:50:30] <jmkasunich> yeah
[05:50:35] <daryl> Jymmm: What are you powering with the variac?
[05:50:36] <weyland> ...damn...
[05:50:52] <weyland> okay
[05:50:58] <weyland> I'll submit one.
[05:51:00] <jmkasunich> I could probably put the old code back in pretty quickly
[05:51:11] <weyland> was the old code good?
[05:51:11] <Jymmm> daryl 250KV tesla coil
[05:51:29] <jmkasunich> it has it's own problems, which one is better probably depends on what you are doing and the characteristics of your machine
[05:51:35] <Jymmm> daryl : Just Kidding =)
[05:51:39] <daryl> oh
[05:51:50] <jmkasunich> for a servo machine, the new code is definitely better - servos automatically smooth out the ramp
[05:51:53] <jmkasunich> but for steppers....
[05:52:03] <weyland> yes?
[05:52:14] <Jymmm> daryl would be for the xylotex driver
[05:52:24] <jmkasunich> for steppers, the fast backlash ramp is probably bad
[05:52:30] <daryl> Yeah, in that case, definitely need isolation.
[05:53:01] <Jymmm> daryl I figured, but variac would have been a Q&D solution
[05:53:17] <weyland> jmkasunich: can you mail me and exlain how I can get and use the old code with my current setup?
[05:53:25] <jmkasunich> the emc2 stepper driver is pretty much immune to that problem, it has accel limiting built in
[05:53:41] <jmkasunich> you are using bdi-4.20?
[05:53:45] <weyland> and I take it that it's not ready yet?
[05:53:45] <daryl> Jymmm: What voltage/current you looking for?
[05:53:48] <weyland> Yes
[05:54:00] <jmkasunich> yeah, emc2 isn't quite ready
[05:54:01] <Jymmm> daryl 24V 100+va
[05:54:10] <jmkasunich> to use the old code, you need two things:
[05:54:37] <jmkasunich> 1) the code replaced in the source file (I can do that, tomorrow (later today I mean))
[05:54:44] <jmkasunich> 2) the ability to compile the code
[05:55:11] <jmkasunich> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BDI-4_Install
[05:55:20] <weyland> been a while since I did all that stuff... does that mean I have to build EMC from scratch?
[05:55:37] <jmkasunich> read that page, and go thru those steps. that will make your machine ready to compile emc
[05:55:48] <weyland> or just recompile over my existing?
[05:55:53] <weyland> Okay
[05:56:00] <jmkasunich> recompile over your existing pretty much
[05:56:06] <weyland> not a prob
[05:56:13] <weyland> Think I can hack my way through that
[05:56:13] <jmkasunich> it's nowhere near as bad as it used to be
[05:56:18] <weyland> LOL~!
[05:56:26] <weyland> Yeah... I remember...
[05:56:27] <jmkasunich> the steps on that webpage you only have to do once
[05:56:45] <weyland> remember when I got it to work on RH 8 & 9?
[05:56:48] <weyland> LOL
[05:56:49] <jmkasunich> yeah
[05:56:53] <weyland> those were the blurs...
[05:57:18] <weyland> Actually, you guys got it to work. I just did the install
[05:57:21] <daryl> Jymmm: No surplus stores near you?
[05:57:40] <Jymmm> daryl there are, just nothin with that high a VA rating
[05:57:45] <daryl> Bummer
[05:57:51] <jmkasunich> if you do everything on that webpage, you will have a freshly compiled version of EMC that is pretty much identical to your original one
[05:58:11] <jmkasunich> then I just have to modify the one file (emcmot.c) with the old backlash code, and you can do a quick recompile
[05:58:35] <weyland> Okay. E* me when I can dl the BDI 4.2 again
[05:58:39] <jmkasunich> Jymmm: how high do you need? the xylotex drives aren't that powerful
[05:58:53] <jmkasunich> 24-30V at 5A or so... less than 200 watts
[05:59:12] <jmkasunich> huh? what do you mean dl the 4.2 again?
[05:59:16] <Jymmm> jmkasunich right, but I can't even find 100va, buch less 200
[05:59:22] <Jymmm> s/buch/much/
[05:59:44] <weyland> Yeah. Or do you mean I just dl the source?
[05:59:49] <weyland> I'm confusered
[05:59:57] <jmkasunich> just read the webpage
[06:00:00] <weyland> okay
[06:00:20] <jmkasunich> you already have a whole CD of debian, only a few meg of it is actually EMC
[06:00:33] <weyland> I'll go do that now, before I pass out for hte night
[06:00:39] <jmkasunich> I think you'll have to download about 20-25 meg one time
[06:00:44] <weyland> kewl
[06:01:03] <jmkasunich> then when bugfixes and such go in, you only download the changed stuff, often less than 10K
[06:01:12] <jmkasunich> the wonders of CVS
[06:01:16] <weyland> oh, kewl
[06:01:25] <weyland> on a related note -
[06:01:40] <weyland> does this Deb support wirelss pci cards?
[06:01:53] <jmkasunich> I have no idea... that would be a question for paul
[06:02:05] <weyland> was thinking of sticking one in there so I could xfr files more easily
[06:02:15] <weyland> okay
[06:02:40] <jmkasunich> I bet it does, there are something like 14000 packages for debian, and BDI-4.xx can use most of them
[06:03:00] <weyland> only an apt-get away, eh?
[06:03:10] <jmkasunich> yeah... I must admit it's pretty nice
[06:03:14] <nevyn> more than 20k binary packages now.
[06:03:25] <Phydbleep> weyland: I wouldn't try to run wi-fi and emc at the same time.
[06:03:30] <weyland> yeah, even as an old RedHat man, I have to admit it too
[06:03:40] <weyland> problems?
[06:03:41] <jmkasunich> well it's 2am here, and I need to get back to coding
[06:03:50] <weyland> Thanks for your time and input, John
[06:03:54] <jmkasunich> later dudes
[06:04:05] <Phydbleep> Later jmkasunich :)
[06:04:21] <weyland> Phydbleep: would that be a prob?
[06:04:55] <Phydbleep> weyland: You can run one or the other safely, but not both at the same time. (I think)
[06:05:06] <weyland> I wonder why?
[06:05:44] <weyland> although I dont forsee trying to run emc and downloading pr0n at the same time :)
[06:06:16] <Phydbleep> rtai screws with the timing in the machine.. tcpip/wi-fi is very clock driven.
[06:06:27] <weyland> Its just that there's no way for me to get a wire back there, and wifi would solve that
[06:06:38] <weyland> Ohhh
[06:06:50] <Phydbleep> Just unload the wifi driver before you fire up emc.
[06:07:02] <weyland> hmmm
[06:07:32] <weyland> do you really have to unload the driver, or can you just ifdown the device?
[06:07:38] <Phydbleep> OR.. Use another 200mHz or so box as a wifi-router.
[06:07:54] <weyland> ? not clear to me...
[06:08:05] <weyland> Oh~! I get it
[06:08:36] <weyland> old, cheap box tu use wifi, with xover cable to EMC box
[06:08:46] <Phydbleep> :)
[06:08:59] <weyland> Lack of space, mostly
[06:09:05] <weyland> brb
[06:09:23] <weyland> http://www.solutionsmachining.com/gallery/shop
[06:11:38] <Phydbleep> ROFL!... I'm in 8'x16' with a full size desk, 2 computers, lathe (3'x7' for the table), shelving, oxy/acetylene bottles, dog, etc. :)
[06:11:58] <Jymmm> Phydbleep that's it?
[06:12:21] <weyland> damn... you got a dog...?
[06:12:23] <weyland> :)
[06:12:42] <weyland> what you don't see is the twenty bikes I have ot wheel in and out every day
[06:12:54] <weyland> and the other twenty motors
[06:12:59] <weyland> and the ten or so frames
[06:13:31] <Jymmm> Hmmm, maybe I can find two battery chargers (10A+)
[06:13:45] <Jymmm> ^ cheap
[06:14:02] <Phydbleep> Hehehe... I didn't even list things I have to move out like the engine hoist, ramps, etc.
[06:14:05] <daryl> Heh... my "shop" is in my dining room.
[06:14:21] <daryl> Late, mill, 4 scopes, spectrum analyzer, computers, desk, two work benches...
[06:14:24] <weyland> daryl: I remember the daze, well...
[06:14:25] <daryl> lathe even
[06:14:31] <weyland> lol
[06:15:00] <daryl> Oh... and it should be "room". It's a 1 bedroom apartment.
[06:15:27] <weyland> at one time it looked more like I was lving in my workspace than working in my living space :)
[06:15:53] <daryl> :)
[06:16:12] <weyland> in fact, I just moved in there two weeks ago
[06:16:22] <Phydbleep> Been there, done that, got baked and ate the t-shirt. :)
[06:17:07] <weyland> you know yer fscked when the OL bitches about the "metal strings" tearing up the vacuum cleaner
[06:17:25] <daryl> Heh.
[06:18:25] <weyland> gonna go read that page
[06:18:32] <weyland> g'nite boyz
[06:18:33] <Phydbleep> weyland: That's why I got a Kirby. :)
[06:18:36] <daryl> Later.
[06:18:38] <weyland> :)
[06:18:48] <Phydbleep> G'nite weyland
[06:19:23] <Phydbleep> Takes nickels to kill a Kirby. :)
[06:19:47] <CIA-4> 03jmkasunich 07kbuild-0-1 * 10emc2/src/ (configure configure.in): Several tweaks to the configure script. Fixed some places where the code was searching for kernel modules using .o instead of .
[06:20:31] <daryl> Heh. Nifty.
[06:20:50] <jmkasunich2> darn it....
[06:20:55] <daryl> ?
[06:21:22] <jmkasunich2> note to self... don't use $MODEXT in commit log messages...
[06:21:28] <Phydbleep> searching for kernel modules using .o instead of .<NULL> ?
[06:21:49] <jmkasunich2> I wrote "instead of $MODEXT"
[06:22:03] <jmkasunich2> the shell did substitution on me
[06:22:13] <daryl> HEh
[06:22:43] <daryl> Hmm.. I just sat up to do something. But now I forget what.
[06:23:13] <Phydbleep> daryl: Did it involve more 'hsort term memory loss'?
[06:23:18] <Phydbleep> short
[06:23:25] <daryl> Apparently
[07:19:42] <CIA-4> 03jmkasunich 07kbuild-0-1 * 10emc2/src/ (configure configure.in): Added a hack that replaces a missing file on BDI-TNG systems. EMC2 should now compile on all BDIs
[07:27:55] <jmkasunich> and on that note, time for bed
[07:28:04] <jmkasunich> jmkasunich is now known as jmk_asleep
[12:21:26] <Phydbleep> * Phydbleep goes to fall over so as not to disrupt the meeting and annoy the dev's. :)
[12:29:13] <A-L-P-H-A> * A-L-P-H-A pokes Phydbleep in the eye
[13:05:15] <anonimasu> good morning
[13:09:14] <anonimasu> logger_aj: bookmark
[13:09:14] <anonimasu> See http://193.226.12.129/irc/irc.freenode.net:6667/emc/2005-05-15#T13-09-14
[13:10:12] <anonimasu> 05:54:00 <jmkasunich> yeah, emc2 isn't quite ready <- actually emc2 runs better then emc1 ever did :)
[13:11:03] <anonimasu> *yawns*
[13:13:55] <Imperator_> Hi all
[13:14:11] <Imperator_> never got EMC1 running with my servocard
[13:36:59] <paul_c> Hrrmmm... Interesting site found...
[13:37:33] <paul_c> includes some C routines for manipulating assorted splines.
[13:38:13] <asdfqwega> link?
[13:39:18] <paul_c> http://astronomy.swin.edu.au/
[13:41:59] <paul_c> Some of this astrophysics stuff may be just what we need for multidimensional modelling.
[13:43:14] <Jymmm> paul_c: Is that for the newest MArtian Fashions?
[13:43:23] <anonimasu_> nice :)
[13:44:27] <paul_c> Jymmm: short segments, blending, trajectory planner, high speed.
[13:46:57] <Jymmm> paul_c : you know, I've been workign on a lil compression algo for years. I have drawn one comclusion from it... that somehow we can use "shapes" to represent numeric values MORE so than the inverse.
[13:47:26] <Jymmm> paul_c : Sorta along the lines of "Here are three circles, prove Pi."
[13:50:28] <paul_c> problem: CAM programs spit out huge quantities of very short lines to describe a surface.
[13:51:24] <paul_c> problem: These need to be blended in to a trajectory that can be plotted within the constraints of velocity, acceleration, and optionally, jerk.
[13:53:48] <paul_c> solution: Complex math.
[13:54:30] <Jymmm> paul_c : If I didn't know the context (CNC) you were speaking, that almost sounds like what my GPS does.
[13:55:27] <les> Hi all
[13:55:57] <Jymmm> Howdy Les ! And oh, on the cadcandro list, the answer is 42
[13:56:13] <les> ?
[13:56:15] <les> heh
[13:56:42] <Jymmm> les (in response to your long post including grey matter on floor)
[13:56:58] <les> ah
[13:57:18] <les> I was just trying to explain inerta matching
[13:57:26] <les> without calculus
[13:57:35] <les> kinda hard to do
[13:57:56] <Jymmm> les Oh I know =) Boeng 737 30K ft and climbing (over my head)
[13:58:23] <paul_c> les: The spiral test should have been doing 60ipm down to a radius of ~0.067" on your machine.
[13:58:24] <les> Paul I haven't talked to fred since you got back....
[13:58:45] <les> Can he help more on the TC TP thing?
[13:58:47] <Jymmm> les you threw in those fancy math symbols (plus, minus, equals, etc) and lost me
[13:58:48] <paul_c> The talk with Fred was very useful
[13:59:49] <paul_c> It highlighted some of the shortcomings of the tp
[14:00:01] <les> With me he starts talking about TP/TC only blending 2 segments etc
[14:00:44] <les> but that is all you need for a parabolic blend of a trap...2 segments and three points
[14:00:58] <les> so i'm kinda ???
[14:01:29] <les> what about the stutter and velocity adaptation?
[14:01:51] <les> Does he consider it an alias effect
[14:01:54] <les> ?
[14:01:55] <paul_c> three points work as long as they take six servo cycles or more to complete
[14:02:20] <les> for the ramps etc...
[14:02:32] <paul_c> stutter is limitations in communication speed...
[14:02:44] <les> really
[14:03:42] <paul_c> Don't confuse stutter (motion ID=0 ) with accel. jerks.
[14:04:00] <les> oh i'm not
[14:04:31] <paul_c> Some of those bangs were from tp
[14:04:36] <les> the stutter seems like a complete pause while something waits for something else
[14:05:46] <les> So is TP stack starvation the culprit in fred's view?
[14:06:44] <paul_c> there are two problems, tp queue starvation, and tp blending.
[14:07:28] <paul_c> One is fairly easy to fix, the other will take time.
[14:07:45] <les> starvation the easy one?
[14:09:29] <paul_c> starvation is the easier of the two (hopefully)
[14:09:58] <les> I should call Fred and get the skinny on this I guess
[14:10:27] <les> since you briefed him on the tests
[14:11:05] <paul_c> Fred is not in a position where he can devote much time to the problems
[14:11:20] <les> I figured
[14:11:36] <les> but a few minutes talk can sve a lot of typing
[14:11:41] <les> save
[14:12:10] <paul_c> about all we can expect from that quarter is quick & simple bug fixes.
[14:12:31] <paul_c> a new tp would have to be done ourselves.
[14:12:49] <les> I am curious about the seeming breakdown of velocity adaptation
[14:15:06] <paul_c> I suspect if we did another spiral of fixed segment length rather than angular, velocity adaptation would go to pot.
[14:15:28] <les> hmmm...ok
[14:15:58] <les> just angle changing
[14:17:44] <les> would a tp section on the wiki be of any use?
[14:18:43] <paul_c> not really...
[14:19:21] <les> as few are familiar with the problem and it's severity...
[14:20:19] <paul_c> and even fewer are familar with the math needed for a first class fix.
[14:21:08] <stevestallings> Granted few can understand the problem, but how do the few who might ever find out about it?
[14:21:53] <paul_c> Those that do know how to code a top notch tp are probably bound by NDAs
[14:22:14] <les> When we try to run modern speed programs steve
[14:22:22] <les> It's pretty obvious
[14:23:05] <les> What we saw would even trash things at BP aluminum or plastic speeds
[14:23:55] <paul_c> but then the test file was deliberately designed to be "nasty"
[14:24:25] <les> yes...but real
[14:24:51] <les> let's see we sarted at about .2 mm point spacing....
[14:24:56] <les> I think
[14:25:25] <paul_c> It was longer than that.
[14:25:44] <les> .01" points at 30 ipm?
[14:26:31] <les> oh BTW could you mail the file when you get a chance? we didn't put it on any box here
[14:26:34] <paul_c> I need to recover the data from that HD
[14:26:55] <anonimasu_> hm
[14:27:05] <stevestallings> Having reference samples of the test data so different people can run the same tests would be valuable in the future.
[14:28:06] <paul_c> stevestallings: Most of the test files that we were discussing were running anyting up to 20 metres/min
[14:28:18] <paul_c> or 1200ipm
[14:28:56] <les> but we ran tests at 60 or less
[14:29:13] <paul_c> I know.
[14:29:17] <les> and it did velocity adapt much lower than that
[14:29:24] <les> plus some feed over ride
[14:29:31] <stevestallings> That is fast, but my point is that comparisons of different code approaches are inpossible unless the test input data can be repeated.
[14:30:29] <paul_c> to be able to do valid comparisons, the test systems also need to be the same.
[14:30:59] <stevestallings> Perhaps this could be solved with "simulated hardware"?
[14:31:54] <les> During the SQ testing bad things did not seem to show up in some simulations
[14:32:17] <les> but that might be the different machine thing
[14:33:39] <les> I had done 200 microsecond servo update at one time in an old 150 M K6 box
[14:33:42] <les> barely
[14:33:51] <les> that was the lock up point
[14:34:13] <les> let's see we were using P3 500?
[14:34:29] <les> and got to what? 400 microsec?
[14:34:50] <stevestallings> If the PC's compute power and interrupt response time were infinitely better, would the current TP etc. work?
[14:35:53] <les> I think the stutter would go away but blending problems might still be there...
[14:36:25] <stevestallings> So it looks like we really have to different things to work on.
[14:36:32] <stevestallings> two
[14:37:19] <les> Well trapezoidal velocity profile planners with cubic sub interpolation is very crude by today's standards
[14:38:23] <les> SQ attempted a more modern multi point spline
[14:38:32] <stevestallings> Can we easily take incremental steps, like moving to S curve profiles?
[14:39:37] <les> Well as I see it the sub interpolation can be considered s-curve if the traj/servo period ratio is big
[14:39:43] <stevestallings> That and eliminating the TP starve would probably go a long ways.
[14:39:50] <les> It rounds the corners of the trapezoid
[14:40:06] <les> yes steve
[14:40:23] <les> TP starve ought to be first
[14:40:59] <les> Because that is not an issue of modern vs old technology...it's a complete breakdown
[14:41:55] <stevestallings> Refresh my memory.... does TP try to run all at once during a single servo cycle? Could this process be decoupled so it runs as an independent task that completes over multiple servo updates?
[14:42:27] <les> Every nth servo loop it runs
[14:42:50] <stevestallings> But, in the old code, it must complete withing one servo update period?
[14:42:59] <les> as far as the other paul would have to answer
[14:43:15] <stevestallings> Thus delaying the next servo update if TP takes too long.
[14:43:37] <les> No steve usually 10 or so srvo cycles/traj cycle
[14:44:04] <les> and it is RT (I think)
[14:44:11] <dave-e> that gets set in the ini ... right?
[14:44:38] <les> It can run at the same rate as servo....but there will be zero cubic blending
[14:44:46] <stevestallings> But it used to be part of one code thread and just skipped the TP code in all but one servo update cycle.
[14:44:48] <les> dave: right
[14:45:20] <stevestallings> Thus a long TP run would cause jitter in servo updates
[14:45:22] <les> steve: yeah I think that is what it does still
[14:46:04] <les> It might
[14:46:54] <les> I know the math...but not the code.
[14:48:18] <dave-e> when you change CPU's ... can you demostrate significant differences in performance?
[14:48:23] <les> And Paul is smartened up on the math as well...he spent some time here sitting on the porch reading robotics text with a cat and a chicken
[18:46:57] <alex_joni> that was one of my intermediate attempts
[18:47:02] <alex_joni> to create those files
[18:47:04] <alex_joni> but...
[18:47:10] <jmkasunich> probably not a bad idea
[18:47:11] <alex_joni> you need a .in file for those
[18:47:33] <alex_joni> jmk: when we finish working on kbuild
[18:47:51] <alex_joni> perhaps you want to take a look of the work I done in autoconf-install-0-1
[18:48:13] <jmkasunich> * jmkasunich does a checkout
[18:48:14] <alex_joni> I had an emc that worked pretty ok for me (the make install part)
[18:48:30] <alex_joni> but.. it's on hold for a few months ;)
[18:49:37] <jmkasunich> no such tag?
[18:50:05] <alex_joni> autoconf_install_0_1
[18:50:12] <alex_joni> was writing from memory
[18:50:54] <alex_joni> emc.run is created by configure
[18:51:05] <jmkasunich> ohhhh, slick
[18:51:31] <jmkasunich> do you create two of them, one for testing and one to install?
[18:51:34] <alex_joni> yup
[18:51:49] <alex_joni> and the install one already has all the paths where emc2 is getting installed
[18:52:08] <alex_joni> back in a bit
[18:52:12] <jmkasunich> ok
[18:55:29] <paul_c> How close are you to merging the lathe_fork interp in to head ?
[18:55:45] <alex_joni> re
[18:55:57] <jmkasunich> it's been in there a couple of weeks
[18:56:09] <alex_joni> what?
[18:56:16] <jmkasunich> the lathe fork interp
[18:56:22] <jmkasunich> merged to head
[18:56:50] <alex_joni> * alex_joni lost smthg on the way..
[18:56:56] <alex_joni> what are you talking about?
[18:57:33] <jmkasunich> paul asked when I was gonna merge the lathe-fork interpreter changes to HEAD
[18:57:37] <alex_joni> ahh
[18:57:44] <alex_joni> ok.. thought it was for me ;)
[18:58:19] <jmkasunich> that was done before the kbuild branch was started
[18:59:36] <anonimasu_> hello
[18:59:41] <jmkasunich> hi anon
[18:59:45] <alex_joni> hi anders
[19:00:53] <Imperator_2> Hmm, that msgcat module, i think it it part of the standard Tcl package ????
[19:01:09] <anonimasu_> alex_joni: we didnt come to a complete conclusion yesterday about the toolchanger..
[19:01:41] <alex_joni> I imagine ;)
[19:03:24] <jmkasunich> that's my cue to go looking for lunch
[19:03:43] <alex_joni> * alex_joni works on the makefiles
[19:03:56] <alex_joni> if anybody has an ideea about this.. he shall speak now
[19:04:16] <jmkasunich> about what? makefiles, or toolchangers?
[19:04:28] <alex_joni> makefiles ;)
[19:04:41] <jmkasunich> I think we're on the right path
[19:04:59] <anonimasu_> * anonimasu_ nods
[19:05:01] <Jymmm> alex_joni : when one runs make make, can you add a video poker?
[19:05:04] <jmkasunich> I'd like to get something that works correctly when compiled (no install)
[19:05:06] <jmkasunich> merge that
[19:05:18] <jmkasunich> then work on the install part in the branch
[19:05:19] <alex_joni> ok
[19:05:27] <jmkasunich> and merge again later when install is working right
[19:05:28] <alex_joni> that's what I said too
[19:05:43] <alex_joni> [21:47] <alex_joni> jmk: when we finish working on kbuild
[19:05:45] <jmkasunich> thought so, just makin' sure
[19:05:49] <alex_joni> [21:47] <alex_joni> perhaps you want to take a look of the work I done in autoconf-install-0-1
[19:06:19] <alex_joni> it keeps things apart
[19:06:25] <alex_joni> as they are supposed to be ;)
[19:07:33] <jmkasunich> * jmkasunich tries running emc2 on 4.20
[19:08:23] <jmkasunich> bummer
[19:08:35] <alex_joni> locked hard?
[19:08:42] <jmkasunich> no, not that bad
[19:08:58] <jmkasunich> just didn't load properly, gotta read the error messages and see what went wrong
[19:09:25] <alex_joni> * alex_joni checks out to a clean dir, and checks himself
[19:09:42] <anonimasu_> alex_joni: btw, I got that error once more today..
[19:09:50] <anonimasu_> alex_joni: where emc refuses to change mode..
[19:09:57] <anonimasu_> although it didnt show up in the debug..
[19:10:54] <alex_joni> an0n: file a bug report
[19:11:04] <alex_joni> using your cvs dev. name this time :D
[19:11:27] <jmkasunich> gawd... BDI-4.20 has about 30 modules loaded before emc starts!
[19:12:20] <alex_joni> there are some modules that are loaded by default
[19:12:26] <alex_joni> that can't be rmmoded
[19:12:31] <jmkasunich> a crapload
[19:12:32] <alex_joni> I noticed that too
[19:12:49] <jmkasunich> * jmkasunich has been thinking about building a kernel for this computer
[19:13:05] <jmkasunich> (been doing linux over 2 years, about time I made the leap)
[19:13:40] <Jymmm> jmkasunich : "Dont jump you'll kill yourself!"
[19:13:41] <alex_joni> heh
[19:13:48] <alex_joni> lol
[19:13:53] <alex_joni> use plug & pray instead
[19:14:17] <Jymmm> jmkasunich : "Think of the children! Won't someone PLEASE think of the children?!"
[19:14:17] <jmkasunich> why are all those "permanent" modules there anyway?
[19:14:43] <jmkasunich> sc1200, triflex, amd74xx, serverworks
[19:15:31] <alex_joni> * alex_joni forwards that question to paul_c
[19:17:18] <jmkasunich> interesting... my startup failed because of tcl problems too, but not the ones Martin reported
[19:20:58] <alex_joni> strange.. what err?
[19:21:16] <jmkasunich> <paul_c> feed uniformally spaced points down to the RT code, and run a cubic or quintic interpolator at servo rate
[19:21:19] <jmkasunich> oops
[19:21:30] <jmkasunich> strange, copy from shell window didn't work
[19:21:44] <jmkasunich> Application initialization failed: this isn't a Tk application
[19:21:47] <jmkasunich> that's better
[19:22:12] <alex_joni> hmmm
[19:22:12] <jmkasunich> also: Xlib: connection to ":0.0" refused by server
[19:22:36] <jmkasunich> there are several more lines
[19:23:15] <Imperator_> have installed some new tk and tcl packages
[19:23:41] <alex_joni> did you run su?
[19:23:47] <alex_joni> or sudo scripts/emc.run ?
[19:23:53] <alex_joni> because su fails on me too
[19:23:57] <jmkasunich> who, me or martin?
[19:24:03] <alex_joni> jmk
[19:24:15] <jmkasunich> yeah, su -c "scripts/emc.run"
[19:24:20] <alex_joni> try sudo
[19:24:26] <alex_joni> su seems to detach from the X-server
[19:24:40] <jmkasunich> it worked on BDI-TNG
[19:25:02] <jmkasunich> fscking changes.... grumble, grumble, mumble, mumble
[19:25:05] <alex_joni> well.. found out it doesn't on 4.20
[19:25:26] <alex_joni> I think it's XFree86 related, not smthg paul did (or didn't)
[19:25:30] <alex_joni> might be some security fix
[19:25:40] <alex_joni> not to allow some hijacked su to access X
[19:25:43] <alex_joni> or smthg like that
[19:25:56] <jmkasunich> perhaps... anyway, it led me to another problem
[19:26:15] <jmkasunich> "scripts/realtime stop" isn't properly unloading things
[19:26:19] <alex_joni> it compiles/runs cleanly on a fresh checkout
[19:26:24] <alex_joni> yup.. the rtai_up thing
[19:26:27] <alex_joni> same here
[19:26:46] <alex_joni> edit rtapi.conf and change ksched with up, and it works great
[19:26:47] <Imperator_> here also
[19:27:14] <alex_joni> well.. it should be consistent
[19:27:23] <alex_joni> as we all use the same distro/rtai/emc
[19:27:24] <alex_joni> ;)
[19:27:30] <jmkasunich> not so great
[19:27:58] <alex_joni> hmmm
[19:28:03] <alex_joni> seems I remembered it wrong
[19:28:14] <alex_joni> rtai_ksched is hardcoded into the rtapi Makefile
[19:28:23] <Imperator_> nope i have bdi4.18 and i have installed a new kernel 2.6.10 and rtai 3.2
[19:28:27] <jmkasunich> it's not the ksched/up thing
[19:28:40] <jmkasunich> <paul_c> feed uniformally spaced points down to the RT code, and run a cubic or quintic interpolator at servo rate
[19:28:43] <jmkasunich> fscker
[19:29:00] <alex_joni> I get:
[19:29:12] <jmkasunich> I can do a ctrl-C to copy from the shell, but when I do ctrl-V to paste here it pastes something I copied a long time ago
[19:29:12] <alex_joni> FATAL: Module rtai_hal is in use.
[19:29:28] <Imperator_> kill hal_lib
[19:29:29] <jmkasunich> but if I right click and paste, it pastes what I just copied
[19:29:37] <jmkasunich> the KDE clipboard is fscked
[19:29:41] <alex_joni> heh
[19:30:03] <alex_joni> Imperator_: hal_lib ?
[19:30:06] <jmkasunich> anyway, I did manually rmmod hal_lib
[19:30:07] <alex_joni> kill?
[19:30:18] <alex_joni> jmk: succeeded?
[19:30:26] <alex_joni> I wouldn't think so
[19:30:33] <alex_joni> rrmod rtai_up first
[19:30:35] <jmkasunich> then tried realtime stop, and it fails because hal_lib isn;t there
[19:30:47] <alex_joni> just try what I said
[19:30:57] <jmkasunich> NO
[19:31:06] <jmkasunich> (I'm being stubborn)
[19:31:08] <alex_joni> edit rtapi.conf and replace rtai_ksched with rtai_up
[19:31:20] <alex_joni> the problem is that rtai_ksched is a symlink ro rtai_up
[19:31:29] <jmkasunich> yeah, I know that
[19:31:31] <alex_joni> if you recall we already talked about this a while back
[19:31:42] <jmkasunich> but it should remove everything up to that point
[19:32:00] <jmkasunich> it seems to be stopping because it can't find hal_lib, and isn't removing anything else
[19:32:21] <alex_joni> hal_lib ????
[19:32:28] <alex_joni> or rtai_hal ?
[19:32:33] <alex_joni> don't mix those
[19:32:38] <jmkasunich> IM(NS)HO, realtime should remove the realtime stuff, even if part of ot has already been removed - if not it's broke, and I'm gonna fix it
[19:32:48] <alex_joni> I agree on that
[19:32:57] <jmkasunich> "FATAL: Module hal_lib not found."
[19:33:01] <Imperator_> * Imperator_ is a winner !! (on ebay)
[19:33:02] <alex_joni> ahhh
[19:33:13] <alex_joni> jmk: yes that's another thing
[19:33:13] <jmkasunich> what didja win
[19:33:24] <alex_joni> I was talking about the rtai_up thing
[19:33:26] <Imperator_> http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=7514543334
[19:33:58] <alex_joni> realtime stop .. should check why a module can't get unloaded
[19:34:07] <alex_joni> and maybe unload dependencies aswell
[19:34:12] <alex_joni> or at least report them
[19:34:31] <alex_joni> and definately go on if a module is missing
[19:35:16] <jmkasunich> that's modprobe for you...
[19:35:39] <alex_joni> heh
[19:35:47] <jmkasunich> it is called with the list of modules in reverse order... under 2.4, it would remove any modules on that list, and ignore any that weren't loaded
[19:36:01] <jmkasunich> under 2.6, if any module on the list isn't loaded, it quits right there
[19:36:21] <jmkasunich> why the fsck did they have to go and change that
[19:36:28] <alex_joni> I did get that error even 2 or 3 times, so I think it goes on
[19:36:42] <alex_joni> lemme check
[19:39:21] <Imperator_2> i think it is going on removing the modules, but it can't because of the dependencys
[19:39:39] <jmkasunich> it's just fscked
[19:39:58] <jmkasunich> I insmoded hal_lib, then did "modprobe -r hal_lib"
[19:40:06] <jmkasunich> and it reported 6276 0 [permanent]
[19:40:06] <jmkasunich> sis5513
[19:40:16] <jmkasunich> not that... pasting screwed again
[19:40:27] <jmkasunich> FATAL: Module hal_lib not found.
[19:40:37] <jmkasunich> but lsmod says hal_lib is loaded
[19:40:57] <jmkasunich> and rmmod can unload it no problem
[19:40:57] <Imperator_2> and with rmmod i can kill it easily
[19:41:23] <alex_joni> modprobe -r hal_lib works here
[19:46:46] <Imperator_2> modprobe fails, only rmmod can kill the hal_lib
[19:47:26] <alex_joni> how do you call modprobe?
[19:47:28] <alex_joni> as root?
[19:47:30] <alex_joni> or sudo?
[19:47:55] <jmkasunich> su -c "modprobe -r hal_lib"
[19:48:27] <jmkasunich> alex: did you run depmod?
[19:48:46] <jmkasunich> and did you install the modules, or are they in the compile directory?
[19:49:09] <alex_joni> hmm.. I think I also installed them
[19:49:28] <Imperator_> as root
[19:49:37] <alex_joni> that can be it
[19:50:23] <Imperator_> also the rtai modules are in /usr/realtime/modules depmod don't know them
[19:50:26] <jmkasunich> modprobe is trying to be smart... it's looking in it's depmod database, can't find hal_lib, so it won't even look at the kernel to see if it is loaded
[19:50:41] <jmkasunich> rmmod is dumb, it just does what I tell it - remove the damn module
[19:50:50] <jmkasunich> I hate programs that try to be smart
[19:51:15] <Imperator_> intelligent system :-)
[19:51:33] <jmkasunich> this is pretty pathetic - Linux is starting to look more and more like winblows
[19:52:06] <jmkasunich> databases, and registries, and all this hidden stuff that tries to make life easier, but only when you do exactly what the database designer had in mind
[19:52:15] <Imperator_> it's also only a OS, it goes the same way
[19:52:25] <alex_joni> * alex_joni can confirm it now
[19:52:54] <alex_joni> yet.. rmmod hal_lib does work
[19:53:06] <alex_joni> opposed to modprobe -r which doesn't
[19:53:27] <jmkasunich> because rmmod isn't trying to be smart... it's not looking at some dependency database, it's just doing what we tell it - remove the damn modules
[19:54:22] <alex_joni> motmod is to be used with modules in /lib/modules/ only
[19:54:26] <alex_joni> modprobe
[19:54:29] <alex_joni> damn ;)
[19:55:01] <jmkasunich> * jmkasunich is going to rewrite the realtime script to use insmod and rmmod only
[19:56:35] <Imperator_> why does it work on 2.4 ???
[19:56:45] <alex_joni> modprobe is different
[19:56:46] <alex_joni> ;)
[19:56:58] <jmkasunich> because on 2.4 modprobe wasn't as "smart"
[19:57:12] <alex_joni> or.. it was smarter
[19:57:18] <alex_joni> depends on the point of view :D
[19:59:06] <jmkasunich> from "man modprobe" on 2.6: "modprobe intelligently adds or removes a module from the Linux kernel"
[19:59:16] <alex_joni> yeah
[19:59:23] <jmkasunich> man modprobe on 2.4 doesn't say anything about "intelligently"
[19:59:23] <alex_joni> can't argue with that
[19:59:24] <alex_joni> :D
[20:00:57] <Imperator_> maybe we send a mail to the developers of modprobe
[20:01:23] <jmkasunich> waste of tome... they are doing what they think is right
[20:01:28] <Imperator_> or should rtai put the modules in /lib/modules
[20:01:50] <jmkasunich> they probably will say "you shouldn't load modules that aren't in /lib/modules and don't have entries in our database"
[20:02:10] <Imperator_> maybe they a right
[20:02:13] <alex_joni> jmk: what's .PHONY used for?
[20:02:20] <alex_joni> the one in Makefile
[20:02:48] <jmkasunich> I used to know. but I'm fuzzy on it now, would have to look at the online make manual
[20:03:05] <alex_joni> never mind
[20:03:10] <alex_joni> I'll look myself
[20:03:16] <jmkasunich> I think it tells make that a target like "clean" is just an internal thing, there is no file called clean
[20:03:23] <anonimasu_> hm
[20:03:50] <jmkasunich> without phony, if you had a file called clean, and it was newer than anything make thought was a dependency for the clean target, then make clean would do nothing
[20:04:18] <alex_joni> I see
[20:04:37] <alex_joni> do I need to add modules to the list of PHONY?
[20:04:48] <jmkasunich> probably
[20:04:51] <alex_joni> ok
[20:05:16] <jmkasunich> it's one of those obscure things... unless you have a file called modules in the same dir it makes no difference
[20:07:02] <alex_joni> jmk: there is one more thing
[20:07:13] <alex_joni> in emc.ini .. do yu have emc.gif as intro graphic?
[20:07:13] <jmkasunich> yes?
[20:07:20] <alex_joni> you even
[20:07:36] <jmkasunich> I don't think so, I've never seen it pop up
[20:07:37] <alex_joni> I need to update that to reflect emc2.gif
[20:07:50] <jmkasunich> I think I still have the popup disabled
[20:07:53] <alex_joni> because emc.gif doesn't exist (emc2.gif does)
[20:08:53] <jmkasunich> yeah, it still says emc.gif here
[20:09:13] <alex_joni> well.. it's actually emc2.gif (I'll commit to emc2 HEAD)
[20:09:31] <alex_joni> and one more thing, I had a typo in emc.run for the popimage path
[20:09:50] <alex_joni> fixed it in HEAD, didn't bother to bring it to kbuild :)
[20:10:14] <jmkasunich> no need, that will get handled when I do the merge
[20:10:25] <alex_joni> yeah.. that's why I didn't
[20:10:34] <jmkasunich> changes from kbuild will merge to HEAD, and I'll also merge changes from HEAD to kbuild
[20:10:51] <jmkasunich> in fact it makes things more compilcated if the same change is done in both
[20:11:17] <alex_joni> ok..
[20:12:44] <alex_joni> jmk: anything agains including the kclean to def_clean ?
[20:12:54] <alex_joni> against
[20:13:40] <alex_joni> in Make.rules I mean
[20:13:44] <jmkasunich> Makefiles in directories that have no kernel modules don't have kclean
[20:14:01] <alex_joni> yup.. that will cause rm *.ko to fail quietly
[20:14:05] <jmkasunich> (but does that matter? I dunno)
[20:14:19] <jmkasunich> oh, that reminds me
[20:14:21] <alex_joni> I'll leave it with kclean for no
[20:14:22] <alex_joni> now
[20:14:28] <jmkasunich> gotta check something first
[20:15:12] <jmkasunich> kclean (at least in the rtapi makefile) does rm .o
[20:15:28] <alex_joni> yes
[20:15:33] <jmkasunich> why is that? it would delete foo.old, which might just be something I didn't want deleted
[20:15:45] <alex_joni> you wouldn't have any foo.o in that dir
[20:15:54] <alex_joni> at least not accordingly to the Makefile
[20:16:01] <jmkasunich> that's not it
[20:16:06] <alex_joni> older foo gets built in RTTMP or RTLIB
[20:16:10] <jmkasunich> dammit, irc changed what I typed
[20:16:39] <jmkasunich> the makefile has <star>.o<star> (IRC didn't show the stars)
[20:16:45] <alex_joni> ahhh
[20:16:52] <alex_joni> I see what you mean
[20:16:54] <jmkasunich> so it doesn't just delete foo.o, it deletes foo.old
[20:17:13] <alex_joni> that's because of .o.cmd
[20:17:13] <anonimasu_> well, why not change it to *.o
[20:17:17] <jmkasunich> is that on purpose for some reason, or a typo?
[20:17:18] <alex_joni> I'll change it
[20:17:35] <jmkasunich> change it to star.o.star
[20:17:46] <anonimasu_> unless it has the purpose of rmoving *.o*
[20:17:55] <jmkasunich> testing: foo .foo. *.foo
[20:18:21] <anonimasu_> ah you run a sensible irc client ;)
[20:18:32] <jmkasunich> huh... stars on both sides of something get deleted and used to bold it
[20:18:36] <anonimasu_> yeah..
[20:18:59] <jmkasunich> sensible until you try to type <star>.o<star> and the client changes your message
[20:19:11] <jmkasunich> another case of a program trying to be smart
[20:19:14] <anonimasu> \*.o.*
[20:19:15] <anonimasu> \*.o.\*
[20:19:17] <anonimasu> heh
[20:19:21] <anonimasu_> escape em ;)
[20:19:26] <jmkasunich> test: \*.o\*
[20:19:32] <anonimasu> **.o.**
[20:19:35] <anonimasu_> nope..
[20:19:41] <anonimasu> *.o.*
[20:19:42] <jmkasunich> test: **.o**
[20:19:47] <anonimasu> *test*
[20:19:50] <anonimasu> hm strange
[20:19:52] <jmkasunich> test
[20:20:29] <jmkasunich> this is ksirc on 2.6 (BDI-4)
[20:20:33] <alex_joni> *test*
[20:20:39] <anonimasu_> I run irssi or mirc at the desktop
[20:20:39] <alex_joni> mirc here
[20:20:40] <jmkasunich> the ksirc on BDI-TNG doesn't do that
[20:20:53] <jmkasunich> I noticed it before for underscores
[20:20:56] <jmkasunich> foo
[20:21:03] <jmkasunich> \_foo\_
[20:21:12] <jmkasunich> \_foo_ bar
[20:21:20] <paul_c> jmkasunich: Got a couple of tweaks for the interp...
[20:21:39] <jmkasunich> you should be able to stick em in HEAD
[20:21:40] <Jymmm> reversed
[20:22:36] <Jymmm> 4Red8Yellow7Orange
[20:22:53] <alex_joni> stop that :)
[20:23:09] <Jymmm> alex_joni : Hey jmkasunich started it!
[20:23:13] <anonimasu_> argh, please think of my eyes
[20:24:07] <alex_joni> jmk: I think it's .o that's needed
[20:24:18] <alex_joni> not *.o.*
[20:24:26] <jmkasunich> ok by me
[20:24:44] <jmkasunich> you want to change it, since your in the makefiles anyway?
[20:25:07] <alex_joni> yes
[20:25:12] <jmkasunich> thanks
[20:31:21] <jmkasunich> ok, got the modprobe -r thing fixed, now is there a better way to deal with the ksched->up thing?
[20:31:37] <alex_joni> hmm...
[20:31:54] <CIA-4> 03paul_c * 10emc2/src/ (8 files in 2 dirs): PI and friends are defined in much higher precision in math.h - We can use them as long as _GNU_SOURCE is defined prior to including math.h
[20:31:54] <paul_c> That will improve the precision of some of the math....
[20:32:37] <alex_joni> https://mail.rtai.org/pipermail/rtai/2004-June/007769.html
[20:32:56] <anonimasu_> * anonimasu_ nods
[20:38:19] <alex_joni> stop nodding
[20:38:25] <alex_joni> it'll hurt your neck ;)
[20:38:39] <Jymmm> alex_joni : Ever see 'Chico and the man'?
[20:38:49] <alex_joni> think so
[20:39:02] <alex_joni> can't remember
[20:39:05] <Jymmm> alex_joni : lil dog in the back of the car?
[20:39:20] <alex_joni> I know those dogs ;)
[20:39:24] <Jymmm> alex_joni heh
[20:42:05] <Jymmm> alex_joni : Even Charo was in it.
[20:42:24] <Jymmm> and Della Reese
[20:42:32] <alex_joni> pedro?
[20:42:53] <Jymmm> Yes, pedro is spanish for dog
[20:42:56] <alex_joni> no wait, that's De La Rosa
[20:42:57] <alex_joni> :D
[20:45:07] <CIA-4> 03alex_joni 07kbuild-0-1 * 10emc2/src/ (10 files in 10 dirs): cleaned the Makefiles a bit, fixed the rm *.o* issue
[20:46:14] <alex_joni> * alex_joni leaves for a bit
[20:46:21] <alex_joni> alex_joni is now known as alex_joni_away
[20:47:24] <Jymmm> You know on most gantry routers they'll make X (longest) axis part of the base, can anyone think of a reason not to mount X on the gantry itself instead?
[20:47:26] <alex_joni_away> jmk: seems ksched should get replaced by up
[20:47:43] <jmkasunich> unless you have a smp box
[20:48:06] <alex_joni_away> ./configure to figure that out?
[20:48:15] <alex_joni_away> check what ksched symlinks to?
[20:48:33] <jmkasunich> that's what I'm thinking, configure can generate rtapi.conf with the list of modules
[20:48:36] <alex_joni_away> but.. rtai_ksched can be changed at anytime ... :(
[20:48:54] <alex_joni_away> or at least have the Makefile take the info from Makefile.inc
[20:48:59] <jmkasunich> BTW, once BDI-4.21 comes out, I will have an SMP machine here...
[20:49:04] <alex_joni_away> heh
[20:49:30] <jmkasunich> althought it's not physically part of the compile farm, I might just run the far scripts on it, treat it as slot 9 or something
[20:49:36] <jmkasunich> so we can test on SMP
[20:52:04] <alex_joni_away> jmk: how about:
[20:53:27] <alex_joni_away> mod=`ls -l $rtai_moddir/rtai_$mod$modext|sed -e "s,.* \-> -*rtai_\([a-z0-9A-Z]*\)$modext.*,\1,"`
[20:53:54] <alex_joni_away> replace the symlink with the target name
[20:55:23] <jmkasunich> sed-fu!
[20:55:42] <jmkasunich> I was hoping to use readlink, but it isn't installed on BDI-2.xx
[20:55:48] <alex_joni_away> rtai-load uses this
[20:55:58] <alex_joni_away> they might have a reason for doing it
[20:55:59] <alex_joni_away> :D
[20:56:01] <jmkasunich> that's encouraging
[20:56:05] <alex_joni_away> I'll be back in 20 mins
[20:56:15] <jmkasunich> sed-fu can get tricky, cause not all ls -l have the same format
[20:58:26] <Imperator_> Jymmm: how do you mean
[20:59:17] <Imperator_> X should be the main axis, not the longest
[21:03:48] <jmkasunich> hi ray
[21:03:59] <rayh> Hi John.
[21:04:17] <rayh> Just starting to unload the car. Had to make room on the shelves.
[21:04:23] <steve_away> steve_away is now known as steve_stallings
[21:04:24] <jmkasunich> lol
[21:05:18] <rayh> How did the discussion about tp come out this morning?
[21:05:20] <jmkasunich> that reminds me... hey steve!
[21:05:29] <steve_stallings> hey John
[21:05:49] <jmkasunich> rayh: went on for a while, very interseting... eventually petered out
[21:05:53] <Jymmm> Imperator_ let me see if I can find a picture
[21:06:16] <steve_stallings> feeling better now, played with backhoe, pulled out old split rail fence
[21:06:27] <jmkasunich> steve: you have one of the linear motors, right?
[21:06:42] <steve_stallings> got one from you at fest
[21:06:51] <jmkasunich> I have some cables that mate to it including the high power D-shell with 4 fat pins
[21:07:17] <jmkasunich> and I also have a little box from Anorad that I think is an interpolator for the sine/cosine dignals from the encoder
[21:07:29] <jmkasunich> it's labeled SQ Logic I think
[21:07:33] <steve_stallings> great, hang on to them and any docs that show up on the power drivers, etc.
[21:07:46] <jmkasunich> the whole thing isn't large, I was gonna ship to you (only a couple lbs)
[21:08:13] <Jymmm> Imperator_ : Ok, see how X axis is on the base of the machine? Instead of putting X axis on the base, put the Y axis on the base, and place the X axis on the gantry. The idea being that you would have a (lets say) a 4 foot wide gantry and can use it as a pass-thru for longer stock.
[21:08:17] <Jymmm> http://www.hobbycnc.com/plans/RouterSide1_Small.jpg
[21:08:34] <steve_stallings> perhaps I will make it to the CNC show at Roland's place, you going?
[21:08:48] <jmkasunich> don't think so.. but who knows...
[21:09:17] <steve_stallings> my ride share fell through, so if I go I may be flying
[21:09:27] <jmkasunich> Jymmm - one reason people use the gantry for the short axis is that long gantries are more flexible (bendy)
[21:09:59] <jmkasunich> also, if the gantry (rather than the table) moves, then you have to move more weight
[21:10:27] <Jymmm> jmkasunich : Well, I was thinking I could easily re-enforce the 'mounting plates' to give it rigidity
[21:10:38] <jmkasunich> first because long axis are heaver than short ones, then made worse because you have to make the long axis thicker to stiffen it up, which adds even more weight
[21:11:15] <jmkasunich> long gantry makes more sense if the table moves, then you can make the
[21:11:22] <jmkasunich> gantry as heavy as you need
[21:12:04] <Imperator_> thats a portal machine
[21:12:16] <Imperator_> if i translate it right
[21:12:27] <Jymmm> jmkasunich Ah, didn't consider moving table into the picture.
[21:12:38] <jmkasunich> problem with moving table is it takes more space
[21:12:41] <Jymmm> jmkasunich nor the added weight
[21:12:54] <jmkasunich> 4 foot travel needs an 8 foot long space if the table moves
[21:13:12] <Imperator_> even more
[21:13:23] <jmkasunich> right - 8 feet minumum
[21:13:48] <Imperator_> but stiffnes is **much** better
[21:14:23] <rayh> TonyP built a bridge or portal for routing. Looked really nice.
[21:14:30] <Jymmm> well, toss that idea out the door =)
[21:14:43] <Jymmm> (x on gantry that is_
[21:14:45] <Jymmm> )
[21:14:58] <rayh> The X axis drooped on the ends.
[21:15:15] <jmkasunich> was X the table?
[21:15:26] <rayh> But when it was pulled under the y and z it was always in place.
[21:15:28] <jmkasunich> or the bridge
[21:15:34] <Imperator_> rayh: can you add your ideas about the tool changer to the wiki page
[21:15:41] <rayh> yes X was the table that slid.
[21:15:59] <rayh> I will do that Martin. I didn't want to mess up your nice page.
[21:16:20] <Jymmm> Heh, I'm still leary about using 3/4" drillrod for the rails (thinking it won't be strong enough.
[21:16:35] <Jymmm> @ 4'
[21:17:40] <Imperator_> rayh: add a "suggestion 2" if it is very different from the first one
[21:17:58] <jmkasunich> not unless you can sypport it at several spots along the rod
[21:17:59] <rayh> Tony's machine was built with small thompson rail and a plate of aluminum.
[21:18:06] <rayh> for X
[21:18:59] <Jymmm> jmkasunich les suggested 2 supports in the middle
[21:19:17] <Jymmm> so basically a support every 12"
[21:19:31] <alex_joni_away> alex_joni_away is now known as alex_joni
[21:19:34] <alex_joni> iab
[21:19:34] <jmkasunich> with C shaped slides that can clear the supports?
[21:19:43] <Jymmm> jmkasunich yeah
[21:20:05] <alex_joni> hello rayh
[21:20:21] <rayh> Imperator_: I'll report on the integration of tcl and the Hardinge Lathe.
[21:20:26] <rayh> Hi Alex.
[21:20:41] <rayh> Great crowd here today.
[21:20:47] <alex_joni> * alex_joni won't be around very long
[21:20:50] <Jymmm> jmkasunich : I just haven't figured out how to make "adjustable supports" yet =)
[21:20:58] <alex_joni> gotta go to a customer tomorrow morning pretty early :)
[21:21:49] <Imperator_> * Imperator_ has two weeks holiday
[21:22:16] <steve_stallings> dang customers, they always want something for their money 8-)
[21:22:24] <alex_joni> yeah..
[21:22:32] <rayh> ain't that the truth.
[21:22:48] <Imperator_> work for the goverment
[21:23:39] <Imperator_> then you do something for two years, and then you say it is not possible, but thanks for the money
[21:23:53] <Imperator_> :-)
[21:24:12] <alex_joni> lol
[21:24:26] <steve_stallings> then you get to write endless proposals to to get the next grant 8-(
[21:24:44] <steve_stallings> I hate writing even more than working
[21:25:06] <Imperator_> same here
[21:26:51] <alex_joni> ditto
[21:27:17] <anonimasu_> * anonimasu_ yawns
[21:27:33] <alex_joni> at least he didn't nod
[21:27:38] <alex_joni> LOL
[21:30:43] <asdfqwega> logger_aj, bookmark
[21:30:43] <asdfqwega> See http://193.226.12.129/irc/irc.freenode.net:6667/emc/2005-05-15#T21-30-43
[21:36:45] <jmkasunich> rayh, paul_c, you guys awake?
[21:39:07] <rayh> Yep. working on describing tool change
[21:39:29] <rayh> Don't see Paul about.
[21:39:36] <jmkasunich> can you join the board channel for a couple mins?
[21:39:43] <rayh> You bet.
[21:51:11] <weyland> jmkasunich: Hey John - baq from testing
[21:51:21] <jmkasunich> hi weyland
[21:51:42] <weyland> Well... I tried different power outlets for the various parts of the system
[21:51:46] <weyland> No love
[21:52:09] <weyland> So, I tried using a "stick font" to reduce the moves in number
[21:52:15] <weyland> better, but not great
[21:52:24] <weyland> so I removed all BL
[21:52:41] <weyland> and, while not great, it was GREATLY better
[21:52:58] <weyland> I'd have to say that it's DEFINITELY a problem with the BL comp
[21:53:09] <jmkasunich> that's what I was afraid of
[21:53:18] <weyland> Now, having said that...
[21:53:32] <jmkasunich> probably the best bet in the short term is for me to restore the original code, wrapped in an ifdef so you can compile either way
[21:53:41] <jmkasunich> and document the problems with both approaches
[21:53:51] <weyland> I'd be more than happy to try any other tests if you'd like
[21:53:53] <daryl> Would it be worth putting a caliper on the table and running a script to move back and forth many many times to check no steps are lost with BL off?
[21:53:57] <weyland> but I'm thinking you're right
[21:53:59] <jmkasunich> I have a feeling one approach is better for some machines, and the other is better for others
[21:54:36] <weyland> daryl: I've actually done something similar already
[21:54:52] <weyland> it's looking like it's definitely in the BL comp
[21:55:20] <weyland> jmkasunich: okay
[21:55:23] <daryl> Bummer.
[21:55:39] <daryl> Well, I guess that's better than not knowing why. :)
[21:55:47] <weyland> jmkasunich: let me know when I can update my install, and I'll try it and report back
[21:56:06] <jmkasunich> gonna be a day or two (I hope that doesn't screw you too badly)
[21:56:44] <weyland> I'm gnawing at the bit, but need it working correctly, so if it's a day or two, it's a day or two
[21:57:11] <weyland> have a few frames I need to make anyway
[21:57:47] <weyland> I posted it as a bug, too.
[21:57:54] <jmkasunich> saw that
[21:58:03] <weyland> hope I worded it correctly
[21:59:26] <alex_joni> well.. gnight guys
[21:59:30] <alex_joni> laters
[22:01:51] <rayh> See you Alex.
[22:23:08] <Jymmm> Oh man.... http://geckodrives.com/ycom/documents/C163R22_spiral.wmv
[22:24:05] <anonimasu_> what's that?
[22:24:26] <Jymmm> URL == Uniform Resource Locator
[22:25:44] <les> nice polygon.
[22:27:58] <anonimasu_> yeah but what does it show?
[22:28:03] <anonimasu_> g200x
[22:28:03] <anonimasu_> ?
[22:28:13] <les> g100 it's called now
[22:28:24] <anonimasu_> hm ok
[22:28:24] <steve_stallings> Mariss did it to demo hardware pulse generation of G200x
[22:29:03] <les> I was just on the camsoft site a bit
[22:29:10] <les> yuck for the price
[22:29:18] <les> $200-$5500
[22:29:22] <anonimasu_> for what?
[22:29:28] <anonimasu_> cam program?
[22:29:29] <les> 2000
[22:29:36] <les> no machine control
[22:29:56] <anonimasu_> changing from emc?
[22:30:05] <anonimasu_> hm not too bad actually
[22:30:08] <les> camsoft/galil is the cheapest reasonbly modern control out there
[22:30:41] <les> 62 microsecond servo update
[22:30:48] <anonimasu_> fanuc quoted me at 8000 for the control..
[22:30:59] <les> about $4000 total
[22:31:05] <les> card and software
[22:31:14] <les> for 3 axis
[22:31:29] <anonimasu_> and 3000$ per axis..
[22:31:33] <les> about $7000 for 5 axis
[22:31:39] <anonimasu_> for their smallest control....
[22:32:02] <anonimasu_> yep adds up quickly
[22:32:40] <anonimasu_> * anonimasu_ sighs
[22:32:42] <les> My only hope for a cnc product was to make that cost go away
[22:32:57] <anonimasu_> that g200x movie was awesome..
[22:33:08] <les> We have the iron
[22:33:16] <les> but not the control
[22:33:27] <steve_stallings> Les, tried Ajax (Centroid)? http://ajaxcnc.com/features_specs.htm
[22:33:45] <les> yeah I have looked at ajax
[22:33:56] <daryl> les.. you thinking of selling cnc machines?
[22:34:01] <les> not good enough for a router
[22:34:10] <les> daryl: yes
[22:34:22] <les> very much
[22:34:39] <steve_stallings> They claim 600 blocks/second, was the servo loop slow?
[22:34:50] <daryl> You looking at steppers or servos?
[22:35:52] <anonimasu_> hm
[22:35:54] <anonimasu_> actually
[22:35:57] <les> I want to have a servo machine...24"x24", 500ipm, wood, plastic ,and light metal with .001" repeatability
[22:35:58] <anonimasu_> ajaxcnc looks good..
[22:36:06] <les> AND
[22:36:14] <les> under $10,000
[22:36:25] <Jymmm> les < $1,000 USD
[22:36:32] <les> ha
[22:36:47] <anonimasu_> I like the online programming stuff..
[22:36:48] <les> We have the iron.
[22:36:55] <les> We have no control.
[22:37:33] <daryl> Is emc fast enough?
[22:37:41] <les> not even close
[22:38:09] <les> not a matter of fast though
[22:38:27] <rayh> * rayh adds a cautionary bs...
[22:38:50] <daryl> ?
[22:38:53] <les> ?
[22:38:57] <les> heh
[22:39:05] <anonimasu_> ?
[22:39:59] <les> ahem we're all eyes ray
[22:40:38] <rayh> I can't explain why Les's machine behaves the way it does.
[22:40:58] <les> heh
[22:41:03] <rayh> I have no understanding of the maths that go into tp or blending
[22:41:35] <rayh> I was told this morning that there was g code out there that would act badly
[22:41:40] <rayh> at bridgeport speeds.
[22:41:51] <rayh> I've done bridgeport speeds
[22:42:09] <daryl> I'm new to this: 2q's: How does les's machine behave? What's blending?
[22:42:15] <rayh> I've done 3.5 hour contouring that involved 0.0002 motions in z
[22:42:29] <rayh> and have not found emc to be deficient.
[22:43:08] <les> Well we got TP stack starvation at 50 pts/sec
[22:43:27] <les> I wish it was not deficient
[22:43:35] <rayh> And I've never seen it.
[22:44:01] <les> Fred has run the machine and said it is TP/TC
[22:44:01] <rayh> I can not explain or even point at the part of the code that is responsible for your problems.
[22:44:16] <les> one question: are you running full servo?
[22:44:25] <rayh> I've not tried to run it of late on a < 300 proc but
[22:44:40] <rayh> Yes. On many of the tests I've pointed to.
[22:45:20] <les> so you have a full servo (stg or similar) BP....
[22:45:23] <rayh> I've used SRG1, and more recently Motenc
[22:45:30] <les> we need to get you the test program
[22:45:30] <rayh> STG
[22:45:47] <paul_c> les: Ray has a copy.
[22:45:48] <les> did Paul mail it to you?
[22:45:54] <les> oh haha
[22:45:56] <les> k
[22:45:59] <rayh> But I see the servo v stepper as a red herring.
[22:46:19] <rayh> cause be are long past the tp and blender when we make pulses.
[22:47:04] <rayh> 'And we are starving the pc worse with pulse generation than we are with servo.
[22:47:08] <les> I would think so...but the pulse generator might be a low pass filter....I don't know
[22:47:27] <rayh> JonE has been running bpt speeds on a bpt since 97 or so.
[22:47:48] <les> well motionid=0 is kinda telling
[22:47:59] <jmkasunich> it depends on the kind of parts you make
[22:48:38] <jmkasunich> I expect that the spiral program will kill Jon's machine as bad as it does Les's
[22:48:51] <jmkasunich> and if not, I could write one that would
[22:49:11] <anonimasu_> night everyone
[22:49:18] <rayh> Catch you later.
[22:49:35] <les> Well Jon runs velocity mode...so an extra integrator...lower bandwidth....
[22:49:43] <les> but the stutter will happen
[22:50:02] <jmkasunich> right - I was talking about the stutter
[22:50:06] <rayh> No jon's bpt is full servo using his amps and tach feedback.
[22:50:16] <rayh> Lets not run to assumptions here.
[22:50:22] <les> funny it is kind of random when it starts
[22:50:24] <jmkasunich> that's what Les means by velocity mode ray
[22:50:29] <les> not periodic at all
[22:50:45] <Jymmm> heh... http://www.protobyte.com/prodrive2000.htm
[22:51:08] <Jymmm> les there ya go les... cheap drives ^^^^^^^^^^^^
[22:51:30] <rayh> And Les is not using tach feedback.
[22:51:34] <Jymmm> Oh, btw... http://geckodrives.com/whyg201.htm
[22:51:42] <jmkasunich> I wonder if that's the guy that ripped off the gecko design
[22:52:01] <steve_stallings> yep
[22:53:14] <les> Ray, current mode with an encoder is the norm for cnc these days
[22:53:38] <les> tachs were used as well long ago when processing power was so limited
[22:53:43] <rayh> I don't mean to troll you less but there are many ways to do these things yet.
[22:53:51] <steve_stallings> Ray, didn't you just install Jon's PWM system on the Hardinge. It runs torque mode with encoders only, right?
[22:54:10] <rayh> I also realize that Mazak switched to some rather tiny steps on it's encoders to handle
[22:54:24] <rayh> velocity computation from digital inputs.
[22:54:54] <rayh> I did make the decision to run Jon's pwm on the hardinge.
[22:55:01] <les> There is a nice video TV show on the Galil site
[22:55:06] <les> the math is right
[22:55:11] <rayh> I also spent a day tuning that system.\
[22:55:12] <les> have a look sometimes
[22:55:27] <rayh> Way different from what Jon was doing.
[22:56:19] <rayh> I was really confused because his system was not honoring [TRAJ] max vel.
[22:56:19] <rayh> or max accel
[22:56:26] <steve_stallings> Had Jon ever had his system on a high mass machine?
[22:56:39] <rayh> I don't know.
[22:57:08] <rayh> I added max accel and max vel on a per axis basis and did get those things working properly.
[22:57:35] <les> Anyway, my configuration just does what it's told...A linear G1 or arc G2 or G3 is executed fast smoothly, and silently (unless the spindle is on)
[22:57:36] <steve_stallings> Not honoring, or just not in the .ini ?
[22:57:37] <rayh> But then the huge numbers he had in PID and the FF's didn't make any sence.
[22:58:32] <les> PID numbers sometimes need to be big depending on amp gain
[22:58:41] <rayh> No matter what accel I put in traj it always came out the same.\
[22:59:00] <les> current limit?
[22:59:17] <rayh> yes I can see that Les but the pwm boards do not have onboard gain.
[22:59:33] <les> hmmm
[22:59:42] <rayh> That will certainly add an additional degree of tuning uncertainty.
[23:01:15] <rayh> Once I got the Hardinge accel up where i wanted it, the other numbers fell into place
[23:01:19] <rayh> rather easily.
[23:01:31] <les> well 0-100 duty cycle in should be 0- max velocity
[23:01:42] <les> if a velocity amp
[23:01:43] <steve_stallings> If I understand Jon's boards, they receive a digital command in PWM that is the output from EMC. The PWM is not translated into a variable current limit, only duty cycle. This would make it some sort or hybrid voltage equiv after filter.
[23:01:45] <rayh> p only and turn it down until run away.
[23:02:22] <weyland> 3
[23:02:25] <weyland> oops
[23:02:37] <weyland> later boyz
[23:02:55] <les> I should mention that if you use PID on a cascaded velocity loop it will make a potentially unstable fourth order system
[23:03:14] <les> just use P
[23:03:38] <rayh> I had some of those issues with rutex.
[23:04:34] <Jymmm> DISCOVERY CHANNEL - 'Brian Man' (right now)
[23:04:34] <Jymmm> Brain
[23:04:36] <rayh> I'd much rather connect a raw power amp to emc than twiddle several layers of competing pid
[23:05:36] <les> In normal torque mode if there is a position error like stick slip it pushes harder.
[23:05:56] <les> In velocity/position cascaded mode it tries to go faster.
[23:06:01] <les> big difference
[23:06:37] <rayh> does seem like it.
[23:06:43] <jmkasunich> except that if stick-slip makes it slow down the (much faster) velocity loop should correct for it before the slower position loop winds up
[23:07:37] <rayh> How about sending me your ini file, Les?
[23:07:51] <les> it is on the site
[23:08:00] <les> lmwatts.com
[23:08:03] <jmkasunich> * jmkasunich is used to industrial motor control, not servo control... a factor of at _least_ 3:1 and usually 5: 1 or better between position loop BW and velocity loop BW, and a similar factor between velocity loop and torque(current) loop
[23:08:42] <jmkasunich> * jmkasunich needs food
[23:08:53] <les> lots of system functions on the galil video
[23:09:09] <les> if you like laplace transforms
[23:09:55] <les> specific warnings about using PID in a cascaded position/velocity loop
[23:10:04] <les> and they are right.
[23:13:28] <rayh> You really running p=5
[23:14:18] <les> no...I knocked that down...otherwise I was afraid people might download it and blow up their machines
[23:14:46] <rayh> What you really running? Want to send that off list.
[23:14:48] <les> the real P is gosh...a thousand or so
[23:15:00] <les> let me look...
[23:15:02] <rayh> BTW a p of 5 is more dangerous than a p of 200
[23:15:18] <rayh> gotta run dinner. Back later.
[23:15:32] <les> heh it is a little lazy...it will blow through limit switches
[23:16:22] <paul_c> * paul_c has the numbers here.
[23:19:03] <les> the .ini we used?
[23:19:12] <paul_c> yes
[23:19:18] <les> best to send him that...
[23:19:35] <les> but not apprapriate for another machine!
[23:19:40] <les> not the PID
[23:21:30] <les> hey paul I see you used the more accurate math library in the little spiral c program
[23:22:04] <steve_stallings> Les, would Jon's PWM amp be considered voltage/velocity mode or current/torque mode?
[23:22:39] <les> I can't say for sure because I have not seen it
[23:22:49] <les> but I have read his stuff
[23:23:23] <les> He says that the PID calcs are wrong in emc
[23:23:38] <les> I would agree...for a cascaded velocity loop
[23:23:52] <les> but not for normal torque mode
[23:24:00] <paul_c> les: nope. just used a definition for Pi that was a little more detailed.
[23:24:08] <les> oh ok
[23:24:12] <paul_c> the math lib remains the same.
[23:24:20] <steve_stallings> As I understand it, the output of his control board is one polarity signal and a current on/off signal.
[23:24:38] <steve_stallings> The amp has current limit only to set MAX current.
[23:24:45] <les> ultimately yeah
[23:25:14] <les> in normal torque mode P is a spring...D is a damper
[23:25:34] <les> in vel mode a good bit different
[23:26:15] <les> fourth order and potentially unstable if you use D and I
[23:27:27] <les> a classical damper supplies a restoring force prop to the velocity error in torque mode
[23:28:03] <steve_stallings> I would consider PWM on/off control of current switch to be a velocity mode if there is no way for the amp to control current in response to PWM.
[23:29:05] <les> well PWM in general is fine...just another analog signal
[23:29:18] <les> three posibilities:
[23:29:49] <les> torque mode...a voltage or duty cyvle controlled current source
[23:30:28] <les> voltage mode...a voltage or duty cyclr controled voltage source...
[23:31:13] <les> and velocity mode.... a voltage or duty cycle controlled tach voltage
[23:32:50] <les> torque mode has high output impedance...
[23:33:06] <les> voltage and tach low...almost zero
[23:33:10] <steve_stallings> So if the PWM simply turns on and off an H bridge driver, it is voltage mode (with max current protection). The PWM value represents velocity request.
[23:34:07] <les> The mode depends on whether the feedback in the amp senses current, output voltage, or tach voltage
[23:34:33] <steve_stallings> There is NO feedback in the amp, only max current limit.
[23:34:54] <les> in Jon's?
[23:35:03] <steve_stallings> As I understand it.
[23:35:56] <steve_stallings> If current rises above safe limit (20 amps??) it simply truncated the PWM for that cycle.
[23:36:24] <les> sounds like voltage mode...but with no voltage feedback (integrated) It will not quite act as a voltage source
[23:37:07] <les> I run servos with big audio amps some...
[23:37:23] <les> but they are almost perfect voltage sources
[23:37:32] <les> due to feedback
[23:37:50] <les> zero input and the servo stops
[23:37:57] <les> because it is shorted
[23:38:01] <steve_stallings> I am more familiar with the PWM controlling the polarity of the drive so the action is voltage mode.
[23:38:25] <les> with a current amp it coasts...an ideal current source has infinite impedance
[23:39:25] <les> for current PWM (like copleys and most) negative feedback of a current monitor is used
[23:39:37] <steve_stallings> My prototypes use the PWM to control polarity. PWM = 50% results in zero effective volts to motor. Current limt just protects the driver and motor.
[23:39:50] <les> right
[23:40:43] <steve_stallings> I was wondering if redesign to current mode would make a "better" driver.
[23:41:04] <steve_stallings> Current sensing is easy. Conversion of PWM to analog worries me, phase lag?
[23:41:12] <les> current mode is used in most all machines now.
[23:41:29] <les> velocity is derived from the D term of PID
[23:41:54] <les> from the encoder
[23:42:02] <les> there is no extra tach
[23:43:32] <les> the encoder is a much better tach than the early analog ones
[23:43:53] <les> they did that then just to offload cpu processing
[23:44:38] <les> but then could not use PID
[23:44:42] <les> usually PI
[23:45:10] <steve_stallings> When you use EMC to control current/torque mode you just end up tuning PID differently, no other changes to EMC?
[23:45:22] <les> right
[23:45:31] <les> PID is dumb
[23:45:44] <les> it is just an error signal and response
[23:46:12] <steve_stallings> So, does conversion of PWM to an analog signal to control current chopper have any impact on loop stability?
[23:46:30] <les> 't spit out velocity or position or accel
[23:46:37] <steve_stallings> PWM into LPF gets voltage, but phase lag.
[23:47:07] <les> PWM does not affect stability as lonfg as you are within the Nyquist limits
[23:47:19] <les> It's just an analog signal
[23:47:47] <les> zero quantization error ideally
[23:47:57] <steve_stallings> So a typical PWM frequeny of 10x the update rate would likely be OK.
[23:48:46] <les> yeah..high enough to not hear the squeal...low enough to be efficient
[23:49:06] <les> 10-20 KHz is typical
[23:49:16] <steve_stallings> I mean, 20KHz PWM signal in a system with 2KHz servo loop.
[23:49:31] <les> no problem at all
[23:50:19] <steve_stallings> OK, I feel better now. Jon's approach while simple in hardware, didn't feel good to me.
[23:50:54] <steve_stallings> Still assuming I understood him correctly.
[23:51:03] <les> I don't know much about it...other than the caution of using cascaded velocity loops with pid
[23:51:41] <les> argh an old root canal shattered
[23:52:04] <les> free pliers or $500 dentist?
[23:52:30] <steve_stallings> Gee, I know I can sometimes make people grind their teeth, but usually I have to be face to face to accomplish that! 8-(
[23:52:32] <les> how about both.
[23:52:45] <les> haha
[23:53:36] <les> the fracture is not down to the bone...just a big chunk has broken and is held on by the gum tissue
[23:53:45] <les> dosen't hurt
[23:53:47] <les> yet
[23:54:22] <les> it is a root canal...it's dead
[23:54:26] <steve_stallings> Been there, grew up without floride, chewed ice while young, lots of cracked molars.
[23:55:00] <steve_stallings> Surprising little pain other than in the wallet.
[23:55:07] <les> yeah
[23:55:45] <les> I am a small business...so for routine stuff...we just pay it.