00:13:42 <rayh> rayh has joined #emc-devel
00:15:32 <rayh> Hi Guys
00:15:41 <SWPadnos> hi ray
00:16:20 <rayh> Hi Steven.
00:17:02 <rayh> IMO a couple of hours and I should have a committable version of halconfig with "open."
00:17:33 <SWPadnos> good deal!
00:17:55 <SWPadnos> what did you end up doing for the command/response problem?
00:20:45 <rayh> kept the     fileevent $fid readable {getsHAL}
00:21:36 <rayh> getsHAL appends all of the return lines into a single string.
00:22:43 <rayh> exHAL vwaits for a flag from getsHAL and then returns the final string.
00:22:49 <SWPadnos> right
00:23:05 <SWPadnos> did you ever get read to work (using the % eof char)?
00:23:29 <rayh> There are at least three nearly empty lines at the end of a read % % \n
00:23:42 <rayh> No I tried a time or two but abandoned it.
00:23:53 <rayh> I think that the last newline was tripping things up.
00:23:54 <SWPadnos> ok
00:23:56 <SWPadnos> phone
01:42:09 <rayh> Interesting, "list pin" returns an immediate % as does "list sig" but "list param" does not.
01:42:58 <SWPadnos> hmmm
01:44:32 <rayh> IMO the existing exec works so much better than open it is unbelievable.
01:44:42 <SWPadnos> odd
01:44:46 <SWPadnos> phone
01:46:46 <rayh> np
02:13:53 <rayh> rayh has quit
12:02:55 <anonimasu> anonimasu has quit
13:14:17 <rayh> rayh has joined #emc-devel
13:30:21 <alex_joni> morning ray
13:41:51 <rayh> Hi Alex
13:42:14 <rayh> still fighting with the open command and stuff comming back from halcmd.
13:42:54 <rayh> My typing/spelling is already bad.
13:43:07 <rayh> * rayh needs more coffee
13:43:19 <rayh> You get that power supply running?
13:59:05 <alex_joni> I'm off to get the trafo, just got word it arrived
14:05:05 <rayh> Great
14:15:31 <rayh> Got a problem with halcmd -skf.  It looks like this.
14:15:35 <rayh> rayh@ray64:~/emcdevelop/emc2$ sudo bin/halcmd -skf
14:15:36 <rayh> %
14:15:36 <rayh> newsig MySig1
14:15:36 <rayh> HAL:1: Unknown signal type ''
14:15:37 <rayh> HAL:1: newsig failed
14:15:37 <rayh> %
14:20:29 <rayh> ah.  I forgot type sorry for that.
16:49:15 <alex_joni> back
17:24:17 <alex_joni_> alex_joni_ has joined #emc-devel
17:29:36 <alex_joni_> alex_joni_ has quit
18:11:52 <SWPadnos_> SWPadnos_ has joined #emc-devel
18:12:10 <SWPadnos_> rayh: are you still around?
18:15:30 <rayh> You bet.
18:15:36 <SWPadnos_> hi there
18:15:46 <SWPadnos_> I'm not getting double % using halcmd -skf
18:16:11 <rayh> Missed a line in the commit.
18:16:28 <SWPadnos_> have you updated halcmd?  the stuff I had you paste in might be wrong
18:16:35 <SWPadnos_> cvs update, that is
18:16:39 <rayh> You will if you run it from halcmd
18:16:49 <rayh> Yep several times.
18:16:51 <SWPadnos_> from tcl?
18:17:02 <rayh> halconfig
18:17:05 <SWPadnos_> ok - let me do a full clean checkout and see what happend
18:17:07 <SWPadnos_> happens
18:17:18 <rayh> Let me commit a minor fix first.
18:17:24 <SWPadnos_> ok
18:19:49 <rayh> * rayh twiddles his thumbs waiting for drip feed.
18:20:06 <rayh> k
18:20:07 <SWPadnos_> heh
18:20:24 <SWPadnos_> ok - I'm checking out now - we'll see which version I get
18:20:50 <rayh> If it doesn't show a tree, hit refresh under the file menu
18:21:13 <SWPadnos_> I can re-update halconfig.tcl after building if necessary
18:21:30 <SWPadnos_> I figured I'd get the compilation started on this slow machine
18:23:00 <SWPadnos_> is there an extra "\n" sent from halconfig?
18:23:30 <rayh> You do get a newline to enter commands on rather than a % x
18:23:53 <SWPadnos_> yep - the newline is sent from halcmd so that you can see the % with gets
18:24:26 <SWPadnos_> I'm wondering if there's an extra newline sent to halcmd from halconfig though
18:24:45 <SWPadnos_> (I'm not sure that would cause the problem, and I can't check while it's compiling :) )
18:25:30 <rayh> If you fix multiple returns of % you will break halconfig.
18:25:45 <SWPadnos_> unless I fix halconfig at the same time ;)
18:26:24 <rayh> Right.
18:28:09 <SWPadnos_> so - here's a question on a mostly unrelated topic:
18:28:27 <SWPadnos_> should G0 moves be blended with other types of move (G1-G4)?
18:29:04 <SWPadnos_> (I say no, they shouldn't)
18:34:11 <rayh> I don't see any reason to cause an exact stop between
18:34:52 <rayh> the effect of doing that means that you will introduce something that approaches a dwell
18:35:13 <rayh> say you are drilling a hole and then rapid back out.
18:35:23 <SWPadnos_> well - the reason I ask is that a friend (who doesn't use emc yet) has problems when pulling out of a hole
18:35:39 <SWPadnos_> the G0 rapid to the next hole position is blended with the retract G1
18:35:46 <rayh> doesn't want to;
18:36:27 <rayh> I'd g0 retract to a safe plane.  That is how the canned cycle does it.
18:37:01 <rayh> You will get blending on the two g0 commands hence the need for safe plane.
18:37:13 <SWPadnos_> but what's a "safe plane", if the retract will be blended with the move to the next hole position?
18:37:23 <SWPadnos_> it would be dependent on the maaccel and max vel parameters
18:37:30 <rayh> yep
18:37:48 <SWPadnos_> ok - so "safe" on a fast machine may be 1 inch above the workpiece
18:38:07 <rayh> fast machine with slow accel
18:38:25 <SWPadnos_> yep - disproportionate accel:vel, anyway
18:38:36 <rayh> you got it.
18:39:18 <rayh> Or if you want exact position command it
18:39:44 <SWPadnos_> so G0 should obey G64 (or whatever those are)?
18:39:53 <rayh> yes.
18:40:11 <SWPadnos_> ok.  I"ll suggest that.  It's also possible that DeskCNC is buggy ;)
18:40:51 <rayh> Yes.  I would expect that it is.  There were a lot of shortcuts taken in their motion planner.
18:40:59 <rayh> Only the interp is emc
18:41:27 <rayh> is/was
18:41:36 <SWPadnos_> I was thinking that they can't specify per block blending (it's a serial interface to a microcontroller)
18:41:43 <SWPadnos_> just an overall mode
18:42:34 <rayh> I'm with Shultz on this, "I know nothing!"
18:42:38 <SWPadnos_> heh
18:42:49 <SWPadnos_> "I hear nothink, I see nothink!"
18:43:04 <rayh> that's it.
18:43:15 <SWPadnos_> I see two instances of halcmd in halconfig
18:43:53 <rayh> the bin/halcmd is used to display plain old replies
18:44:19 <rayh> while the open |bin/halcmd -skf is used to do the work
18:44:43 <SWPadnos_> "plain old replies" ?
18:45:03 <rayh> bin/halcmd show pin for example
18:45:34 <rayh> Rather than formatting the replies to conform to jmk's way of showing
18:46:09 <SWPadnos_> ok - so when I click on "components" in the tree, does that use the "|open ... -skf" or an exec?
18:46:20 <rayh> exec
18:46:34 <rayh> if you are in show mode
18:46:46 <SWPadnos_> one sec - phone
18:46:50 <rayh> k
18:48:53 <rayh> I'll work on the ordering of watch
19:19:18 <SWPadnos_> OK.  I fixed the double percent problem
19:19:32 <SWPadnos_> it was an extra \n in exHAL
19:22:17 <rayh> ?
19:23:29 <rayh> puts $fid "${argv}\n"
19:23:47 <rayh> should be puts $fid "${argv}"
19:25:31 <SWPadnos_> yep
19:25:46 <rayh> There is sometimes a % returned at the start of a command as well.
19:28:05 <SWPadnos_> it prints a % when first run
19:28:06 <rayh> perhaps we should gets right after opening the channel and toss the first prompt.
19:28:19 <rayh> before we fileevent/
19:28:32 <SWPadnos_> yep
19:30:54 <SWPadnos_> then you can rip out all the "two % lines" stuff (which I did, and it works fine)
19:31:21 <rayh> k
19:31:34 <rayh> You want to commit?
19:31:47 <SWPadnos_> sure - I'm just fixing the comments ;)
19:32:30 <SWPadnos_> I haven't changed openHALCMD yet - it didn't seem to be a problem
19:33:33 <SWPadnos_> OK - I just fixed that (I think).  It didn't break, anyway
19:35:51 <SWPadnos_> I no longer use "retlength", should I just remove that?
19:37:50 <rayh> Um. Seems that var would be quicker than a string search
19:38:30 <SWPadnos_> could be, though  the comparison is {if $tmp != "\%"}
19:38:53 <SWPadnos_> though the retlength also would remove blank lines, which halcmd does print
19:39:25 <rayh> don't know if blank lines get appended.
19:39:35 <rayh> they would lappend
19:39:49 <SWPadnos_> they do get returned, but they have zero length
19:39:59 <SWPadnos_> so when you add the line, you should get nothing, I guess
19:40:57 <SWPadnos_> well, it works without retlength.  I think I'll take it out (even if it is 12 ns faster ;) )
19:41:22 <rayh> Don't know.  Do know that in many tcl things an empty is {} or ""
19:41:59 <SWPadnos_> as far as the append goes, an empty string should change nothing when it's appended to a string
19:42:22 <SWPadnos_> (not that it's done that way, but I think that's how it should work)
19:43:27 <rayh> I use lappend in a lot of the treenode stuff but that should be long after the returned string.
19:44:51 <SWPadnos_> I'll commit this.  it seems to work the same as before, but without the double % stuff
19:45:52 <SWPadnos_> try that out - see how you like it
19:46:24 <rayh> Great.
19:48:31 <rayh> wind's blowing from the north.  bits are slow.
19:48:35 <SWPadnos_> heh
19:48:50 <SWPadnos_> I've got to brave the outside to get the mail
19:48:59 <SWPadnos_> at least it's above freezing (by a degree or so)
19:49:33 <SWPadnos_> hmmm - it's not that intuitive that you have to click "cancel" in setupcongfig to be able to create a new config
19:49:52 <rayh> I saw that.
19:50:28 <rayh> could combine a couple of screens there I think.
19:50:48 <SWPadnos_> yep, like add an "advanced" button on the first screen
19:51:52 <SWPadnos_> same problem going to run a config - you have to hit cancel after creating a new config, before you're allowed to run it
19:52:15 <rayh> and it doesn't pass the selected config from one to the next.
19:52:21 <SWPadnos_> right
19:52:43 <SWPadnos_> as long as there's a logger present, I'll mention another feature request ;)
19:53:14 <SWPadnos_> add a "default" button to the dialog class, so you can press return instead of clicking on the "next" button all the time
19:53:57 <rayh> I thought that halcmd -s stripped off the ==> stuff.
19:54:10 <SWPadnos_> no - that's still there
19:54:25 <SWPadnos_> just the extra hex prints for bytes and shorts
19:54:41 <SWPadnos_> you still need to know which direction a signal goes
19:57:17 <SWPadnos_> now I remember why - it's a PITA To go through the list of pins twice, just so the "write" pin can be printed first
19:57:43 <SWPadnos_> so you get the arrow for each pin, and you have to find the pin that writes the signal
20:09:02 <SWPadnos> back in a bit
20:13:04 <rayh> k
20:14:45 <rayh> seems to work good.  almost identical to what I had here.
20:30:41 <alex_joni> hello
20:52:17 <rayh> Hi alex
20:53:44 <alex_joni> brb ray
20:58:19 <alex_joni> back
21:30:59 <alex_joni> darn.. my coke froze outside :(
21:54:03 <rayh> alex_joni: Got your sliders in hanconfig just now.
21:54:11 <rayh> halconfig
21:55:52 <alex_joni> nice..
21:55:58 <alex_joni> I'm struggling to get emc2 to run
21:56:35 <cradek> there is a problem without sudo
21:56:44 <cradek> just like on my rtlinux
21:56:47 <alex_joni> I NOTICED
21:56:51 <alex_joni> :)
21:56:52 <cradek> did you do the udev thing?
21:56:55 <alex_joni> yes
21:57:01 <alex_joni> but with sudo it runs
21:57:07 <cradek> aha
21:57:25 <alex_joni> seems that userapp are not allowed to access shm
21:57:28 <cradek> hey I know
21:57:33 <cradek> it's the permissions on /dev/rtai_shm
21:57:37 <alex_joni> yup
21:57:42 <cradek> duhhh!
21:57:44 <cradek> how obvious
21:57:46 <alex_joni> great minds think alike <(
21:57:48 <alex_joni> :)
21:58:15 <alex_joni> crw-------  1 root root 10, 254 2006-01-25 23:49 rtai_shm
22:03:13 <alex_joni> oh madre dio, and all the saints
22:03:18 <alex_joni> ferror on joint 2
22:03:24 <cradek> haha
22:03:49 <cradek> help us, halscope, you're our only hope
22:03:54 <alex_joni> that really annoys me
22:03:58 <alex_joni> no halscope yet
22:04:00 <alex_joni> :D
22:04:10 <cradek> I think it's gtk1.2-dev
22:04:27 <alex_joni> BUT stepper is slowly (Feed_overrid = 120%) chipping away at chips
22:04:33 <alex_joni> so, yay
22:04:41 <cradek> yay yay
22:04:43 <cradek> this is great news
22:04:45 <alex_joni> emc2 is working on ubuntu with your kernel & rtai
22:05:08 <alex_joni> cradek: I suspect I know what the problem is
22:05:15 <alex_joni> on the ferror
22:05:21 <cradek> oh yeah?
22:05:35 <alex_joni> there is an G0 down, continued by a G1 further down
22:05:42 <alex_joni> exactly where this is happening
22:05:57 <alex_joni> so I suspect blending G0 & G1
22:07:45 <cradek> blending colinear segments is definitely wrong
22:07:49 <cradek> you might get a big vel spike
22:15:55 <logger_devel> logger_devel has joined #emc-devel
22:15:55 <herbert.freenode.net> topic is: "Welcome to the Enhanced Machine Control development place. | Regular Developers' meetings 24/7 !"
22:15:55 <herbert.freenode.net> Users on #emc-devel: logger_devel SWPadnos_ rayh SWPadnos alex_joni LawrenceG jtr_ cradek @ChanServ 
22:17:18 <alex_joni> hrmm.. don't get it by running the sim setup
22:17:59 <rayh> Need your quick thoughts on led color.
22:18:05 <alex_joni> red
22:18:08 <rayh> false is dard red
22:18:13 <rayh> dark
22:18:14 <alex_joni> green, blue for true
22:18:35 <rayh> green for true
22:19:46 <rayh> false->dark red, true ->bright green.
22:20:23 <cradek> how about 1 and 0
22:20:40 <cradek> or 1 is led on, 0 is off
22:21:03 <cradek> I have an rs232 breakout box that uses dual color LEDs
22:21:08 <cradek> I can never remember which way it works
22:21:32 <rayh> Is 0 associated with false?
22:21:35 <cradek> yes
22:21:53 <cradek> think about the power light on your monitor
22:22:02 <cradek> for on/true/1, it lights up
22:22:05 <cradek> otherwise, it's dark
22:22:17 <cradek> I think that's what you want for your program, not two different colors
22:22:31 <alex_joni> how about grayed out even?
22:22:39 <cradek> no matter what two colors you pick, you'll have to explain it to every user
22:22:50 <cradek> yeah, grey (matching the background) is fine
22:22:53 <rayh> Yep
22:22:59 <cradek> ON = a red/green/blue/yellow circle
22:23:06 <cradek> OFF = a circle filled with the background color
22:23:48 <cradek> bbl, going home
22:23:59 <rayh> see you.  Thanks
22:24:53 <cradek> also red/green means stop/go or, more harmfully, error condition/normal condition
22:26:25 <rayh> On black and white, I think I'll use dark false light true
22:26:41 <rayh> rather than bg color for false
22:26:57 <cradek> b&w makes this really tough
22:27:06 <cradek> I had that problem writing palm software
22:27:09 <rayh> should work better for color impared folk
22:27:25 <rayh> palm, yep been there.
22:39:59 <alex_joni> night all
22:40:05 <alex_joni> I'm off to bed
22:51:28 <rayh> see you alex
23:14:13 <SWPadnos_> hey rayh - you're still here
23:14:35 <SWPadnos_> or maybe not (I guess I should have had timestamps turned on :) )
23:14:50 <cradek> has anyone seen a problem in emc2 where attempted mode switches are ignored?
23:14:59 <SWPadnos_> not me
23:15:08 <SWPadnos_> but then again, I don't actually use it on a machine
23:15:52 <cradek> http://sourceforge.net/tracker/index.php?func=detail&aid=1205237&group_id=6744&atid=106744
23:18:37 <SWPadnos_> right - I've seen that bug report, but haven't reproduced it (since I only run emc for development purposes ATM)
23:18:51 <cradek> well the gui stops responding
23:18:55 <cradek> you don't need a machine
23:19:01 <cradek> seems only some people run into it for some reason.
23:19:15 <rayh> SWPadnos_: yep
23:19:23 <SWPadnos_> ah - hi
23:19:59 <SWPadnos_> actually, I had a comment (on emc2 equivalents of emc1 configs) I wanted to make on Sunday, but didn't really have the chance
23:20:20 <SWPadnos_> more of an idea, actually
23:20:28 <rayh> ??
23:21:04 <SWPadnos_> It occurred to me that the best plan would be to make a converter for ini files, rather than trying to duplicate every machine config
23:21:17 <cradek> looks like alex_joni has the best handle on this, but he's asleep
23:21:42 <SWPadnos_> I just flipped back and forth a dozen times, and had no issue
23:22:03 <rayh> It would not be difficult IMO to at least read the bridgeport specific sections
23:22:11 <rayh> and write a .hal file from it.
23:23:11 <SWPadnos_> there only needs to be one HAL file structure, since all the bridgeporttask/io modules were the same (right?)
23:23:24 <SWPadnos_> the only difference is what hardware they were linked to use
23:23:49 <SWPadnos_> (ie, with ppmc support, you'd have a module named rbidgeporttask, but it uses ppmc I/O calls)
23:24:03 <SWPadnos_> bridgeporttask
23:24:46 <SWPadnos_> the physical pin connections are either in [MOTION]*_INDEX, or are hardcoded in the module
23:26:07 <rayh> Right for ppmc
23:27:06 <SWPadnos_> is that not the case for the other cards?
23:27:44 <SWPadnos_> note that having MOTMOD = stg_task is easier to deal with, because we know that means "STG"
23:30:36 <rayh> But motmod does not handle any of the iocontrol stuff.
23:30:50 <rayh> and that was the heart of the bridgeport io definitions.
23:31:16 <SWPadnos> well, we have two parameters that determine the machine hardware config (for the most part), TASK =  and MOTMOD =
23:31:50 <rayh> the motion io like limits, homes, enables yes they were board specific
23:32:01 <SWPadnos> bridgeporttask uses either hardcoded connections (which are easy to recreate in .hal files), or configuration read from the ini, which is easy to read again
23:32:33 <SWPadnos> we would have to ask the user what hardware they were using, if we see an ambiguous entry (like bridgeporttask, which was used for just about everything)
23:33:58 <rayh> true bpttask gives us access to a whole range of io signals.
23:34:23 <SWPadnos> it's a fairly well defined set of signals, it's just where they go that's the question
23:34:37 <rayh> yes
23:35:16 <rayh> and that was determined by the settings in the [EMCIO] section
23:35:39 <SWPadnos> right - and those are readable using inifind (even though it's depreciated ;) )
23:35:46 <rayh> The motion io signals were always there
23:36:21 <rayh> their routing was determined by the freqmod, stgmod, or whatever
23:36:43 <SWPadnos> I'd make the converter work by having a description file (similar to a vcp file, possibly), where certain ini keywords are used to generate a .hal file (from a template), and/or ini settings
23:36:53 <SWPadnos> sure, but freqmod has hardcoded signals as well
23:37:16 <rayh> Yep without recompiling there was no flexibility.
23:37:28 <SWPadnos> right - which means we know wher eto look for the config info ;)
23:37:42 <rayh> I think your idea here would make a great converter script.
23:37:53 <SWPadnos> that's what I was thinking
23:37:56 <rayh> Would you run it once and build a new config
23:38:03 <SWPadnos> maybe we can convince jeff to write it in python ;)
23:38:05 <SWPadnos> yes
23:38:14 <SWPadnos> then tweak with halconfig if needed
23:38:24 <rayh> Sure.
23:38:44 <rayh> It could be an add on to setupconfig
23:39:00 <SWPadnos> I was just thinking that.  I'd loke to stay away from a GUI and all that
23:39:05 <rayh> or a stand alone.
23:39:17 <SWPadnos> so I can make it more like halcmd, where GUI progs can use it
23:39:23 <SWPadnos> or command line
23:40:13 <rayh> Sure that way it could be invoked from a button in setupconfig if jmk wants.
23:40:32 <SWPadnos> by the way - on the LED color question - I'd make it so that the circle is dim when 0, and bright when 1.  Let the user choose the color if possible
23:40:43 <SWPadnos> (sorry to change subjects)
23:41:01 <SWPadnos> some signals are good when on (so a green LED), others are bad (so a red LLED)
23:41:08 <rayh> np.  But that brings up a huge issue, personalization and how to save it.
23:41:17 <SWPadnos> yes
23:41:42 <rayh> But how you gonna code that except every possible signal listed someplace.
23:41:56 <SWPadnos> not every possible one
23:42:10 <rayh> just the bad ones?
23:42:12 <SWPadnos> there are only so many motion and IO modules with emc1
23:42:13 <SWPadnos> heh
23:42:26 <SWPadnos> or are we talking LEDs?
23:42:35 <rayh> LED's
23:42:46 <rayh> and the signals that run em
23:42:52 <SWPadnos> (sorry - got a cold, so things flit in and out of the brain rapidly, and not under my control)
23:43:09 <SWPadnos> it depends on the UI you're talking about
23:43:13 <rayh> I know that feeling -- often.
23:43:29 <rayh> Wish I could blame it on a bug.
23:43:30 <SWPadnos> if it's halconfig, then just choose some color, and dim=false, bright=true
23:43:32 <SWPadnos> heh
23:43:44 <rayh> That's what I was thinking.
23:43:49 <SWPadnos> usually I wait until the extra thoughts go away, but then I can't remember them
23:44:03 <rayh> firebrick4 v firebrick1
23:44:38 <SWPadnos> err - ok.  Maybe you should get some rest ;)
23:45:49 <SWPadnos_> does tcl have a doubleclick event?
23:46:14 <rayh> Sure and all the modifiers.
23:46:42 <SWPadnos_> ok.  I think I'll add doubleclick config selection to setupconfig :)
23:47:24 <rayh> What happens when you doubleclick
23:47:31 <SWPadnos_> nothing
23:48:23 <rayh> Button1, B1     Mod5, M5
23:48:24 <rayh> Button2, B2     Meta, M
23:48:24 <rayh> Button3, B3     Alt
23:48:24 <rayh> Button4, B4     Double
23:48:25 <rayh> Button5, B5     Triple
23:48:48 <rayh> are just a few of the possible.
23:48:54 <SWPadnos_> ok
23:49:04 <SWPadnos_> how are UI events captured?
23:50:05 <rayh> bind "widget" <Double-Button-1> -command {}
23:50:24 <SWPadnos_> ok, thanks
23:50:36 <rayh> if you use "." for widget it is always on regardless of where the focus is.
23:50:44 <SWPadnos_> I should have remembered that from the halcommand tester
23:50:53 <SWPadnos_> ok - that's a "bind all"
23:50:56 <rayh> np.
23:51:06 <rayh> Close enough
23:51:23 <SWPadnos_> or "bind default", more likely
23:52:25 <rayh> gotta get some dinner here back later.
23:52:31 <SWPadnos_> ok.  see ya