Back
[00:00:05] <K4ts> well
[00:00:06] <Jacky^> wow
[00:00:08] <Jacky^> strong
[00:00:10] <Jacky^> :)
[00:00:54] <les_w> also cayenne, hungarian, chile
[00:01:00] <Jacky^> heheheheh
[00:01:04] <les_w> I will have a big garden in the spring
[00:01:27] <Jymmm> tri-tip cubed and braised with inions and poblano peppers, then slow simmered with chili powder till fork tender. Grilled in cast iron skillet and served taqueria style with onions, cilantro, lime juice, and favorite salsa!
[00:01:45] <Jymmm> That's MY dinner tonight =)
[00:01:51] <les_w> < drool>
[00:01:57] <Jacky^> rofl
[00:02:15] <K4ts> les take oil ease and pepper
[00:02:35] <Jacky^> uhmm
[00:02:46] <les_w> oil and pepper? hot
[00:02:54] <Jymmm> chili oil?
[00:03:01] <Jymmm> good stuff!
[00:03:08] <Jacky^> * Jacky^ lol
[00:03:12] <K4ts> lightly all
[00:03:15] <les_w> well, oil is a solvent for capsaicin
[00:03:29] <Jymmm> hey les, got some spare hdd's? I need about 15TB worth!
[00:03:34] <Jacky^> K4ts: is fighting with the dictionary
[00:03:40] <les_w> I have 240G.
[00:04:05] <Jymmm> les_w I got 500G, still not enough, I'm downloading the world!
[00:04:14] <Jymmm> 60% complete
[00:04:32] <les_w> I know what she is saying ...use a little oil with peppers and broil them
[00:05:16] <onlyyou> hi all
[00:05:22] <Jacky^> K4ts: want to mean small peppers
[00:05:32] <K4ts> chili pepper
[00:05:45] <les_w> oh
[00:05:46] <les_w> ok
[00:06:07] <K4ts> jacky bad prompter
[00:06:12] <les_w> haha
[00:06:13] <Jacky^> uhm
[00:06:40] <Jacky^> K4ts: I just sayd chili peppers is aprodisiac
[00:06:40] <K4ts> ease
[00:06:45] <Jacky^> :D
[00:07:19] <Jymmm> * Jymmm lol @ K4ts
[00:07:19] <Jacky^> hahaha
[00:07:22] <les_w> ha not if you eat too many
[00:07:23] <onlyyou> hi K4ts :-P
[00:07:43] <onlyyou> is dangerous chili peppers
[00:07:52] <Jacky^> les_w: K4ts decided o find an image to show you
[00:07:58] <les_w> ok
[00:08:00] <Jacky^> hahahhaha
[00:08:16] <K4ts> ttp://www.fotofoto.it/free/cibo/1.htm
[00:08:25] <Jacky^> http
[00:08:27] <les_w> looking
[00:08:27] <K4ts> aglio
[00:08:35] <Jacky^> bauhhahahaa
[00:08:46] <K4ts> ahhhhhhhhh
[00:08:49] <onlyyou> is a photo of dinner of Jacky^ ???
[00:08:58] <K4ts> no onlyyou
[00:09:01] <Jacky^> onlyyou: O_O
[00:09:04] <Jacky^> nah
[00:09:07] <K4ts> it is aglio!
[00:09:13] <onlyyou> O_O
[00:09:18] <Jacky^> :D
[00:09:50] <onlyyou> :-S aglio sigh...
[00:10:09] <les_w> garlic or...
[00:10:11] <K4ts> les_w: ok?
[00:10:16] <Jacky^> * Jacky^ offer a drink to onlyyou : cannonau from sardinia island
[00:10:21] <Jacky^> :P
[00:10:22] <onlyyou> garlic hi
[00:10:31] <Jacky^> les_w: yep
[00:10:36] <Jacky^> its right
[00:10:51] <onlyyou> 1 � 4 pound
[00:10:57] <Jacky^> :D
[00:10:59] <onlyyou> wow
[00:11:05] <onlyyou> i like cannonau
[00:11:12] <onlyyou> hic hic
[00:11:13] <les_w> I grow garlic too
[00:11:16] <Jacky^> I like chili pepper
[00:11:17] <les_w> easy to grow
[00:11:34] <Jacky^> hehe
[00:12:17] <Jacky^> ouch
[00:12:32] <Jacky^> K4ts: wont accept my suggestions :(
[00:12:33] <K4ts> to fry lightly
[00:12:42] <K4ts> all
[00:13:28] <les_w> right...a little oil, and fry just a little with high heat
[00:13:33] <les_w> like a wok?
[00:13:52] <les_w> garlic and pepper together?
[00:14:00] <K4ts> add if you like anchchovy
[00:14:06] <onlyyou> oil garlic and chili pepper ???
[00:14:14] <les_w> I make sauce with garlic and pepper.
[00:14:19] <Jacky^> thats a bomb
[00:14:23] <Jacky^> hahaha
[00:14:26] <onlyyou> ahaahahh
[00:14:32] <onlyyou> boooommm
[00:14:36] <les_w> yes
[00:15:06] <Jacky^> K4ts: is looking for a photo ..
[00:15:19] <les_w> vinegar, smoked cayenne, garlic, salt
[00:15:22] <Jacky^> alici
[00:15:48] <Jacky^> les_w: Im bit confused
[00:16:03] <les_w> oh for my pepper sauce I make
[00:16:09] <Jacky^> :D
[00:16:25] <Jacky^> K4ts: is looking for 'alici' pic
[00:16:27] <les_w> I smoke the peppers on a wood fire
[00:16:32] <Jacky^> hahahaha
[00:16:36] <K4ts> eh eh
[00:16:38] <Jacky^> :(��
[00:16:47] <K4ts> non si trovano alici
[00:16:48] <K4ts> ah ah
[00:16:54] <K4ts> on web
[00:17:02] <Jacky^> K4ts: cant find alici on the web
[00:17:18] <Jacky^> ok ok
[00:17:21] <Jacky^> wait
[00:17:39] <les_w> I understand alici...garlic in latin name is allicium
[00:17:47] <Jacky^> I know , here, they seels air fom naples
[00:17:50] <onlyyou> the stomach with this prescription burns me :-P I prefer spaghetti with eggs of tuna.. the garlic chili pepper. mmmmmmmmmm
[00:17:56] <Jacky^> air in bottle
[00:18:03] <Jacky^> from naples
[00:18:04] <K4ts> http://www.stellafoods.com/i/prodotti/acciughe.html
[00:18:05] <Jacky^> O_O
[00:18:19] <Jacky^> ah.. she found
[00:18:23] <onlyyou> air in boxed also
[00:18:29] <Jacky^> hehehe
[00:18:41] <Jacky^> really
[00:18:45] <K4ts> les sto sudando
[00:18:50] <Jacky^> they seels air rom naples
[00:18:57] <Jacky^> from
[00:19:13] <onlyyou> how much air of naples ?
[00:19:24] <Jacky^> how much ?
[00:19:38] <Jacky^> about 20 E. liter
[00:19:42] <Jacky^> :)
[00:19:45] <les_w> selling air? what a novel idea
[00:19:47] <onlyyou> acccc
[00:19:50] <Jacky^> yeahh
[00:19:53] <Jacky^> les_w: really
[00:19:57] <Jacky^> look
[00:20:01] <onlyyou> only italian have this idea
[00:20:05] <Jacky^> K4ts: is searching.. wait
[00:20:09] <les_w> ok
[00:20:12] <Jacky^> hahaha
[00:20:35] <Jacky^> thats for the napolitans outside from here
[00:20:40] <Jacky^> really
[00:20:42] <K4ts> http://www.napolimania.com/
[00:20:59] <onlyyou> the italian government have this idea many many years ago
[00:21:07] <Jacky^> heheh
[00:21:30] <onlyyou> now ..only opa !!
[00:21:34] <onlyyou> lol
[00:22:06] <Jacky^> les_w: cant find it now
[00:22:08] <K4ts> http://www.napolimania.com/prodotto2.php?sez=21&prod=1191
[00:22:13] <les_w> what if vesuvio erupts?
[00:22:22] <Jacky^> I will send you the air from naples !
[00:22:30] <Jacky^> soon
[00:22:32] <Jacky^> :)
[00:22:37] <onlyyou> on DCC ?????
[00:22:39] <onlyyou> :-D
[00:22:51] <Jacky^> onlyyou: nahh from POste italiane
[00:22:51] <les_w> oh, hahaha
[00:22:57] <onlyyou> ahahahahaahah
[00:23:05] <Jacky^> :)
[00:23:20] <Jacky^> dcc wont accept air from naples :(
[00:23:23] <Jacky^> yet ..
[00:23:24] <Jacky^> :)
[00:24:18] <onlyyou> the Italian mail are slow, send fresh air of Naples arrive smog of Milan
[00:24:21] <Jacky^> les_w: look at the K4ts url
[00:24:23] <Jacky^> :
[00:24:29] <les_w> ok
[00:24:46] <les_w> I saw a box of air
[00:24:50] <les_w> haha
[00:24:52] <Jacky^> hehehe
[00:25:07] <onlyyou> solo posta prioritaria
[00:25:10] <Jacky^> a box cointaining air from naples
[00:25:13] <Jacky^> :)
[00:25:31] <Jacky^> I've a better Idea ;P
[00:25:33] <les_w> sell helium...shipping cost is by weight. So with helium the shipper pays you.
[00:25:37] <Jacky^> hahahhaa
[00:26:39] <onlyyou> only the weight of pack
[00:26:47] <les_w> ah well
[00:26:52] <Jacky^> well, guys, have a fun
[00:26:55] <les_w> I will eat my pizza now
[00:26:56] <Jacky^> bed calls
[00:26:59] <Jacky^> :D
[00:27:01] <Jymmm> c ya
[00:27:05] <les_w> bye
[00:27:07] <Jacky^> night ;)
[00:27:17] <onlyyou> more a piece than lead
[00:27:21] <onlyyou> ehehe
[00:27:26] <onlyyou> g night
[00:27:31] <Jacky^> ciao les_w
[00:27:35] <Jacky^> night all
[00:27:38] <onlyyou> ciao les_w
[00:27:49] <onlyyou> hi K4ts
[00:27:53] <onlyyou> gn
[00:28:16] <K4ts> byeeeeeeeee
[00:28:24] <onlyyou> bye bye K4ts
[00:28:27] <K4ts> night
[00:29:06] <onlyyou> good night all
[02:18:43] <CIA-8> 03cradek 07simple_tp * 10emc2/src/emc/kinematics/ (tc.c tc.h tp.c tp.h):
[02:18:43] <CIA-8> I think simple_tp, the well-documented minimalist trajectory planner, is
[02:18:43] <CIA-8> working.
[02:24:14] <jepler> yay
[02:24:16] <jepler> cradek: buy you a drink?
[02:26:01] <cradek> I've been hitting the coffee and irish cream already...
[02:35:35] <jepler> oh
[02:35:40] <jepler> maybe another night then
[02:36:01] <cradek> I wasn't sure if you were serious... Want to go to the coffee shop?
[02:36:38] <jepler> oh .. seems silly for you to make a trip into town just for that
[02:36:43] <jepler> maybe tomorrow when you're in town already
[02:37:00] <cradek> well, I'm trying to squeeze every little bit of enjoyment out of my weekend
[02:37:56] <jepler> if you want to drive into town, I'm game.
[02:38:14] <cradek> ok then, let's meet there
[02:38:25] <jepler> do you want to pick me up?
[02:41:11] <les_w> I'll have a look at what you wrote for the TP chris
[02:42:30] <cradek> sure, I'll pick you up
[02:44:23] <cradek> les_w: I'm anxious to hear what you think
[02:44:26] <cradek> jepler: leaving now
[02:55:52] <alex_joni> hello
[02:56:01] <alex_joni> cradek, jepler : still there?
[02:57:05] <alex_joni> guess I just missed them..
[02:58:11] <skunkworks> think they went for coffee
[02:58:19] <alex_joni> skunkworks: seems like it..
[02:58:36] <skunkworks> ;)
[03:01:09] <alex_joni> damn, I gotta stop doing this..
[03:01:51] <alex_joni> 5am again :)
[03:01:58] <CIA-8> 03alex_joni * 10emc2/src/po/de_rs274_err.po: fixed a few typo's and translations
[03:02:43] <skunkworks> wow - I can't stay awake past 10:00
[03:03:10] <alex_joni> 10am?
[03:03:18] <skunkworks> ;) pm
[03:03:23] <alex_joni> it was 7 yesterday..
[03:03:36] <skunkworks> sorry forget to use 24 hour time
[03:04:05] <alex_joni> n/m
[03:14:28] <alex_joni> think I'm off to bed finally :)
[03:14:34] <alex_joni> night all
[03:15:21] <skunkworks> night
[03:33:11] <RifRaf_> RifRaf_ is now known as RifRaf
[03:38:35] <fenn> does "rotor flux" mean the direction of the combined magnetic fields of magnets on the rotor?
[03:39:18] <fenn> i'm slowly chipping away at a "field orientated control" whitepaper
[03:40:21] <fenn> wish they would use plain english
[04:15:38] <cradek> alex_joni: still there?
[04:27:14] <cradek> oh, I see he said goodnight (again)
[07:43:46] <RifRaf_> RifRaf_ is now known as RifRaf
[07:55:37] <CIA-8> 03rayhenry * 10emc2/tcl/bin/halconfig.tcl: Start at on-line configuration system.
[09:23:14] <RifRaf_> RifRaf_ is now known as RifRaf
[12:57:48] <alex_joni> morning
[12:57:55] <alex_joni> anyone around?
[12:58:26] <alex_joni> maybe later ..:)
[12:59:36] <ValarQ> we're all dead...
[13:04:25] <cradek> I'm out of the habit of going to work
[13:05:00] <cradek> it seems harder than usual
[13:05:22] <cradek> alex_joni: I see you were looking for me last night
[13:12:04] <les_w> hi chris. looking at your code this morning
[13:13:00] <les_w> but cvs just went down for me
[13:14:05] <les_w> Much more readable.
[13:14:35] <les_w> seems tc is all queue housekeeping
[13:14:47] <les_w> and tp is the actual planner
[13:15:22] <les_w> great job
[14:07:36] <cradek> thanks les
[14:08:07] <cradek> I might move that last real function out of tc.c so the queue stuff can be in its own file (and forgotten about)
[14:09:56] <les_w> I am checking some math now
[14:09:59] <les_w> question
[14:11:11] <les_w> input is a distance (straight line in your case) and a feedrate
[14:13:05] <les_w> therefore since distance=feedtate*time a time of distance/feedrate is requested.
[14:13:44] <les_w> Ig this time is less than the cycletime, this motion cannot be done at the requested feed.
[14:14:47] <les_w> so feed must be clamped such that requested time is greater than cycletime, or the queue will starve.
[14:15:11] <les_w> EMC1 seems to have no such clamp
[14:15:38] <les_w> of course later vel and accel may be clamped
[14:17:04] <les_w> now included in this I think should be the fact that start and end are zero
[14:17:48] <les_w> so worst case 2*requested feedrate would have to be used
[14:18:10] <les_w> to get an average feed equal to requested feed
[14:18:29] <les_w> because it is a triangular feed/time profile
[14:21:31] <les_w> so, the conditional might be if(0.5distance/feedrate >= cycletime)
[14:23:47] <les_w> I have to think about this more though...as to where it needs to be clamped.
[14:24:16] <les_w> in the general case accel and velocity limits must be honored
[14:25:14] <les_w> so the the Feed clamp for cycletime would need to be last.
[14:25:21] <les_w> couple ways to do that.
[14:29:51] <cradek> so let me see if I understand
[14:30:08] <cradek> you're talking about extremely short segments, right?
[14:30:49] <les_w> it's relative....depends on the machine capabilities
[14:31:05] <cradek> I think in simple_tp the shortest segment will take two periods
[14:31:24] <cradek> it will certainly not have anywhere near the requested velocity
[14:32:14] <cradek> but what you mean by queue starvation must be different from what I think queue starvation is
[14:32:18] <cradek> would you explain what you mean please
[14:32:26] <les_w> i'll try
[14:32:58] <Jacky^> morning folks :)
[14:33:42] <les_w> you have from g-code and cannonicals a requested distance and a requested time (derived from requested feedrate)
[14:34:00] <Jacky^> hi les_w
[14:34:08] <cradek> right
[14:34:16] <les_w> that time has to be greater than cycletime
[14:34:24] <les_w> to be realizable
[14:34:25] <cradek> why?
[14:34:35] <cradek> oh, ok
[14:34:36] <les_w> the queue will starve
[14:34:55] <cradek> we all understand that the F word is the desired velocity but you will get something less than that.
[14:34:57] <les_w> and it does.
[14:35:16] <cradek> which queue?
[14:35:26] <les_w> the motion queue
[14:35:41] <cradek> again please explain what you mean by starve
[14:36:05] <cradek> the queue doesn't empty (no more motions available to the tp)
[14:36:12] <cradek> that's queue starvation
[14:36:13] <les_w> and no, I think sometimes actual velocity will be desired velocity
[14:36:23] <les_w> ok need to define terms I guess
[14:36:51] <cradek> well it may move at F for a while, but the average V will be lower than F because of accel
[14:37:07] <cradek> often segments don't hit F at all
[14:37:58] <les_w> ok I get what you mean
[14:38:13] <les_w> it kinda depends on average velocity in the motion
[14:38:16] <les_w> but
[14:39:13] <les_w> if actual velocity capability can be more than requested velocity....
[14:39:35] <les_w> it is possible to complete the requested distance in the requested time
[14:39:38] <les_w> ok?
[14:39:59] <les_w> peak velocity will be more of course
[14:40:03] <cradek> only if you're blending and lucky
[14:40:07] <les_w> if the machine can do it
[14:40:08] <cradek> ??
[14:40:24] <cradek> are you saying the TP is supposed to exceed the vel of the F word??
[14:40:52] <les_w> yes that is done in some tp
[14:40:59] <les_w> does not have to be
[14:41:27] <les_w> if it is not, requested average velocity will never be reached as you say
[14:42:11] <cradek> an F word (no, not that F word; we mean feedrate) is interpreted to mean the controlled point should move at a certain number of inches per minute, millimeters per minute, or degrees per minute, depending upon what length units are being used and which axis or axes are moving.
[14:42:28] <cradek> the spec is not very specific about this point
[14:42:33] <les_w> sure.
[14:42:55] <les_w> well different plans can be used.
[14:43:21] <les_w> If the F word is considered to be average velocity in a segment...
[14:43:37] <les_w> you can do whatever is required to make that happen
[14:43:57] <les_w> or you can clamp it and always go slower.
[14:43:59] <cradek> sure, but you're going to not always be able to do that, as you say
[14:44:08] <les_w> right
[14:44:21] <cradek> where did we start here les? were you saying there was a problem in simple_tp?
[14:44:31] <les_w> that is the point where there is no cruise phase.
[14:44:46] <les_w> We got off the subject I think
[14:44:49] <cradek> yeah
[14:46:35] <les_w> Paul and I did measurements and found that if the g code requested move time (derived from distance and feed) was less than cycletime the violent stutter began.
[14:46:52] <les_w> Paul described that as queue starvation.
[14:46:57] <les_w> As did Fred.
[14:47:07] <les_w> Might not be...
[14:47:25] <SWPadnos> I'd bet that was the interpolator not knowing to do when it runs out of travel length (for a move)
[14:47:51] <SWPadnos> or just screwing up feedrates in that situation
[14:48:06] <SWPadnos> (there could even have been some negative thing happening at the end there)
[14:48:20] <les_w> well, it does not crash...it waits a while then tries to catch up. Seems almost random, hence the term stutter
[14:48:26] <les_w> but
[14:48:54] <les_w> if requested move time is always greater than the cycletime this does not happen
[14:49:03] <les_w> we tested and timed it.
[14:49:31] <cradek> well the TP only gets at most one pending motion from the queue per TRAJ cycle
[14:49:50] <jepler> the usefulness of a move so short it's less than a cycle time seems .. questionable
[14:50:16] <SWPadnos> the usefulness of a system that doesn't barf when presented with such a move isn't questionable, imo :)
[14:50:32] <les_w> I'm just suggesting that requested motion times have to be clamped to cycletime
[14:50:52] <SWPadnos> ie, feedrate is changed such that a move will never be less than one cycle
[14:50:52] <les_w> >= cycletime
[14:50:57] <steves_logging> Do you guys mean to say that neither Paul nor Fred ever recommended trying to alter the TP to avoid generating motions that completed in less than a TP cycle time?
[14:51:24] <steves_logging> steves_logging is now known as steve_stallings
[14:51:29] <les_w> heh
[14:51:31] <SWPadnos> (hey - I was going to aask that question)
[14:51:53] <les_w> Fred reccomended throwing the whole thing out. haha
[14:52:03] <cradek> les_w: I'd have to test, but I don't think this is a consideration in simple_tp because it stops after every move anyway.
[14:52:07] <les_w> And we could not put the code in.
[14:52:29] <cradek> les_w: it's true if you were blending and didn't want to screw up, you might want to plan those short segments differently
[14:52:43] <les_w> cradek, I think it is.....even in exact stop.
[14:52:48] <les_w> wrote it up here
[14:53:51] <cradek> les_w: I'm pretty sure simple_tp will just move to the segment's end point in one traj cycle
[14:54:02] <cradek> next cycle, the next motion is loaded
[14:54:16] <cradek> les_w: I don't think there's a special case to worry about
[14:54:25] <cradek> les_w: I could certainly be wrong of course
[14:54:28] <les_w> at best performace you have a vel ramp up to max vel at half cycletime, and ramp down to zero in the second half
[14:54:54] <les_w> now the time it takes to do that, best case, needs to be longer than cycletime.
[14:55:05] <les_w> oops
[14:55:10] <cradek> all the TP does is move the requested machine position
[14:55:33] <cradek> if it moves it to the end of the segment, what else is there you can do?
[14:56:06] <cradek> it's going to move slowly compared to F, but that happens all the time and is not anything special
[14:56:35] <les_w> You know, math on IRC doesn't work well.
[14:56:40] <les_w> I need pictures
[14:56:44] <cradek> nope, it sucks
[14:56:49] <cradek> it also sucks on web pages
[14:56:59] <cradek> a font problem, mostly
[14:57:05] <les_w> I will draw it up and put it on a page
[14:57:34] <cradek> before you do:
[14:57:40] <SWPadnos> openoffice math is pretty good - just look at the help
[14:57:41] <les_w> yes?
[14:57:59] <cradek> do you understand that TP only moves the machine position in steps?
[14:58:17] <les_w> I basically just need a blackboard.
[14:58:25] <cradek> aside from throwing out the segment, it seems to me the only thing you can do with a short segment is move from the beginning to end of it in one cycle
[14:58:27] <les_w> Yes I understand that fully
[14:58:34] <les_w> stops at each point
[14:59:03] <cradek> so it seems that what you call the feed rate is irrelevant
[14:59:11] <les_w> or velocity adapt Chris
[14:59:24] <les_w> but I'll try to draw some pictures.
[14:59:25] <cradek> that is velocity adaptation
[14:59:36] <cradek> I'm still talking exact stop here, are you talking about something else?
[14:59:41] <les_w> nope
[14:59:48] <les_w> exact stop
[15:00:54] <les_w> anyway, I'll draw something
[15:00:58] <cradek> so what is velocity adaptation in exact stop mode?
[15:01:04] <cradek> ok
[15:01:12] <les_w> this nasty thing call work may interfere
[15:02:05] <les_w> chris, in exact stop mode it can be possible to have move time requests faster than cycletime.
[15:02:34] <les_w> It is a peculiarity of a real time TP that's all
[15:03:45] <cradek> I don't follow what you mean by move time requests
[15:04:47] <les_w> What if I want to move from a to b starting and ending at a standstill in .001 seconds
[15:04:52] <les_w> repeatedly
[15:05:04] <les_w> and cycletime is greater than .001?
[15:05:18] <cradek> then it will take cycletime to do it
[15:05:24] <cradek> you end up with a feed slower than requested
[15:05:31] <les_w> exacly
[15:05:44] <les_w> oops
[15:05:54] <cradek> that's not a bug, that's a feature
[15:06:06] <les_w> emc1 does not do this.
[15:06:25] <les_w> it doesn't have the feature
[15:06:37] <cradek> ok, interesting
[15:06:45] <cradek> I'm pretty sure simple_tp will do as I say
[15:07:11] <les_w> well you may have the cycletime clamp in there already
[15:07:21] <Jacky^> * Jacky^ goes for shopping ..
[15:07:23] <Jacky^> later
[15:07:31] <les_w> later jacky
[15:08:06] <cradek> les_w: I can't say I understand emc's existing blending code - I know it does some strange things sometimes.
[15:08:44] <les_w> ok, well have to talk on phones to make money to eat and stuff
[15:08:54] <les_w> I'll get back to this as I can
[15:09:19] <cradek> thanks for looking at it - maybe you can help put blending in one of these days
[15:09:40] <les_w> yes I think I can
[15:09:51] <les_w> I understand most of what I see
[15:10:01] <cradek> great, that's the idea
[15:10:16] <cradek> I'm glad to hear it
[15:10:19] <les_w> yeah. good plan.
[15:40:56] <alex_joni_> howdy all
[15:43:14] <cradek> hi alex
[15:43:18] <cradek> thanks for doing those translations
[15:43:28] <alex_joni_> no problem
[15:43:36] <alex_joni_> I think I'll do the romanian translation aswell
[15:43:46] <alex_joni_> but not for RS274 error messages
[15:44:04] <alex_joni_> I don't really think those should get translated.. I mean I wouldn't want them :P
[15:44:38] <jepler> yeah I appreciate it as well
[15:44:43] <alex_joni_> huh, probably my english knowledge is a bit lacky..
[15:44:51] <alex_joni_> "Unclosed expresson" <- that's new for me ;)
[15:44:59] <alex_joni_> jepler: anytime
[15:45:26] <jepler> This expression is closed: "(3+3)". This one isn't: "(3+3".
[15:45:31] <jepler> I think that's what the error message in question is about
[15:45:57] <jepler> (but in g-code I think they're brackets, not parens)
[15:46:03] <alex_joni_> yeah I know Unclosed, didn't know 'expresson'
[15:46:11] <alex_joni_> I expected 'expression'
[15:46:18] <jepler> oh
[15:46:26] <jepler> maybe I missed your point
[15:46:35] <jepler> 'expresson' isn't a word.
[15:46:43] <alex_joni_> oh.. I fscked up the text aswell :D
[15:46:49] <alex_joni_> msgid "Unclosed expresson"
[15:46:50] <alex_joni_> that should read "Unclose expression"
[15:46:58] <jepler> yes, it should be "expression"
[15:47:00] <alex_joni_> I really meant "Unclosed expression"
[15:47:24] <jepler> now it's all clear to me
[15:47:32] <alex_joni_> sorry ;)
[15:48:36] <alex_joni_> ok, things seem to be moving along quite nicely
[15:48:39] <alex_joni_> * alex_joni_ is happy
[15:50:16] <alex_joni_> jepler: one question though
[15:50:27] <alex_joni_> http://axis.unpy.net/index.cgi-files/01136301942/axis-de.png <- some stuff isn't translated it seems to me
[15:51:05] <cradek> I'd have to agree
[15:51:36] <alex_joni_> On "Manual Control" maybe the (F3) is the problem (that doesn't exist in the .pot file)
[15:52:02] <jepler> alex_joni_: yeah, I'm working on that right now
[15:52:04] <alex_joni_> oh, and it's lowercase 'Manual control' not 'Manual Control'
[15:52:14] <jepler> alex_joni_: it seems that I have to use ""-quotes instead of {}-quotes when the string contains certain special characters
[15:52:31] <alex_joni_> you should know ;)
[15:52:41] <cradek> yay tcl
[15:52:43] <jepler> documentation on how gettext works with tcl files is .. sparse at best
[15:52:48] <jepler> cradek: it's not tcl; it's gettext's tcl parser
[15:52:56] <jepler> it's tough (impossible really) to parse tcl
[15:53:14] <alex_joni_> why not use msgcat::mc for tcl?
[15:53:21] <jepler> so amybe it is tcl's fault
[15:53:28] <jepler> alex_joni_: because then I think I'd have to use two separate message catalogs
[15:53:41] <alex_joni_> you are right ;)
[15:54:36] <alex_joni_> what's "touch off" interface ?
[15:54:53] <alex_joni_> optimized for 'touch-screens' ?
[15:57:58] <jepler> alex_joni_: when making circuit boards, we want to zero with the tool touching the surface of the copper
[15:58:11] <alex_joni_> ahh.. that kind of touch off ;)
[15:58:17] <jepler> alex_joni_: this involves using a .0002" (?) feeler gauge
[15:58:32] <alex_joni_> whatever that is :P
[15:58:38] <jepler> it would be nice if the last steps weren't "now go down .0002" and hit shift-home" but "hit shift-home"
[15:58:40] <alex_joni_> how about a probe?
[15:58:54] <jepler> well that would be nice too
[15:59:06] <alex_joni_> and automate the heck out of it ;)
[15:59:22] <alex_joni_> probe 3 points, determine the plane, change the tool, start milling :D
[15:59:47] <alex_joni_> although that would need a bit more than g-code, step-nc might be suitable
[15:59:52] <alex_joni_> to talk to the CAM program
[16:01:23] <jepler> looks like there are 34 messages that weren't found before by 'gettext'
[16:01:29] <jepler> alex_joni_: which means more work for you!
[16:01:41] <alex_joni_> jepler: no problem, keep them coming :)
[16:01:48] <jepler> work calls at the moment, though
[16:02:02] <alex_joni_> ok, I'll boot a BDI and address some more bugs
[16:02:05] <alex_joni_> in emc2 that is
[16:02:17] <alex_joni_> drop me an email when you have something for me.. ok?
[16:17:30] <alex_joni_> * alex_joni_ goes away for a while
[16:31:08] <les_w> chris, you there?
[16:31:17] <cradek> yes
[16:31:24] <les_w> talk a min?
[16:31:35] <cradek> sure
[16:32:09] <les_w> ok. I drew some pictures and thought some between phone calls.
[16:32:20] <les_w> Let say....
[16:33:11] <les_w> you had 1000 exact stop moves one after the other, and each move was 0.01 long.
[16:33:27] <les_w> And the Fword was 60.
[16:34:19] <les_w> Would you expect that move sequence to be completed at a specific time?
[16:34:42] <cradek> not really
[16:34:50] <les_w> ok
[16:34:57] <les_w> what would you expect?
[16:35:01] <cradek> it would depend greatly on the accel for instance
[16:35:52] <les_w> alright. Here's what I'm getting at:
[16:36:57] <les_w> TRYING to complete that move as if it was one single move at the specified distance/time...
[16:37:12] <les_w> Is what you would want to do with blending
[16:37:28] <les_w> constant controlled feedrate at specified value.
[16:37:41] <les_w> now that is not the case with exact stops...
[16:37:57] <les_w> but later if you want to blend a scheme like that is needed
[16:38:35] <cradek> sure if we blended right, I'd expect it to take just over 10 seconds
[16:39:02] <les_w> why not exactly or a little less?
[16:39:20] <cradek> because it would still have to start and stop
[16:39:54] <les_w> not if it comprnsated for that time
[16:40:04] <cradek> with exact stop, it could take from 10 seconds (infinite accel) to 20 seconds (can just barely reach F60 in .005") to much longer
[16:40:07] <les_w> It's a matter of what is desired I guess
[16:40:11] <cradek> sure
[16:41:47] <SWPadnos> I don't think the planner should ever try to move faster than the programmed rate
[16:42:10] <SWPadnos> the only possible exception is if you're in inverse time mode
[16:42:11] <cradek> SWPadnos: maybe it should in inverse feed mode
[16:42:14] <les_w> ok. In blending a two sided convergence to the specified feeed is desirable I think
[16:42:16] <SWPadnos> ok
[16:42:18] <cradek> yeah that
[16:42:48] <les_w> I think a planner should try to get to specified feed rate from either side
[16:43:07] <les_w> there is Max_ Velocity though
[16:43:15] <les_w> not in gcode
[16:43:17] <SWPadnos> yes - I think that's what I had said before - plan the velocity midpoint at the segment boundary
[16:43:21] <les_w> but written in stone
[16:44:55] <les_w> Ok. Depends on what you want. I general, trapeziodal planners try to match average velocity in a segment as defined by F word.
[16:45:29] <cradek> that's interesting
[16:45:39] <cradek> I don't have any experience with other planners
[16:45:39] <les_w> and the do that by feeding greater than the F value if needed, but never greater than max velocity in the ini.
[16:45:50] <cradek> I just know emc doesn't do that at all
[16:45:57] <les_w> right!
[16:46:39] <cradek> it seems to me like you choose F in order to cut properly, not in order to make your program complete at exactly noon
[16:46:46] <les_w> Well either can be done, but what I describe lends itself more to blending that's all.
[16:46:53] <SWPadnos> I suppose that the material removal rate is more of an average, so short moves higher than the programmed rate may be ok
[16:47:11] <cradek> most of the cut is done at cruise speed
[16:47:22] <cradek> so I think I'd want the cruise speed to match my F word
[16:47:26] <SWPadnos> yes
[16:47:43] <jepler> if the move is long (cruise time / accel time), then the cruise speed will not be much higher than the F-word rate
[16:47:50] <les_w> if you constrain the planner to specified feedrate as a maximum, it will be lower in genral
[16:47:55] <SWPadnos> blending doesn't depend on having the average feedrate match the F word
[16:48:00] <les_w> and not known
[16:48:02] <les_w> easily
[16:48:36] <SWPadnos> assuming that you have a perfect blend algorithm, the time is easily calculabe from the F word, and the machine max accel
[16:49:05] <les_w> Well, feedrate TRIES to math the F word.
[16:49:43] <SWPadnos> les - are you thinking of the case where a number of small segments should be aggregated into single larger moves?
[16:50:00] <les_w> ultimately yes
[16:50:06] <SWPadnos> ok
[16:50:45] <les_w> and more specifically code where that kind of stuff can be easily implemented
[16:51:00] <SWPadnos> in those cases, the aggregated move ill appear to be a single large move (that's what it ends up being)
[16:51:30] <SWPadnos> so the feedrate issue is a non-issue - the machine will cruise through the endpoints at the programmed feedrate
[16:51:40] <SWPadnos> (midpoints, I should say)
[16:52:27] <les_w> yes...I think simple tp is a great idea...just don't want it to be too hard coded away from something that can blend
[16:52:47] <SWPadnos> it is that way, on purpose
[16:52:54] <cradek> les_w: well it's pretty much done
[16:52:59] <SWPadnos> the point is that it's easier to understand where to put the blending in :)
[16:53:06] <les_w> right
[16:53:08] <cradek> les_w: the whole trapezoidal-exact-stop part is about 10 lines of code in one function
[16:53:19] <les_w> one other thing....
[16:53:24] <les_w> the aliasing
[16:53:31] <les_w> thought about that too
[16:54:06] <les_w> In simple tp if the move time is less than the cycletime and the machine can do it....
[16:54:17] <les_w> it will complete the move and wait.
[16:54:28] <les_w> which arguably it should do
[16:54:31] <les_w> right?
[16:54:43] <cradek> well, I don't think there's any waiting
[16:55:22] <les_w> what if the move is completed in .005 sec and cycle time is .01?
[16:55:43] <SWPadnos> the move will be stretched to 0.01 (or 0.02)
[16:55:52] <SWPadnos> the feedrate will go down
[16:55:55] <cradek> you keep talking about move time, but there's no such thing
[16:56:10] <cradek> every traj cycle, the TP spits out another point
[16:56:33] <cradek> I don't think the machine can move for half a traj cycle and stop for the other half
[16:56:40] <les_w> hmm, yes tp math works with times whever possible
[16:57:58] <les_w> I see the TP as spitting out not just a point, but a plan for the pid to follow in between
[16:58:20] <cradek> no, it doesn't do that
[16:58:26] <les_w> ok
[16:58:40] <cradek> I have no idea what happens to the points after the tp, but the tp's job is to spit out a new point every traj cycle.
[16:59:09] <les_w> ok
[16:59:21] <les_w> well the subinterpolator is still in there
[16:59:42] <cradek> yeah, I think that's the next step
[16:59:56] <cradek> although comments in the code say it doesn't work...
[17:01:13] <cradek> but in the tp, every move takes an integer number of traj cycles >= 1
[17:01:29] <les_w> Ok. I define planner as a recipie for positions and their derivatives that can be referred to at any time
[17:01:31] <cradek> and I'm not sure about the 1 case, it may be >= 2, but that might be a bug
[17:02:39] <les_w> like a trip where...
[17:03:39] <les_w> at two oclock, I need to be at mile marker xxx going yyy speed and accelerating at zzz
[17:03:57] <les_w> even when that mile marker is not a trajectory point
[17:05:19] <cradek> we may have to add a stage that does what you describe: inputs from canon and outputs a continuous path represented mathematically
[17:05:34] <les_w> exact stop is no different....it's just some gas stations are trown in a various places where you have to stop.
[17:05:38] <cradek> afterward, we would quantize it in time
[17:05:56] <cradek> today, those two functions are done together
[17:06:40] <cradek> most moves will change a little when you quantize them because of boundary conditions
[17:07:17] <les_w> ok. Ultimately a good blended TP would spit out a set of polynomial coefficients valid for any time during that trajectory period
[17:07:28] <les_w> they get canged each priod.
[17:07:39] <SWPadnos> yep - the hard part is in figuring out the equations (or coefficients) that an RT routine can evaluate quickly
[17:07:40] <les_w> changed each period
[17:08:15] <cradek> well that's where you math guys need to step in
[17:08:25] <SWPadnos> you math guy, in this group ;)
[17:08:33] <SWPadnos> (speaking of Les, of course)
[17:08:44] <les_w> I can do the equations....but it is about a 6x6 matrix to solve. No numerical methods though.
[17:08:50] <cradek> I'm not very successful at translating from the math world to the programming world.
[17:08:59] <SWPadnos> that I can usually do
[17:09:34] <les_w> really I see no math bottlenecks
[17:09:57] <les_w> I just need to see a queue that these coefficients can be stored in
[17:10:16] <SWPadnos> getting those matrix coefficients rapidly may be an issue for some pathological input cases
[17:10:52] <les_w> if the tp is real time yes
[17:11:20] <les_w> you know I mentioned completing the move and waiting
[17:11:35] <les_w> which is fine in exact stop
[17:11:46] <les_w> is a disaster in blends
[17:11:57] <SWPadnos> sure
[17:12:18] <SWPadnos> actaully, I'm not thinking of an RT planner - just one that can keep up in "real time" - ie, as the moves are needed
[17:12:30] <SWPadnos> not on a microsecond deadline
[17:13:08] <les_w> well, non RT is fine...just have to monitor a queue and keep it full
[17:13:24] <SWPadnos> it's keeping the queue full that may be an issue
[17:13:38] <les_w> worst case is to que up the entire motion program
[17:13:56] <SWPadnos> I'm not sure that's possible, given feed override and the like
[17:14:08] <cradek> I'm sure this is obvious but I want to say it anyway
[17:14:20] <cradek> the data passed into the TP does not have to be lines and circles
[17:14:30] <cradek> it can be anything - splines, cubics
[17:14:32] <les_w> well feed override would have to be non time optimal servo rate scaling
[17:14:50] <cradek> all you need is a structure to represent that kind of motion and
[17:15:11] <cradek> an evaluation function that gives the point along the motion
[17:15:20] <les_w> yes, just a list of poly coefficients
[17:15:26] <SWPadnos> splines or something else would be needed for anything that wants to allow for variable accel (between TP points)
[17:15:28] <les_w> a truncated power series
[17:15:29] <SWPadnos> right
[17:15:52] <cradek> so the calculation of any of that is done outside the TP (and outside realtime)
[17:16:10] <les_w> it can be
[17:16:18] <cradek> so that is what I need from one of you math guys
[17:16:28] <cradek> then I can make the TP follow it!
[17:16:29] <cradek> easy
[17:16:37] <les_w> ok
[17:16:48] <les_w> what about the sub interpolator?
[17:16:56] <les_w> know what is going on there?
[17:16:59] <cradek> nope
[17:17:17] <les_w> i.e. can you surgically extract the thing?
[17:17:21] <cradek> I don't understand it, so I think it can be ignored
[17:17:29] <les_w> haha
[17:17:30] <cradek> no idea
[17:17:41] <cradek> is it hurting anything?
[17:17:45] <SWPadnos> ignored or replaced
[17:18:09] <les_w> I don't know
[17:18:17] <SWPadnos> it's actually following the points spit out by the TP, so I'd say that ignoring it would be a bad idea
[17:18:46] <les_w> I would call it an integral part of the TP
[17:18:56] <cradek> well assuming it does its job, we can leave it alone?
[17:19:10] <les_w> may have no choice
[17:19:49] <SWPadnos> I'm not sure you can, but I'll have to think about it more
[17:20:00] <SWPadnos> it may be part of the stutter problem
[17:20:36] <cradek> I think you guys may have seen the actual tc queue emptying
[17:21:12] <cradek> but I don't know of course, I wasn't there
[17:22:52] <les_w> the queue of coefficients I suspect is in cubic.c.
[17:23:11] <les_w> Paul thought it was.
[17:23:40] <les_w> Fred just said "throw it out. It's no good"
[17:24:02] <les_w> (the entire trajectory planner)
[17:24:05] <les_w> heh
[17:24:48] <cradek> that's a funny story but doesn't do us any good
[17:24:56] <les_w> yeah
[17:25:02] <skunkworks> it is like anything else - it was written as a test and it worked ok. So it never got touched again.
[17:25:03] <les_w> I am a little confused
[17:25:27] <les_w> simple tp only spits out xyzuvw points?
[17:25:38] <cradek> yes
[17:25:41] <cradek> xyzabc
[17:25:57] <cradek> same as the old planner
[17:27:06] <les_w> and these points are simply from the gcode?
[17:27:26] <SWPadnos> along the path described by the g-code
[17:27:31] <cradek> right
[17:27:38] <SWPadnos> but one tp cycle apart in time
[17:27:41] <cradek> along the path
[17:27:55] <SWPadnos> (this is the "quantizer" of the path)
[17:27:58] <les_w> ok
[17:28:23] <les_w> I think cubic.c has to go then
[17:29:00] <les_w> you are performing that function in simpletp.
[17:29:57] <les_w> i.e. interpolated points in between the gcode destinations
[17:30:13] <cradek> I think cubic's job is to interpolate between TRAJ waypoints
[17:30:14] <les_w> correct?
[17:30:41] <cradek> yes I guess
[17:31:38] <les_w> bleh. I think confusion is caused by "interpolating then "subinterpolating"
[17:31:56] <les_w> Most papers I have just interpolate period.
[17:32:13] <cradek> really, ignore it
[17:32:17] <les_w> thw word subinterpolat is a Fred thing I think
[17:32:25] <cradek> TP gives waypoints along the g code
[17:32:36] <cradek> some magic happens later to make the machine follow them smoothly
[17:32:45] <cradek> don't make this harder than it is
[17:33:26] <les_w> hmm
[17:35:09] <les_w> I think the magic is wrong magic
[17:35:13] <SWPadnos> waypoints can be chosen in many ways, and that's where the blend methods come into play
[17:37:16] <les_w> ok so I have no place to put replacement blend algos....
[17:37:55] <SWPadnos> in simple_tp
[17:38:15] <SWPadnos> (can't tell you exactly where, since I haven't had a chance to look at it yet
[17:38:17] <SWPadnos> )
[17:38:46] <SWPadnos> brb
[17:38:58] <les_w> if so, simple tp would need to run at the servo rate
[17:39:01] <les_w> it would seem
[17:39:09] <les_w> tp.c can I think
[17:39:39] <les_w> fred says it turns cubing subinterpolation off though
[17:39:41] <les_w> hmm
[17:39:58] <cradek> yeah, I'm sure it can run faster if ... it's simple enough
[17:40:41] <les_w> well it runs every nth servo cycle in the RT thread....
[17:40:59] <les_w> this is hard RT so if it can run every nth it can run every time
[17:41:26] <cradek> that's true I guess
[17:41:52] <les_w> I need to look at the structures you have those points in
[17:42:04] <les_w> and where modals and other commands are
[17:42:06] <cradek> what points?
[17:42:23] <les_w> simpletc output points
[17:42:37] <cradek> it's just a struct with xyzabc
[17:42:43] <cradek> motion grabs them and feeds them to cubic
[17:42:44] <les_w> whatever you are spitting out of it
[17:43:03] <les_w> oh ok.
[17:43:05] <cradek> an EmcPose structure
[17:43:47] <les_w> allright. Blending must have earlier and later points. It requires lookahead.
[17:43:56] <les_w> that's all in cubic I guess
[17:44:15] <les_w> that suggests....
[17:44:28] <les_w> I can't blend in simpletp?
[17:44:42] <les_w> since I must have a history and lookahead?
[17:44:44] <cradek> why not?
[17:44:51] <cradek> you have lookahead, there's a queue
[17:45:00] <cradek> having history simply means working on tc #n instead of #0
[17:46:43] <cradek> for instance I might add a simple "blend" if dotproduct(end of last segment, start of this segment) ~= 1 { don't decel/accel }
[17:47:30] <cradek> that requires just lookahead to the next queued motion
[17:48:16] <cradek> just add to the motion queue items an initial and final velocity
[17:48:30] <les_w> I had better look at the header file a little
[17:48:40] <cradek> yeah look at the code - it's the best documentation
[17:48:42] <cradek> lunch
[17:49:03] <les_w> yeah
[19:51:43] <only4you> hi all
[19:51:52] <cradek> hi
[19:52:11] <only4you> hi cradek
[20:09:14] <Jymmm> hi cradek
[20:31:10] <alex_joni_> evening
[20:33:46] <jepler> hi again alex
[20:33:50] <alex_joni_> hi jeff
[20:33:56] <alex_joni_> you know anything about MOD_INC_USE_COUNT ?
[20:34:03] <jepler> I know it's something in the kernel
[20:34:15] <SWPadnos> it increments the reference count for a kernel module
[20:34:24] <jepler> it prevents unloading a module that is being used (hopefully)
[20:34:30] <alex_joni_> right
[20:34:41] <alex_joni_> both of you, but I mean if anyone used it before ;)
[20:34:44] <SWPadnos> what else is there to know? ;)
[20:34:49] <jepler> I've never written a kernel module
[20:35:04] <SWPadnos> I have, but in the 2.0-2.2 timeframe
[20:35:08] <alex_joni_> SWPadnos: if you screw up the INC / DEC stuff, you won't be able to ever unload the module
[20:35:17] <alex_joni_> * alex_joni_ plans of adding this to rtapi
[20:35:30] <alex_joni_> so you can't remove rtapi when things depend on it
[20:35:39] <SWPadnos> yes - if you screw that up, you'll need to rmmod -f (or whatever the force option is)
[20:35:50] <SWPadnos> you may also need to have compiled in "forced module unloading"
[20:35:53] <alex_joni_> if -f is enabled in the kernel config
[20:35:55] <alex_joni_> right
[20:36:18] <alex_joni_> well. the problem is user apps depending on rtapi
[20:36:37] <alex_joni_> because when those might get killed uncleanly, they might leave the usage count behind :(
[20:36:59] <alex_joni_> if you get what I'm thinking..
[20:37:23] <SWPadnos> yep - I get it, and I'm also not sure what to do about it :)
[20:39:22] <alex_joni_> wonder what happens if the cleanup_module returns -1
[20:39:42] <SWPadnos> that should be a -Esomething
[20:40:09] <jepler> alex_joni_: sounds like you need to be aware the process exits and clean up in kernel space when it happens
[20:41:03] <alex_joni_> jepler: the problem right now is that a rmmod rtapi will remove it, even if stuff is in use by user level processes
[20:41:37] <alex_joni_> kernel dependencies get cleared by rmmod and kernel symbol table, no sweat, but user level stuff needs to get treated separately
[20:41:46] <SWPadnos> is there not a check for references in RTAPI, or is it being "overridden" by a --force (like) option?
[20:42:22] <SWPadnos> I thought the original bug report mentioned that there is refcounting, but it's being ognored at removal time
[20:42:27] <SWPadnos> ignored
[20:42:52] <alex_joni_> no, there is no refcount
[20:43:26] <SWPadnos> not necessarily MOD_INC_USE_COUNT, but internal refcounting of semaphores, shmem, etc
[20:44:01] <SWPadnos> this is what I was referring to:
[20:44:12] <SWPadnos> The rtapi kernel module maintains usage counts for shared
[20:44:14] <SWPadnos> memory blocks that were allocated thru it. However, it does
[20:44:15] <SWPadnos> not prevent itself from being unloaded when those counts
[20:44:17] <SWPadnos> are non-zero.
[20:44:19] <SWPadnos> in the bug report
[20:44:27] <SWPadnos> (assuming you're looking at that bug :) )
[20:45:52] <alex_joni_> yes
[20:46:06] <alex_joni_> the refcounts exist, but there is no place where you can check that
[20:46:06] <jepler> so MOD_INC_USE_COUNT when the internal count increases, and MOD_DEC_USE_COUNT when the internal count decreases?
[20:46:19] <jepler> (he says, without looking at the bug report or any source code)
[20:46:47] <SWPadnos> well - the bug goes on to say that the realtime script checks for userspace use of shmem, and prevents the unload if needed, but that should be done in RTAPI
[20:46:50] <alex_joni_> jepler: not that easy.. it's split between RT and userlevel stuff, one counter increased in RT when modules get loaded/unloaded, the other one at user_level
[20:47:05] <alex_joni_> SWPadnos: right, but you have no place to do that
[20:47:28] <SWPadnos> module_exit? (or whatever it's called now)
[20:47:40] <alex_joni_> too late
[20:47:54] <alex_joni_> that's cleanup_module(), and it gets called when the module gets unloaded, not before
[20:48:16] <SWPadnos> hmmm - I'll take a look in the Rubini book - there's got to be a place for a module to tell the kernel that it doesn't want to be removed
[20:48:17] <alex_joni_> there's no way (afaik) to tell the kernel to stop unloading at that stage
[20:48:29] <alex_joni_> there was can_unload
[20:48:35] <SWPadnos> hmm
[20:48:35] <alex_joni_> but that has been deprecated
[20:48:42] <alex_joni_> at least for 2.6
[20:48:55] <alex_joni_> SWPadnos: but if you find anything, I'd be happy to hear about it
[20:49:18] <SWPadnos> I'll take a look - no guarantees
[20:49:27] <alex_joni_> coo
[21:06:43] <CIA-8> 03rayhenry * 10emc2/configs/m5i20/ (m5i20.ini m5i20_io.hal m5i20_motion.hal README): Switchless estop and limit operation and P,I,D named vars in ini.
[21:57:05] <alex_joni_> got a nice idea ;)
[21:57:11] <alex_joni_> SWPadnos: still around?
[21:57:14] <SWPadnos> sort of
[21:57:25] <SWPadnos> whatcha think of?
[21:58:33] <alex_joni_> not me directly.. smarter people in #kernelnewbies ;)
[21:58:38] <SWPadnos> heh
[21:59:00] <alex_joni_> exporting a device, and let user apps open it
[21:59:35] <alex_joni_> well in this case code from rtai_ulapi() I guess
[21:59:40] <SWPadnos> yep - then it gets closed when a program is killed
[21:59:44] <alex_joni_> right
[22:00:05] <alex_joni_> and as far the device is in use, the module can't get unloaded.. and presto :D
[22:00:25] <alex_joni_> like I said.. smarter people :P
[22:00:32] <alex_joni_> now I need to figure out how to do it
[22:00:37] <SWPadnos> heh
[22:00:48] <SWPadnos> you need #kerneloldbies ;)
[22:02:03] <alex_joni_> or #kerneloldiesbutgoldies
[22:02:40] <alex_joni_> ok, will download LDD3 and read tonight ;)
[22:02:47] <alex_joni_> later everyone..
[22:03:00] <SWPadnos> there's not much in there on this subject - I just loked throuigh the book
[22:03:03] <SWPadnos> see ya
[22:14:32] <alex_joni_> jepler: are you there?
[22:15:25] <Jymmm> no, he's here. <rimshot>
[22:15:46] <NickServ> This nickname is owned by someone else
[22:15:46] <NickServ> If this is your nickname, type /msg NickServ IDENTIFY <password>
[22:15:47] <jepler> alex_joni_: did you get the second updated de.po file?
[22:15:49] <alex_joni_> jepler: got the de.po, yet all umlauts are borked :(
[22:16:05] <jepler> alex_joni_: uh oh
[22:16:11] <alex_joni_> and I don't really want to go through all the file again
[22:16:16] <jepler> I don't blame you
[22:16:23] <alex_joni_> can you tar the file and send it like that?
[22:16:36] <jepler> it looks like the working version got messed up
[22:16:43] <alex_joni_> or maybe send me only the texts and I'll add them to my de.po ?
[22:16:57] <alex_joni_> I still have the one I sent you
[22:17:24] <alex_joni_> one second thought I can do a simple diff.. can't be that many texts.. right?
[22:17:44] <alex_joni_> jepler: don't worry, I'll try to fix it.. ok?
[22:18:57] <jepler> alex_joni_: are you using utf-8 or iso-8859-1 as your character set?
[22:22:35] <jepler> alex_joni_: it looks like you sent me an iso-8859-1 file, but something I did caused it to be turned into utf-8.
[22:22:56] <alex_joni_> guess iso-8859-1
[22:23:12] <alex_joni_> don't worry I'll add the diff texts to the initial one, and resend.
[22:23:48] <jepler> did you find the diffs you needed?
[22:28:27] <alex_joni_> I'll look over them a bit later. 4077 is calling now ;)
[22:28:41] <alex_joni_> that's M.A.S.H. if you know it ..
[22:28:50] <alex_joni_> a bit old, but I love it
[22:29:02] <alex_joni_> I'll be around later, I think
[22:29:25] <jepler> see you
[22:29:32] <alex_joni_> yup.. bye
[23:09:17] <dmes2> ello tous ; )
[23:26:36] <zwisk> Greetings all, and happy new year.
[23:45:42] <les_w> same for you zwisk
[23:59:16] <zwisk> Lots of folks on channel, but not a lot of talkin' ... Everyone must be recovering from the holli-daze.
