Back
[01:05:01] <tomp> there's some markup left in pyvcp_widget.py (just checked out 7pm cst 15012006)
[01:05:06] <tomp> File "/home/tomp/emc2-head/lib/python/pyvcp_widgets.py", line 232 <<<<<<< pyvcp_widgets.py
[01:05:21] <tomp> the "<<<<<<<" is in the file
[01:09:35] <tomp> i removed all but the self.update_dot(), and it runs, but
[01:09:51] <tomp> i still get Waiting for component 'pyvcp' to become ready............(forever)
[01:16:21] <SWPadnos> was that ever fixed?
[01:22:04] <tomp> SWPadnos: no, i can change the file and make it run, but can't fix pyvcp not becoming ready.
[01:22:30] <tomp> the terminal is still spitting out dots
[01:22:43] <tomp> i dont know how to stop it
[01:33:00] <jmkasunich> <vincent price accent> good eeeeeevening
[01:33:59] <tomp> :)
[01:35:15] <SWPadnos> heh
[01:35:43] <jmkasunich> hmm, the mailing list must be doing funny things
[01:35:56] <jmkasunich> I see a reply to a reply about RC servos, but not the original message
[01:36:04] <SWPadnos> I saw that
[01:36:15] <SWPadnos> and tomp was missing your pyvcp sample mail
[01:36:38] <jmkasunich> thats probably a good thing, seeing as how I never tested that
[01:36:43] <jmkasunich> and I think it had a couple bugs
[01:36:45] <tomp> oh i found that... it was older than i thought
[01:36:52] <SWPadnos> ah
[01:37:15] <jmkasunich> a while back I thought about a hal module for RC servos
[01:38:09] <jmkasunich> I should do that one of these days
[01:38:25] <tomp> and right now i have a runaway hal issue... the halrun -I pyvcp-dro.hal is still waiting for pyvcp to be ready ( and printing endless dots to the terminal )
[01:38:30] <jmkasunich> * jmkasunich ,_ Mr/ useless HAL things
[01:38:44] <SWPadnos> heh
[01:38:53] <SWPadnos> that probably didn't come out right :)
[01:38:58] <jmkasunich> that would have worked better if I wasn
[01:39:01] <SWPadnos> tomp, hit ctrl-c in the terminal
[01:39:06] <jmkasunich> wasn't off by one key
[01:39:18] <SWPadnos> leading spaces are significant
[01:39:21] <tomp> did that... nada
[01:39:40] <tomp> only thing that affects it is ^Z (zombie)
[01:40:15] <tomp> i can open another terminal and bin/halcmd unloadrt all, but the comps still exist
[01:40:34] <tomp> how do i get rid of them?
[01:40:39] <jmkasunich> unloadrt unloads realtime comps only
[01:40:47] <jmkasunich> use unloadusr or just plain unload
[01:40:58] <tomp> ok, i dont know what i'm asking except how do i stopit
[01:41:11] <jmkasunich> bin/halcmd unload might work
[01:42:51] <tomp> bin/halcmd unload _> HAL:0: ERROR: component '' is not loaded
[01:43:02] <tomp> bin/halcmd unloadusr no effect
[01:43:28] <jmkasunich> I guess I don't know exactly what you have going on there
[01:43:42] <tomp> i've been rebooting :(
[01:43:50] <jmkasunich> don't do that
[01:43:52] <tomp> but i wanted to learn about that stuff
[01:44:02] <tomp> well, gimme a clue
[01:44:06] <jmkasunich> I really don't know what you are doing
[01:44:24] <jmkasunich> came into the conversation late, and you've been a bit cryptic
[01:44:40] <tomp> right you didnt see the beginning, my bad...
[01:45:55] <tomp> i just found the files you had for pyvcp and the dro, igot the updated last versions and tried them with this effect
[01:46:24] <tomp> it runs, and appears, but i dont get the hacmd prompt,
[01:46:44] <tomp> just this endless 'waiting for pyvcp to be ready ' series of dosts
[01:46:54] <jmkasunich> ok, lemme get the same files and try it
[01:46:59] <tomp> so i got new checkout of cvs head and built it
[01:47:04] <tomp> same thing happens
[01:47:21] <tomp> i got them from pastebin
[01:47:42] <tomp> but they have the fixes discussed in the thread
[01:47:55] <tomp> i'm looking for the pastebin (or ca) url
[01:48:07] <jmkasunich> please be patient
[01:48:50] <tomp> k
[01:49:49] <jmkasunich> ok I get the same result
[01:50:20] <tomp> how do you kill it?
[01:50:33] <jmkasunich> kill -9 seems to do the trick
[01:50:42] <jmkasunich> but the behavior is a bug
[01:51:02] <tomp> whats the pid to kill? or name
[01:51:12] <jmkasunich> go to another shell and do ps -A
[01:51:16] <jmkasunich> kill halcmd
[01:51:24] <tomp> thanks
[01:51:42] <jmkasunich> I will figure out why its doing that
[01:52:04] <jmkasunich> actually there are two "that"s here
[01:52:34] <tomp> ahhhh it died :)
[01:52:39] <jmkasunich> printing the dots is "expected", in that we told halcmd to load the pyvcp and wait until it exits (so somebody could play around with it)
[01:52:57] <jmkasunich> thats NOT how you would actually build a hal based DRO application
[01:53:16] <jmkasunich> problem #2 is that closing the pyvcp hung halcmd - thats a bug
[01:54:20] <tomp> should the halcmd appear when the window is closed?
[01:54:29] <jmkasunich> I don't know yet
[01:55:34] <jmkasunich> loadusr can do several things, depending on what options you pass it
[01:56:15] <jmkasunich> it can 1) load the program (pyvcp in this case) and immediately continue on to the next line in the hal file
[01:56:31] <jmkasunich> 2) load the program, and wait until it exports its hal pins, then continue
[01:56:46] <jmkasunich> 3) load the program and wait until it exits, and then continue
[01:57:19] <jmkasunich> I think we were aiming for 2 in this case, but the "wait until it exports it pins" test is busted, so it thinks the pins never got exported
[01:57:42] <tomp> should i check maybe with halmeter?
[01:57:50] <jmkasunich> check what?
[01:57:59] <tomp> if pins got exported
[01:58:03] <jmkasunich> I'm sure they did
[01:58:05] <tomp> k
[01:58:27] <jmkasunich> halcmd (in another shell if needed) is the best way to see what is going on in hal
[01:58:38] <jmkasunich> halmeter is good if you want to look at one thing
[01:58:46] <jmkasunich> halcmd show gives you the big picture
[01:59:01] <tomp> i meant the select list inhalmeter to see pins signals parm
[01:59:27] <tomp> yes halcmd is more powerfu
[01:59:29] <tomp> ll
[01:59:32] <jmkasunich> halcmd show pin will give you the pin list
[01:59:42] <jmkasunich> halmeter too, do whatever you like
[02:10:42] <jmkasunich> tomp: found out why it was waiting for the component to be ready
[02:10:56] <jmkasunich> the line in pyvcp_dro.hal that loads the pyvcp should be:
[02:10:58] <jmkasunich> loadusr -Wn foo pyvcp -c foo pyvcp_dro.xml
[02:10:59] <tomp> cool, your fast!
[02:11:41] <jmkasunich> -W alone says "wait till the componenet becomes ready", where "the component" is expected to be named whatever the first arg of loadusr is
[02:12:02] <jmkasunich> adding the "n foo" after -W means "wait till component foo is ready"
[02:12:21] <tomp> yep, it was just -W
[02:12:26] <jmkasunich> and the "-c foo" after pyvcp means "when you create the component, call it foo
[02:12:32] <jmkasunich> as long as the names match, it works
[02:12:59] <jmkasunich> however, if its waiting, and you kill the program, that should stop the wait
[02:13:07] <jmkasunich> thats a bug, and I'm gonna see if I can fix it
[02:13:57] <jmkasunich> actually, for that hal script to work right, you can't use foo
[02:14:27] <jmkasunich> "loadusr -W pyvcp -c pyvcp pyvcp_dro.xml" should do the trick
[02:14:32] <SWPadnos> ok - that was the problem. halcmd is waiting for a component of a different name to become ready
[02:14:47] <SWPadnos> you still need the n, right?
[02:14:56] <SWPadnos> halcmd -Wn pyvcp
[02:14:58] <SWPadnos> ...
[02:15:33] <jmkasunich> not sure
[02:15:45] <jmkasunich> the man page says without n, it uses the name of the first arg
[02:15:48] <jmkasunich> which is pyvcp
[02:16:06] <jmkasunich> show
[02:16:12] <jmkasunich> oops
[02:16:13] <SWPadnos> iirc, the problem was that pyvcp can create a component with a name other than pyvcp. so you have to tell halcmd what the resulting component name will be
[02:16:42] <jmkasunich> exactly
[02:17:13] <jmkasunich> but the example hal file assumes that the component (or rather its pins) _will_ be called pyvcp
[02:17:21] <SWPadnos> so the first command line you posted should workl: halcmd -Wn foo pyvcp -c foo something.xml
[02:17:21] <jmkasunich> linksp pyvcp.blah
[02:17:31] <SWPadnos> ok, so all the links will be wrong
[02:17:37] <jmkasunich> yep
[02:17:40] <SWPadnos> but it won't be waiting :)
[02:17:45] <jmkasunich> right
[02:18:11] <SWPadnos> it's kind of an error waiting to happen, but it should work if people are careful
[02:18:33] <SWPadnos> I guess I should get that var thing working, which would make it easier to keep all the names straight
[02:18:43] <jmkasunich> ?
[02:19:21] <SWPadnos> well, using env vars would be a reasonably good (though ugly) way of keeping the halcmd and pyvcp names the same, as well as making the correct pin connections
[02:19:27] <SWPadnos> but it could result in long lines, so ...
[02:19:39] <SWPadnos> overflow checking should be improved, as you pointed out
[02:19:55] <jmkasunich> I don't see how env vars come into play here
[02:20:29] <jmkasunich> I think the dro hal file was made before the -c option was added to pyvcp
[02:20:32] <SWPadnos> pyname=foo halcmd -Wn $pyname) pyvcp -c $pyname pyvcpfile.xml
[02:20:35] <SWPadnos> -)
[02:20:58] <SWPadnos> in the halfile: linksp $(pyname).count.0.out blah blah
[02:21:08] <jmkasunich> if I were redoing it, I'd use pyvcp -c dro pyvcp_dro.xml
[02:21:15] <jmkasunich> and then all the pins would be dro.blah
[02:21:22] <jmkasunich> and I'd use that name for the links
[02:21:39] <SWPadnos> so halcmd -Wn dro pyvcp -c dro pyvcp_dro.hal ...
[02:21:45] <jmkasunich> yeah
[02:21:55] <SWPadnos> and if you want another one? ...
[02:22:01] <tomp> well this works, and now i'll chg to 'dro' as suggested loadusr -W pyvcp -c pyvcp pyvcp_dro.xml
[02:22:40] <jmkasunich> SWPadnos: dro2 ;-)
[02:22:46] <SWPadnos> heh
[02:22:55] <tomp> my other brother earl
[02:22:57] <SWPadnos> along with a new hal file to connect all the pins ,,, :)
[02:23:17] <SWPadnos> that's Daryl :)
[02:23:28] <tomp> yeh Daryl :)
[02:23:40] <SWPadnos> Larry, Daryl and Daryl :)
[02:23:54] <tomp> 2 guys who'll do anything for a buck
[02:24:15] <tomp> hey thanks guys!
[02:24:20] <jmkasunich> SWPadnos: yes, if you wanted to be able to make N dro's at once, an env var would be helpfull
[02:24:39] <SWPadnos> or >1 of anything at once
[02:24:42] <jmkasunich> if you only want one tho, it just adds another layer of confusion on top of the confusion we already had
[02:24:46] <SWPadnos> heh
[02:27:35] <jmkasunich> hmm, thats unfortunate.
[02:28:15] <jmkasunich> when a loadusr exec fails, any stdout or stderr output from the program being exec'ed goes into the bitbucket (I think)
[02:29:04] <SWPLinux_> SWPLinux_ is now known as SWPLinux
[02:29:22] <SWPLinux> what's unfortunate?
[02:29:28] <jmkasunich> when a loadusr exec fails, any stdout or stderr output from the program being exec'ed goes into the bitbucket (I think)
[02:30:29] <SWPLinux> unless you're grabbing stdin/stderr, it should go to the terminal that controls halcmd (?)
[02:30:50] <jmkasunich> I said "I think", I'm not sure whats going on at the moment
[02:31:57] <jmkasunich> when I run my edited version of pyvcp_dro.hal using halrun, the pyvcp window appears (briefly) then it shuts down because "thread '' not found"
[02:32:35] <jmkasunich> so I tried running the same halfile using scripts/realtime start followed by halcmd -kvf pyvcp_dro.hal"
[02:32:50] <jmkasunich> and pyvcp doesn't even load, and it doesn't even get to the threads error
[02:32:59] <jmkasunich> wtf is the difference between those two cases?
[02:33:10] <jmkasunich> (I've never used halrun before this evening)
[02:33:46] <jmkasunich> ah, PATH crap
[02:33:56] <jmkasunich> probably not even finding pyvcp
[02:35:29] <jmkasunich> yep
[02:35:50] <jmkasunich> and the thread problem is an error in the hal file, left the thread name out of an addf command
[02:36:57] <jmkasunich> thats better
[02:37:14] <tomp> did you get HAL:23: Unknown 'show' type 'pins' ?
[02:37:22] <jmkasunich> pin, not pins
[02:37:40] <tomp> right, remove the s from the file
[02:38:12] <jmkasunich> I dunno what file you have, I have no show commands in this file
[02:38:50] <tomp> oh, this has them sprinkled thru it... some leftover debug... no problem
[02:44:11] <jmkasunich> found a bug...
[02:44:26] <jmkasunich> halcmd loadusr actually checks three places for the specified program name
[02:44:28] <jmkasunich> first the name by itself
[02:44:40] <jmkasunich> then the name with the emc bin dir prepended
[02:44:49] <jmkasunich> then the name with the users path (I believe)
[02:45:25] <SWPLinux> hmmm
[02:45:31] <jmkasunich> if any of those tests succeed, it then proceeds to use the name by itself, regardless of which test succeeded ;-)
[02:45:53] <SWPLinux> oops :)
[02:57:56] <SWPLinux> hmmm. so, on the replace_vars thing. I'm thinking of just erroring out if an environment var is too long (like say, >127 chars) - any objection?
[02:59:18] <jmkasunich> no
[02:59:25] <SWPLinux> ok
[02:59:35] <jmkasunich> var names and vars are both limited to 128
[02:59:44] <jmkasunich> and the total length of the line is also limited
[03:00:05] <jmkasunich> I have no problem with printing a relevant error message and bailing for any overflow
[03:00:11] <SWPLinux> since the replacement happens before tokenization, it can contain more than a name and command, but 128 still seems like a lot
[03:00:14] <SWPLinux> right
[03:00:42] <SWPLinux> two, actually - one that says the command buffer is too short, and another that ways a particular var is too long
[03:00:49] <SWPLinux> s/ways/says/
[03:01:05] <jmkasunich> don't forget var _names_
[03:01:14] <jmkasunich> and ini file section names
[03:01:19] <SWPLinux> right
[03:20:51] <SWPLinux> if you run halcmd -kf, do you get a segfault if you enter just "q"?
[03:21:04] <jmkasunich> I dunno, should I?
[03:21:10] <SWPLinux> I hope not
[03:21:37] <jepler> $ halcmd -kf
[03:21:37] <jepler> halcmd: q
[03:21:37] <jepler> HAL:1: Unknown command 'q'
[03:21:40] <jmkasunich> no, I get "unknown command q"
[03:21:43] <jepler> doesn't for me (haven't updated lately)
[03:21:57] <SWPLinux> ok - that's good. I'll fix my code then :)
[03:22:09] <jmkasunich> lol
[03:36:14] <jepler> http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes-2.0/user/user.html#SECTION03242000000000000000
[03:36:56] <jepler> I am guessing that this is not a "good enough" realtime for emc
[03:38:58] <SWPLinux> hard to tell just by scanning :)
[03:57:29] <cradek> "Pulse With Modulation (PWM) signal as supplied by Mach 2 Step/Dir control similar to stepper motor drivers"
[03:57:37] <cradek> I don't understand what this even means
[03:58:57] <SWPLinux> where is that little bit of wisdom?
[03:59:13] <cradek> http://homanndesigns.com/store/index.php?main_page=product_info&cPath=1&products_id=3
[03:59:19] <SWPLinux> ah
[03:59:48] <SWPLinux> well, it's PWM, regardless of what he says ;)
[04:00:10] <SWPLinux> the digispeed-GX is the one to look at
[04:00:24] <cradek> "Designed for controlling KB electronics KBIC style DC motor controllers as used in Sherline lathes and mills. "
[04:01:03] <SWPLinux> oh right - I wanted to send an email to Xylotex. their emc link is stale (and points to the old BDI dir from the old linuxcnc.org)
[04:01:13] <skunkworks> do all kb electronic dc motor controllser to 5v also?
[04:01:47] <cradek> the nist lathe has some kind of isolator board added onto it
[04:30:54] <SWPLinux> I twiddled with replace_vars, and now I have some funny stuff going on
[04:31:51] <jmkasunich> ah
[05:01:06] <jmkasunich> I need a sounding board...
[05:01:18] <jmkasunich> loadusr, -w, and -W
[05:01:50] <SWPLinux> yah
[05:01:54] <jmkasunich> -w = wait till program exits
[05:02:03] <jmkasunich> -W = wait till it sets the hal component ready flag
[05:02:15] <jmkasunich> nothing prevents you from specifying both
[05:02:23] <jmkasunich> (although that makes no sense)
[05:02:34] <jmkasunich> but thats not what started me on this
[05:02:47] <SWPLinux> it seems that "waitmode" should be {none, ready, finished}
[05:02:48] <jmkasunich> if you give -W, and the program never sets the flag, halcmd hangs
[05:03:15] <jmkasunich> there is actually code in the wait loop that does waidpid(nohang) and sets "exited" if it did
[05:03:26] <jmkasunich> but that isn't tested in the loop
[05:03:30] <jmkasunich> easily fixed
[05:04:00] <jmkasunich> but theres also a goto after the waitpid (I think jeff was reusing some result decoding/ message printing code from farther down)
[05:04:43] <jmkasunich> and if I'm not carefull, the -w -W combo could cause waitpid to be called twice, the second time after the first one has already said the child terminated
[05:05:09] <SWPLinux> that would be a problem. exit implies ready, IMO
[05:05:18] <SWPLinux> (or never will be)
[05:05:25] <jmkasunich> yes, the latter
[05:05:58] <jmkasunich> exit implies "might have been ready, but you blinked - ain't ready now, and won't be cause ain't even alive now
[05:06:22] <jmkasunich> in fact, that may be the answer I'm looking for
[05:06:33] <jmkasunich> any exit, not just an error exit, in the -W loop, is an error
[05:06:43] <SWPLinux> hmmm
[05:07:01] <SWPLinux> I'd say that it's an error depending on the return code
[05:07:54] <jmkasunich> if you say "loadusr -W true", that should not succeed
[05:08:18] <jmkasunich> -W implies "wait until the component is loaded (because I want to connect to its pins)
[05:08:35] <jmkasunich> when "true" exits, it doesn't have any pins
[05:08:48] <SWPLinux> that's true. I guess the user should use -w if they just want something to happen
[05:08:51] <jmkasunich> right
[05:09:14] <SWPLinux> then again, -wW doesn't make sense anyway. -W should probably trump -w
[05:09:41] <SWPLinux> in either case, the loop waiting should exit if the child exits
[05:09:51] <jmkasunich> one should trump the other, not sure which
[05:10:17] <SWPLinux> well, that's a good question, now that you mention it
[05:10:51] <SWPLinux> I gues sit should be "wither condition"
[05:10:54] <SWPLinux> argh
[05:10:57] <jmkasunich> the code (with a few tweaks to fix the other bugs) can do sane things for -wW
[05:11:04] <SWPLinux> it shoud be "either condition"
[05:11:12] <jmkasunich> the -W loop comes first, followed by the -w loop
[05:11:30] <jmkasunich> (each loop is skipped if the option was not specified
[05:11:37] <SWPLinux> they should be the same loop, if possible
[05:11:40] <jmkasunich> so if you spec both, it waits for ready, then waits for end
[05:11:45] <jmkasunich> no
[05:11:48] <SWPLinux> and the check in that loop skipped if the option wasn't specified
[05:12:07] <jmkasunich> I mis-spoke, the wait for exit loop isn't really a loop at all, just an if
[05:12:20] <jmkasunich> it does a waitpid without "nohang"
[05:13:09] <jmkasunich> the -W loop alternates between seeing if it exited, and seeing if its ready
[05:13:29] <jmkasunich> if its ready, it should fall out of the loop
[05:13:35] <jmkasunich> if it exited, thats an error
[05:13:51] <jmkasunich> (exited without ever becoming ready)
[05:14:08] <SWPLinux> that error can be protected with an if(waitingforexit)
[05:14:32] <SWPLinux> and the waitpid(without nohang) can be protected with if(!exited)
[05:14:44] <SWPLinux> whetever that entails ;)
[05:15:06] <jmkasunich> I don't see why you'd want to merge the -w wait (a single blocking call) with the loop (which has a nanosleep call, and prints dots while it waits, etc)
[05:15:39] <SWPLinux> semantically, it makes sense for -wW to be equivalent to "wait for ready or wait for exit"
[05:15:54] <SWPLinux> alternately, it's "continue when ready and continue at exit"
[05:16:01] <jmkasunich> I read it as wait for ready then wait for exit
[05:16:22] <jmkasunich> IOW, and rather than or
[05:16:32] <SWPLinux> that's unnecessary, since wait for exit implies ready (unless there was an error, in which case the program should return an error code)
[05:16:33] <jmkasunich> after all, w AND W are on the command line ;-)
[05:16:37] <SWPLinux> heh
[05:16:47] <jmkasunich> not true, -w does not imply -W
[05:17:06] <jmkasunich> -w might be used with programs that intentionally don't become ready, because they're not even hal components
[05:17:09] <SWPLinux> if it exits, there's no sense checking for ready any more, so in that sense, w implies W
[05:17:25] <SWPLinux> or at least, supersedes it
[05:17:58] <jmkasunich> -w alone means wait until the program exits, whether it ever becomes ready or not
[05:18:31] <jmkasunich> -W means wait until it becomes ready, if it exits without becoming ready, that is an error (its a hal comp dammit, it better become ready or something is wrong)
[05:19:14] <SWPLinux> it could also be a GUI that decides it's not needed (because some non-critical signal is missing ...)
[05:19:13] <jmkasunich> -wW means wait for it to become ready (and if it exits without becoming ready its an error) and after it becomes ready, keep waiting for a normal exit (which is not an error)
[05:19:48] <SWPLinux> ok by me if you really want that functionality
[05:20:15] <jmkasunich> well, thats why I'm discussing it
[05:20:34] <jmkasunich> I want a third opinion, where did that lazy cradek fellow run off to?
[05:20:39] <SWPLinux> bastid
[05:21:33] <SWPLinux> let's look at what happens with programs that don't do what they're supposed to do, and see if that helps
[05:21:43] <jmkasunich> ok
[05:21:48] <jmkasunich> case 1:
[05:22:21] <jmkasunich> pyvcp -c name doesn't match the -W name, so pyvcp never appears to become ready (it is, but under the wrong name)
[05:22:37] <jmkasunich> the user gets disgusted and kills pyvcp
[05:22:42] <jmkasunich> that should be an error
[05:23:05] <SWPLinux> what's the return value if pyvcp (or anything else) gets killed?
[05:23:18] <SWPLinux> (set in the _exit function, no doubt)
[05:23:19] <jmkasunich> dunno
[05:23:50] <jmkasunich> actually I think it returns success
[05:24:04] <SWPLinux> so this case is "things that should stay running, and need to say they're ready"
[05:24:11] <jmkasunich> because if it returned failure, this code would have taken the goto branch and broken out of the loop
[05:24:24] <SWPLinux> ah
[05:24:40] <jmkasunich> instead the code set the exited flag (which wasn't tested in the loop) and just sat there
[05:25:00] <jmkasunich> yeah, -W basically means "this should become ready, and remain running"
[05:25:13] <SWPLinux> the return code is easy to fix in pyvcp, but may not be correct
[05:25:36] <jmkasunich> -w means "this should run to completion" it may or may not be a hal component, and thus may never become ready
[05:26:06] <jmkasunich> absence of either one means "this might keep running, don't wait for it"
[05:26:25] <jmkasunich> there is also a -i
[05:26:45] <jmkasunich> which means "ignore an error return when a -w exits
[05:27:00] <SWPLinux> hmmm - ok
[05:27:09] <jmkasunich> without -i the command would fail if the program returned an error
[05:27:26] <SWPLinux> so there are 8 combinations of w, W, and i
[05:27:31] <jmkasunich> yeah
[05:27:35] <jmkasunich> but some are meaningless
[05:27:46] <jmkasunich> at least right now, -i is only relevant if you have -w
[05:29:07] <jmkasunich> "nothing" is well defined - start the program and carry on
[05:29:36] <jmkasunich> "-i" is meaningless - you're going to start the program and move on, so there is nothing to ignore
[05:29:37] <SWPLinux> since -w will cause this halcmd to not exit until the child exits, does it matter to this halcmd if the component never becomes ready?
[05:30:00] <jmkasunich> -w alone does not (and should not) care if the component becomes ready
[05:30:40] <jmkasunich> "-w sleep 5" is perfectly legal, and maybe even usefull
[05:31:20] <jmkasunich> "-W sleep 5" should (IMO) be an error, because it will never become ready
[05:31:32] <jmkasunich> as it is today, it would hang
[05:31:43] <SWPLinux> I guess I'm not sure that the "insure ready then wait for child exit" is useful enough to cause a problem when someone has a typo (-wW) and runs something that never signals "ready"
[05:32:20] <jmkasunich> if it never signals ready, and never exits, then you are hung until you kill it
[05:32:39] <jmkasunich> if it exits, then it will generate a hal error message and call your attention to the typo
[05:33:42] <SWPLinux> if a child that's supposed to signal "ready" exits with an error (and is therefore never ready), that should clearly allow halcmd to go on
[05:33:47] <jmkasunich> -W basically means "wait until ready OR exit, on exit report error, on ready continue
[05:34:01] <jmkasunich> why should it allow HAL to go on?
[05:34:14] <jmkasunich> its an error - any subsequent link commands might fail, etc
[05:34:37] <SWPLinux> so for some pyvcp thing sees a malformed XML file, and exits instead of saying "I'm ready - start connecting stuff", halcmd should get the error and move on
[05:34:54] <SWPLinux> without -k, halcmd will stop
[05:34:57] <jmkasunich> exactly
[05:35:11] <jmkasunich> thats what you want - stop so the xml can be fixed
[05:35:32] <jmkasunich> not keep going and try to run a machine with parts missing
[05:35:37] <SWPLinux> sure
[05:36:23] <SWPLinux> ok - your ready loop will do that
[05:36:37] <jmkasunich> yeah
[05:36:40] <SWPLinux> and the only thing needed is to protect the next waitpid
[05:36:50] <jmkasunich> -W = loop till ready or exit, and exit = error
[05:37:08] <jmkasunich> since exit = error, its easy to break out and skip the following waitpid
[05:37:29] <jmkasunich> if it becomes ready, then it moves down to the next step
[05:37:37] <jmkasunich> if no -w, run the next line in the hal file
[05:37:42] <jmkasunich> if -w, wait until it exits
[05:38:03] <SWPLinux> well, I won't waste any more of your time. I'd say do it that way, and if anyone complains, they can fix it :)
[05:38:11] <jmkasunich> heh
[05:38:37] <jmkasunich> you know what command is missing that this conversation has brought to mind?
[05:38:45] <SWPLinux> nope
[05:38:47] <jmkasunich> wait-comp <name>
[05:38:53] <SWPLinux> indeed
[05:38:57] <jmkasunich> suppose you want to build a DRO
[05:39:01] <jmkasunich> load the vcp, with -W
[05:39:06] <jmkasunich> connect stuff to it
[05:39:24] <jmkasunich> then wait until the user closes the window before cleaning up and shutting down
[05:39:47] <SWPLinux> that may be a runscript kind of thing
[05:39:55] <jmkasunich> waitusr <comp-name> would be better, don't want to wait on a rt comp
[05:40:13] <jmkasunich> today it is
[05:40:25] <SWPLinux> that brings up all sorts of stuff, like wait-for-value ...
[05:40:26] <jmkasunich> but I don't want a runscript for a dro
[05:40:29] <SWPLinux> sure
[05:41:05] <jmkasunich> the current runscript must run the GUI last, because when that process ends, emc shuts down
[05:41:06] <SWPLinux> it's a semantic shift from a configuration / testing tool to some programming logic
[05:41:09] <SWPLinux> yep
[05:41:23] <jmkasunich> I wonder how axis implements the "run after axis is loaded" hal file?
[05:41:27] <jmkasunich> thats fairly new
[05:41:28] <SWPLinux> and there's only one, so you can't change from tkemc to AXIS or something
[05:41:38] <SWPLinux> it does it itself
[05:41:43] <jmkasunich> inside axis?
[05:41:59] <jmkasunich> or in the runscript somehow?
[05:42:00] <SWPLinux> yep - I'm not sure of the exact method
[05:42:04] <SWPLinux> no - in axis, I think
[05:42:17] <jmkasunich> that would make sense, because the runscript is blocked, waiting for axis to exit
[05:42:37] <jmkasunich> I really do think waitusr would be usefull
[05:43:02] <SWPLinux> do you remember what that ini option is called (to get axis to run something)?
[05:43:06] <jmkasunich> but that can wait
[05:43:08] <SWPLinux> POSTGUI or something?
[05:43:13] <jmkasunich> something like that
[05:43:19] <jmkasunich> (I'm a big help)
[05:43:28] <SWPLinux> POSTGUI_HALFILE
[05:43:46] <SWPLinux> yep - it spawns a halcmd -f command
[05:44:19] <jmkasunich> so its really POSTAXIS_HALFILE, the other GUIs would ignore it
[05:44:39] <SWPLinux> yes, though they could be similarly modified
[05:44:54] <jmkasunich> since they don't export hal pins, they don't really need it
[05:45:08] <SWPLinux> true enough
[05:59:32] <SWPLinux> man - I hate it when you think up-arrow will recall the command "env", and it actually gets "vmware" instead
[06:41:22] <SWPLinux> crap - I just ran the diff on that because I was about to commit ;)
[06:41:41] <jmkasunich> mine shouldn't conflict with yours
[06:41:46] <jmkasunich> totally differnet areas of the code
[06:41:49] <SWPLinux> shouldn't
[06:41:52] <jmkasunich> do a cvs up
[06:42:02] <jmkasunich> you won't get a "C"
[06:42:32] <SWPLinux> is there a fixed version of pyvcp_demo.{hal,xml}?
[06:42:47] <SWPLinux> M - means merged?
[06:42:53] <jmkasunich> modified
[06:42:58] <jmkasunich> (your copy is modified)
[06:43:03] <SWPLinux> ok
[06:43:08] <jmkasunich> my changes should have been merged as well
[06:43:52] <jmkasunich> I think there are several versions of pyvcp_dro.xxx floating around, dunno which are fixed
[06:44:10] <SWPLinux> oh right - it was a dro, not the one in configs/sim/
[06:45:05] <jmkasunich> did the cvs output indicate that it merged in my changes?
[06:46:23] <SWPLinux> I can se they're in there
[06:46:25] <SWPLinux> see
[06:46:46] <jmkasunich> good
[06:46:49] <jmkasunich> bedtime then
[06:47:02] <SWPLinux> yay - I even have a DRO working now :)
[06:47:06] <SWPLinux> see you later
[06:47:18] <SWPLinux> err - not a DRO, a big thing with numbers :)
[07:11:12] <tomp> pyvcp-dro-Zonly diagram
http://imagebin.org/6930
[13:44:19] <jepler> cradek: I don't think it's xrdb that's the problem, but an overzealous C preprocessor
[13:44:35] <jepler> cradek: some idiot might change cpp to issue a warning like this, though I can't fathom why
[13:45:57] <jepler> that's my guess, anyway
[13:46:46] <alex_joni> cpp?
[13:47:09] <jepler> xrdb sends its input through cpp, so that you can use #define, #if, and #endif
[13:47:21] <alex_joni> oh my.. sounds like overkill to me :)
[13:47:33] <alex_joni> but I guess there are people who actually use it that way :)
[13:48:45] <jepler> there were 10 years ago, maybe
[13:49:26] <alex_joni> so I guess you need cpp to use xrdb even for simpel requests?
[13:49:30] <alex_joni> simple even
[13:53:49] <jepler> it looks like ubuntu lts uses 'mcpp_prestd'
[13:53:57] <jepler> $ echo '080' | mcpp_prestd
[13:53:57] <jepler> # 1 "<stdin>"
[13:53:57] <jepler> <stdin>:1: warning: Illegal digit in octal number "080"
[13:54:55] <jepler> MCPP is probably the best C preprocessor in the world.
[13:54:58] <jepler> </the docs>
[14:00:21] <alex_joni> what happens if you use 0x080 ?
[14:00:31] <alex_joni> http://www.ubuntuforums.org/showthread.php?p=996369
[14:00:38] <alex_joni> seems others have problems with _prestd too
[14:02:30] <alex_joni> they fixed that in edgy :
https://lists.ubuntu.com/archives/ubuntu-patches/2006-September/001623.html
[14:03:45] <jepler> in dapper, 'mcpp -@old' is not accepted
[14:06:35] <alex_joni> odd
[14:06:57] <jepler> it's not clear to me whether that's to fix a problem, or because the upstream changed
[14:08:19] <alex_joni> sorry.. don't know more
[14:46:12] <cradek> jepler: thanks for figuring that out.
[15:17:07] <jepler> cradek: it was a blast, I assure you
[15:24:30] <cradek> wonder if [TRAJ]HOME is another of those unused things that should come out
[15:25:48] <jepler> initraj.cc still refers to it
[15:28:46] <cradek> that (emcmotStatus->world_home) looks like it's used for nontrivkins
[15:29:07] <alex_joni> that's right
[15:29:19] <alex_joni> it's used to map from joint homes to world home
[15:29:25] <cradek> ok
[15:29:32] <alex_joni> cradek: you need to specify them all for nontrivkins
[15:37:16] <jepler> so [TRAJ]HOME is unused for trivial kinematics?
[15:37:34] <cradek> appears that way
[15:38:29] <jepler> ini_config describes [AXIS_n]HOMING this way:
[15:38:28] <jepler> HOME_OFFSET = 0.0
[15:38:28] <jepler> A distance to move once the home position has been found. The axis position is set to zero or the [TRAJ] HOME value for that axis after the HOME_OFFSET distance has been moved.
[15:38:34] <jepler> er, HOME_OFFSET
[15:38:36] <jepler> I think that's just wrong ...
[15:39:01] <cradek> yeah that seems totally wrong to me
[15:39:59] <jepler> I wonder if those short explanations should be removed
[15:40:08] <jepler> otherwise, how's this summary? HOME_OFFSET: The axis position of the home switch or index pulse.
[15:40:23] <cradek> sure
[15:41:46] <skunkworks> I could see needing that. the home switch may not be where you want the machine to park - I could see that for a robot arm
[15:56:12] <jepler> the AMD virtualization stuff looks interesting as a foundation for a realtime layer under linux
[15:56:50] <jepler> if the VMM/realtime layer is properly written, linux can disable interrupts all it wants, but the timer interrupt can still be intercepted by the VMM to call the realtime code
[15:58:23] <jepler> including SMM if I read this right
[16:00:36] <jepler> you can force SMM to run in the context of a guest VM
[16:59:04] <alex_joni> jepler: I think "The axis position of the home switch or index pulse.
[16:59:09] <alex_joni> that might be reversed
[17:00:31] <jepler> I don't understand what you mean
[17:00:52] <alex_joni> A distance to move once the home position has been found.
[17:00:59] <alex_joni> that was the previous definition
[17:01:19] <alex_joni> so if you tell it HOME_OFFSET=10, I think it moved 10" in the positive direction
[17:01:39] <alex_joni> now if you say HOME_OFFSET=10, the position of the switch is at 10", then it needs to move -10" to get to 0
[17:01:57] <cradek> alex_joni: the old wording was wrong
[17:02:24] <alex_joni> cradek: are you very sure? I think I didn't get it abou 5 times, but in the end jmk made me understand the old wording
[17:02:31] <alex_joni> I can't remember how it went though :)
[17:02:38] <cradek> heh
[17:02:51] <jepler> I was trying to make that text match what is described here:
http://linuxcnc.org/docs/2.1/html/config/ini_homing/index.html
[17:02:53] <cradek> I think the pictures are right, the wording wasn't
[17:03:12] <jepler> HOME_OFFSET
[17:03:12] <jepler> 'HOME_OFFSET' is a value setable from the ini in the AXIS_* section. It contains the location of the home switch or index pulse, in joint coordinates. It can also be treated as the distance between the point where the switch or index pulse is latched and the zero point of the joint. After detecting the index pulse, EMC sets the joint coordinate of the current point to ``HOME_OFFSET''. The default value is zero.
[17:03:25] <jepler> the old wording in ini_config describes something completely different from this
[17:03:59] <cradek> that wording is how I understand the operation
[17:03:58] <alex_joni> I think that's how it's supposed to work
[17:04:21] <jepler> "It contains the location of the home switch or index pulse" ~ "The axis position of the home switch or index pulse."
[17:04:34] <cradek> (except for "setable" which isn't a word)
[17:04:34] <alex_joni> if you make that joint position ..
[17:05:42] <SWPadnos> it should be called HOME_SWITCH_POSITION
[17:06:06] <cradek> yep
[17:07:21] <jepler> anybody remember emc1 homing? Maybe the text in ini_config actually described emc1 homing?
[17:07:43] <alex_joni> emc1 didn't have OFFSET iirc
[17:07:51] <alex_joni> * alex_joni looks
[17:07:54] <SWPadnos> I think it did
[17:08:14] <SWPadnos> most anything in the ini is a holdover from emc1 ;)
[17:09:28] <alex_joni> HOME_OFFSET <float> where to move axis after home
[17:09:43] <alex_joni> that's from emc/src/emcnml/iniaxis.cc
[17:09:55] <SWPadnos> ok - that's what I thought I remembered. find the switch, then move this far away, then set zero ...
[17:10:26] <SWPadnos> or find the switch, set zero, then move to this position (damn - can't really remember)
[17:10:56] <cradek> I guess I don't care as long as the docs match the current behavior
[17:11:53] <alex_joni> all kinds of crazy things in emc1
[17:11:54] <alex_joni> example:
[17:12:01] <alex_joni> /* Note that I put a multiplication factor of 2 in front of
[17:12:01] <alex_joni> the homing velocity below. The reason is that, I think,
[17:12:01] <alex_joni> if you found the index pulse you know your exact position
[17:12:02] <alex_joni> it is save to travel with higher speeds. In addition to
[17:12:02] <alex_joni> that, you actually see that the machine has found its
[17:12:05] <alex_joni> index pulse for the specified axis */
[17:12:06] <alex_joni> tpSetVmax(&emcmotDebug->freeAxis[axis],
[17:12:09] <alex_joni> 2 * (emcmotConfig->homingVel[axis]));
[17:13:03] <cradek> cvs annotate!
[17:13:29] <alex_joni> I meant the mere fact to randomly multiply the speed by 2..
[17:13:42] <cradek> yeah I know
[17:13:54] <alex_joni> although it's not a bad idea
[17:18:27] <SWPadnos> emc2 has two homing velocities though
[17:19:27] <alex_joni> SWPadnos: yup
[17:19:35] <alex_joni> and it rapids on the last move
[17:20:02] <SWPadnos> yep
[17:20:09] <SWPadnos> so 3 speeds really :)
[17:20:31] <alex_joni> but all are user definable
[17:20:37] <alex_joni> not 2*something definable :)
[17:21:25] <SWPadnos> yep. much better that way (except forthose people who are afraid of editing text files to configure their setup)
[17:21:56] <alex_joni> lol
[19:49:57] <jepler> cradek: can you give install2:/tmp/hal_type_t.txt a quick read?
[19:52:40] <jepler> old version here:
http://linuxcnc.org/docs/2.1/html/man/man3/hal_type_t.3hal.html
[20:02:03] <cradek> I like it
[20:02:21] <cradek> did you get rid of "at least" [range] on purpose?
[20:07:46] <jepler> though it's true (it might turn out that gcc generates non-atomic writes of 8-bit types on x86-64) I think it's best to not bring it up
[20:08:08] <jepler> except in the case of bit, which is likely to confuse a lot of people
[20:08:19] <jepler> (I know I wrote something wrong and I'm a seasoned C programmer who should have known better)
[20:08:52] <jepler> what do you think about saying "at least"?
[20:09:26] <cradek> well what do you get for those types on x86_64 today? isn't it bigger?
[20:10:09] <jepler> typedef volatile __u32 hal_u32_t;
[20:10:20] <jepler> no, unless the underlying library is not giving the right type for __U32
[20:10:30] <alex_joni> jepler: I think there's a small issue with the new deb system
[20:10:40] <jepler> alex_joni: what's tht?
[20:10:41] <cradek> ok then I agree with leaving out "at least"
[20:11:31] <alex_joni> jepler: I tried to install the new packages with dpkg -i emc2*.deb, but emc2-2.6.15-magma collided with emc2 (which it's supposed to), but it wasn't recognized as an update
[20:11:52] <alex_joni> I had to remove the old emc2 package, then install the new debs
[20:12:46] <jepler> I wonder if it will do the same thing under apt
[20:13:07] <alex_joni> I'll set them up as a repo and try
[20:14:00] <jepler> dpkg: regarding emc2-2.6.12-magma_2.1.0~alpha0_i386.deb containing emc2-2.6.12-magma:
[20:14:04] <jepler> emc2-2.6.12-magma conflicts with emc2
[20:14:06] <jepler> emc2 (version 1:2.0.5) is installed.
[20:14:08] <jepler> emc2 provides emc2 and is installed.
[20:14:11] <jepler> you get something like this?
[20:14:14] <alex_joni> yes
[20:35:28] <alex_joni> http://pastebin.ca/318879
[20:35:33] <alex_joni> jepler: it's close
[20:35:47] <alex_joni> but I think emc2-foo should also replace emc2-axis
[20:37:48] <jepler> alex_joni: does it work better when you have emc2-2.6.12-magma Provide: emc2-axis ?
[20:38:10] <alex_joni> * alex_joni needs to try that
[20:38:17] <jepler> er, Provides:
[20:39:34] <alex_joni> if I remove emc2-axis, and only try to install emc2-2.6.15-magma it updates correctly
[20:39:40] <alex_joni> however not on it's own..
[20:39:52] <alex_joni> I need to manually install it.. which isn't that bad now that I think of it :)
[20:41:58] <jepler> alex_joni: so apt-get upgrade doesn't see emc2-2.6.12-magma-2.1.0~alpha0 as an upgrade for emc2-2.0.5? interesting
[20:42:33] <jepler> it means we can put the 2.1.0 packages in the repository and users won't all immediately get upgraded
[20:42:35] <alex_joni> no, it doesn't
[20:42:44] <alex_joni> yeah, that's what I thought too
[20:42:51] <jepler> we won't be so lucky with 2.2 so we'll have to be more careful
[20:43:24] <alex_joni> I'm rebuilding the packages with Provides: emc2, emc2-axis
[20:43:38] <alex_joni> but I wonder if I shouldn't have Conflicts: emc2-axis aswell
[20:43:51] <jepler> maybe, my dpkg skill level is pretty low still
[20:45:22] <alex_joni> setting up a local repo isn't that hard once you figure out the process :D
[20:45:33] <alex_joni> and apt doesn't even complain there's no key
[20:54:28] <alex_joni> jepler: I'm seeing double :)
[20:54:46] <alex_joni> jepler:
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/debian/control.in?rev=1.3.6.3;content-type=text%2Fplain;only_with_tag=v2_1_branch seems there are 2 Provides: lines for emc2-kernel
[20:55:01] <alex_joni> once I figure this out I'll fix it
[20:55:28] <jepler> alex_joni: how confusing
[20:56:10] <jepler> same on the TRUNK
[20:58:06] <jepler> I'd fix it but I imagine you're touching the same file right now
[20:58:38] <alex_joni> yes
[20:58:44] <alex_joni> 2 minutes.. it seems to work now
[20:59:22] <alex_joni> http://pastebin.ca/318899
[21:00:36] <cradek> after the upgrade are there any outdated files left in /etc/emc2?
[21:00:45] <alex_joni> * alex_joni looks
[21:01:16] <alex_joni> all folders are dated today..
[21:02:38] <alex_joni> hmm.. there are a couple of files dated Dec 03
[21:03:23] <alex_joni> but I think those are files which apt just didn't upgrade (no need to)
[21:03:42] <alex_joni> only README's which didn't change and the emc2.gif emc2icon.png, etc
[21:04:05] <jepler> cradek: I think it's standard to leave "configuration files" from a removed package
[21:04:14] <cradek> right
[21:04:30] <cradek> that's why I asked, I wonder if any of it will end up being bogus for the new version
[21:04:42] <alex_joni> no.. it seems there are no old things around
[21:04:45] <cradek> ok, readmes and images, cool
[21:04:50] <alex_joni> only a subset of the new configs
[21:04:52] <cradek> remind me why those images are in /etc?
[21:04:59] <cradek> * cradek shrugs
[21:05:26] <alex_joni> if apt sees a config folder with 5 files, and 2 are the same as the old ones it will skip them
[21:05:37] <alex_joni> it will only update the changes
[21:05:42] <alex_joni> makes sense sometimes :)
[21:11:34] <tomp> pyvcp_widgets with dial widget for analog output
http://pastebin.ca/318915
[21:11:56] <tomp> please test
[21:13:26] <alex_joni> I wonder if pastebin's highlighting is broken oor if tomp has some typos in there
[21:13:45] <alex_joni> """" A jogwheel that outputs a HAL_FLOAT count .... """
[21:14:17] <jepler> alex_joni: that will be accepted just fine but there's an undesired extra double quote at the start of the string
[21:14:25] <jepler> >>> print """"x"""
[21:14:25] <jepler> "x
[21:14:31] <alex_joni> oh.. ok
[21:14:38] <jepler> but clearly the syntax-highlighter doesn't "get" triple quoted strings
[21:14:43] <alex_joni> I wondered because everything after that turned up red
[21:14:56] <jepler> it saw "" "" ... "" " and thinks it's in a string at the end
[21:15:43] <alex_joni> righ :)
[21:15:47] <tomp> right... quadruple quote is wrong
[21:15:54] <alex_joni> right even.. darn my typing sux
[21:17:25] <alex_joni> jepler: remind me.. why do we want emc2-'kernelname' as the package name? opposed to just Requires: 'kernel-image' ?
[21:17:50] <jepler> alex_joni: -sim
[21:18:03] <alex_joni> ah, ok.. I'll be silent :P
[21:18:32] <alex_joni> the rest seems to work though
[21:18:36] <jepler> but if you only want to support one kernel per distribution then it sure could be emc2-rt and emc2-sim intead of emc2-kernelname
[21:18:52] <alex_joni> emc2-rt is no better than emc2-2.6.15-magma
[21:19:16] <jepler> I'm not sure if emc2-sim and emc2 are usable as package names
[21:19:31] <alex_joni> why not?
[21:19:36] <jepler> I dunno
[21:19:39] <jepler> must be some reason
[21:19:42] <alex_joni> * alex_joni tries that
[21:21:22] <alex_joni> I see 'acpi' and 'acpi-support' installed on dapper
[21:21:48] <alex_joni> same for 'apt' and 'atp-utils', 'at' and 'at-spi'
[21:22:13] <alex_joni> 'cpp' and 'cpp-4.0'
[21:22:29] <jepler> maybe I wanted 'apt-get install emc2' to say that there were two candidates: emc2-sim and emc2-(kernel version), and the user must decide which to install
[21:22:40] <jepler> I think you get that by not having a package actually called emc2, but by having several packages that provide it
[21:22:45] <alex_joni> right
[21:23:06] <alex_joni> I guess the 2 variants give us 2 different behaviours
[21:23:31] <alex_joni> emc2 and emc2-sim would give us automatic updates for the users (even for newer kernels)
[21:23:49] <alex_joni> emc2-kernel_ver and emc2-sim is a bit nicer when installing manually
[21:23:54] <jepler> (like 'sudo apt-get install mail-transport-agent')
[21:24:36] <jepler> is it only a small fraction of people who want -sim? if so, go with emc2 and emc2-sim
[21:24:39] <alex_joni> wonder how many ubuntu users do that
[21:24:51] <jepler> tiny?
[21:25:00] <alex_joni> probably
[21:25:03] <cradek> I think the number of sim users will be very small
[21:25:12] <cradek> (the ones who expect packages, anyway)
[21:25:18] <alex_joni> but I'm still trying to decide if our users should know these things
[21:25:41] <alex_joni> I guess for new users it'll be 2 different install scripts anyways
[21:26:07] <alex_joni> and the ones already running RT have little reason to uninstall it, and use only sim
[21:26:42] <alex_joni> jepler: not saying what you did is wrong.. just thinking out loud here
[21:26:46] <jepler> I can take it
[21:26:51] <jepler> tell me what you really think
[21:26:59] <alex_joni> I thought I just did :)
[21:27:43] <alex_joni> I think it's a bit easier for people already running emc2 to keep updating using the automatic update
[21:28:08] <tomp> dial widget
http://pastebin.ca/318927 do we want user to change tick value on screen or only in xml? ( later by pin )
[21:28:10] <alex_joni> new users will have to use a script/ use a live-cd already "fixed"
[21:29:10] <alex_joni> wonder what happens if emc2-sim Provides: emc2
[21:29:25] <alex_joni> then I guess apt-get install emc2 will make them chose
[21:29:49] <jepler> I don't think so
[21:30:13] <jepler> cradek may be right that few users will want emc2-sim so it's silly to make things harder for the typical user
[21:30:14] <tomp> lunch bbl
[21:32:41] <alex_joni> jepler: have you tried building sim packages?
[21:32:59] <jepler> alex_joni: yes I think so
[21:33:03] <jepler> not sure if I actually installed them :-P
[21:33:14] <alex_joni> configure feels lacky..
[21:33:28] <alex_joni> I'm not sure I understand what happens when ./configure sim is entered
[21:38:49] <alex_joni> jepler: I'm thinking about this:
http://pastebin.com/860813
[21:42:31] <tomp> awallin: dial widget
http://pastebin.ca/318927 do we want user to change tick value on screen or only in xml? (later by pin)
[21:43:29] <jepler> alex_joni: looks fine, I assume it tests OK too
[21:43:39] <alex_joni> I'm about to install the packages
[21:43:47] <jepler> tomp: "standard" GUI toolkits don't usually let the user manipulate the tick spacing
[21:45:07] <tomp> awallin: i mean the amount of change per tick ( like .01 or .0001 or 256 )
[21:46:39] <tomp> else user is 'stuck' at some resolution (fine tuning and coarse tuning cannot be done on 1 widget )
[21:48:21] <alex_joni> tomp: how about pin
[21:48:29] <alex_joni> then user can link a second ticker to that pin
[21:49:14] <awallin> hi tomp
[21:49:16] <tomp> alex_joni: or a number
[21:49:26] <tomp> awallin: hiyahiyahiya
[21:49:40] <awallin> pastebin is slow...
[21:49:52] <tomp> take a look at your barely mod'd jogwheel
[21:50:03] <awallin> looking
[21:51:24] <tomp> alex_joni: the number i mention would be a field for user to change the scaling of what 1 tick meant
[21:51:43] <tomp> like the x10 on a scope
[21:52:38] <tomp> i thought of sevral btns (radio buttons) but then thought just let it be simple, let the user change by PI per tick....
[21:52:48] <alex_joni> seems 1:2.0.5 is greater than 2.1.0~alpha0
[21:52:57] <alex_joni> * alex_joni whines
[21:53:04] <awallin> tomp: you haven't bound <shift> or <ctrl> or anything for changing resolution yet?
[21:54:15] <tomp> no, i dont know what to chg them to. dont want to tell user how to think/what to think
[21:55:10] <awallin> tomp: would you want this widget to also have a min and max value, i.e. it cannot go past a certain limit?
[21:55:38] <tomp> awallin: yes, will do that ( not an infinite turn pot )
[21:56:11] <alex_joni> jepler:
http://pastebin.com/860825
[21:56:36] <awallin> tomp: then I think it makes sense to have a separate widget, maybe "dial", and not include all functionality in jogwheel
[21:56:56] <awallin> tomp: would the idea be to change self.unit when shift or ctrl is pressed?
[21:57:29] <tomp> awallin: it is 'dial' now, lives nicely alongside jogwheel
[21:58:33] <tomp> awallin: i'd change self.unit when user likes, shift/ctrl is very digital, what about a field entry?
[21:59:11] <awallin> tomp: do you want the angular change to reflect the actual change (self.funit), or would the dial always turn in discrete increments?
[21:59:34] <awallin> tomp: field entry: why not, but I have not looked at those at all. spinbox might be easier
[22:00:03] <tomp> awallin: no, more & less is ok for me, the angular value is problematic, esp if we chg rez mid turn
[22:00:47] <tomp> awallin: did you ever wire a metawidget? ( spinbox + dial = metawidget )
[22:01:09] <awallin> you could easily wire that in HAL
[22:01:43] <awallin> but it might be more elegant to do it as a new widget, all in python code
[22:03:36] <awallin> tomp: don't you think three levels of 'digital' resolution would be enough: no key=1, shift=0.1, shift-ctrl=0.01
[22:03:45] <tomp> ok, a combination widget... spinbutton for scale & dial for tiks... for now a copy of each creating one new widget, not trying to wire separate widgets into metwidget
[22:04:02] <tomp> awallin: i cant guess what would be enuf
[22:04:02] <awallin> they would not have to be 1, 0.1, 0.01, they could be user selectable
[22:04:28] <awallin> tomp: basically, do you have to set parameters with pyvcp to more than three digits of precision
[22:04:52] <jepler> alex_joni: guess it needs to be 1:2.1.0~alpha0 then
[22:05:15] <alex_joni> jepler: that's what I'm doing now :/
[22:05:45] <jepler> alex_joni: probably faster to just do this instead of full dpkg-buildpackage: fakeroot debian/rules binary
[22:06:06] <alex_joni> I'm using debuild..
[22:06:21] <alex_joni> but that fakeroot .. binary I've used before
[22:06:52] <tomp> awallin: yes,i've done it, passed it in the xml... OOPS i used 'resolution' to do that in tests, and now resolution is 'scale', need another allowed word.
[22:07:51] <alex_joni> The following packages have been kept back:
[22:07:51] <alex_joni> emc2
[22:07:57] <alex_joni> anyone has an idea what that means?
[22:08:23] <jepler> emc2 isn't upgraded back to 1:2.0.5 because you specifically requested the version 2.1.0~alpha0
[22:08:47] <jepler> I think you get rid of that by: apt-get install emc2 (to reset the version number to "latest available")
[22:08:54] <alex_joni> oh that works
[22:09:04] <alex_joni> I think I specifically installed 1:2.0.5
[22:09:28] <alex_joni> should I commit these changes?
[22:15:45] <jepler> sure
[22:16:12] <tomp> awallin: if you meant do i need 3 digits, i cant tell what the user's range or precision might be, gallons or microamps, nor what the amount of change in that range might be, it needs to be flexible
[22:16:29] <alex_joni> jepler: seems I missed something :)
[22:18:12] <awallin> tomp: but I would still argue that three or four digits of precision is plenty for most applications
[22:18:47] <jepler> alex_joni: that never happens to me :-P
[22:19:32] <tomp> awallin: ok we begin there, is there a display item in this widget?
[22:19:58] <alex_joni> jepler: I'm sure it doesn't :P
[22:20:59] <awallin> tomp: what do you mean by display item?
[22:21:01] <alex_joni> hmm.. I see only man1 and man9 in the package
[22:21:52] <alex_joni> nm.. man3 is in the dev package
[22:22:07] <tomp> awallin: feedback saying newscale or feedback saying outputvalue
[22:22:55] <awallin> tomp: no, but you could add text in the middle of the dial if you want. Look at how it's done in pyvcp_bar
[22:23:01] <tomp> yep
[22:24:39] <tomp> bbl ( 2 texts , 1 for current scale i for total, add min, add max, add ^ add alt add shift)
[22:25:00] <awallin> sounds like a good plan
[22:34:55] <jepler> alex_joni: got the problems worked out? hooray
[22:36:52] <alex_joni> I seem to think so :)
[22:48:26] <jepler> there's this .nml problem with 64-bit machines that we never addressed
[22:48:38] <jepler> I have to change the tool buffer size on 64 bit machines
[22:48:46] <alex_joni> oh right
[22:48:54] <alex_joni> which broke it for other machines
[22:49:13] <alex_joni> isn't there something we can fix so you don't have to change the size?
[22:49:27] <jepler> I would rather figure out why changing the size didn't work...
[22:49:31] <jepler> it seemed like it was just john k's machine
[22:49:36] <jepler> that didn't like the bigger size
[22:49:45] <alex_joni> bet that machine is long gone now :)
[22:49:52] <jepler> then we can change it :-P
[22:49:59] <alex_joni> I think it was one of the farm's
[22:50:32] <alex_joni> jepler: wanna release -x64 sim packages for 2.1.0 ?
[22:50:45] <alex_joni> or do you want to change that in TRUNK
[22:50:52] <alex_joni> cradek: see.. I used TRUNK :P
[22:50:55] <jepler> I'd like to do it for 2.1.0
[22:51:12] <jepler> I use it fairly frequently, and just tested it a few minutes ago -- tkemc ran after I changed the nml file
[22:51:26] <alex_joni> emc.nml.. right?
[22:51:27] <jepler> yes
[22:51:30] <alex_joni> what size?
[22:51:47] <alex_joni> 8192 ?
[22:51:52] <jepler> -B toolSts SHMEM localhost 4096 0 0 5 16 1005 TCP=5005 xdr
[22:51:55] <jepler> +B toolSts SHMEM localhost 8192 0 0 5 16 1005 TCP=5005 xdr
[22:52:01] <alex_joni> right
[22:52:18] <jepler> I have a suspicion that under some circumstances the shared memory doesn't get cleaned up at exit, and jmk happened to be in that state on his machine
[22:52:27] <jepler> it would have worked after a reboot or an ipcrm
[22:52:43] <jepler> we don't usually notice that condition, because requesting with the same size again works
[22:53:08] <alex_joni> I see..
[22:53:09] <jepler> that would explain why one person would have a problem, and others wouldn't
[22:53:15] <alex_joni> * alex_joni tries the new value
[22:53:26] <alex_joni> need to rebuild for rip though :)
[22:56:47] <alex_joni> jepler: seems to work OK here
[22:56:53] <alex_joni> AXIS is running
[22:57:14] <alex_joni> tkemc is running
[22:58:42] <jepler> yay
[22:58:51] <alex_joni> jepler: feel free to put that into TRUNK
[22:59:02] <alex_joni> if there are no complaints.. we can put it in 2.1 too