Back
[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
[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
[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: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