01:57:06 rayh has joined #emc-devel 02:08:49 jmkasunich: I don't remember; it was a year or two ago 02:09:15 jmkasunich: I think there was a patch file and a tarball on free area of the web site 02:55:51 alex_joni has joined #emc-devel 03:00:11 hello 03:00:56 hi 03:14:56 alex_joni_ has joined #emc-devel 03:15:08 alex_joni has quit 03:15:12 alex_joni_ is now known as alex_joni 03:15:21 hi 03:19:34 Hi steven 03:19:44 hi Ray - how are you 03:19:46 ? 03:20:04 good. 03:20:08 cool 03:20:28 I read your post to the user list (along with the rest of the wiki/docs thread) 03:20:34 good stuff 03:20:41 having a bitch of a time getting the tickle command exec to pass proper args to halcmd 03:21:04 proper how? (or, a bitch how?) 03:21:04 I thought maybe I was being a bit harsh. 03:21:08 nah 03:21:29 the command I want to issue runs like this 03:21:35 one thing though - there's been a lot of progress since the WP5 days - LyX may not be the ideal tool any more ;) 03:22:04 set pascommand 03:22:09 dont even think it. 03:22:12 hhe 03:22:20 Lyx is far beyond xxx 03:22:35 tex and latex are the basis of publication these days 03:22:49 sure - they're very powerful 03:22:51 if you want a fscking word processor 03:22:55 just not as well known these days 03:23:16 Yes that's why I suggested taking a day or two. 03:23:41 It was difficult to get jmk to start using but Hal_xxx looks great 03:23:50 yep 03:23:56 Okay back to tickle 03:23:59 I'm sure I'll nbe the same way 03:24:04 ok - sorry to derail things 03:24:44 nah it's me. set passcommand show param 03:25:14 set passcommand "show param pid.0" 03:25:45 exec bin/halcmd $passcommand 03:26:02 it gets as far as show param pid 03:26:41 I wonder if there's some regexp thing going on 03:27:01 or if the .0 is interpreted to mean something (that happens to be null) 03:27:04 it seems that the . is a reserved character for the exec command. 03:27:41 the tcl wiki suggests this 03:27:43 set url http://ats.nist.gov/cgi-bin/cgi.tcl/echo.cgi?hello=1&hi=2 03:27:44 exec [file join $env(COMSPEC)] << "start \"\" \"$url\" \n exit \n" 03:27:55 but I don't have a clue what that means. 03:28:02 heh 03:28:42 I have an idea that join is doing the work and the \"$url is the heart of it. 03:29:02 I will try that. 03:29:16 I'm looking at the O'Reilley TCL book now 03:29:59 rayh_ppmc_usc has joined #emc-devel 03:30:36 rayh is now known as rayh_away 03:30:41 try set passscommand {{show param pid.0}} 03:31:11 think I did. 03:31:15 hm 03:31:25 gotta fire up emc 03:31:59 Starting emc... 03:31:59 iniFind is depreciated 03:32:05 gets me every time. 03:32:18 yeah - it keeps losing book value 03:33:19 have you tried escaping the '.'? 03:37:48 HAL:0: Unknown 'show' type 'show param {{pid.0.stepgen}}' 03:37:55 funny 03:38:24 did you put that in quotes? 03:38:49 with single {} i get HAL:0: Unknown 'show' type 'show param pid.0.stepgen' 03:39:12 let me try dcc to you of the file. 03:40:09 rayh_ppmc_usc has quit 03:40:39 I'm playing in tclsh 03:40:59 rayh_ppmc_usc has joined #emc-devel 03:41:14 that didn't work 03:41:24 heh - nope ;) 03:41:49 ok - here's the problem 03:42:11 when you pass the command in as one string, that's what halcmd sees it as - one string with those spaces in it 03:42:22 I'm not registered as this nick 03:42:32 tcl doesn't use the normal shell exec, it does its own thing 03:42:46 right. 03:43:23 do halcmd doesn't understand "show param pid.0' as a command (like help or show ...) 03:43:28 s/do/so/ 03:43:33 someone suggested issuing a /bin/sh and then pass the arg 03:43:47 yes. 03:43:55 when I issue it in a terminal 03:44:22 let me look at the wiki once more. 03:45:34 http://wiki.tcl.tk/4304 03:46:30 can you pass an array as the command line params? 03:46:34 the set shell may work but if I'm opening a socket I may as well make it to halcmd 03:46:59 yes - if you echo the command to halcmd, that should work 03:47:23 could you explain that a bit more. 03:48:15 if you spawn "bin/halcmd -kf", and capture stdio to a pipe in tcl, then you should be able to print strings to the pipe, and halcmd should execute them 03:49:32 Right I've tried a bit of that. But it is not a natural thing for me to do. 03:49:40 ok 03:50:09 it also won't be perfect yet, since halcmd doesn't always give notification that it's finished with a command 03:52:56 I've read a bit about dumping buffers. 03:53:25 but I liked the single command use of halcmd better 03:53:54 and you don't have to fear about closing emc before you close the tickle 03:54:16 it's easier to understand, and less prone to startup / shutdowm difficulties 03:54:18 right 03:54:54 hmmm - an array may make some sense, actually 03:55:27 (excuse any not-quite-right TCL - I don't know the language) 03:55:29 make an array with all of the commands you want to pass 03:56:17 no - I'm thinking one with command, option, name elements 03:56:42 then exec bin/halcmd $cmd(command) $cmd(option) $cmd(name) 03:57:57 tickle doesn't do arrays real well but something like array(1.2.3,4) 03:58:49 exec bin/halcmd $cmd $option $arg 04:00:15 out of curiosity, why are you trying to build the entire command into one string? 04:00:46 I pass the string to a process 04:01:18 after I get one running, then I'll ask it to search for a running emc 04:01:26 look for the type of servo card 04:01:33 and make a set of tuning pages. 04:01:56 can you pass several vars instead of just one? 04:02:22 (like the $cmd $option $arg line above) 04:02:46 or is this not a tcl "process"? 04:03:01 I know that. Just not comfortable with variable number of args. 04:03:33 always pass all of them - just set option to "" if you don't need it 04:03:51 right - neverminf 04:03:52 d 04:04:01 and halcmd is not real friendly. Man readable but not friendly. 04:04:06 nope ;) 04:04:24 I talked to jmk yesterday about the filtering stuff 04:04:40 Where exec seems to trip up is when I put the . in. 04:05:09 to that point it hands the command to grep or whatever halcmd uses 04:05:23 and will spit out the reply. 04:05:28 I don't think the . is the problem 04:06:03 then why do I get a different answer when I issue the command from bash 04:06:16 than I do when I issue the same aparent command from exec 04:06:27 because tcl is sending the entire string as the first argument to halcmd 04:06:51 it sees one item on its command line, and tries to interpret that as a command (help, show, list, etc) 04:06:56 No halcmd is happy to return the result of "param pid" 04:07:07 not from tclsh 04:07:16 sure 04:07:39 it just won't return "param pid.0 04:07:47 as a special case. 04:08:03 does 'param pid' work? 04:08:11 either of those returns the error "HAL:0: Unknown command 'show param pid'" 04:08:11 yes. 04:08:17 (or pid.0) 04:08:25 no I get an answer 04:08:25 in tclsh anyway 04:08:29 odd 04:08:32 in tcl 04:08:34 indeed 04:08:56 let me switch to the box and get a return 04:09:09 I'd like to see what the halcmd error is also 04:09:25 there is no error if I set it up right. 04:09:53 I just don't get the limited return that I want. 04:10:09 I get back all of bin/halcmd show param pid 04:10:24 rather than bin/halcmd show param pid.0.stepgen 04:11:33 If I start a terminal and ask for watch bin/halcmd show param pid.0.stepgen I get a really nice display of what I'd like to see in the tuning screen. 04:11:40 course I don't need watch 04:12:08 cause I can loop the update 04:15:31 is there a pid.0.stepgen ? 04:15:41 don't remember such a name 04:16:25 ppmc.0.stepgen ;) 04:16:42 ahh.. ok, got confused 04:16:56 that's the closest I can think of 04:17:02 Hey I think your idea of multiple args may get be there. 04:17:08 brb 04:17:11 ok 04:17:23 Nah I'm confusing two different modules 04:17:26 I've got to go for a while. see you later 04:17:36 pid.0 or pid1 04:17:43 for one view 04:17:54 and axis.0.xxx for another. 04:18:24 SWPadnos_ is now known as SWP_Away 04:19:21 wah. Thank you steven. It works great. 04:24:42 nice to hear that 04:39:15 rayh_away is now known as rayh 05:12:22 rayh_ppmc_usc has quit 05:18:41 alex_joni_ has joined #emc-devel 05:18:50 alex_joni has quit 05:18:53 alex_joni_ is now known as alex_joni 08:03:10 petev has joined #emc-devel 08:20:06 petev_ has joined #emc-devel 08:36:36 hi pete 08:36:44 hi alex 08:37:02 seen lots of talk of you & jmk about TP 08:37:10 yes 08:37:18 petev has quit 08:38:16 also lots of talk between dmess & les_w on #emc today 08:38:22 yes 08:38:37 ok.. just pointing it out 08:51:23 chris: can you point me out what the difference in cradek_stable from a RUM-free HEAD is? 08:53:40 alex_joni: I'm not sure what a RUM-free HEAD is 08:53:49 alex_joni: do you mean the base of the stable branch I made? 08:53:53 current HEAD without the RUM changes 08:54:01 alex_joni: I say that only because I don't know what has been added to HEAD 08:54:02 or you didn't follow HEAD 08:54:06 OK 08:54:08 gotcha 08:54:25 only about 10 commits in the last 6 months.. so no worries 09:30:46 rayh has quit 09:32:17 rayh_usc has joined #emc-devel 10:06:06 hiya Ray 10:06:29 Hi steve 10:06:39 so - you got it working - that's great 10:06:42 Your multiple args solved the problem for me. 10:06:46 cool 10:06:53 swp: any thought on the interp base class? 10:07:03 Got the start of a tuner going now. 10:07:12 petev_: haven't really looked at it yet - sorry 10:07:31 ok, got an optimized version that's 3x as fast as what I sent you 10:07:34 rayh_usc: is tcl smart enough to pass all the elements of an array when you exec? 10:07:38 hhe - cool 10:07:40 heh 10:07:55 you've got a usc board. as soon as I get a bit further I'l send to you for your opinions and code 10:08:04 cool 10:08:16 Yes I think so but will have to test a bit first. 10:08:41 sure - testing makes perfect ;) 10:10:51 alex_joni_ has joined #emc-devel 10:11:09 alex_joni has quit 10:11:14 alex_joni_ is now known as alex_joni 10:11:21 SWP_Away is now known as SWPadnos_ 10:11:59 actually - test programs for each card can be made fairly easily 10:12:02 test / tuning 10:13:10 but it would be better with a hal access library, rather than 'exec'-ing halcmd all the time 10:16:02 I suppose that's true but exec gets around the shutdown issue. 10:16:20 It can be a mess to clean up an improper shutdown. 10:16:34 I was thinking more like a library that you load, and have direct functions for the things you're execing now 10:16:52 not a piped interpreter like we were talking about before 10:18:24 I have no clue how that would work. 10:18:34 which - the pipe or the library? 10:18:35 swp: does tcl have bindings for other languages? 10:18:48 Sure about 50 or more 10:18:52 I think you can make tcl bindings for "C" libraries 10:19:08 hmm, I thought tcl was just interpreted by wish 10:19:13 not this you 10:19:19 is there a way to tell wish it's a C binding? 10:19:30 sure. 10:19:34 lots of em. 10:19:44 that's what we are using in emcsh and iosh 10:20:00 These are both expanded wish shells 10:20:09 no, emcsh is a C program that interprets stuff from the GUI 10:20:26 ok, expanded wish 10:20:45 so not really a tcl C binding mechaism built in at all then 10:20:46 but you can use external packages as well 10:22:22 I wouldn't know the difference. Sorry 10:22:55 isn't tk a C library that's used by tcl? (for the most part) 10:23:10 while both of u guys are here, what are your thoughts on being able to support interpreters other than g-code? 10:23:25 swp: I don't know tcl/tk at all 10:23:41 me either - I've just got the O'Reilley book ;) 10:23:49 canterp is in there now 10:24:03 I'd like multiple interpreters, but I'm not sure how far we can realistically go with that 10:24:12 The front end to canterp is "step" 10:24:13 at some point, the interp ends up being a CAM program 10:24:22 is that STEP? 10:24:27 yes 10:24:42 I thought there were patent or copyright issues with STEP 10:24:46 and I hear screams that STEP is proprietary 10:25:06 yep 10:25:08 NIST got an agreement from STEP that what they do will be open. 10:25:15 the reall issues are with g-code specific stuff being exported to the task an UI APIs 10:25:30 I'd like to be able to load an STL file, myself. but that goes way beyond an "interpreter" 10:25:50 well - it's not necessarily G-code specific (some is, but some isn't) 10:26:06 relative coordinates - could be used in non-G-code interps 10:26:09 so, can we generalize stuff like active Gs, Ms, etc. to make them non g-code specific? 10:26:12 Well Bob and weber has been working on EMC operation from inside his display. 10:26:19 at 10:28:13 think of them as machine states - they may have different words to describe them (in different lagnuages), but they're the same thing 10:28:17 ray, I'm looking at canterp, and it implements a whole new emc task 10:28:30 swp: yes, that's what I'm thinking 10:28:34 so a G-code front end would look at metric units, and say that the machine is in G21 mode 10:28:44 but now they are all gcode specific all the way to the UI 10:29:02 the GUI and the interpreter need to be fairly closely linked, I think 10:29:08 swp: but that builds g-code knowledge from the interp into the UI 10:29:11 (it's a bummer - I'de prefer if that weren't the case) 10:29:17 what if G21 was something else? 10:29:24 night all 10:29:27 alex_joni has quit 10:29:39 what I'm saying is that the machine says to the GUI (or interp) "I'm in metric units" 10:29:54 and the interp (or GUI) tells the operator "the machine is in G21 mode" 10:30:07 because that's how the G-code interpreter interprets metric 10:30:07 yes, but take a case where the G code isn't as standard is all I'm saying 10:30:20 the UI is guessing at what the g-code is for that machine mode 10:30:28 prp 10:30:38 right - in SteveCode, it might say "the machine is using 1000 micron units" 10:30:46 yep 10:30:54 no - the GUI asks the interpreter to tell it the machine state 10:31:06 the interpreter becomes a forward and reverse interpreter 10:31:21 hang on 10:31:26 it looks at the machine state, and converts to the names for that "language" 10:31:35 so right now the interp has status that needs sharing with the GUI 10:31:56 if we generalize this status, how can the GUI show it in languague specific terms? 10:32:09 unfortunately, I can't continue now - will you be around in a few hours? 10:32:21 no, but later tonight 10:32:34 ok - that should be good - let's take it up then 10:32:34 tomorrow as well 10:32:38 yep 10:32:39 ok 10:32:47 see you later (time to eat! ) 10:32:51 SWPadnos_ is now known as SWP_Away 11:07:15 petev_ has quit 11:09:09 part 11:09:13 rayh_usc has left #emc-devel 13:27:29 SWP_Away is now known as SWPadnos_ 14:36:43 rayh has joined #emc-devel 14:36:53 hiya Ray 14:37:15 Hey wot's going on? 14:37:24 I have no idea 14:38:00 been there still there. 14:38:05 heh 14:38:15 at least I know I don't have far to fall ;) 14:38:32 right. 14:38:52 Now that i've got this first set of screens running 14:39:08 I'm thinking of expanding a bit. 14:39:18 which direction? 14:39:33 stomach of course. 14:40:00 heh 14:40:05 i can get the tuning stuff fairly easily 14:40:27 The next step is a big one -- changing links 14:40:56 like - insert PID hare, or "unhook that so I can play with it" 14:41:03 s/hare/here/ 14:41:13 remember that qconfig that got attributed to me but was all your work? 14:41:20 heh -yep 14:41:26 (and Alex) 14:41:51 We had talked about using that for HAL config, didn't we? 14:42:17 yes - sort of 14:42:23 I think it was more for ini config 14:42:38 oh okay 14:42:53 I don't think it would have been possible to make it capable of configuring HAL - there are too many possible connections 14:43:04 it was also for setting build options, just like in the kernel 14:43:13 (though that isn't really needed these days) 14:43:18 Right I remember that 14:44:56 anyway - about your extensions (of the TCL kind) 14:45:21 I'm willing to postpone that build options for a bit but when we've got a hundred different drivers I'll be back. 14:45:30 heh - yeah 14:46:29 It would be possible to start up an emc2 with little to no hal other than iocontrol and it's cousins 14:46:53 nothing connected nothing threaded. 14:47:06 yep 14:47:34 and with a few choices add the stuff an integrator wants to add. 14:47:48 ah - right. I think I see where you're going 14:47:53 ppmc or mesa or parports 14:48:47 sure - select steppers or servos -> interface (parport / ppmc / servo card) -> scaling (encoder res, steps/inch) -> tuning .... 14:48:52 Since I've got the ability now to show stuf as it's added. 14:49:28 HAL becomes its own resource for available pins, parms and such 14:49:33 yep 14:49:58 I would want to separate the load commands into a file by themselves 14:50:08 the only information you don't have (until you connect everything), is the order you should run the functions in the various threads 14:50:26 True 14:51:47 why load separately? I'd think that it would make more sense to load a hal component / driver or two, then make the connections you know need to be made, in that file 14:52:13 that way, you could snap out one driver for another, and many of the pin names would go along with the load of that driver 14:52:36 Yes but halcmd can spit out a hal file only it won't contain the loads 14:53:17 ah - so you'd load a module, tell the user to connect what they want, then halcmd save to get the connections / params 14:53:19 and you can not reload using -f ?filename? if it does contain the load info 14:53:44 sure - the loads need to be somewhere 14:54:39 I could see side by side screens with iocontrol in one and a parport in the other 14:55:02 or motion and a parport 14:55:16 or motion and pids 14:55:21 yep 14:55:34 of course, the trouble is filtering ;) 14:55:51 It isn't quite the visual schematic that jmk was thinking about 14:56:15 nope, but it's a good start 14:56:19 filtering? 14:56:34 I'm not sure how long ValarQ will take with halgui 14:56:59 yeah - you would want to sort the pins/params into various groups 14:57:03 input or output 14:57:10 bit / byte / float 14:57:15 I've looked but don't read any python so .... 14:57:19 no - me either 14:57:41 certainly grouping is essential 14:58:06 some of this can be seen by looking at the show sig xxx 14:58:20 well - show pin/param xxx 14:58:30 sigs need to be created by your program 14:59:07 linkpp does some of that for you 14:59:17 treu 14:59:21 true, even 14:59:46 depending on how difficult it is, I have an idea for dealing with these things 14:59:54 well - I have an idea anyway 15:00:11 * rayh is all eyes 15:00:26 when you load a component, there are 4 kinds of I/Os 15:00:42 input or output pins, and read or write params 15:01:02 yes 15:01:04 an output pin can't be connected to anything other than a signal (and then only one that has no other output connected) 15:01:57 unless or... is interposed 15:01:57 so, for output pins, you either place no user-settable control, or if you're nice, you can place an edit box next to each one, so the user can name a signal that the pin should drive 15:02:30 write params aren't important for this application, so they can be ignored 15:02:41 (write meaning that the component writes to them) 15:03:43 I'll have to study the motion modules a bit more before that becomes clear to me. 15:03:46 read params need to be editable, ideally from a checkbox (for bits), or a range-limited numeric (for integer types), or a float editor 15:03:51 I'll explain in a bit 15:04:26 the easiest is to just have an edit box, and let teh user type on / off / 0 / 1 / true / false for bits, rather than choosing a control based on the type 15:05:18 the last type is the input pin, and what that needs is a drop-down box with signals and/or output pins of the same type 15:05:31 choose one, and the pin gets connected there 15:05:48 that's all four, right? 15:06:59 any questions? 15:07:11 lots but I see where you are going. 15:07:14 heh 15:07:57 actually - I'm there already - that's it except for some possible filtering enhancements (don't show pins on the same component in the input dropdown boxes, etc) 15:08:28 except for the loopback conditions. 15:08:43 sure - OK. it's easier to leave that out anyway 15:09:13 I'm not sure you connect loopbacks externally, but you could, I suppose 15:09:37 I'm recommending that for all signals from EMC 15:10:14 ah - right. the motion enable stuff 15:10:22 don't know that I'll get my way though. 15:10:43 I've already tried pouting, crying, stamping my feet.... 15:10:59 I guess flying off the handle is your last option 15:11:11 that is pretty severe. 15:11:25 "or I'll take my ball and my bat, and go home!" 15:11:57 can't hardly do that, to many irons depend upon this emc fire. 15:12:34 remember though that you can't drive a signal from more than one output pin, so looping back within motion means that no machine state can come back to emc 15:12:56