Back
[00:00:51] <Jacky^> G night
[00:01:02] <Jacky^> Jacky^ is now known as Jacky^afk
[00:15:28] <k4ts> night
[00:16:10] <rayh> k4 musta saw me sneaking in!
[01:02:55] <Jacky^afk> Jacky^afk is now known as Jacky
[01:38:16] <Jacky> Jacky is now known as Jackyafk
[01:38:36] <Jackyafk> Jackyafk is now known as Jacky^afk
[03:25:23] <mbaulfinger__> mbaulfinger__ is now known as mbaulfinger
[14:29:07] <Jacky^afk> Jacky^afk is now known as Jacky^
[15:20:30] <Jacky^> Jacky^ is now known as Jacky^afk
[16:57:08] <Jacky^afk> Jacky^afk is now known as Jacky^
[16:59:44] <Jacky^> rayh: is Emc2 notes doc released under GPL or GFDL ?
[17:00:25] <rayh> * rayh looks a bit
[17:00:34] <Jacky^> Id like to translate it in italian..
[17:01:42] <Jacky^> and if is possible, id like to re-distribuite it for Roboitalia Community
[17:02:28] <Jacky^> Im not sure if is permitted or under what terms of license
[17:02:34] <rayh> Right now is shows no copyright, which means it is owned by jmk
[17:03:00] <Jacky^> should I ask to jmk ?
[17:03:26] <rayh> I'll get him to put a author and copyright on it.
[17:04:00] <Jacky^> I hope in something like gfdl
[17:04:04] <rayh> Yes do, I'm certain there will be no problem with your translation.
[17:04:14] <Jacky^> ok, thanks :)
[17:04:37] <bill20r3> Hi.
[17:04:49] <Jacky^> I already have the latest vers. you gave me
[17:04:58] <rayh> okay.
[17:05:03] <Jacky^> hi bill20r3
[17:19:39] <bill20r3> Question, when you're cnc milling something that needs to be milled on both sides, how do you align it exactly for the second side?
[17:20:38] <Jacky^> good question
[17:21:06] <Jacky^> it think depend on too much things ..
[17:21:27] <Jacky^> I never tried to get it
[17:22:24] <Jacky^> I think it*
[17:22:42] <jepler> for circuit boards, you can ensure there's no rotation by putting one edge of the board up against something fixed and flat
[17:22:53] <bill20r3> I'm >< this close to ordering conversion parts.
[17:23:07] <bill20r3> if the geckos werent gonna be like $400+ I'd have allready ordered.
[17:23:25] <jepler> then, use cordinate system offsets for X and/or Y before beginning to mill the second side
[17:24:43] <bill20r3> that makes sense for square stuff.
[17:24:47] <jepler> by always drilling a hole at (0,0) you have something to jog to when setting the offsets
[17:24:53] <cradek> bill20r3: often you use an edge finder
[17:25:33] <jepler> cradek: this is a manual process, using that thing with a dial?
[17:25:46] <alex_joni> hi jeff
[17:25:49] <cradek> it is a manual process, but it doesn't have a dial
[17:25:51] <jepler> hi alex
[17:26:53] <cradek> http://www.metalwebnews.com/howto/edge/edgefind.html
[17:28:09] <jepler> oh that thing
[17:28:23] <bill20r3> I just got one, but I havent used it yet.
[17:28:25] <cradek> if you're using a milling vise, you use an indicator in the spindle to mount it squarely. Then using the squareness of the mounting and the edge finder, you can relocate your part
[17:29:34] <CIA-14> 03rayhenry * 10emc2/tcl/bin/halconfig.tcl: Switch to open command for most halcmd comm. Major reorganization.
[17:30:01] <bill20r3> that makes sense.
[17:30:09] <bill20r3> that also reminds me I need a better vise.
[17:30:14] <cradek> haha
[17:30:31] <cradek> yeah if you don't have any parts you can depend on (to be square, for instance) relocating a workpiece is really hard.
[17:30:46] <cradek> a good milling vise will be square on the back jaw and the bottom
[17:30:58] <bill20r3> I have a crappy drill-press vise.
[17:31:10] <bill20r3> I just got it because I needed something now.
[17:31:14] <cradek> first carefully clean out chips, then as you tighten the vise, thump the top of the workpiece with a non-marring hammer
[17:31:38] <cradek> you may have to use parallels if your piece is short
[17:31:56] <cradek> then locate two edges (that you carefully left on the work before flipping it) and you're done
[17:32:02] <bill20r3> that reminds me to get some parallels
[17:32:09] <bill20r3> <--- new, lacks tools.
[17:33:00] <cradek> thinking ahead to these remounts is a big part of successful machine work
[17:33:19] <cradek> lathes are worse because chucks aren't very repeatable at all
[17:33:27] <bill20r3> ugh.
[17:33:50] <bill20r3> mine is all wonky, if I can get something with less than .001 runout I'm pretty happy
[17:34:06] <bill20r3> although I do have a new 4jaw chuck that I havent' mounted yet.
[17:34:09] <bill20r3> so that should help.
[17:34:32] <cradek> yeah at least with a 4 jaw you can use an indicator to recenter something
[17:34:49] <cradek> but turning between centers is better if you need to flip the work
[17:37:14] <bill20r3> I'm not really at the point where I'm building anything complex yet.
[17:37:19] <bill20r3> I'm just learning, slowly.
[17:38:20] <cradek> when I started, I took the first few lathe and mill classes at my local community college
[17:38:32] <cradek> it was VERY valuable and not at all expensive
[17:38:37] <bill20r3> I looked for one, but they only had one that was even close, and it was full
[17:38:40] <cradek> also fun
[17:38:46] <cradek> that's too bad
[17:38:48] <bill20r3> it was 'intro to mechanical design'
[17:38:55] <bill20r3> yeah, I'll have to try again next term
[17:38:58] <cradek> it's also nice to use well-maintained machinery that you don't have to buy
[17:46:06] <jepler> bill20r3: for steppers, anyway, there are alternatives to the geckos that are quite a bit cheaper, though they may be somewhat lower-performance.
[17:46:22] <les_w> I got my dad to but a unimat lathe mill when I was 15.
[17:47:03] <jepler> bill20r3: for instance, if you can find a way to get the circuit boards made inexpensively, the L297/8 board at www.pminmo.com run bipolar steppers and the parts cost around $25 per board (1 board per axis)
[17:47:03] <les_w> $129.
[17:47:25] <bill20r3> hmm.
[17:47:36] <bill20r3> it's the cost of the gecko's thats really putting me off.
[17:47:57] <SWPadnos> remember the voltage and current specs though
[17:47:59] <bill20r3> ahh, he sells blank pcb's for $8
[17:48:03] <SWPadnos> (hi)
[17:48:05] <bill20r3> I can solder like a mofo
[17:48:15] <cradek> yeah I understand geckos are really good but they sure are expensive.
[17:48:30] <jepler> I didn't know he sold the boards. That makes it even easier.
[17:49:00] <jepler> the board for sale is not the L297/8 board I was referring to
[17:49:01] <Jacky^> uh, sorry I lost the topic ..
[17:49:20] <Jacky^> bill20r3: are you tryng to start a business with pcb's ?
[17:49:31] <bill20r3> no, I'm just a hobbiest.
[17:50:16] <jepler> bill20r3: this is the board I'm talking about:
http://www.pminmo.com/l297-8/l297-8.htm
[17:50:32] <SWPadnos> even Jymmm (the cheapskate) said that he'd have gotten geckos if he had known what he knows now (he has a Xylotex)
[17:51:14] <cradek> I think it's easy to predict that performance of a xylotex is going to be bad
[17:51:29] <bill20r3> yeah, I dont want to get something I'll just have to replace.
[17:51:43] <SWPadnos> I'm not sure a build-it-yourself kit will be much better.
[17:51:54] <jepler> l297/8 has higher voltage limits, and all the good board designs use external protection diodes
[17:52:08] <cradek> and provision for heatsinking
[17:52:09] <jepler> I think it's better (more reliable certaily) than the xylotex seems to be
[17:52:14] <SWPadnos> ok - could be
[17:52:31] <jepler> not 80V voltage, but 44V can be used reliably
[17:52:34] <Jacky^> I think cnc isnt the answer for pcb, its just an alternative way..
[17:52:37] <jepler> * jepler goes to lunch
[17:52:44] <SWPadnos> 2.5A may be a significant limitation
[18:19:44] <CIA-14> 03rayhenry * 10emc2/tcl/bin/halconfig.tcl: minor startup problem with tree.
[18:30:18] <Jacky^> Jacky^ is now known as Jacky^dinner
[19:13:07] <Jacky^dinner> Jacky^dinner is now known as Jacky^
[19:45:47] <CIA-14> 03swpadnos * 10emc2/tcl/bin/halconfig.tcl: Fixed double percent problem with halcmd -skf.
[20:34:04] <k4ts> hello
[20:37:17] <Jacky^> hi guys
[22:55:55] <Jacky^> Jacky^ is now known as Jacky^afk
[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