Back
[03:27:55] <SWPadnos> SWPadnos is now known as SWP_Away
[03:40:17] <cradek> jmkasunich: still around?
[03:43:07] <cradek> jmkasunich: I have a working spindle encoder
[03:59:10] <jmkasunich> woo hoo!
[03:59:33] <jmkasunich> (just got back)
[04:08:32] <cradek> it seems to work even though it's a 4096 count encoder
[04:08:48] <cradek> I'm only turning it by hand - the spindle motor driver needs serious work before I plug it in
[04:09:05] <jmkasunich> thats why it works
[04:09:19] <cradek> yep
[04:09:26] <jmkasunich> 2-4 revs per sec will probably be top speed
[04:09:46] <cradek> 4 rps might be fast enough
[04:10:01] <cradek> I may have to make a hardware divider I guess
[04:10:07] <cradek> but it's good to know everything is working
[04:10:14] <jmkasunich> what's wrong with the spindle
[04:10:39] <cradek> one of his students hacked on it, and he apparently had never soldered before
[04:10:45] <jmkasunich> eww
[04:10:49] <cradek> it's pretty bad
[04:11:03] <cradek> but I can tell how he intended to wire it - maybe I can just clean it up
[04:11:07] <jmkasunich> hacking in the drive itself, or the interface to it?
[04:11:22] <cradek> a little of both
[04:11:56] <cradek> I *think* you have to unhook the motor and feedback from the original driver, plug this board on top of it, and rewire everything through it
[04:12:47] <jmkasunich> can I md5sum a freshly burned cdrom by doing md5sum /dev/cdrom?
[04:13:10] <cradek> that rarely works
[04:13:28] <cradek> I mean it can't hurt to try
[04:13:35] <cradek> but if it doesn't match, that's no guarantee your cd is bad
[04:13:37] <jmkasunich> its running now
[04:13:56] <jmkasunich> I seem to recall something about padding at the end that throws it off
[04:14:11] <cradek> iirc scsi cdrom drives typically worked, ide don't
[04:17:21] <jmkasunich> it didn't
[04:17:43] <cradek> yep, no surprise
[04:19:53] <cradek> hmm, something is failing in X, when I started it had a half turn of backlash, now it has a full turn
[04:20:01] <cradek> I hope something is just loose
[04:20:51] <jmkasunich> yeah
[04:23:28] <jmkasunich> heh, running it thru dd and specifying the exact size worked
[04:34:01] <cradek> cool
[04:34:07] <cradek> I would not have thought to try that
[04:35:14] <cradek> I better get to bed... maybe tomorrow I'll cut something
[04:35:54] <jmkasunich> goodnight
[04:35:56] <cradek> the way this is geared, I expect it to have 4-5x the torque of my sideways-lathe, so with a tailstock I should be able to cut real threads
[04:36:06] <jmkasunich> nice
[04:36:16] <jmkasunich> there's reduction from motor to spindle?
[04:36:22] <cradek> yes a lot
[04:36:29] <cradek> mine is ~ 1:1
[04:37:03] <cradek> this is about 1/2" driving about 3"
[04:37:13] <jmkasunich> nice
[04:37:22] <jmkasunich> that will help make up for the high spindle ppr
[04:38:11] <cradek> yeah, I bet it will be workable just like this
[04:39:42] <cradek> if I want to run this speed control, I may have to come up with a 0-12v analog signal, I have no clue how to do that
[04:39:48] <cradek> 0-5 maybe I could do with pwm
[04:39:54] <jmkasunich> does it need to be floating?
[04:40:00] <cradek> I don't know
[04:40:17] <cradek> I know little about this
[04:40:19] <jmkasunich> given that you won't be using full speed, 0-5 may be enough
[04:40:28] <cradek> maybe I'll wait until the show and you guys can help me figure it out
[04:40:34] <jmkasunich> and for testing, you can control spindle speed with a knob
[04:40:47] <cradek> yes definitely
[04:41:12] <cradek> soon I'll have everything working that I wanted before workshop
[04:41:17] <jmkasunich> * jmkasunich looks for the ubuntu iso md5sum
[04:41:26] <jmkasunich> I thought I had a bad burn, so I made a new one
[04:41:34] <cradek> maybe I'll write some nice demo gcode too
[04:41:39] <jmkasunich> but it seems the iso, and both burns, are the same
[04:41:48] <cradek> hmm
[04:41:53] <cradek> still won't install for you?
[04:42:09] <jmkasunich> the last time it failed at least an hour into the install
[04:42:22] <jmkasunich> this time, who knows?
[04:42:31] <cradek> yuck
[04:42:41] <jmkasunich> could even be the drive I'm using to read it
[04:42:50] <cradek> yeah who knows
[04:42:53] <cradek> well goodnight again
[04:42:57] <jmkasunich> lol
[04:43:00] <jmkasunich> goodnight
[12:39:08] <SWP_Away> SWP_Away is now known as SWPadnos
[15:12:54] <jmkasunich> back in a couple hours
[16:15:14] <rayh> IMO we ought to collapse the config picker tree.
[17:43:28] <jmkasunich> I ray
[17:43:45] <jmkasunich> you mean make it come up collapsed, let the user open it?
[17:44:41] <cradek> it's my habit to use just the down arrow to get to the config I want, I think I would have to mess with it more each time if it was all closed up
[18:06:39] <lilo> [Global Notice] Hi all. As you know, Google's official Summer of Code channel has moved to slashnet this year. With that in mind, we're opening up an unofficial channel for freenode participants in Soc 2006: ##googlesummer .... if you're involved with mentoring or you're submitting a project, please stop by! As always, be as courteous as you can. Thanks. :)
[18:22:30] <rayh> I've seen a bit of confusion after folk copy a config to their home directory.
[18:22:58] <rayh> 'course I'm always confused, having about 35 configurations laying around.
[18:23:23] <cradek> what is confusing?
[18:23:44] <rayh> Where the configs are.
[18:24:35] <rayh> A fellow copied to his home but then didn't know his way around the file system enough to pick it from the tree.
[18:25:08] <jmkasunich> I suppose a smart assed comment from me right now won't help the discussion
[18:25:39] <cradek> They are in order from most "personal" on top to least personal (distributed samples) on the bottom
[18:26:01] <cradek> so even if the paths (which are right there) don't make any sense to someone, he can pick the top one
[18:26:20] <cradek> also, I don't understand how closing the tree would help this, is that what we're talking about still?
[18:27:24] <rayh> Yes. You would only see the "groups" of configs rather than all at once.
[18:29:04] <cradek> that's true, but they would still be the pathnames
[18:29:38] <rayh> Yep.
[18:29:39] <cradek> seems like less information would make it less clear, not more clear
[18:30:04] <cradek> unless the user doesn't understand the concept of the tree at all, and you think adding more steps (clicks) would help him understand
[18:30:09] <jmkasunich> some folks probably have information overload
[18:30:28] <rayh> And the more familiar one is with a thing the less likely they are to experience information overload.
[18:30:51] <cradek> maybe we could close all but the top directory's configs
[18:31:02] <cradek> then if you have a custom config, the samples start out closed
[18:31:15] <rayh> That would be an idea.
[18:31:28] <cradek> I am pretty sure we shouldn't close all of them - that just adds useless steps for everyone every time.
[18:31:42] <rayh> good one. if only sample then they would show.
[18:32:00] <cradek> seems like an ok compromise
[18:32:02] <jmkasunich> a related question, the dirs that contain multiple inis
[18:32:05] <cradek> what do you think jmkasunich?
[18:32:07] <jmkasunich> should they default to open?
[18:32:16] <jmkasunich> I think closing all but the top is good
[18:32:35] <cradek> yes I think they should default to open
[18:33:15] <rayh> right and left arrow open and close nodes.
[18:33:29] <rayh> so it is still possible to arrow around.
[18:33:44] <cradek> ok, glad that works
[18:34:08] <cradek> rayh: can you do that (close all the dirs but the top one) on head so we can try it?
[18:35:07] <rayh> phone
[18:35:29] <Lerneaen_Hydra> Could there be a flag/button that says something like "start with this config automatically next time", becuase it took me a while to find out how to autostart a config. (is it frowned upon for non-devel to write here?)
[18:35:53] <jmkasunich> not frowned on, unless its idle off-topic chatter
[18:36:15] <jmkasunich> we've thought about a way to set a default
[18:36:23] <jmkasunich> but actual inplementation is non-trivial
[18:36:54] <jmkasunich> if you set a default that applies when you run "emc" without an argument, how would you ever get back to the selector screen if you wanted to?
[18:37:38] <jmkasunich> by requiring a config on the command line in order to skip the selector screen, we provide a way to do that without locking you out of it forever
[18:37:59] <Lerneaen_Hydra> there could be some flag/button/config in the GUI, which would probably be a pita to implement
[18:38:14] <cradek> if we had the last choice the highlighted one by default, you could just hit enter
[18:38:26] <jmkasunich> that would be nice
[18:38:32] <cradek> that would not have any of the problems that worried us, but it's also not exactly what LH asked about
[18:38:43] <jmkasunich> maybe a good compromise?
[18:38:47] <cradek> possibly
[18:39:01] <cradek> seems like I'm an unusually-good compromiser today
[18:39:11] <jmkasunich> LH, what do you think? would that be helpful, or do you really want to skip the selector completely?
[18:39:42] <rayh> reading back
[18:40:27] <Lerneaen_Hydra> that would helpful, maybe also some text that explains how to auto-select a config. (I've set it up now with the launcher but it took a while to find out how to do that)
[18:41:37] <jmkasunich> something that would be nice (but very non-portable) would be a button that says "create an icon on the desktop that will start the selected config"
[18:41:37] <rayh> If we were to highlight the last run config, that picker would have to be writable or we'd create yet another configuration file.
[18:42:12] <cradek> the picker should certainly not be rewritten, we'd want ~/.emcrc or similar
[18:42:16] <rayh> That would not be all that tough? ~/Desktop is the location.
[18:42:40] <jmkasunich> it depends on the environment
[18:42:54] <jmkasunich> a Gnome icon and a KDE icon are probably not created the same
[18:43:04] <jmkasunich> and some systems might not have either
[18:43:37] <SWPadnos> they should be the same - there's a standard at freedesktop.org
[18:43:45] <jepler_> here's an idea: All the .ini files should be +x and say #!/usr/bin/emc
[18:44:42] <jepler_> as executables, they should be easily addable as desktop shortcuts or whatever, if the desktop environment is worth two craps
[18:45:15] <cradek> jepler_: we use $PWD to find files though
[18:45:37] <cradek> but maybe you're on to something
[18:46:01] <jmkasunich> * jmkasunich envisions executable hal files with #!/usr/bin/halcmd as the first line
[18:46:10] <cradek> I just want to be clear, I was not talking about icons or kde or gnome or desktops or any of that: only a way to save the previously-chosen config in a per-user way
[18:46:17] <SWPadnos> great for installed systems, but not so good for RIP
[18:46:38] <rayh> tree widget does have a drag and drop but I don't know if it works from tree to desktop.
[18:46:49] <jmkasunich> cradek: I understand, but LH's real request was for an icon that starts the config he wants
[18:47:22] <jmkasunich> the "most recent highlighted" is a hack that helps some, and is portable
[18:47:25] <cradek> I read back and I do not see him asking that
[18:47:46] <jmkasunich> from LH: I've set it up now with the launcher but it took a while to find out how to do that
[18:47:57] <SWPadnos> "most recent" requires a config file somewhere, which I think is the issue currently being discussed
[18:48:19] <cradek> a dot file in the home directory is the usual way of saving state like that
[18:48:30] <SWPadnos> sounds good to me
[18:48:33] <cradek> seems pretty asy
[18:48:35] <rayh> writing from emc (tcl) should be easy enough.
[18:48:37] <cradek> and easy
[18:48:58] <cradek> if someone wants to put it in HEAD, I think that would be cool, we can try it out
[18:49:00] <rayh> We'd just have to add a highlight to the tree.
[18:49:02] <Lerneaen_Hydra> maybe there could be some type of quick-start guide that explains how to do various basic tasks (such as autostart config) rather than trying to making something that is platform-dependant? (this is the autostart from icon I'm, talking about now, not select previous).
[18:49:47] <SWPadnos> I think "emc" without parameters should just run the previously selected config
[18:49:48] <rayh> This kind of documentation will either be done by another, or it will wait for fest.
[18:49:51] <cradek> Lerneaen_Hydra: in its most basic form, that information is in the emc man page
[18:50:03] <SWPadnos> there can be an option like -s to re-select (or -m for menu)
[18:50:57] <rayh> A last run highlight in the tree would just mean two clicks to start the same config every time.
[18:50:58] <jmkasunich> SWP: I disagree
[18:51:06] <jmkasunich> the first time you run emc with no args it gets you the picker
[18:51:25] <jmkasunich> the next time it doesn't? and you have to read the man page to find out how to get the picker
[18:51:54] <rayh> When we get past this, if we have a half hour I'd like your impressions of halconfig.tcl?
[18:52:05] <cradek> I also disagree for the same reasons
[18:52:29] <jmkasunich> when we get past this I was hoping to go back to digging into LH's TP bobbles
[18:52:32] <cradek> that's why I suggested the compromise of highlighting a default, it gets us most of what both sides want
[18:52:40] <SWPadnos> ok. there are a lot of precedents for doing "setup" on the first run though
[18:53:06] <cradek> rayh: I used halconfig to show the parport input bits (LEDs) and thought it was cool
[18:53:08] <SWPadnos> consider it passed then. I don't think it's important enough to hold up "real work"
[18:53:30] <rayh> Thanks.
[18:53:45] <rayh> I put the latest in head a bit ago.
[18:53:47] <jmkasunich> I think the concensus is that "highlight most recent" is a) doable b) acceptable to everyone if not perfect
[18:54:15] <Lerneaen_Hydra> from my point of veiw (end-user) it sounds very good
[18:54:16] <cradek> jmkasunich: fwiw, I'd like to see that in HEAD
[18:54:16] <rayh> and the latest is in ~/.emcrc?
[18:54:29] <SWPadnos> sounds OK to me. the addition of a button to create a desktop icon would make it good for all cases, I think
[18:55:18] <cradek> SWPadnos: I think making emc manipulate your desktop environment and files in any way should be avoided.
[18:55:19] <SWPadnos> (even just a .desktop file, if the location of the desktop is hard to find)
[18:55:32] <SWPadnos> they're just files in a directory, as far a I know
[18:55:35] <SWPadnos> as
[18:55:48] <SWPadnos> it's not like the Windows Registry ;)
[18:55:49] <jmkasunich> ~/.emcrc might someday need to contain other info besides most recent config
[18:55:58] <cradek> that's true only if you assume a particular version of a particular desktop environment
[18:56:31] <SWPadnos> I know it's true of gnome and KDE, and any other desktop that claims compatibility with the freedesktop standards
[18:56:32] <jmkasunich> so either establish a format for it that allows individual items, or use something like ~/.emcdefaultconfig
[18:56:43] <rayh> picker should read all of .emcrc and only edit the "start_using" variable.
[18:57:08] <rayh> That should be easy enough for me to handle.
[18:57:31] <jmkasunich> so emcrc will consist of multiple lines of "name = value"
[18:57:41] <jmkasunich> possibly with # comments?
[18:57:47] <rayh> sounds good to me.
[18:58:28] <jmkasunich> that file might be handy for other things too
[18:58:36] <jmkasunich> most recently opened g-code files
[18:59:25] <SWPadnos> I can';t seem to run halconfig from within axis
[18:59:58] <SWPadnos> I get the following error:
[19:00:18] <SWPadnos> Error in startup script: window name "label-0-input_scale" already exists in parent
[19:00:19] <SWPadnos> while executing
[19:00:21] <SWPadnos> "label [set af$j].label-$j-$lowername -text "$thisininame: " -width 20 -anchor e"
[19:00:23] <SWPadnos> (procedure "makeIniTune" line 43)
[19:00:25] <SWPadnos> invoked from within
[19:00:26] <SWPadnos> "makeIniTune"
[19:00:28] <SWPadnos> (procedure "whichTune" line 56)
[19:00:29] <SWPadnos> invoked from within
[19:00:31] <SWPadnos> "whichTune"
[19:00:33] <SWPadnos> (file "/Project/emc2/tcl/bin/halconfig.tcl" line 1324)
[19:00:35] <cradek> works for me in TESTING-2006-04-09
[19:00:53] <SWPadnos> I just upped both emc and axis, using HEAD for emc
[19:01:08] <rayh> odd.
[19:01:10] <cradek> ok
[19:01:44] <SWPadnos> axis is rev 1.3a0
[19:01:50] <rayh> What were you using for a config SWPadnos
[19:02:04] <SWPadnos> a slightly customized univstep
[19:02:15] <rayh> let me try it here.
[19:02:19] <SWPadnos> k
[19:02:33] <SWPadnos> I could try it from tkemc or mini as well
[19:03:49] <SWPadnos> ok. same problem from tkemc here
[19:06:03] <rayh> insmod: error inserting '/home/rayh/emc2/rtlib/motmod.ko': -1 Operation not permitted
[19:06:20] <SWPadnos> make setuid?
[19:06:50] <cradek> check dmesg
[19:06:52] <rayh> my problem.
[19:07:08] <rayh> Looks like I trashed the script.'
[19:07:12] <rayh> emc
[19:07:12] <SWPadnos> is there any reason why make setuid can't automatically be done when making RIP?
[19:07:17] <SWPadnos> bummer
[19:07:38] <jmkasunich> same reason install can't be done when making normally, it needs to be sudo
[19:07:54] <jmkasunich> "can't" is too strong a word
[19:08:04] <jmkasunich> "usually isn't" is better
[19:09:20] <SWPadnos> ah ok. so putting those two lines (under the setuid target) into the normal RIP target with sudo prepended wouldn't work?
[19:09:49] <SWPadnos> (with a suitable prompt so you know why you're being asked for a password, in case you get asked)
[19:10:55] <jmkasunich> I'd rather not, make it a specific user action, just like make install
[19:11:02] <SWPadnos> ok
[19:11:29] <jmkasunich> one reason (irrelevant to most folks) is that the compile farm wants to do a build but not install or make setuid
[19:11:48] <SWPadnos> I think that's mostly irrelevant ;)
[19:11:55] <jmkasunich> as I said ;-)
[19:11:57] <SWPadnos> it isn't detrimental to make setuid
[19:12:15] <SWPadnos> do the compile farm slots do RIP or "normal" makes?
[19:12:17] <jmkasunich> also, some systems may not have sudo set up, people use su to install software
[19:12:27] <jmkasunich> normal I think, so its even more irrelevant
[19:13:19] <rayh> looks like the last commit of halconfig was borked.
[19:13:27] <rayh> I'll put a new there in a few.
[19:14:32] <SWPadnos> ok
[19:15:58] <jmkasunich> swp: I have two scripts in my top level checkout directory:
[19:16:16] <jmkasunich> update: cvs up -dP && cd src && ./configure --enable-run-in-place
[19:16:32] <jmkasunich> build: cd src && make && sudo make setuid
[19:16:50] <SWPadnos> "update-emc" does the work for me :)
[19:17:24] <jmkasunich> build is faster when I'm compiling changes that I've made
[19:17:29] <SWPadnos> but you're right - build is a better name for that script
[19:17:43] <SWPadnos> #!/bin/bash
[19:17:44] <SWPadnos> # script to update emc after a new cvs checkout
[19:17:46] <SWPadnos> cd src
[19:17:47] <SWPadnos> # re-run configure
[19:17:49] <SWPadnos> ./configure --enable-run-in-place
[19:17:50] <SWPadnos> # re-run make
[19:17:52] <SWPadnos> make 2>&1 | tee build.log
[19:17:54] <SWPadnos> # make it executable
[19:17:56] <SWPadnos> sudo make setuid
[19:27:02] <rayh> Try this halconfig when you get the chance.
[19:27:10] <rayh> Try this halconfig when you get the chance.
[19:27:23] <rayh> uh that's redundant.
[19:27:26] <rayh> sorry.
[19:28:49] <rayh> Nope. I'm not getting a commit.
[19:29:04] <SWPadnos> I just got a commit message
[19:29:06] <rayh> Says I am but it is not putting my current version in the cvs.
[19:32:02] <rayh> * rayh goes away to kick the dog. Seems something overwrote my last version here.
[19:32:11] <SWPadnos> ugh
[19:39:18] <rayh> Okay. I think it is just a failure with the parameter names in univstep.
[19:41:51] <rayh> darn ppmc uses names like
[19:42:00] <rayh> 05 float -W 4.00000e+03 ppmc.0.encoder.00.scale
[19:42:00] <rayh> 05 float -W 4.00000e+03 ppmc.0.encoder.01.scale
[19:42:00] <rayh> 05 float -W 4.00000e+03 ppmc.0.encoder.02.scale
[19:42:00] <rayh> 05 float -W 1.11111e+01 ppmc.0.encoder.03.scale
[19:42:13] <rayh> rather than
[19:43:03] <rayh> m5i20.0.dac-00-gain
[19:43:14] <SWPadnos> decimals versus hyphens?
[19:43:19] <rayh> Yep.
[19:43:30] <jmkasunich> oh, "." vs "-" for section separators
[19:43:30] <SWPadnos> hmm - ok
[19:43:46] <rayh> and I [split $xx .]
[19:43:58] <rayh> to get the ending name of the param.
[19:45:46] <SWPadnos> ok, do you have several encoder.00. as "parent names"
[19:45:58] <rayh> Tcl can use encoder-00-scale for a widget name
[19:46:03] <SWPadnos> can you split on s/do/so/
[19:46:09] <rayh> but can't use encoder.00.scale
[19:46:20] <SWPadnos> right, because . is significant
[19:47:59] <rayh> In the other modules each . indicates a step deeper into detail
[19:48:29] <rayh> until you get to the "first name" of the module.
[19:48:57] <rayh> I suppose I could use arbitrary incremented names for all parameters.
[19:49:16] <rayh> in the widget construction.
[19:49:28] <rayh> and use the full name in the text portion.
[19:49:28] <SWPadnos> manual splitting based on either '.', '-', or '_' would probably work best
[19:49:52] <SWPadnos> well, second best, behind standardization of naming schemes across all HAL components ;)
[19:50:33] <rayh> I use the first two parts, in this case ppmc.0 as the name of a tab.\
[19:51:19] <rayh> I could try to attack it from that rather than from the right end.
[19:53:19] <rayh> I presume there is universal agreement in these parts that this is rayh's problem?
[19:53:48] <jmkasunich> standardization of HAL naming is a noble goal
[19:53:52] <jmkasunich> but not at the top of the list
[19:54:51] <rayh> so tillie is out the window.
[19:56:11] <SWPadnos> it seems that the best way is to split based on either '.' or '-', then assemble the tree based on whether each piece is a number or text
[19:56:34] <jmkasunich> I consider . to be a real split, and - to divide words that are part of the same thing
[19:56:48] <SWPadnos> as you said, that's a noble goal ;)
[19:56:56] <jmkasunich> ppmc.0.encolder.00.position-scale
[19:57:01] <jmkasunich> position-scale is all one word
[19:57:07] <SWPadnos> so in your view, the m5i20 pins are poorly named?
[19:57:16] <jmkasunich> yes
[19:57:26] <jmkasunich> m5120.0.dac.00.gain
[19:57:33] <jmkasunich> m5i20 is the general class
[19:57:36] <jmkasunich> 0 is the board id
[19:57:40] <jmkasunich> dac is the function
[19:57:45] <jmkasunich> 0 is the dac id
[19:57:50] <jmkasunich> gain is the parameter
[19:58:03] <jmkasunich> I would use dash only within one of those fields
[19:58:18] <SWPadnos> ok. so an algorithm that could work is to split on both . and -, then re-concatenate adjacent strings, and separate on numbers
[19:58:22] <jmkasunich> such as P-gain and I-gain, or min-value, or somethign like that
[19:58:28] <SWPadnos> agreed
[19:58:45] <SWPadnos> just trying to think about how to account for both right now
[19:58:54] <jmkasunich> for the trees, you might want to divide after numbers
[19:59:00] <rayh> and it was working so well, even with multiple parports.
[19:59:09] <jmkasunich> so m5i20.0 is one level
[19:59:13] <jmkasunich> dac.0 is another
[19:59:17] <jmkasunich> and gain is the last
[19:59:33] <SWPadnos> so m5i20.0.dac-03-gain splits to 5 elements: m5i20 0 dac 03 gain
[20:00:13] <jmkasunich> a convention requires two things: first, people do decide on one (based on thinking thru all the implications, something that was not done originally, halconfig wasn't even a glimmer then)
[20:00:29] <jmkasunich> and 2) people to go in and modify the modules to match the convention
[20:00:42] <SWPadnos> sure
[20:00:47] <jmkasunich> (which at this point will cause all manner of problems because things change)
[20:00:51] <rayh> Guess I've got the wrong parport def for univstep. brb
[20:09:44] <SWPadnos> hi again Ray
[20:12:21] <rayh> Hi O
[20:12:27] <rayh> I'm back.
[20:12:49] <SWPadnos> indeed you are
[20:13:17] <rayh> Still no got on univstep. I keep getting intermittent limit errors on axis 3,4
[20:13:33] <SWPadnos> in halconfig?
[20:13:45] <rayh> No in the startup of univstep.
[20:13:51] <SWPadnos> strange
[20:14:17] <rayh> They flash on and off every so often.
[20:15:13] <SWPadnos> are they connected to anyhardware?
[20:15:19] <SWPadnos> or are the inputs floating
[20:15:22] <rayh> no.
[20:15:44] <SWPadnos> what is the USC sitting on?
[20:15:50] <SWPadnos> (or does it have standoffs?)
[20:16:04] <rayh> a "Rhino" mouse pad.
[20:16:22] <SWPadnos> is it anti-static?
[20:16:29] <rayh> yep.
[20:16:35] <SWPadnos> then it's slightly conductive
[20:16:49] <SWPadnos> stick it on a piece of cardboard or something, and see if the problem goes away
[20:16:55] <rayh> The conclusion of the naming convention discussion was that 5i20 is wrong.
[20:16:58] <rayh> ??
[20:17:02] <SWPadnos> I think so
[20:17:17] <SWPadnos> but I also think there's a viable workaround
[20:17:41] <rayh> You don't know how many times I rework those names.
[20:17:55] <SWPadnos> heh
[20:17:58] <SWPadnos> I can believe
[20:18:14] <SWPadnos> can split use more than one character to split on? (ie, either . or - )
[20:18:28] <rayh> gotta go away for a bit. bbl.
[20:18:45] <SWPadnos> ok. I may miss you until Thursday then
[20:18:48] <SWPadnos> bummer
[20:31:32] <rayh> No luck with the univstep board. Limits on 3 and 4 still flash.
[20:31:50] <rayh> Moved to insulated surface.
[20:35:55] <rayh> univpwm does about the same behavior.
[20:56:24] <SWPadnos> bummer
[20:56:26] <SWPadnos> I don
[20:56:33] <SWPadnos> I don't see any of that behavior
[21:06:37] <rayh> Well I'll build a slower box to test this stuff on.
[21:08:39] <SWPadnos> can you split based on either of two characters, or do you need to split twice?
[21:08:55] <SWPadnos> (ie, split each resulting word with the other character)
[21:11:50] <rayh> I should be able to split it up. Problem is I named variables and widgets according to the tail.
[21:12:27] <rayh> And now the tails of these things overlap a whole bunch.
[21:12:47] <rayh> You get a set of 8 scale variables and.
[21:13:47] <rayh> and can't use the new assembled name as a reference for HAL>
[21:13:55] <Lerneaen_Hydra> bya all
[21:14:10] <Lerneaen_Hydra> bye*
[21:15:03] <SWPadnos> hrm
[21:17:17] <rayh> I'm thinking that I'll have to use arbitrary names
[21:17:25] <SWPadnos> the thing is, the tail shouldn't contain any numbers, regardless of whether it was a . otr a - separator
[21:17:29] <rayh> like param1 through param 101
[21:17:43] <SWPadnos> that would be pretty ugly. I hope it's not needed
[21:18:10] <rayh> They have to because the eight scale names must have some sort of difference
[21:18:26] <rayh> in order to use with widgets.
[21:18:52] <SWPadnos> ok. I'm looking at the config tool with sim right now (and I like it, BTW)
[21:20:00] <SWPadnos> when you look at the motion pins, you see digital-out-00 through digital-out-03 - those should be under another branch, IMO
[21:21:48] <rayh> another branch than ?
[21:22:11] <SWPadnos> like this (using -> to show a tree level)
[21:22:29] <SWPadnos> pins -> motion -> digital-out -> 00 01 02 03
[21:22:39] <SWPadnos> (though that's ugly for other reasons)
[21:22:51] <SWPadnos> so 00-03 are a subtree under digital-out
[21:23:10] <rayh> look at parport with stepper_inch.
[21:23:14] <SWPadnos> ok
[21:23:30] <rayh> same numbering problem that jmk points out with m5i20
[21:23:45] <rayh> The last right element of the name is a number.
[21:24:29] <rayh> if you dotted those you'd have nothing left but in or out or in-not
[21:24:41] <SWPadnos> no. unfortunately, it's in or out or in-not
[21:25:10] <SWPadnos> ok. it's a thorny problem
[21:25:53] <SWPadnos> parport was named this way to make it easy to wire, but it does wreak havoc on the software
[21:26:27] <SWPadnos> it should be output.01 or input.01-not
[21:26:32] <SWPadnos> ...
[21:26:49] <rayh> would we have the same problem with any pinned io.
[21:26:59] <rayh> say I've got a 48 io card.
[21:27:20] <rayh> I really don't want each to be a node of it's own.
[21:27:37] <SWPadnos> sort of. the problem is that the hal names are called "pin-number-function", rather than "function.number"
[21:28:02] <SWPadnos> no, but it would be nice to group inputs together, and outputs together, separate from inputs
[21:28:38] <rayh> But if we allow parameters to set in or out for individual pins like you can do with most of the fpga boards.
[21:28:50] <rayh> Then you have a naming mess.
[21:28:53] <SWPadnos> the HAL pins will be named corerctly
[21:29:04] <rayh> It's just pin 1 through 48
[21:29:08] <SWPadnos> you can see that with parport by specifying that the data port be input
[21:29:24] <SWPadnos> then you get 13 inputs, and no output
[21:29:27] <rayh> Okay.
[21:29:50] <SWPadnos> oops - you always get 3 outputs (pins 14, 16, 17)
[21:30:09] <SWPadnos> anyway - 2-9 can be set for in or out on a port by port basis
[21:32:22] <rayh> With most of the 24 or 48 IO cards you can assign 2-8 pin i or o and the third in blocks of four.
[21:33:04] <SWPadnos> this all depends on the naming scheme, which is fubared for parport
[21:33:21] <SWPadnos> the mesa or 8255 cards name the HAL pins in sequence, I believe
[21:33:53] <SWPadnos> I'm not sure if they go in pin order (ie, you have pin.in.00-07, then pin.out.08-15 ...)
[21:34:28] <SWPadnos> or if they go in separate chinks (ie, all inputs pins are numbered sequentially, regardless of whether there are output pins in between)
[21:34:33] <SWPadnos> chunks (oops ;) )
[21:35:40] <rayh> the m5i20 driver names three sets of 25 pins. First set is motion and encoders, second and third is 16 in 8 out
[21:36:08] <SWPadnos> you get out 0-15, and in 0-31, and it doesn't matter where the pins are physically
[21:36:59] <SWPadnos> if the driver could be configured for some other mode, like 24 in and 24 out, then you'd still get sequential HAL pin names
[21:37:21] <SWPadnos> parport is weird because the HAL pins are named for the physical connector pin numbers
[21:37:44] <SWPadnos> which is good for the people that use parports, but bad software design-wise
[21:39:55] <rayh> No with the m5i20 the pins are hard named
[21:40:32] <SWPadnos> one sec - I'm looking at the ax5214h driver
[21:42:02] <SWPadnos> ok. it looks like that one keeps the pin numbers in sequence, regardless of the data direction
[21:42:47] <SWPadnos> so if you specify "IIIOOOIII" as the cfg string, you get 0-23 input, 24-47 output, and 48-71 input
[21:43:13] <SWPadnos> you don't get 00-47 input (on pins 0-23 and 48-71) and 00-23 output (on pins 24-47)
[21:44:56] <SWPadnos> oops - wrong numbers, but hopefully the idea was still clear
[21:45:11] <rayh> Sure.
[21:46:11] <rayh> And how does HAL know what configuration of I v O a card is using. Does that have to be hard coded in the driver?
[21:46:27] <SWPadnos> hopefully it's a config string, passed at loadrt time
[21:46:50] <SWPadnos> that's what it is in the ax5214 driver
[21:47:39] <SWPadnos> and parport, for that matter
[21:51:53] <rayh> So they could be configured in 1-xx and out 1-xx without reference to real pin numbers.
[21:52:14] <SWPadnos> they could be
[21:53:56] <SWPadnos> actually, the pin numbers shouldn't matter. it's how the names are arranges
[21:53:59] <SWPadnos> arranged
[21:54:42] <SWPadnos> parport could just as well name the pins as parport.0.output.nn.out
[21:55:15] <rayh> Well, in the absence of a standard naming convention for hal parameters, I'm sol.
[21:55:15] <SWPadnos> or parport.0.input.15.in-not
[21:55:21] <SWPadnos> sort of :(
[21:55:45] <rayh> That sounds very un intelligible.
[21:55:48] <SWPadnos> what part has to be unique for tcl?
[21:56:11] <SWPadnos> the displayed text can be the same, but the widget name can't be?
[21:58:23] <rayh> But if the displayed text is the same, how does tillie know which to fix for her setup.
[21:58:50] <SWPadnos> it shouldn't be under the same sub-tree
[21:59:20] <rayh> enc-00-scale
[21:59:27] <rayh> is pretty obvious.
[21:59:29] <SWPadnos> if you parse out the encoder 00-03 on ppmc, for instance, those will each be a separate sub-tree with the pins/params for that encoder only
[21:59:44] <rayh> I'm not thinking tree here.
[21:59:51] <rayh> I'm looking at tuning param
[21:59:58] <SWPadnos> ah - one sec ;)
[22:00:48] <SWPadnos> you're looking at the tune 0 - tune 2 tabs?
[22:02:10] <SWPadnos> on my display, the very left hand side of the label "STEPGEN_MAXACCEL:" is cut off
[22:02:22] <SWPadnos> the S is missing the left couple of pixels
[22:02:39] <rayh> Looking at stepper?
[22:02:56] <SWPadnos> yes - stepper_inch
[22:03:37] <rayh> Yep. Gotta stretch that label a bit.
[22:04:06] <rayh> I was afraid to let them float. Bad things were happening during testing.
[22:04:44] <SWPadnos> yep. can it stretch when you stretch the window (pin the left side to the left side of the panel)
[22:05:23] <rayh> I'm feeling a lot like just trashing all of halconfig.
[22:05:36] <SWPadnos> why? it looks quite useful
[22:05:48] <rayh> tossing the handouts I'd worked on for fest
[22:05:52] <rayh> and not even showing up.
[22:06:09] <SWPadnos> don't even think of it!
[22:06:56] <SWPadnos> how would we keel Elson in line? ;)
[22:06:59] <SWPadnos> keep
[22:07:34] <rayh> ha
[22:07:40] <rayh> You'd figure out a way.
[22:07:51] <rayh> I don't think I can make halconfig live.
[22:08:04] <rayh> I've spent weeks on it now.
[22:08:04] <SWPadnos> I'm not sure we could get by without the Resident Loudmouth ;)
[22:08:22] <rayh> You might all go home running machxx
[22:08:31] <SWPadnos> well, as jmk said, we can come up with a specification for pin naming, then stick with it.
[22:08:36] <SWPadnos> eeeewww
[22:08:57] <SWPadnos> that would make things a lot easier for everyone, I think
[22:09:06] <SWPadnos> (naming conventions, not running mach)
[22:10:31] <SWPadnos> one thing you should realize is that in software development, making things work for idiots (tillies) is the hardest thing, even in a suystem that's intended from day one to be used by them
[22:10:39] <rayh> Do you have any other "servo" systems besides univstep there?
[22:10:47] <SWPadnos> m5i20
[22:10:56] <rayh> Is that in the box?
[22:11:38] <SWPadnos> yep
[22:11:51] <rayh> Fire it up and try halconfig with it.
[22:11:53] <SWPadnos> got 4 parports, the USC and an m5i20
[22:12:40] <SWPadnos> ok. running
[22:12:48] <SWPadnos> cool
[22:13:02] <SWPadnos> input scale defaults to 81920?
[22:13:08] <SWPadnos> that seems a bit high
[22:13:28] <rayh> That's what pete put in there.
[22:13:36] <SWPadnos> it still seems high ;)
[22:13:41] <rayh> Yes it does.
[22:14:00] <SWPadnos> that's double the real resolution of my machine
[22:14:02] <rayh> I set mine to 40k for a sherline with servos and 500 ppr encoders.
[22:14:11] <SWPadnos> that's what my Bridgeport will be
[22:14:41] <rayh> Try setting one axis back to another value.
[22:15:12] <SWPadnos> I just saw a cool idea for a servo mount actually. just make something that bolts onto the bearing bracket where the bearing retainer normally is
[22:15:13] <rayh> position needs to be zero or you get fe.
[22:15:14] <SWPadnos> ok
[22:15:26] <SWPadnos> does it need to be "homed"
[22:15:38] <rayh> no
[22:15:51] <SWPadnos> ok
[22:16:14] <rayh> the test and cancel toggle the numbers.
[22:16:26] <rayh> okay sets the entry to the running value.
[22:16:39] <SWPadnos> yep - I see that. very nice, actually
[22:16:56] <rayh> thanks
[22:17:05] <SWPadnos> the only thing missing is a halscope trace showing the overshoot ;)
[22:17:21] <rayh> The button logic was cradek's idea
[22:17:34] <SWPadnos> it works for me.
[22:17:35] <rayh> I wish there was an easy way to do that.
[22:17:39] <SWPadnos> heh
[22:17:59] <SWPadnos> you have to loop through all the edits, disabling them, and the buttons, right?
[22:18:18] <rayh> ??
[22:18:32] <SWPadnos> nevermind - easy way to do the halscope trace :)
[22:18:35] <SWPadnos> I get it now
[22:19:00] <rayh> Yes. All the entry widgets are a loop normal or disable.
[22:19:31] <SWPadnos> one trick I've used on Windows is to put the controls on a panel, then enable/disable the panel itself
[22:19:34] <rayh> You can save your tuning changes to the ini file you started from.
[22:19:40] <SWPadnos> that also propagates down to the child controls
[22:19:49] <SWPadnos> not sure if it works with tcl
[22:19:54] <SWPadnos> ok - lemme try that
[22:20:19] <SWPadnos> with a .bak file - good
[22:21:04] <rayh> Try saving a netlist.
[22:21:17] <SWPadnos> incidentally, the speed seems fine. I looked at the modify page, and it took a second to draw, but nothing terrible
[22:21:37] <rayh> Well that's encouraging.
[22:21:54] <rayh> If you really want to test the speed, refreshing the tree takes the longest.
[22:21:55] <SWPadnos> it's called blah.net.hal?
[22:22:03] <SWPadnos> that'll be 5 seconds, IIRC
[22:22:30] <SWPadnos> yep - about 5-7 seconds
[22:22:33] <rayh> yes. If you edit an ini to use it halconfig will show all available writable params.
[22:22:43] <SWPadnos> I think m5i20 has more pins than the usc
[22:22:57] <SWPadnos> where?
[22:23:44] <rayh> It doesn't let you edit param values in the tuning pages yet.
[22:23:48] <SWPadnos> (ie, where can I edit the ini, and where can I change all writable params)?
[22:23:55] <SWPadnos> ok
[22:24:05] <SWPadnos> that's OK, since those parameters come from the ini files
[22:24:08] <rayh> just copy m5i20.ini
[22:24:47] <rayh> comment out the normal hal files and add the xxx_net.hal
[22:24:52] <SWPadnos> ah
[22:25:09] <rayh> when you restart emc it will show the new ini as well as the others.
[22:25:43] <SWPadnos> ok. cool. you have it keeping track of where it got the information
[22:26:16] <rayh> Yes
[22:26:30] <SWPadnos> I remember discussing that. I'm glad you got it to work
[22:26:59] <rayh> That is why I'm having real difficulties with "naming conventions."
[22:27:17] <SWPadnos> yep. it's a bitch, since the name is the only identifier available
[22:27:34] <rayh> I don't want to impose names on a hal. I'd rather halconfig discover them.
[22:27:40] <SWPadnos> I do have one idea, if it's not too hard.
[22:27:49] <rayh> I had to impose categories on the signals.
[22:28:00] <rayh> I'm all eyes.
[22:28:22] <SWPadnos> if there's only one instance of something (like m5i20, or parport), then don't make a subtree with just "0"
[22:28:44] <SWPadnos> looking at m5i20, it goes m5i20 -> 0 -> (all the stuff)
[22:28:48] <rayh> Yea that would be a lot cleaner to nav around.
[22:29:06] <SWPadnos> I'm not sure exactly how to determine that cleanly though
[22:29:50] <rayh> if {!m5i20.1} { bla bla}
[22:30:24] <SWPadnos> that works if all instances go 0 .. 1 .. 2 etc
[22:30:41] <SWPadnos> I think some boards can skip numbers, based on jumper settings (motenc?)
[22:30:45] <rayh> it comes back to naming again.
[22:30:49] <SWPadnos> yep
[22:31:02] <rayh> Right.
[22:31:23] <rayh> I believe that ppmc starts with zero but I'm not certain of that.
[22:31:29] <SWPadnos> ok, so the immediate problem is that "correct" naming causes problems
[22:31:31] <SWPadnos> yes it does
[22:31:35] <rayh> I do have a dual ppmc card set here but have not tried it.
[22:31:39] <rayh> phone
[22:31:41] <SWPadnos> ok
[22:32:38] <SWPadnos> I need to do some packing. yell when you're ready
[22:38:43] <rayh> np
[22:43:32] <SWPadnos> ok back
[23:00:11] <SWPadnos> hmmm. what's the black rectangle below the show output?
[23:06:48] <SWPadnos> hmmm. we may want to add "check sample config sanity" to the TODO list
[23:08:32] <SWPadnos> looking at m5i20, the input scales are massively high (81920), the MIN limits are some negative number (X=-32, Y=-16, and Z=-6), and MAX limits are all 0
[23:08:54] <SWPadnos> MAX_OUTPUT is 1.0 for all (which may make sense, but I'm not sure) ...
[23:10:16] <SWPadnos> oops. rayh - one more suggestion if you're still there
[23:10:18] <jmkasunich> each sample config was done by a different person, with different ideas
[23:10:34] <SWPadnos> yeah - that makes it even more important to do a sanity check ;)
[23:11:18] <SWPadnos> even some comments saying what the ini vars mean for that particular setup (driver)
[23:12:57] <SWPadnos> rayh, the suggestion is to use the axis name on the "Tune" tab label, rather than the axis number
[23:13:16] <rayh> phone bla bla
[23:13:19] <SWPadnos> read from the [TRAJ]COORDINATES string
[23:13:19] <rayh> brb
[23:13:22] <SWPadnos> ok
[23:13:48] <rayh> back
[23:13:56] <SWPadnos> ok
[23:13:59] <rayh> That black rect was a sep
[23:14:07] <rayh> but something is not quite right there yet.
[23:14:19] <SWPadnos> ok. it got thick when I stretched the window a lot vertically
[23:14:59] <rayh> The limit settings like that, set up for a machine someplace, make me cringe.
[23:15:09] <rayh> even stepper has stupid ones for z.
[23:15:23] <SWPadnos> yep. shall I add "Sample Config sanity checks" to the TODO?
[23:16:07] <rayh> Okay I can do that for the ini tune routines.
[23:16:23] <SWPadnos> should be easy for you - I can just about do it ;)
[23:16:34] <rayh> the netlist tune gets a bit more troublesome.
[23:17:07] <SWPadnos> netlists should use HAL naming, but the tuning tabs should be tillie-compatible
[23:17:13] <SWPadnos> "Tune X" looks so much better
[23:17:46] <rayh> Okay. As long as they don't look at the ini they are tuning.
[23:18:08] <rayh> This is where xml would really give us a leg up.
[23:18:20] <rayh> one giant config file.
[23:18:32] <SWPadnos> yep
[23:18:54] <SWPadnos> emc 2.2 or 2.4 maybe ;)
[23:20:02] <rayh> probably 4.4
[23:20:21] <rayh> scuse me for being down tonight.
[23:21:10] <SWPadnos> no problem. happens from time to time
[23:21:19] <rayh> okay then in summary. I need to fix tree so that if there is only one parport or mxx20
[23:21:25] <rayh> the o goes away.
[23:21:28] <rayh> 0
[23:21:47] <SWPadnos> if it's easy, then yes
[23:22:09] <rayh> and I need to change the approach to naming from parameters.
[23:22:48] <rayh> I'm guessing lookup lists
[23:23:12] <rayh> That way we don't give a fra what folk name em.
[23:24:18] <SWPadnos> I suppose the generic idea for collapsing parport when there's only one is to merge any branch that has only one child (if that's possible
[23:24:49] <SWPadnos> the naming is a bit of a bear I think. can you hold off on that until Wednesday night or Thursday?
[23:25:05] <SWPadnos> I'd like to think about it a bit, but I'm on the road through Wednesday at least
[23:25:47] <rayh> We do what we can.
[23:26:14] <rayh> I don't think it's practical to write a naming convention and do the work in time for emc2 release.
[23:26:44] <rayh> and then rewrite halconfig and produce handouts.
[23:27:21] <SWPadnos> I think it's best if halconfig can handle whatever naming conventions are used
[23:27:29] <SWPadnos> I'd just like to think about how to accomplish that
[23:28:13] <rayh> Okay.
[23:28:36] <SWPadnos> I think it's doable, but I need to look at the code a bit more to be sure
[23:28:44] <SWPadnos> (and maybe that TCL book I have ;) )
[23:29:19] <SWPadnos> cvs server question: if I download a tarball of a directory, does it include subdirectories?
[23:29:58] <rayh> [lindex $thislist [lsearch $thatlist $thatparam] ]
[23:30:24] <SWPadnos> you don't say
[23:30:46] <rayh> and the other way around as well.
[23:31:41] <rayh> Hey thanks for all the help today.
[23:31:56] <SWPadnos> ] ]maraptaht$ tsiltaht$ hcraesl[ tsilsiht$ xednil[
[23:32:02] <SWPadnos> that makes no sense ;)
[23:32:05] <SWPadnos> you're welcome
[23:33:14] <SWPadnos> the answer to the cvs question is yes, subdirectories are included (as expected)