00:18:41 jmkasunich has joined #emc-devel 00:26:20 this is damned annoying 01:57:39 rayh has joined #emc-devel 01:57:47 evening ray 01:58:46 Hi guys. I just put a little tarball in www.linuxcnc.org/dropbox/tree_test.tgz 01:59:03 what kinda goodies are in there? 01:59:27 It will at least let you see what the tree widget looks like and a bit of how it works. 01:59:44 It will display some hal info if a hal is running. 02:00:00 But it does not build it's tree display from hal yet. 02:00:31 I need a few opinions about what you see there before I expand it to a real display. 02:00:51 Say jmkasunich Thanks for the formatting line. 02:00:54 so I should go take a look? 02:00:58 I put that in the file as well. 02:01:01 you're welcome 02:01:05 saw that commit 02:01:53 where should I untar the tarball? 02:02:33 in emc2/tcl/bin 02:02:48 You wind up with a bit of a readmen in there but ... 02:02:53 readme 02:03:38 Then if you run it from emc2 while running a hal it should show you stuff. 02:04:10 The nav between tree and info is what I'm thinking works pretty well. 02:04:33 crappy layout but it was done just for the testing. 02:04:46 untared, about to try it 02:05:49 compare clicks on the + box and clicking on a node name. 02:05:55 gotta do a cvs up, my configs are screwed up 02:06:04 oh right. 02:06:16 alex was working on that yet this afternoon. 02:06:18 step_cl doesn't have an ini file right now? 02:06:30 don't need sudo to run 02:06:51 The updated should. 02:07:01 * rayh looks 02:07:38 need to add "demo" on front 02:07:41 yes scripts/emc demo_step_cl should get a system running 02:08:14 we may want to change that cause they all should be demo in the repository. 02:08:45 the configs are gonna be in a state of flux for a little bit ;-) 02:09:41 Error in startup script: can't find package BWidget 02:09:42 while executing 02:09:42 "package require BWidget" 02:09:42 (file "tcl/bin/tree-test.tcl" line 6) 02:09:43 John@main:~/emcdev/emc2head$ 02:09:57 oh yea. 02:10:07 frickin dependencies 02:10:31 No kidding. I wish tickle had tree abilities. 02:11:05 so what do I do now? 02:12:00 let me find you a link. Sorry for the delay. 02:12:05 s'ok 02:12:15 I'm tcling on my thing, so no rush 02:12:27 ohh, that came out wrong :-/ 02:12:28 hi guys 02:12:40 * jmkasunich hides 02:12:55 nope - not necessary tonight ;) 02:14:40 bwidget is used by Axis. 02:14:56 then how come I don't have it? I've run axis 02:15:08 probably cant find it. 02:15:13 the python version maybe? (if there is one) 02:15:23 silly tcl interp.... 02:29:24 damn, I have to say, the linux tcl interp is a lot nicer than the doze one 02:29:42 actual meaningfull error messages, with the source line number even... what a novel concept 02:34:34 I confess looks like I got bwidget as a part of vtcl 02:35:12 but there is a /usr/lib/bwidget directory that looks a lot like the bwidget one in axis. 02:38:48 no /usr/lib/bwidget here 02:42:06 trying a link to axis in another box. 02:45:06 sure that works. 02:45:15 find your axis install 02:45:44 you mean the one that gets uninstalled every time I make clean emc2? 02:45:46 ;-/ 02:45:48 look for thirdparty 02:45:59 That's probably it. 02:46:24 directory and you'll see bwidget directory. 02:46:38 there is some magical incantation to make axis, which I don't remember 02:46:51 link from that directory to /usr/lib and it should find the package. 02:47:16 env EMCROOT=/path/to/emc2 python setup.py install 02:47:21 looks just a bit different than it does on this box but not bad. 02:47:37 possibly with a semicolon in there somewhere ;) 02:47:42 ok, found ~/emcdev/emc2head/src/axis-20051202/thirdparty 02:48:07 so I want to go to /usr/lib and make do what? 02:48:28 ln -s bwidget ~/emcdev/emc2head/src/axis-20051202/thirdparty/bwidget ? 02:49:39 * jmkasunich doesn't do much with links 02:50:16 I start two file browsers and drag and drop 02:50:28 clicky clicky ;-) 02:50:37 * rayh hangs his head in shame. 02:50:52 well, I don't know how to do it either 02:51:08 the only diff is that the cmd line way is easier to explain over IRC 02:51:17 Yes it is. 02:52:33 ok, got a symlink 02:52:35 trying again 02:53:20 working this time 02:53:28 * jmkasunich goes clicky clicky 02:54:33 There is a sorta tree widget in the blt tool kit as well and that one is on the BDI 02:54:35 I see the tree, no params on it for some reason 02:54:47 You could make one. 02:54:49 what are the buttons for again? 02:54:54 click param on the buttons 02:55:05 ok, its red 02:55:07 type axis.0 in the upper entry widget 02:55:21 type encoder in the lower entry widget and press test. 02:55:53 I don't even know if that is a good param name but it will show. 02:56:25 I see, you tell it what branch you want to look at, it doesn't discover the branches 02:56:49 Not right now. I was just working on the logic of nodes, subnodes, .... 02:57:00 but how did it come up with the signals? 02:57:07 did you hard code that or something? 02:57:15 The halcmd list will be able to do that 02:57:27 yes there is a stack of em at the bottom of the script. 02:58:10 interesting 02:58:11 If you have a running emc2 you could expand iocontrol and pick a leaf 02:58:35 shows it in the white box 02:58:39 click the name and you'll "show" that pin 02:58:43 (wrapped - the box isn't wide enough) 02:59:00 You can click "pins" and it will show all pins 02:59:26 you can scroll the white area with mouse wheel 02:59:34 yes 02:59:44 it needs to be wider tho, so they don't wrap 02:59:45 you can scroll the tree with mouse wheel as well. 02:59:53 either that or a horizontal scrollbar 02:59:55 so true. 03:00:18 wrapped by word they look like signals. 03:01:10 is the stuff displayed in the white just raw out of halcmd, or are you parsing and re-assembling it? 03:01:23 raw from show 03:01:43 the -s show condenses it a bit. 03:01:54 yes 03:02:07 I was wondering how much overhead we would cause if we 03:02:29 showed each leaf in turn and looked for true or false and changed the 03:02:44 forground text color rred for true black for false 03:02:54 depends on how often you poll it 03:03:08 right now it only calls halcmd when I click on it, right? 03:03:36 yes and you can see the signals change by re clicking the name. 03:03:50 right, but no automatic update 03:03:59 you can use awk or something to make the show output in the form of "pin_name value", which could be useful for array-like processing 03:04:01 No 03:04:24 can you find a node by name? 03:04:34 (with bwidget) 03:04:36 Yes and if you got all pin names from a single run of halcmd 03:04:45 that should be pretty efficient. 03:04:50 yep - that's the udea 03:04:52 idea 03:05:03 The leaf names are the pin or param names 03:05:14 including everything up to the root? 03:05:26 right now my tree has two 'axis" branches 03:05:28 ie, ppmc.0.encoder.00.value 03:05:34 with a pin. or param. in front. 03:05:37 ok 03:05:53 pin.ppmc.0.encoder.00.value 03:06:17 ok, and param.ppmc.0.stepgen.00-03.pulse-width 03:06:28 For these complex ppmc names do we need another node level? 03:07:06 is it just a single beanch now (all pins under one root node, all params under another)? 03:07:11 branch 03:07:13 I don't understand why you make the user specify the nodes 03:07:26 because there's no automatic parsing yet ;) 03:07:29 heh 03:07:47 suggestion: branch every time you encouter a '.' in a name 03:07:53 I was just giving you a device to see how node names might interact 03:08:07 It makes a really wide display 03:08:10 it;s a "Technology Demo" 03:08:14 ok 03:08:30 param.ppmc.0.stepgen.00-03.pulse-width has 6 levels 03:08:43 As you can see by clicking on a signal you don't get the same response. 03:08:46 is this file in the dropbox? 03:09:04 In fact only pin and param respond like I planned. 03:09:20 at present, none of our configs use '.'s in their names 03:09:24 But you can look at funct or thread or components 03:09:24 might want to change that 03:10:03 You want to show files using this also. 03:10:19 we could do that with the xxx_ss.hal 03:10:45 IMO this needs auto parsing 03:11:00 That is the plan. 03:11:30 the tree layout is interesting 03:11:32 the suggestion that each . be another depth of node is one concern. 03:11:38 why? 03:12:03 Just the number of times you have to iterate each pin/sig name 03:12:18 I'm assuming autoparse 03:12:21 the algorithm is pretty easy 03:12:26 for autoparse 03:12:30 so when you open it, you have a tree already built 03:12:47 and you can dig right down 03:12:49 I don't think you quite understand the implications of a 6 deep node array 03:12:55 heh 03:13:05 nasty in tcl? 03:13:14 does it use a real tree, or is it a multidimensional array? 03:13:16 You'll have to have an enormous window to see anything significant. 03:13:34 how do the subnodes show up? 03:13:42 are they aligned with the roght of the parent? 03:13:46 right 03:14:17 You have some control over both the vertical spacing and horizontal offset 03:14:17 swp: think windows explorer dir tree, with '+' and '-' to open/close subtrees 03:14:20 each level in the tree should only print a line and a little space, about 2-3 characters worth of indentation 03:14:31 ok - that's what I'm thinking 03:14:55 but 6 deep should be less wide than the pin name itself 03:15:06 Yes but you've got to remember that these are not short pin names when you get to the leaves 03:15:09 or about the same, at least 03:15:17 I was thinking maybe the one big window, and once you open down to unique pins, the value appears right there 03:15:22 the name in each leaf shouldn't include all the parent information 03:15:32 that's known because of the position of the leaf 03:15:32 instead of having another window 03:15:36 It doesn't. 03:15:36 exactly 03:15:40 in the sample 03:15:50 where's the sample? (in the dropbox?) 03:16:00 the name of the node can be different from the text displayed for that node 03:16:06 Yes. 03:16:06 yes 03:16:08 ok 03:16:12 tree-test.gwz 03:16:27 ok (gwz?) 03:16:33 tgz 03:16:36 some zippy thing 03:16:43 goes in tcl/bin? 03:16:47 yeah 03:16:47 gwhizz 03:16:55 and you need the bwidget thing 03:17:29 boy am i glad cradek and jeppler put that in their gui stuff. 03:17:41 otherwise I'd be accused of bloat again. 03:17:45 heh 03:18:30 It would be easily possible to have more than one tree. 03:18:40 these hal elements could be one 03:18:46 GTK also has tree widgets 03:18:49 files could be another 03:19:06 and a listing of all the wizard components could be the third. 03:19:30 ray is going tree happy ;-) 03:19:46 This would give us a single sort of navigation thing for all of the wizard. 03:20:36 I'm not sure a list of wizards is inherently hierarchical... and using a tree for non-hierarchical data seems a bad fit 03:20:56 hal and ini stuff is hier-whatever 03:21:04 that word is hard to type 03:21:34 I imagine a hier... based on starting to make a HAl from scratch. 03:21:49 Here are the available modules 03:22:09 want to add motion from emc? 03:22:14 oh, ok 03:22:18 I misunderstood 03:22:20 How about io from emc? 03:22:23 that sort of thing. 03:22:40 I thought you meant a tree to select the ini wiz vs the hal wiz vs the cl wiz... 03:22:46 which seems like overkill 03:23:25 Probably that is although it is attractive to be able to edit or write changes to all of those. 03:23:43 I wish there were a tk front end to cl. 03:23:57 * jmkasunich runs away 03:23:59 you have to have a running emc, with any hardware you might want to configure, fot the config from scratch thing to work 03:24:00 where is petev when we need him. 03:24:08 or at least realtime 03:24:48 I suppose we could make a tickle container frame 03:24:51 SWP: idealy, you'd load modules (from the GUI) and their pins would appear 03:25:02 and figure out how to get the ladder display into it. 03:25:05 that only happens if you have the hardware connected 03:25:19 and you specify the correct command line parameters, for those that need them 03:25:44 That is one real advantage of building a HAL system with hal running. 03:25:47 ray: I certainly hope tcl/tk can wrap itself around GTK windows/apps, because any serious HAL tools I build will not be tcl, they'll be C + GTK 03:26:02 not just HAL, but also the hardware, like a ppmc, that you want to configure 03:26:13 SWP: the wiz should help you with that 03:26:24 start with a list of supported HW 03:26:38 you pick a driver, it attempts to load it and sees what happens 03:26:40 it can't - the HAL module either won't load, or it won't export the right pins without the hardware 03:26:45 "I'm not finding a univpwm card out there on any of the parports!" 03:27:05 then maybe you don't have one and should try another choice ;-) 03:27:08 I did find a univstep 03:27:09 yes - you can report that it didn't work, and that's good 03:27:32 but what if I'm trying to create a config for someone else? (not a huge problem, but definitely annoying) 03:27:33 and if it does, you get instant access to the pins and params of it. 03:27:39 if the guy thinks clicking on a STG is gonna make an $800 card appear in his computer, he needs more than a wizard, he needs a shrink 03:28:02 SWP: then you type into a hal file like a real man ;-) 03:28:15 ugh - put hair on chest! 03:28:19 actually, we might want to consider a "fake it" mode for the drivers 03:28:37 that' what I was thinking, though the complex ones may have a hard time 03:28:38 "export your pins, but don't do any RT stuff, and don't touch the HW" 03:28:40 That would assume a card data file. 03:28:52 the driver is a card data file 03:29:03 but for something like ppmc, the driver exports based on what it finds 03:29:11 the driver knows what it's supposed to do, you pass a param like "simcfg=0x378" 03:29:19 I don't like the idea of an offline driver at all. 03:29:24 you;d have to tell it "pretend that you have boards a, b, c" 03:29:25 yeah - you'd have to select the right one - it gets hairy 03:29:41 I don't either, but I was responding the SWPs situation 03:30:03 anyway - that's my conundrum for the evening ;) 03:30:12 answer: buy more hardware! 03:30:20 I've got more hardware! ;) 03:30:30 actually, there is another possbility 03:30:36 (USC, G-Rex, m5i20 ...) 03:30:46 You guys might be able to fake a stg hal setup but I'd bet 100 to 1 mine wouldn't work. 03:30:51 a driver called "dummy", runs in userspace, reads a file and exports the pins listed in the file 03:31:01 nothing whatsoever behind the pins... 03:31:18 but you can sit there and hook them up, and save the .hal file 03:31:31 And everyone would be saying, rayh you need to run dummy! 03:31:41 run dummy, run! 03:31:59 poor choice of names 03:32:12 Nah it works great. 03:32:26 hey, dummy - run this 03:32:31 then you'd wind up with a bunch of pin list files 03:32:35 oops, I mean "hey, run this dummy" 03:32:38 stg.pinlist 03:32:43 usc.pinlist 03:32:45 etc 03:33:04 we can generate those with the proper hardware, but things like unit numbers will be wrong 03:33:06 Those files could be right in the configs/stg directory 03:33:16 we could put in specific %xx markers for those though 03:33:24 yes 03:33:52 blocks would be a pain, but once we can instantiate after load, that'll be relatively painless 03:34:02 heh, here a wild thought 03:34:15 there's got to be a way to ask a module what params it can take 03:34:32 (load-time parameters, that is) 03:34:49 for any driver, I can write a .vcp file, that exports the same pins, and displays lights and buttons on screen instead of real HW 03:34:51 wild thought? 03:35:08 * SWPadnos_ starts to have maintenance nightmares 03:35:11 rayh: I dunno how much you know about .vcp 03:35:40 something I'm working on in the background when not doing stuff for the release 03:35:52 * rayh admits ignorance once again 03:35:54 think ioshow on steroids 03:36:12 Okay. 03:36:33 a fairly simple file format that lets you place widgets like LEDs, buttons, etc, in a window, but each widget has a HAL pin 03:36:42 more like an ioshow development kit ;) 03:36:56 so I can make an on-screen pendant, or a fake parport, or whatever 03:36:56 that would be great. 03:37:14 so far I have the core parser/builder working, and buttons work... LEDs are next 03:37:17 I did that with dio_exercise 03:37:58 sort of 03:38:35 I was hoping to demo vcp soon, but it looks like I should aim for emc2.1 03:40:19 * jmkasunich goes back to tcl config stuff 03:40:24 Now if you could just build into the stg.vcp all of the sim stuff like motor and driver and encoder stuff from emc. 03:40:52 I can't simulate behavior, just IO 03:41:19 a motor/encoder simulation module is on my to-do list, but pretty far dowm 03:41:40 2.6 03:41:40 actually - CL-type stuff would be a really useful thing 03:41:58 you would load the module to do the behavior, then use vcp to observe and interact with it 03:42:02 so you can disable some controls based on pin/signal state 03:42:30 do you have "disable" inputs on the controls as well as the normal HAL data pins? 03:42:53 no - a vcp button always drives its hal pin 03:42:55 (last question, then you can get back to config trees ;) ) 03:42:57 ok 03:43:05 push it, pin goes tru, let go, pin goes false 03:43:14 just like a real button 03:43:19 toggles also? 03:43:19 Sounds great. Wot no toggle? 03:43:27 toggle buttons are on the list 03:43:36 beat ya. 03:43:42 I suppose us other programmers could add that kind of thing later 03:43:44 now that the skeleton is done, adding new widgets is pretty easy 03:44:13 toggles would be very easy, but I want a display widget before I spend any time on additional control widgets 03:44:29 Shall I expand it so that each . gets a new level of node. 03:44:30 I'll add toggles, its just a matter of a couple hours 03:44:37 but LEDs are first, and they are more complex 03:44:43 because you have to paint on the screen 03:44:49 heh 03:44:56 samea s sliders and stuff 03:45:12 sliders are native GTK widgets, they'll be easy 03:45:19 take a look at the tk stuff in ioshow 03:45:20 so will numerical analog displays 03:45:30 bargraphs will be similar to LEDs 03:47:10 rayh: where is ioshow 03:47:26 I have an emc1 checkout... but I don't know that tree at all 03:47:30 tcl/scripts/IO_Show.tcl 03:47:39 emc2 03:48:02 and it will run with the stock emc -- or would a few days ago. 03:48:41 I just tried to open it from the scripts menu of tkemc (my emc2 is still running from before) 03:48:51 didn't work 03:49:05 not privileged to access IO-- disabling IO 03:49:06 Error in startup script: bad index "": must be integer or end?-integer? 03:49:06 while executing 03:49:06 "lreplace $in_sig_map $pinnum $pinnum [lindex $io_in_labels $i]" 03:49:07 ("foreach" body line 3) 03:49:07 invoked from within 03:49:08 "foreach insig $io_in_sigs { 03:49:10 set pinnum [emc_ini $insig EMCIO] 03:49:12 set in_sig_map [lreplace $in_sig_map $pinnum $pinnum [lindex $io_in_labels $i]] 03:49:14 You need the original emcio section from the ini 03:49:14 ..." 03:49:16 (file "/home/John/emcdev/emc2head/tcl/scripts/IO_Show.tcl" line 72) 03:49:27 oh well 03:49:37 but that's still only good for the parport - it directly accesses the hardware, right? 03:49:43 back to configs - I want to focus on stuff needed for the release 03:50:58 ray: is there any way to embed really long strings in a tcl program (like paragraphs long) 03:51:08 I know I can line wrap with \ 03:51:12 but that gets messy 03:52:37 I don't even know where emc.ini or it's successor is so I'm no help. 03:53:14 sure the length of a string doesn't matter at all to tcl. 03:53:32 I know, I'm talking about in the source file 03:53:37 set thisstring { ... } 03:54:18 You could even build it from paragraphs like this. 03:54:32 set individual strings, then concatenat them? 03:54:40 set thisstring "$para1 $para2 xxx " 03:54:47 ok 03:54:48 thanks 03:55:06 You could use append or lappend as well 03:56:01 welcome. 03:56:08 one thing that is kinda cool about tcl is that function names and variables are both strings 03:56:16 I have a state machine engine in 2 lines 03:56:27 Right as long as you don't let it bite you. 03:56:33 while ( state != "quit" ) { 03:56:36 state 03:56:38 } 03:56:51 Even widget names are strings. 03:57:07 each state is also a function, and the last thing it does is set the new state 03:57:46 yea, I figured the widget thing out after seeing your code, I was really getting to hate .frame1.frame2.label1 and so on 03:58:00 $parent.child is nicer 03:58:26 much easier if you get very far down into layers 03:58:43 or if you write generic procs 03:59:14 so true. I'm not much good with args and even less so using return values. 03:59:17 I have one that is a wizard page, you call it with the buttons you want on the bottom of the page, it returns a frame you can fill with page specific stuff, the buttons are already done 03:59:36 so additional wiz pages are pretty simple to add 04:00:02 Good. There are a set of popup dialogs with variable buttons. 04:00:41 like "are you sure you want to destroy this file and all of it's backups." 04:00:46 press okay or cancel 04:01:23 I just added an intro page to the new config sequence "you have decided to make a new config, the next few pages will walk you thru the process" back, quit, next 04:01:45 pretty easy to do 04:01:45 Good. 04:02:11