01:03:16 ajoni has joined #emc-devel 01:03:53 alex_joni_ has quit 01:03:58 ajoni is now known as alex_joni_ 01:12:05 alex_joni_ has quit 01:12:08 alex_joni_ has joined #emc-devel 01:30:06 alex_joni_ has quit 01:30:30 jmkasunich has joined #emc-devel 02:36:42 alex_joni_ has joined #emc-devel 04:05:26 ajoni has joined #emc-devel 04:05:59 alex_joni_ has quit 04:06:04 ajoni is now known as alex_joni_ 04:15:42 jmkasunich has quit 04:23:53 ajoni has joined #emc-devel 04:23:53 ajoni has quit 04:25:47 alex_joni_ has quit 04:26:22 alex_joni_ has joined #emc-devel 05:04:36 alex_joni_ has quit 09:08:27 anonimas1 has quit 10:16:40 SWPadnos has joined #emc-devel 10:32:15 SWP_Away has quit 10:46:34 anonimasu has joined #emc-devel 11:37:58 SWPadnos has quit 11:38:00 SWP_Away has joined #emc-devel 11:38:02 SWP_Away is now known as SWPadnos 13:10:35 anonimasu has quit 15:29:23 alex_joni_ has joined #emc-devel 16:04:16 alex_joni_ has quit 16:04:45 alex_joni_ has joined #emc-devel 16:48:35 alex_joni_ has quit 17:45:14 jmkasunich has joined #emc-devel 17:59:05 hiya jmk 17:59:16 last day off from work? 18:01:47 hi swp 18:01:57 nope, today is the last day of my vacation 18:02:02 heh 18:02:11 (since the 1st fell on sunday, they gave us monday) 18:02:30 right - my wife's off today as well (still) 19:03:08 alex_joni_ has joined #emc-devel 19:03:54 morning alex 19:04:06 evening john :) 19:04:14 or afternoon, or evening, or whatever it is on your personal clock 19:04:15 not really morning at 21:04 ;) 19:04:31 my personal clock is screwed, that is local time however 19:04:40 when did you go to sleep, and when did you wake up? ;-) 19:05:01 about 7am, and about 2pm I think 19:05:36 7 hrs since you woke up then... so it is afternoon for you ;-) 19:05:49 yup 19:06:10 although I slept too little last night, so it feels like evening 19:06:43 then maybe you can go to sleep in a couple hours, and be back on schedule 19:06:59 I think so.. 19:07:11 anyways, there was a nice long discussion with ray yesterday 19:07:25 about? 19:07:26 he has some ideas about reorganizing hal stuff a bit (hal config files) 19:07:34 * alex_joni_ looks for a log 19:08:22 http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2006-01-01.txt starting around 1800 19:08:35 18:25 19:11:31 ok, I started reading it, but I need to go for a couple hours 19:11:31 welcome back jmk 19:11:39 jmkasunich is now known as jmk_away 19:11:40 oh, hi chris 19:11:45 hi alex 19:11:59 jmk_away: no problem, not sure if I'll be around though :) 19:12:02 you're a bad influence on me, I slept 0300-1200 19:12:07 * alex_joni_ hides 19:12:18 I slept 0700-1400 19:13:11 ok, jepler's fix seems to do the trick.. it looks ok now (http://dsplabs.utt.ro/~juve/blog/index.cgi/photography) 19:33:20 cradek: still around? 19:42:48 alex_joni_ has quit 20:09:39 hey cradek - you're a shell script guy, right? 20:21:52 alex_joni_ has joined #emc-devel 20:22:01 hey alex 20:22:12 hey swampy 20:22:23 do you know much about sed and/or awk? 20:22:30 not really :( 20:22:33 ok 20:22:38 but ask away.. 20:22:54 I probably won't be much help, yet you never know 20:23:01 well - I'm thinking of making a little utility to print only one section of an ini file 20:23:24 ok.. 20:23:27 it would be useful for making hal files that contain lots of stuff, but are executed in a specifieed order 20:23:47 invoke like "inisect EMCMOT 20:23:50 " 20:24:00 keep going.. 20:24:01 and it prints all the stuff in the EMCMOT section of the ini file 20:24:18 * alex_joni_ still doesn't see what that is good for 20:24:28 so, you could have a section that has, for instance, a list of other sections to run through halcmd, in order 20:24:40 and you pipe each section into halcmd as needed 20:25:04 why not use the HALCMD's that are in place? 20:25:09 or the HALCOMMAND's ? 20:25:12 halcmd can use ini-style parameter setting, for example (param = value) 20:25:58 I had thought about making a version of halcmd that could read a single section of an ini file (and do other stuff with it as well) 20:26:06 for example, the AXIS_n sections 20:26:38 have the script return AXIS_0 section, with pid.0. prepended to all the settings (matching a certain pattern) 20:26:50 and that pattern exists where? 20:27:11 on the command line or in a separate part of the (ini) file 20:27:31 I'm thinking of ways to accomplish the "phases configuration" of HAL, but not have 162 config files 20:27:31 can't say I'm convinced :( 20:27:36 phased 20:27:51 well.. you'll have 4-5 / config 20:27:57 can't see a reason for more 20:28:23 there's the ini, which has some stuff duplicated in the HAL files 20:28:53 there are core_*, *io, *motion, and now possibly *_cl, *_limits, *_debug 20:29:02 *_pid, etc 20:29:15 (not now, but implied by parts of the discussion you referenced) 20:29:44 I'm still not understanding what you are proposing 20:29:53 essentially, this utility would allow you to have multiple .hal files in a single ini-style file (with sections, at least) 20:30:14 have a script of some kind, called from somewhere with certain command line parameters, which reads an ini and does some hal stuff.. 20:30:17 that's all I got 20:30:24 err - OK 20:30:48 so you want to scrap .hal files? and move stuff to the ini? 20:30:52 right now, there is a [HAL] section in the ini file, which contains the names of several hal files 20:30:56 not necessarily 20:30:59 and/or commands 20:31:18 I'd like to make it so that you could have a single .hal file that halcmd only executes a part of 20:31:22 one section at a time 20:31:29 in the order you want 20:31:47 if those sections happen to be in the ini file, that's OK too 20:31:56 if you look carefully at an ini file, you'll see very few sections releated to HAL 20:32:25 almost all sections are related to HAL - all of the axis tuning is, as are the settings for motion (or IO) 20:32:40 grep for [ in the hal files 20:32:46 I can't see why a hal file would have sections called in another order then they were written 20:33:18 it just adds flexibility, and allows you to have non-HAL stuff in the same file (like the ini) 20:33:42 it would allow a single ini file, with sections executed by halcmd 20:33:52 and other sections ignored by halcmd 20:33:57 a single ini file? 20:34:05 yes 20:34:15 though there would still be an nml file, of course 20:34:44 how do you mean a single ini file? there is only one ini file now.. 20:35:01 one ini file, plus all the hal files 20:35:09 btw, I grepped for [ in all hal files, and I only found AXIS_xx 20:35:12 I'm saying that with this, you could put the hal files into the ini file 20:35:23 yep, but a lot of them ;) 20:35:26 [22:30] so you want to scrap .hal files? and move stuff to the ini? 20:35:30 [22:30] not necessarily 20:35:40 now you got me puzzled... 20:35:43 right - it's just one option, but the capability doesn't exist now 20:36:08 that's not the only goal, so I should have said "that's one possibility" 20:36:10 I think what HAL's deficiency right now is, is too much flexibility 20:36:23 yes, and the way we're headed, too many little config files 20:36:39 you could have only one, for what I care 20:36:46 or place the stuff in the ini 20:36:51 you could, but that's not how things are being set up 20:36:56 the user won't be able to use it one way or the other 20:37:01 use/handle 20:37:26 there's a problem in deciding how to do this - on one side, you don't want a 50k config file, on the other side, you don't want 50 1k files either 20:37:31 right 20:37:35 not really 20:37:50 IF you want a user to hand edit these files, then 50 1k files is the way to go 20:38:09 unless they depend on each other, and reference things in other files 20:38:14 IF you want the user to use a tool for that, one 50k file is the way to go 20:38:15 then it becomes more problematic 20:38:28 if you lay it out properly, it should be OK 20:38:35 true either way 20:38:39 like having 45 1k files a user never touches 20:38:49 and 5 1k files the user MIGHT want to change 20:39:07 but it's really a question of semantics 20:39:15 whether it's in a file or in several 20:39:31 some prefer short files, others few files.. 20:39:44 it's kind of a mish-mash now - the ini is there, but largely only because that's what was used in emc1 20:39:50 I get dizzy by looking at a 50k file I never saw before 20:40:00 yeah, that's true 20:40:11 The ini has lots of stuff not related to HAL 20:40:28 and a few stuff that are related to hal, and some which are only needed in HAL 20:40:38 so that's a PITA right now.. 20:40:41 I agree 20:40:42 yep 20:41:05 but having halcmd run sections from the ini .. don't see how that helps.. 20:41:09 it's a bad separation of data 20:41:14 ie, there isn't any ;) 20:41:20 just tossing the dead fish from one place to another 20:41:36 sort of - look at what ray was looking to do 20:41:43 load, then add, then configure 20:41:50 (you or ray or both said that) 20:42:11 ok, only configure MIGHT be interesting in the ini 20:42:26 load and add should not be there (if the user won't change it) 20:42:36 configure can almost be done by the ini, except that halcmd can't ignore the other parts of the file 20:42:47 but then again there are some load's and add's which the user might want to do.. 20:43:12 yes, and they do specify what to load as well, by selecting a basic hardware configuration 20:43:17 how do you do common stuff? 20:43:27 how do you mean? 20:43:33 core_stepper.hal 20:43:41 core_servo.hal 20:43:54 replicate that in every ini file? 20:44:00 what does core_servo do? it loads the PID blocks, and sets the parameters from the ini file 20:44:08 exactly 20:44:29 what if tomorrow the naming of the PID block pins changes.. 20:44:40 wouldn't that make more sense if there were a [SERVO] section in the ini, which loaded the blocks, then had all the "paramx = y" lines? 20:44:40 you'll get a mess 20:45:17 the whole idea was to have common stuff, so you don't need to replicate them over and over again 20:45:22 but doesn't the config chooser copy the core_* files into the "new" directory? 20:45:30 dunno 20:45:52 I think the consensus was that there had to be a separate copy, else a cvs update would trash any customizations the user had done 20:46:41 that's my understanding too 20:46:48 if the namings change anything will get trashed anyway 20:46:59 but probably that's another topic 20:47:00 that was the counter-argument ;) 20:47:11 ok, so back to the issue 20:47:19 the thing is to stuff hal data in the ini 20:47:29 or in a multi-section hal file 20:47:37 what's a multisection hal file? 20:48:01 how's that different from a big file with comments in it? 20:48:04 one that uses the ini-style section names, and looks like a normal hal file in each section 20:48:19 it allows programmatic separation of the sections 20:48:28 you can do that with comments too :P 20:48:33 grep is your friend 20:48:49 you could, for example, have a single large CORE hal file, and choose whether to execute the [STEPPER] section or the [SERVO] section 20:48:58 (not that I'd advocate fro that) 20:49:28 or have an optional [TEST] section 20:50:12 SWPadnos: I must say I'm not 100% satisfied by the way current configs are 20:50:24 yet I'm not convinced that what you're saying will make it better 20:50:42 I think there's too much configuration to have a perfect solution 20:50:46 you might want to prove me wrong.. 20:51:02 well - that's where sed / awk come in 20:51:19 * alex_joni_ silently points to cradek 20:51:26 I can easily construct a regexp that will match a section header 20:51:28 SWPadnos: don't say I sent you 20:51:40 I asked for him first - he ignored me ;) 20:51:54 and another one that will match any other section start 20:51:57 he's busy catching up on sleep :) 20:52:13 it's getting one of those two utilities to print everything in between that's the problem ;) 20:52:20 why not remember the line numbers? 20:52:35 and then use awk to split out inbetween? 20:52:52 possibly not the nicest approach.. but it works 20:53:00 should work anyways 20:53:20 well - awk can be used to find the beginning of the block, then I guess I can set a variable that causes stuff to be printed untile another section is found 20:53:23 who me? 20:53:29 what 20:53:54 SWPadnos: that might work too.. 20:53:55 I'm just looking for simple (lazy) answers about sed and/or awk 20:54:04 ask man :P 20:54:05 ah 20:54:10 I'll try 20:54:44 I suspect that it's easier to get awk to do this, rather than sed, since sed seems to need major contortions to let you span lines 20:54:50 one question, I remember I said I'll do a lot of things while on vacation 20:55:00 but bugger me if I remember one of it 20:55:10 SWPadnos: do what? (I haven't been watching) 20:55:18 grep /path/to/irc/logs vacation ;) 20:55:30 cradek: say you have a ini, and you want to print an entire section 20:55:37 that's what SWPadnos wants 20:55:42 find a regexp, then print everything until another regexp is found 20:56:12 possibly with some modification, if the stuff being printed matches another regexp 20:57:02 % awk '/^RAJ/,/^IS_0/' % awk '/^RAJ/,/^IS_0/' argh 20:57:23 yes - argh 20:57:37 % awk '/^\[TRAJ\]/,/^\[AXIS_0\]/' that's what I meant 20:58:01 ok, or even % awk '/^\[TRAJ\]/,/^\[/' awk has /re1/,/re2/ to act on lines from re1 to re2 20:58:08 ok - cool 20:58:18 I knew there had to be an easier way ;) 21:00:03 SWPadnos: what setup do you have? 21:00:08 kernel & RT ? 21:00:16 BDI 4.30 21:00:22 bugger it 21:00:26 2.6.12-magma, I believe 21:00:34 ok.. 21:00:38 I also have a gentoo machine, but I'm not sure what it's got 21:00:47 it'll also be 2.6 though, I think 21:00:52 any 2.4 anywhere? 21:01:17 don't think so, unless the BDI on my laptop is (around 2.18-2.2x, I think) 21:01:21 me me me 21:01:30 was wondering if anyone wants to look at http://solaris.cs.utt.ro/~emc/emc-1.2.0-rc1.src.tgz 21:01:44 cradek: see, you had to brag :P 21:01:48 arrgh 21:01:54 didn't I already try that? 21:02:07 I changed ini's, so yes you did.. 21:02:15 oh good 21:02:18 guess we should put it up as RC.. 21:02:21 what do you think? 21:02:31 I wish someone else could test it 21:02:36 someone with a complex machine 21:02:36 I'll ask jmk_away if he can run it on the compile_farm 21:02:53 I'll ask Till if he can.. 21:03:02 good idea 21:03:24 alex_joni_: do you remember when you made the spindle turn off when ESC is hit? 21:03:34 in response to my complaining? 21:03:46 I did? 21:03:53 yes, I'm sure it was you 21:04:30 in emc2 21:04:47 ahh yes 21:04:47 I did ;) 21:05:14 I wonder if that change was responsible for also making the spindle turn off when switching to Manual mode 21:05:32 ajoni has joined #emc-devel 21:05:37 alex_joni_ has quit 21:05:45 cradek: : probably 21:05:52 let me look 21:05:52 (bug 1384013) 21:06:07 yeah I know, pondered on adressing that a bit earlier 21:06:15 sorry, you were working on emc1 and I interrupted 21:06:30 I was just going to try to fix it, but I bet you can do it much faster 21:06:35 not really working on emc1 21:06:41 I can do it.. hang on 21:07:21 need to read a bit of emc1 io stuff 21:07:35 fun 21:07:41 cradek: do you have a running emc2? 21:07:51 yes I think so 21:08:04 yes 21:08:07 what gets sent on Esc? 21:08:27 EMC_TASK_ABORT EMC_TOOL_ABORT EMC_TASK_PLAN_SYNCH 21:08:32 EMC_TASK_ABORT 21:08:46 just parsed tkemc, and emcsh and fount it 21:10:22 the ESC key is "motion abort"? 21:10:36 all abort 21:10:42 ok 21:10:50 on mode change EMC_TASK_SET_MODE gets sent 21:11:15 that seems to call EMC_TOOL_ABORT 21:11:38 right 21:11:46 and EMC_TOOL_ABORT stops the spindle 21:11:53 and all other tool relevant stuff 21:12:00 why does SET_MODE call TOOL_ABORT? 21:12:17 SET_MODE calls taskAbort() 21:12:31 emcTaskAbort() 21:12:43 you are in a twisty maze of passages 21:12:57 I want some coffee 21:12:58 brb 21:13:05 to abort all the task was doing? (and that implies emcMotionAbort() and emcToolAbort() ) 21:14:00 I think this is relevant: '16-Feb-1999 FMP changed code for issuing EMC_TASK_SET_MODE to call for 21:14:01 aborts if the desired mode is manual and we're not in manual 21:16:23 and the reason you were not seeing this in emc1 is probably because you weren't running bridgeporttask 21:16:41 because that does exactly the same (sends SPINDLE_ABORT eventually) 21:17:03 EMC_SPINDLE_ABORT even.. 21:18:06 cradek: say when properly caffeinized 21:18:27 ok, it's brewing 21:18:35 read back? 21:18:48 yes I was running bridgeporttask 21:18:53 well let me make sure 21:19:01 and you didn't get an abort? that's ODD 21:19:20 yes bridgeporttask 21:19:30 strange.. 21:19:49 I followed the path in emc1, and it's basicly the same 21:19:59 let me see if my emc1 will run 21:20:36 ok.. 21:21:47 EMC_TASK_SET_MODE calls emcTaskAbort(); 21:22:03 when you enter Manual from MDI or AUTO.. 21:23:04 after that emcTaskAbort() calls emcIoAbort(), which sends an EMC_TOOL_ABORT 21:23:15 oh hell 21:23:18 it does 21:23:22 I'm sorry 21:23:34 I could have sworn I tested it 21:23:45 EMC_TOOL_ABORT is received by bridgeporttool, which sends EMC_SPINDLE_ABORT to the spindle controller 21:23:59 cradek: no problem, just seemed odd as it follows the same paths ;) 21:24:06 may I close the tracker? 21:24:43 I bet I tested it in emc1/sim 21:24:55 looks like it works completely differently 21:25:10 different task controller 21:25:12 for instance you can turn the spindle on AND it leaves the brake on 21:25:12 I think 21:25:22 yeah 21:25:29 bleah :( 21:25:53 yeah, but it doesn't do anything.. 21:26:14 emc1's programming style of "copy some files to a new name and hack out parts" causes me nightmares 21:26:55 yes.. I can't see any good reasons for having that many different files 21:27:07 for instance a spindle controller which talks NML :( 21:27:53 I guess we should close the bug 21:28:03 so the tool controller actually talks to some other controllers .. that's overengineered only to show off NML channels 21:28:19 (but I still don't want that behavior) 21:28:24 ajoni is now known as alex_joni_ 21:28:58 cradek: comment out the emcTaskAbort() call in emctaskmain.cc 21:30:22 but this is another classic example of machine logic embedded in the sources :( 21:31:09 unfortunately, if you take it out of the source, you put it into the config file(s) :( 21:32:26 yeah. 21:32:33 SWPadnos: still better 21:32:47 yep - user configurable, once they can find the right options 21:33:13 users don't need to worry about that 21:33:27 integrator-configurable 21:33:28 only a handfull of integrators might 21:34:06 indeed 21:35:58 ok, I'm up for a fight.. 21:36:04 the bugs are going down :D 21:36:29 DING DING! round 2 has begun 21:36:45 anyone care to help? 21:36:53 it's not fair 1 against many :D 21:36:58 uh - well, I have this bad back, you see ;) 21:37:03 you can always count me in 21:37:18 I may be able to help later in the week - I'm trying to get all my accounting done, and there's a lot of it 21:37:45 but yuck, I see interpreter-related bugs 21:38:09 ok.. I'm looking from the bottom up 21:38:11 _t naming 21:38:22 do we really need that removed? 21:38:44 I don't care one bit about that 21:38:53 cradek: you've done quite a bit of coding.. what's your advice? 21:38:58 nanming is cosmetic, and therefore unnecessary 21:39:01 naming 21:39:11 ok.. so a feature request at the most 21:39:17 * alex_joni_ closes it 21:39:18 to change - of course, names are needed ;) 21:39:43 can you change it to a feature request? 21:39:43 This has been bumped up in priority as it is now a major 21:39:43 stumbling 21:39:45 block before the bdi-4 branch can be joined to HEAD 21:39:47 ???? 21:40:29 oh there's talk about joining bdi4/emc-head in this bug 21:40:29 hmmm - then it may be more important, but for the integration of lathe commands and the like (it's one route, anyway) 21:40:30 yeah, paul's way of stirring up things 21:40:32 that's why it's there 21:40:46 SWPadnos: there is no lathe stuff 21:41:00 G33 is in bdi-4, right? 21:41:03