Back
[00:26:20] <jmkasunich> this is damned annoying
[01:57:47] <jmkasunich> evening ray
[01:58:46] <rayh> Hi guys. I just put a little tarball in www.linuxcnc.org/dropbox/tree_test.tgz
[01:59:03] <jmkasunich> what kinda goodies are in there?
[01:59:27] <rayh> It will at least let you see what the tree widget looks like and a bit of how it works.
[01:59:44] <rayh> It will display some hal info if a hal is running.
[02:00:00] <rayh> But it does not build it's tree display from hal yet.
[02:00:31] <rayh> I need a few opinions about what you see there before I expand it to a real display.
[02:00:51] <rayh> Say jmkasunich Thanks for the formatting line.
[02:00:54] <jmkasunich> so I should go take a look?
[02:00:58] <rayh> I put that in the file as well.
[02:01:01] <jmkasunich> you're welcome
[02:01:05] <jmkasunich> saw that commit
[02:01:53] <jmkasunich> where should I untar the tarball?
[02:02:33] <rayh> in emc2/tcl/bin
[02:02:48] <rayh> You wind up with a bit of a readmen in there but ...
[02:02:53] <rayh> readme
[02:03:38] <rayh> Then if you run it from emc2 while running a hal it should show you stuff.
[02:04:10] <rayh> The nav between tree and info is what I'm thinking works pretty well.
[02:04:33] <rayh> crappy layout but it was done just for the testing.
[02:04:46] <jmkasunich> untared, about to try it
[02:05:49] <rayh> compare clicks on the + box and clicking on a node name.
[02:05:55] <jmkasunich> gotta do a cvs up, my configs are screwed up
[02:06:04] <rayh> oh right.
[02:06:16] <rayh> alex was working on that yet this afternoon.
[02:06:18] <jmkasunich> step_cl doesn't have an ini file right now?
[02:06:30] <rayh> don't need sudo to run
[02:06:51] <rayh> The updated should.
[02:07:01] <rayh> * rayh looks
[02:07:38] <jmkasunich> need to add "demo" on front
[02:07:41] <rayh> yes scripts/emc demo_step_cl should get a system running
[02:08:14] <rayh> we may want to change that cause they all should be demo in the repository.
[02:08:45] <jmkasunich> the configs are gonna be in a state of flux for a little bit ;-)
[02:09:41] <jmkasunich> Error in startup script: can't find package BWidget
[02:09:42] <jmkasunich> while executing
[02:09:42] <jmkasunich> "package require BWidget"
[02:09:42] <jmkasunich> (file "tcl/bin/tree-test.tcl" line 6)
[02:09:43] <jmkasunich> John@main:~/emcdev/emc2head$
[02:09:57] <rayh> oh yea.
[02:10:07] <jmkasunich> frickin dependencies
[02:10:31] <rayh> No kidding. I wish tickle had tree abilities.
[02:11:05] <jmkasunich> so what do I do now?
[02:12:00] <rayh> let me find you a link. Sorry for the delay.
[02:12:05] <jmkasunich> s'ok
[02:12:15] <jmkasunich> I'm tcling on my thing, so no rush
[02:12:27] <jmkasunich> ohh, that came out wrong :-/
[02:12:28] <SWPadnos_> hi guys
[02:12:40] <jmkasunich> * jmkasunich hides
[02:12:55] <SWPadnos_> nope - not necessary tonight ;)
[02:14:40] <rayh> bwidget is used by Axis.
[02:14:56] <jmkasunich> then how come I don't have it? I've run axis
[02:15:08] <rayh> probably cant find it.
[02:15:13] <SWPadnos_> the python version maybe? (if there is one)
[02:15:23] <jmkasunich> silly tcl interp....
[02:29:24] <jmkasunich> damn, I have to say, the linux tcl interp is a lot nicer than the doze one
[02:29:42] <jmkasunich> actual meaningfull error messages, with the source line number even... what a novel concept
[02:34:34] <rayh> I confess looks like I got bwidget as a part of vtcl
[02:35:12] <rayh> but there is a /usr/lib/bwidget directory that looks a lot like the bwidget one in axis.
[02:38:48] <jmkasunich> no /usr/lib/bwidget here
[02:42:06] <rayh> trying a link to axis in another box.
[02:45:06] <rayh> sure that works.
[02:45:15] <rayh> find your axis install
[02:45:44] <jmkasunich> you mean the one that gets uninstalled every time I make clean emc2?
[02:45:46] <jmkasunich> ;-/
[02:45:48] <rayh> look for thirdparty
[02:45:59] <rayh> That's probably it.
[02:46:24] <rayh> directory and you'll see bwidget directory.
[02:46:38] <jmkasunich> there is some magical incantation to make axis, which I don't remember
[02:46:51] <rayh> link from that directory to /usr/lib and it should find the package.
[02:47:16] <SWPadnos_> env EMCROOT=/path/to/emc2 python setup.py install
[02:47:21] <rayh> looks just a bit different than it does on this box but not bad.
[02:47:37] <SWPadnos_> possibly with a semicolon in there somewhere ;)
[02:47:42] <jmkasunich> ok, found ~/emcdev/emc2head/src/axis-20051202/thirdparty
[02:48:07] <jmkasunich> so I want to go to /usr/lib and make do what?
[02:48:28] <jmkasunich> ln -s bwidget ~/emcdev/emc2head/src/axis-20051202/thirdparty/bwidget ?
[02:49:39] <jmkasunich> * jmkasunich doesn't do much with links
[02:50:16] <rayh> I start two file browsers and drag and drop
[02:50:28] <jmkasunich> clicky clicky ;-)
[02:50:37] <rayh> * rayh hangs his head in shame.
[02:50:52] <jmkasunich> well, I don't know how to do it either
[02:51:08] <jmkasunich> the only diff is that the cmd line way is easier to explain over IRC
[02:51:17] <rayh> Yes it is.
[02:52:33] <jmkasunich> ok, got a symlink
[02:52:35] <jmkasunich> trying again
[02:53:20] <jmkasunich> working this time
[02:53:28] <jmkasunich> * jmkasunich goes clicky clicky
[02:54:33] <rayh> There is a sorta tree widget in the blt tool kit as well and that one is on the BDI
[02:54:35] <jmkasunich> I see the tree, no params on it for some reason
[02:54:47] <rayh> You could make one.
[02:54:49] <jmkasunich> what are the buttons for again?
[02:54:54] <rayh> click param on the buttons
[02:55:05] <jmkasunich> ok, its red
[02:55:07] <rayh> type axis.0 in the upper entry widget
[02:55:21] <rayh> type encoder in the lower entry widget and press test.
[02:55:53] <rayh> I don't even know if that is a good param name but it will show.
[02:56:25] <jmkasunich> I see, you tell it what branch you want to look at, it doesn't discover the branches
[02:56:49] <rayh> Not right now. I was just working on the logic of nodes, subnodes, ....
[02:57:00] <jmkasunich> but how did it come up with the signals?
[02:57:07] <jmkasunich> did you hard code that or something?
[02:57:15] <rayh> The halcmd list will be able to do that
[02:57:27] <rayh> yes there is a stack of em at the bottom of the script.
[02:58:10] <jmkasunich> interesting
[02:58:11] <rayh> If you have a running emc2 you could expand iocontrol and pick a leaf
[02:58:35] <jmkasunich> shows it in the white box
[02:58:39] <rayh> click the name and you'll "show" that pin
[02:58:43] <jmkasunich> (wrapped - the box isn't wide enough)
[02:59:00] <rayh> You can click "pins" and it will show all pins
[02:59:26] <rayh> you can scroll the white area with mouse wheel
[02:59:34] <jmkasunich> yes
[02:59:44] <jmkasunich> it needs to be wider tho, so they don't wrap
[02:59:45] <rayh> you can scroll the tree with mouse wheel as well.
[02:59:53] <jmkasunich> either that or a horizontal scrollbar
[02:59:55] <rayh> so true.
[03:00:18] <rayh> wrapped by word they look like signals.
[03:01:10] <jmkasunich> is the stuff displayed in the white just raw out of halcmd, or are you parsing and re-assembling it?
[03:01:23] <rayh> raw from show
[03:01:43] <rayh> the -s show condenses it a bit.
[03:01:54] <jmkasunich> yes
[03:02:07] <rayh> I was wondering how much overhead we would cause if we
[03:02:29] <rayh> showed each leaf in turn and looked for true or false and changed the
[03:02:44] <rayh> forground text color rred for true black for false
[03:02:54] <jmkasunich> depends on how often you poll it
[03:03:08] <jmkasunich> right now it only calls halcmd when I click on it, right?
[03:03:36] <rayh> yes and you can see the signals change by re clicking the name.
[03:03:50] <jmkasunich> right, but no automatic update
[03:03:59] <SWPadnos_> 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] <rayh> No
[03:04:24] <SWPadnos_> can you find a node by name?
[03:04:34] <SWPadnos_> (with bwidget)
[03:04:36] <rayh> Yes and if you got all pin names from a single run of halcmd
[03:04:45] <rayh> that should be pretty efficient.
[03:04:50] <SWPadnos_> yep - that's the udea
[03:04:52] <SWPadnos_> idea
[03:05:03] <rayh> The leaf names are the pin or param names
[03:05:14] <SWPadnos_> including everything up to the root?
[03:05:26] <jmkasunich> right now my tree has two 'axis" branches
[03:05:28] <SWPadnos_> ie, ppmc.0.encoder.00.value
[03:05:34] <rayh> with a pin. or param. in front.
[03:05:37] <SWPadnos_> ok
[03:05:53] <rayh> pin.ppmc.0.encoder.00.value
[03:06:17] <SWPadnos_> ok, and param.ppmc.0.stepgen.00-03.pulse-width
[03:06:28] <rayh> For these complex ppmc names do we need another node level?
[03:07:06] <SWPadnos_> is it just a single beanch now (all pins under one root node, all params under another)?
[03:07:11] <SWPadnos_> branch
[03:07:13] <jmkasunich> I don't understand why you make the user specify the nodes
[03:07:26] <SWPadnos_> because there's no automatic parsing yet ;)
[03:07:29] <jmkasunich> heh
[03:07:47] <jmkasunich> suggestion: branch every time you encouter a '.' in a name
[03:07:53] <rayh> I was just giving you a device to see how node names might interact
[03:08:07] <rayh> It makes a really wide display
[03:08:10] <SWPadnos_> it;s a "Technology Demo"
[03:08:14] <jmkasunich> ok
[03:08:30] <jmkasunich> param.ppmc.0.stepgen.00-03.pulse-width has 6 levels
[03:08:43] <rayh> As you can see by clicking on a signal you don't get the same response.
[03:08:46] <SWPadnos_> is this file in the dropbox?
[03:09:04] <rayh> In fact only pin and param respond like I planned.
[03:09:20] <jmkasunich> at present, none of our configs use '.'s in their names
[03:09:24] <rayh> But you can look at funct or thread or components
[03:09:24] <jmkasunich> might want to change that
[03:10:03] <rayh> You want to show files using this also.
[03:10:19] <rayh> we could do that with the xxx_ss.hal
[03:10:45] <jmkasunich> IMO this needs auto parsing
[03:11:00] <rayh> That is the plan.
[03:11:30] <jmkasunich> the tree layout is interesting
[03:11:32] <rayh> the suggestion that each . be another depth of node is one concern.
[03:11:38] <jmkasunich> why?
[03:12:03] <rayh> Just the number of times you have to iterate each pin/sig name
[03:12:18] <jmkasunich> I'm assuming autoparse
[03:12:21] <SWPadnos_> the algorithm is pretty easy
[03:12:26] <SWPadnos_> for autoparse
[03:12:30] <jmkasunich> so when you open it, you have a tree already built
[03:12:47] <jmkasunich> and you can dig right down
[03:12:49] <rayh> I don't think you quite understand the implications of a 6 deep node array
[03:12:55] <SWPadnos_> heh
[03:13:05] <jmkasunich> nasty in tcl?
[03:13:14] <SWPadnos_> does it use a real tree, or is it a multidimensional array?
[03:13:16] <rayh> You'll have to have an enormous window to see anything significant.
[03:13:34] <SWPadnos_> how do the subnodes show up?
[03:13:42] <SWPadnos_> are they aligned with the roght of the parent?
[03:13:46] <SWPadnos_> right
[03:14:17] <rayh> You have some control over both the vertical spacing and horizontal offset
[03:14:17] <jmkasunich> swp: think windows explorer dir tree, with '+' and '-' to open/close subtrees
[03:14:20] <SWPadnos_> each level in the tree should only print a line and a little space, about 2-3 characters worth of indentation
[03:14:31] <SWPadnos_> ok - that's what I'm thinking
[03:14:55] <SWPadnos_> but 6 deep should be less wide than the pin name itself
[03:15:06] <rayh> Yes but you've got to remember that these are not short pin names when you get to the leaves
[03:15:09] <SWPadnos_> or about the same, at least
[03:15:17] <jmkasunich> I was thinking maybe the one big window, and once you open down to unique pins, the value appears right there
[03:15:22] <SWPadnos_> the name in each leaf shouldn't include all the parent information
[03:15:32] <SWPadnos_> that's known because of the position of the leaf
[03:15:32] <jmkasunich> instead of having another window
[03:15:36] <rayh> It doesn't.
[03:15:36] <jmkasunich> exactly
[03:15:40] <rayh> in the sample
[03:15:50] <SWPadnos_> where's the sample? (in the dropbox?)
[03:16:00] <rayh> the name of the node can be different from the text displayed for that node
[03:16:06] <rayh> Yes.
[03:16:06] <jmkasunich> yes
[03:16:08] <SWPadnos_> ok
[03:16:12] <jmkasunich> tree-test.gwz
[03:16:27] <SWPadnos_> ok (gwz?)
[03:16:33] <jmkasunich> tgz
[03:16:36] <jmkasunich> some zippy thing
[03:16:43] <SWPadnos_> goes in tcl/bin?
[03:16:47] <jmkasunich> yeah
[03:16:47] <rayh> gwhizz
[03:16:55] <jmkasunich> and you need the bwidget thing
[03:17:29] <rayh> boy am i glad cradek and jeppler put that in their gui stuff.
[03:17:41] <rayh> otherwise I'd be accused of bloat again.
[03:17:45] <jmkasunich> heh
[03:18:30] <rayh> It would be easily possible to have more than one tree.
[03:18:40] <rayh> these hal elements could be one
[03:18:46] <jmkasunich> GTK also has tree widgets
[03:18:49] <rayh> files could be another
[03:19:06] <rayh> and a listing of all the wizard components could be the third.
[03:19:30] <jmkasunich> ray is going tree happy ;-)
[03:19:46] <rayh> This would give us a single sort of navigation thing for all of the wizard.
[03:20:36] <jmkasunich> 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] <jmkasunich> hal and ini stuff is hier-whatever
[03:21:04] <jmkasunich> that word is hard to type
[03:21:34] <rayh> I imagine a hier... based on starting to make a HAl from scratch.
[03:21:49] <rayh> Here are the available modules
[03:22:09] <rayh> want to add motion from emc?
[03:22:14] <jmkasunich> oh, ok
[03:22:18] <jmkasunich> I misunderstood
[03:22:20] <rayh> How about io from emc?
[03:22:23] <rayh> that sort of thing.
[03:22:40] <jmkasunich> I thought you meant a tree to select the ini wiz vs the hal wiz vs the cl wiz...
[03:22:46] <jmkasunich> which seems like overkill
[03:23:25] <rayh> Probably that is although it is attractive to be able to edit or write changes to all of those.
[03:23:43] <rayh> I wish there were a tk front end to cl.
[03:23:57] <jmkasunich> * jmkasunich runs away
[03:23:59] <SWPadnos_> 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] <rayh> where is petev when we need him.
[03:24:08] <SWPadnos_> or at least realtime
[03:24:48] <rayh> I suppose we could make a tickle container frame
[03:24:51] <jmkasunich> SWP: idealy, you'd load modules (from the GUI) and their pins would appear
[03:25:02] <rayh> and figure out how to get the ladder display into it.
[03:25:05] <SWPadnos_> that only happens if you have the hardware connected
[03:25:19] <SWPadnos_> and you specify the correct command line parameters, for those that need them
[03:25:44] <rayh> That is one real advantage of building a HAL system with hal running.
[03:25:47] <jmkasunich> 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] <SWPadnos_> not just HAL, but also the hardware, like a ppmc, that you want to configure
[03:26:13] <jmkasunich> SWP: the wiz should help you with that
[03:26:24] <jmkasunich> start with a list of supported HW
[03:26:38] <jmkasunich> you pick a driver, it attempts to load it and sees what happens
[03:26:40] <SWPadnos_> it can't - the HAL module either won't load, or it won't export the right pins without the hardware
[03:26:45] <rayh> "I'm not finding a univpwm card out there on any of the parports!"
[03:27:05] <jmkasunich> then maybe you don't have one and should try another choice ;-)
[03:27:08] <rayh> I did find a univstep
[03:27:09] <SWPadnos_> yes - you can report that it didn't work, and that's good
[03:27:32] <SWPadnos_> but what if I'm trying to create a config for someone else? (not a huge problem, but definitely annoying)
[03:27:33] <rayh> and if it does, you get instant access to the pins and params of it.
[03:27:39] <jmkasunich> 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] <jmkasunich> SWP: then you type into a hal file like a real man ;-)
[03:28:15] <SWPadnos_> ugh - put hair on chest!
[03:28:19] <jmkasunich> actually, we might want to consider a "fake it" mode for the drivers
[03:28:37] <SWPadnos_> that' what I was thinking, though the complex ones may have a hard time
[03:28:38] <jmkasunich> "export your pins, but don't do any RT stuff, and don't touch the HW"
[03:28:40] <rayh> That would assume a card data file.
[03:28:52] <jmkasunich> the driver is a card data file
[03:29:03] <jmkasunich> but for something like ppmc, the driver exports based on what it finds
[03:29:11] <SWPadnos_> the driver knows what it's supposed to do, you pass a param like "simcfg=0x378"
[03:29:19] <rayh> I don't like the idea of an offline driver at all.
[03:29:24] <jmkasunich> you;d have to tell it "pretend that you have boards a, b, c"
[03:29:25] <SWPadnos_> yeah - you'd have to select the right one - it gets hairy
[03:29:41] <jmkasunich> I don't either, but I was responding the SWPs situation
[03:30:03] <SWPadnos_> anyway - that's my conundrum for the evening ;)
[03:30:12] <jmkasunich> answer: buy more hardware!
[03:30:20] <SWPadnos_> I've got more hardware! ;)
[03:30:30] <jmkasunich> actually, there is another possbility
[03:30:36] <SWPadnos_> (USC, G-Rex, m5i20 ...)
[03:30:46] <rayh> 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] <jmkasunich> a driver called "dummy", runs in userspace, reads a file and exports the pins listed in the file
[03:31:01] <jmkasunich> nothing whatsoever behind the pins...
[03:31:18] <jmkasunich> but you can sit there and hook them up, and save the .hal file
[03:31:31] <rayh> And everyone would be saying, rayh you need to run dummy!
[03:31:41] <SWPadnos_> run dummy, run!
[03:31:59] <jmkasunich> poor choice of names
[03:32:12] <rayh> Nah it works great.
[03:32:26] <SWPadnos_> hey, dummy - run this
[03:32:31] <jmkasunich> then you'd wind up with a bunch of pin list files
[03:32:35] <SWPadnos_> oops, I mean "hey, run this dummy"
[03:32:38] <jmkasunich> stg.pinlist
[03:32:43] <jmkasunich> usc.pinlist
[03:32:45] <jmkasunich> etc
[03:33:04] <SWPadnos_> we can generate those with the proper hardware, but things like unit numbers will be wrong
[03:33:06] <rayh> Those files could be right in the configs/stg directory
[03:33:16] <SWPadnos_> we could put in specific %xx markers for those though
[03:33:24] <SWPadnos_> yes
[03:33:52] <SWPadnos_> blocks would be a pain, but once we can instantiate after load, that'll be relatively painless
[03:34:02] <jmkasunich> heh, here a wild thought
[03:34:15] <SWPadnos_> there's got to be a way to ask a module what params it can take
[03:34:32] <SWPadnos_> (load-time parameters, that is)
[03:34:49] <jmkasunich> 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] <rayh> wild thought?
[03:35:08] <SWPadnos_> * SWPadnos_ starts to have maintenance nightmares
[03:35:11] <jmkasunich> rayh: I dunno how much you know about .vcp
[03:35:40] <jmkasunich> something I'm working on in the background when not doing stuff for the release
[03:35:52] <rayh> * rayh admits ignorance once again
[03:35:54] <jmkasunich> think ioshow on steroids
[03:36:12] <rayh> Okay.
[03:36:33] <jmkasunich> 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] <SWPadnos_> more like an ioshow development kit ;)
[03:36:56] <jmkasunich> so I can make an on-screen pendant, or a fake parport, or whatever
[03:36:56] <rayh> that would be great.
[03:37:14] <jmkasunich> so far I have the core parser/builder working, and buttons work... LEDs are next
[03:37:17] <rayh> I did that with dio_exercise
[03:37:58] <rayh> sort of
[03:38:35] <jmkasunich> I was hoping to demo vcp soon, but it looks like I should aim for emc2.1
[03:40:19] <jmkasunich> * jmkasunich goes back to tcl config stuff
[03:40:24] <rayh> 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] <jmkasunich> I can't simulate behavior, just IO
[03:41:19] <jmkasunich> a motor/encoder simulation module is on my to-do list, but pretty far dowm
[03:41:40] <rayh> 2.6
[03:41:40] <SWPadnos_> actually - CL-type stuff would be a really useful thing
[03:41:58] <jmkasunich> you would load the module to do the behavior, then use vcp to observe and interact with it
[03:42:02] <SWPadnos_> so you can disable some controls based on pin/signal state
[03:42:30] <SWPadnos_> do you have "disable" inputs on the controls as well as the normal HAL data pins?
[03:42:53] <jmkasunich> no - a vcp button always drives its hal pin
[03:42:55] <SWPadnos_> (last question, then you can get back to config trees ;) )
[03:42:57] <SWPadnos_> ok
[03:43:05] <jmkasunich> push it, pin goes tru, let go, pin goes false
[03:43:14] <jmkasunich> just like a real button
[03:43:19] <SWPadnos_> toggles also?
[03:43:19] <rayh> Sounds great. Wot no toggle?
[03:43:27] <jmkasunich> toggle buttons are on the list
[03:43:36] <rayh> beat ya.
[03:43:42] <SWPadnos_> I suppose us other programmers could add that kind of thing later
[03:43:44] <jmkasunich> now that the skeleton is done, adding new widgets is pretty easy
[03:44:13] <jmkasunich> toggles would be very easy, but I want a display widget before I spend any time on additional control widgets
[03:44:29] <rayh> Shall I expand it so that each . gets a new level of node.
[03:44:30] <jmkasunich> I'll add toggles, its just a matter of a couple hours
[03:44:37] <jmkasunich> but LEDs are first, and they are more complex
[03:44:43] <jmkasunich> because you have to paint on the screen
[03:44:49] <SWPadnos_> heh
[03:44:56] <SWPadnos_> samea s sliders and stuff
[03:45:12] <jmkasunich> sliders are native GTK widgets, they'll be easy
[03:45:19] <rayh> take a look at the tk stuff in ioshow
[03:45:20] <jmkasunich> so will numerical analog displays
[03:45:30] <jmkasunich> bargraphs will be similar to LEDs
[03:47:10] <jmkasunich> rayh: where is ioshow
[03:47:26] <jmkasunich> I have an emc1 checkout... but I don't know that tree at all
[03:47:30] <rayh> tcl/scripts/IO_Show.tcl
[03:47:39] <rayh> emc2
[03:48:02] <rayh> and it will run with the stock emc -- or would a few days ago.
[03:48:41] <jmkasunich> I just tried to open it from the scripts menu of tkemc (my emc2 is still running from before)
[03:48:51] <jmkasunich> didn't work
[03:49:05] <jmkasunich> not privileged to access IO-- disabling IO
[03:49:06] <jmkasunich> Error in startup script: bad index "": must be integer or end?-integer?
[03:49:06] <jmkasunich> while executing
[03:49:06] <jmkasunich> "lreplace $in_sig_map $pinnum $pinnum [lindex $io_in_labels $i]"
[03:49:07] <jmkasunich> ("foreach" body line 3)
[03:49:07] <jmkasunich> invoked from within
[03:49:08] <jmkasunich> "foreach insig $io_in_sigs {
[03:49:10] <jmkasunich> set pinnum [emc_ini $insig EMCIO]
[03:49:12] <jmkasunich> set in_sig_map [lreplace $in_sig_map $pinnum $pinnum [lindex $io_in_labels $i]]
[03:49:14] <rayh> You need the original emcio section from the ini
[03:49:14] <jmkasunich> ..."
[03:49:16] <jmkasunich> (file "/home/John/emcdev/emc2head/tcl/scripts/IO_Show.tcl" line 72)
[03:49:27] <jmkasunich> oh well
[03:49:37] <SWPadnos_> but that's still only good for the parport - it directly accesses the hardware, right?
[03:49:43] <jmkasunich> back to configs - I want to focus on stuff needed for the release
[03:50:58] <jmkasunich> ray: is there any way to embed really long strings in a tcl program (like paragraphs long)
[03:51:08] <jmkasunich> I know I can line wrap with \
[03:51:12] <jmkasunich> but that gets messy
[03:52:37] <rayh> I don't even know where emc.ini or it's successor is so I'm no help.
[03:53:14] <rayh> sure the length of a string doesn't matter at all to tcl.
[03:53:32] <jmkasunich> I know, I'm talking about in the source file
[03:53:37] <rayh> set thisstring { ... }
[03:54:18] <rayh> You could even build it from paragraphs like this.
[03:54:32] <jmkasunich> set individual strings, then concatenat them?
[03:54:40] <rayh> set thisstring "$para1 $para2 xxx "
[03:54:47] <jmkasunich> ok
[03:54:48] <jmkasunich> thanks
[03:55:06] <rayh> You could use append or lappend as well
[03:56:01] <rayh> welcome.
[03:56:08] <jmkasunich> one thing that is kinda cool about tcl is that function names and variables are both strings
[03:56:16] <jmkasunich> I have a state machine engine in 2 lines
[03:56:27] <rayh> Right as long as you don't let it bite you.
[03:56:33] <jmkasunich> while ( state != "quit" ) {
[03:56:36] <jmkasunich> state
[03:56:38] <jmkasunich> }
[03:56:51] <rayh> Even widget names are strings.
[03:57:07] <jmkasunich> each state is also a function, and the last thing it does is set the new state
[03:57:46] <jmkasunich> 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] <jmkasunich> $parent.child is nicer
[03:58:26] <rayh> much easier if you get very far down into layers
[03:58:43] <jmkasunich> or if you write generic procs
[03:59:14] <rayh> so true. I'm not much good with args and even less so using return values.
[03:59:17] <jmkasunich> 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] <jmkasunich> so additional wiz pages are pretty simple to add
[04:00:02] <rayh> Good. There are a set of popup dialogs with variable buttons.
[04:00:41] <rayh> like "are you sure you want to destroy this file and all of it's backups."
[04:00:46] <rayh> press okay or cancel
[04:01:23] <jmkasunich> 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] <jmkasunich> pretty easy to do
[04:01:45] <rayh> Good.
[04:02:11] <rayh> Will this config wizard be a single file or do we want a sub directory for it?
[04:02:23] <jmkasunich> right now its one tcl file
[04:02:51] <jmkasunich> I stole your BASEDIR code, so now it will run from other directories than just the config dir
[04:03:12] <jmkasunich> question: what is the difference between tcl/, tcl/bin, and tcl/scripts?
[04:03:20] <rayh> No problem. Got it from alex and steven
[04:03:48] <rayh> Nothing except the scripts directory gets read and a tkemc menu made from it.
[04:04:00] <jmkasunich> ok
[04:04:05] <rayh> As well as the start of a genedit menu
[04:04:18] <jmkasunich> so the config manager wouldn't go in scripts
[04:04:36] <rayh> but you coud as easily put wizard things in there just use a .wiz extension
[04:05:11] <rayh> the tkemc looks for .tcl extensions and the genedit looks for .ngc extenisons
[04:05:40] <rayh> and that balloon stuff is a bastard child that fredp put in it.
[04:06:38] <rayh> We need to remove a couple of the bin/ files
[04:06:46] <rayh> cause they don't work at all with emc2
[04:08:19] <rayh> You are welcome to overwrite that config file I put in there last night.
[04:09:08] <jmkasunich> the config_setup.tcl (something like that)?
[04:09:23] <rayh> I have pride but it isn't based on the durability of stuff I write.
[04:09:27] <rayh> yep.
[04:09:42] <jmkasunich> I might do that - makes it easy for others to play with it
[04:10:03] <jmkasunich> (but I'm saving a copy locally, for reference)
[04:10:10] <rayh> * rayh has got to get away
[04:10:12] <jmkasunich> I still have a lot to learn about tcl
[04:10:19] <rayh> Thanks for all the good work guys.
[04:10:25] <jmkasunich> goodnith
[10:57:09] <rayh> logger_devel: bookmark
[10:57:09] <rayh> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emcdevel/2005-12-14#T10-57-09
[12:01:19] <rayh> Balloon help does not work with tkemc in emc2
[12:01:28] <rayh> should I fix it or remove it?
[12:05:36] <alex_joni> dunno.. never used it ;)
[12:05:40] <alex_joni> I guess we should fix it
[12:05:55] <alex_joni> if you want I can help tonight
[12:06:19] <rayh> I think that it is just an ini file reference.
[12:06:28] <rayh> something that got stripped out
[12:16:51] <rayh> to enable balloon help with tkemc
[12:17:07] <rayh> add # Enable popup balloon help
[12:17:07] <rayh> BALLOON_HELP = 1
[12:17:44] <rayh> in [DISPLAY]
[12:18:20] <alex_joni> that's not the place for it imho
[12:18:27] <alex_joni> we should just enable it from tkemc's menu
[12:18:40] <alex_joni> because it has no function to other DISPLAY's afaik
[12:18:56] <rayh> That is where it was in emc
[12:19:24] <alex_joni> I'll look it over tonigh.. ok?
[12:19:29] <rayh> okay.
[12:19:44] <rayh> the ini does allow for it as a default behavior.
[12:29:55] <rayh> Trying to add a config/univstep dir
[12:30:14] <rayh> got an ini in there and the older ppmc stuff.
[12:31:10] <rayh> error message follows.
[12:31:12] <rayh> rayh@ray64:~/emcdevelop/emc2$ scripts/emc univstep
[12:31:12] <rayh> Starting emc...
[12:31:12] <rayh> Can't find motion controller /home/rayh/emcdevelop/emc2/rtlib/.ko
[12:32:12] <rayh> HALFILE = core_servo.hal
[12:32:12] <rayh> HALFILE = ppmc_motion.hal
[12:32:12] <rayh> HALFILE = ppmc_io.hal
[12:32:21] <alex_joni> bugger it.. that's the problem not finding the ini
[12:32:25] <alex_joni> univstep/univstep.ini
[12:32:42] <alex_joni> althought the error message is everything else but clear
[12:32:53] <rayh> # HAL config file for Pico Systems USC board
[12:32:53] <rayh> #
[12:32:54] <rayh> # install driver
[12:32:54] <rayh> loadrt hal_ppmc
[12:33:09] <alex_joni> no.. the problem is the ini doesn't get found
[12:33:14] <alex_joni> nothing to do with HAL
[12:33:30] <rayh> okay it was named ppmc.ini in my old setup. Let me change it.
[12:34:47] <alex_joni> I'll really try to fix that.. an error checking isn't working as it should
[12:34:50] <rayh> Okay I'm into HAL type errors so I should be able to fix those.
[12:35:04] <rayh> Thanks alex
[12:35:09] <alex_joni> HALFILE = ../common/core_servo.hal
[12:35:15] <alex_joni> make sure you change that
[12:35:44] <alex_joni> [14:31] <rayh> HALFILE = core_servo.hal (should read ../common/core_servo.hal)
[12:35:57] <rayh> oh I did a bunch of editing on core so should change the name.
[12:36:13] <rayh> I put it in the same configs directory.
[12:36:16] <alex_joni> ok.. you know what you did..
[12:36:23] <alex_joni> then it's ok without the ../common/
[12:36:41] <rayh> a lot of it gets unclear pretty quick.
[12:36:53] <alex_joni> it beeing what?
[12:37:00] <rayh> Should I commit the new directory or wait
[12:37:16] <alex_joni> I think jmk had some issues with the ppmc directory names
[12:37:30] <alex_joni> and I created a ppmc directory.. without knowing that :(
[12:37:38] <rayh> Let me post him a note.
[12:37:44] <alex_joni> better like that
[12:38:05] <alex_joni> I think he wanted univ_usc and univ_pwm , but I can't really recall
[12:41:44] <rayh> okay. sent him a email. should get a reply before long.
[12:43:01] <rayh> as soon as those are done and tested here, i want to add a m5i20 but think I'll name that one configs/demo_mesa
[12:43:15] <rayh> or configs/demo_mesa_5i20
[12:43:31] <rayh> Because they make a whole set of other motion boards as well.
[12:44:23] <alex_joni> there is a m5i20 already
[12:44:34] <rayh> Oh I see that now.
[12:45:13] <rayh> We can have more than one ini in a config directory?
[12:45:24] <rayh> we just have to name it during startup?
[12:53:22] <alex_joni> yeah
[12:53:40] <alex_joni> if there is more than one ini, we need to make sure the directory name is a symlink to the one we want
[12:53:44] <alex_joni> or the user wants
[13:05:01] <rayh> Just tested the simlink idea and it works great.
[13:05:36] <rayh> In fact we could put both usc and upc board definitions in the same directory.
[13:06:01] <rayh> the io file would be the same for both.
[13:09:15] <rayh> ../common/emc.nml doesn't work
[13:13:53] <alex_joni> hrmm.. that's odd
[13:15:49] <rayh> works for the demo_step_cl
[13:16:07] <rayh> brb
[20:44:37] <SWPadnos_> I talked to jmk about it - the consensus was that I can write my own utility if I'm so inclined ;)
[20:44:55] <alex_joni> GOOD advice ;)
[20:44:58] <SWPadnos_> heh
[20:45:36] <SWPadnos_> the idea was to have a command that halcmd could use to grab a section of the ini, and apply the items in the section to a particular component (or just a text prefix on params)
[20:46:16] <SWPadnos_> so halcmd -i inifile loadsection axis_0 ppmc.0.stepgen.00
[20:46:38] <SWPadnos_> but anyway
[20:47:14] <alex_joni> let's return to releasing emc2 first ;)
[20:47:21] <SWPadnos_> party pooper
[20:47:26] <alex_joni> then go to 2.1.x and break the hell of it
[20:47:33] <SWPadnos_> yeah!!!
[20:47:41] <alex_joni> but first 2.0.x
[20:47:46] <SWPadnos_> I mean - well, we should try to maintain backward compatibility ;)
[20:47:54] <alex_joni> on 2.0.x
[20:48:04] <alex_joni> that's how it usually is..
[20:48:08] <SWPadnos_> heeh
[20:48:10] <SWPadnos_> hehe
[20:48:11] <SWPadnos_> heh
[20:48:18] <alex_joni> same line of development should work..
[20:48:24] <alex_joni> other might/probably break
[20:48:29] <SWPadnos_> glarggghhh - all the caffeine went to my left hand
[20:48:45] <alex_joni> faster then the right one?
[20:48:53] <SWPadnos_> with some words, it seems
[20:48:57] <SWPadnos_> maybe it's just less cold
[20:49:25] <alex_joni> * alex_joni goes back to writing an email to the dev list
[20:49:30] <SWPadnos_> heh
[20:49:44] <SWPadnos_> I'll probably have to go fror a while - damned customers and their marketing people
[20:50:06] <SWPadnos_> (see, the extra 'r' is from my left hand)
[20:50:35] <rayh> darn I just can't make cds.ngc run at 100 percent.
[20:50:46] <rayh> and the fedrate is only 16
[20:50:53] <cradek> rayh: what happens?
[20:51:02] <rayh> following error
[20:51:05] <rayh> every time
[20:51:13] <cradek> same place?
[20:51:39] <SWPadnos_> did you set FF1 to 1?
[20:51:48] <rayh> nope it is almost random
[20:52:27] <rayh> yes.
[20:52:28] <cradek> I'm going to up and rebuild HEAD here
[20:53:04] <rayh> Just got a sawmill service call. Back later.
[20:53:06] <cradek> oh you must not be using stepper
[20:53:20] <SWPadnos_> it's a univpwm
[20:53:35] <SWPadnos_> so it still has all the servo PID stuff
[20:53:41] <rayh> it's a usc marked board.
[20:53:54] <cradek> maybe the next thing to do is set halscope to trigger on the ferror
[20:54:00] <SWPadnos_> sorry - univstep -that's what I meant
[20:54:02] <rayh> I also have a upc marked board
[20:58:20] <rayh> running now with ferror 1.00
[21:00:39] <rayh> saw it with halscope. suddenly the fe was huge.
[21:01:07] <rayh> Was running about 1/2 mv and then jumped.
[21:01:13] <cradek> an instantaneous jump?
[21:01:22] <rayh> Yep
[21:01:27] <rayh> way off scale.
[21:01:30] <rayh> both ways.
[21:01:32] <cradek> wow
[21:01:44] <cradek> sounds like a bug or hardware problem, not simple configuration
[21:01:44] <rayh> when I get back I'll swap parports and try that.
[21:01:49] <cradek> yeah
[21:01:58] <rayh> thanks guys
[21:55:58] <alex_joni> did that mail go through?
[21:56:27] <SWPadnos_> yep
[21:56:33] <SWPadnos_> looks good to me
[21:56:58] <alex_joni> ok then
[21:57:15] <SWPadnos_> I'd like to have the emc and config script live in the emc2/ dir though
[21:57:35] <alex_joni> they were there initially :)
[21:57:38] <SWPadnos_> or in the bin dir, with a link or something
[21:57:41] <alex_joni> at least the ./configure
[21:57:41] <SWPadnos_> yep
[21:58:01] <alex_joni> but it's nice to have it clean
[21:58:32] <SWPadnos_> sure, but there are 3 possible places for the scripts to live: tcl, bin, and scripts
[21:59:10] <SWPadnos_> shold the config script be in tcl, since it's written in tcl, or in bin beacuse it's a program, or scripts because it's a tcl script?
[21:59:39] <alex_joni> tcl/bin
[21:59:45] <alex_joni> that matches 2 of 3 :)
[21:59:57] <SWPadnos_> but it's a script, not compiled. it should be in tcl/scripts ;)
[22:00:09] <alex_joni> not if it's chmod +x
[22:00:11] <alex_joni> ;)
[22:00:26] <alex_joni> so it can be executed opposed to only sourced
[22:00:43] <alex_joni> because after all .. all tcl's are scripts
[22:00:45] <SWPadnos_> so there really shouldn't be a scripts dir at all then, since it's full of +x stuff ;)
[22:00:55] <alex_joni> probably
[22:00:56] <alex_joni> :D
[22:01:36] <SWPadnos_> just looking at it from a user perspective - the time to leave the old ways behind is before the first release :)
[22:02:22] <alex_joni> right
[23:16:59] <SWPadnos_> woohoo - I got a following error!