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