#emc | Logs for 2005-05-24

Back
[00:00:28] <asdfqwega> I'm debating whether to apply for developer access to emc
[00:00:30] <CIA-12> 03paul_c * 10emc2/src/emc/rs274ngc/interp_cycles.cc: Also need to fix a bug that Billy Singleton pointed out back in March.
[00:15:49] <Phydbleep> Whee!
[00:28:57] <paul_c> damit... The compile farm shows the bdi-4 branch as failing to build...
[01:13:48] <daryl> paul_c: Any thoughts on that axis/tkemc x-axis problem?
[01:14:12] <paul_c> Yes.
[01:14:38] <paul_c> Axis uses OpenGL for much of it's rendering
[01:15:29] <paul_c> The system that is having problems uses one of those chipsets with video on the MoBo
[01:16:01] <paul_c> Shared main memory is known to cause problems with realtime systems.
[01:16:33] <daryl> Would putting in a video card help?
[01:17:04] <paul_c> I would surmise that if axis was run as a remote GUI (or a decent video card was installed), the problem would disappear.
[01:17:29] <daryl> But not running it through an SSH tunnel?
[01:18:09] <paul_c> nope - That only compounds the problem with eth0 data.
[01:19:28] <paul_c> damit John...
[01:19:38] <jmkasunich> you've been busy
[01:20:18] <paul_c> fscking{mumble,mumble] CVS $Tags$
[01:20:27] <jmkasunich> dammit yourself... there was something I wanted to ask you, and in the last 5 mins it completely slipped my mind
[01:20:30] <cradek> are you guys talking about an AXIS problem?
[01:20:35] <jmkasunich> you think I makde to many?
[01:20:42] <jmkasunich> s/makde/made
[01:20:44] <daryl> cradek: Sort of.
[01:21:00] <daryl> My system misses steps on the x-axis when I'm running axis
[01:21:06] <jmkasunich> tags can be deleted... I needed them to keep things straight during the kbuild merge(s)
[01:21:08] <cradek> I'm half of the team to blame for AXIS
[01:21:34] <cradek> daryl: oh, that doesn't sound like an AXIS problem. It sounds like a problem with your realtime setup.
[01:21:49] <daryl> cradek: Could be... but what would it be?
[01:21:51] <cradek> AXIS puts a lot of load on the X server or GL driver.
[01:22:17] <cradek> maybe it would show up with any (non-realtime) program loading your system.
[01:22:25] <daryl> Maybe.
[01:22:53] <daryl> cradek... how tough would it be to get axis to run on another non-realtime machine?
[01:22:57] <cradek> run glxgears or something and try tkemc
[01:23:27] <cradek> you need to find and fix the actual problem, not hack around it, if you want your system to be reliable.
[01:23:50] <daryl> Umm... If the actual problem is load, then removing the load is the fix, isn't it?
[01:24:03] <cradek> the actual problem *isn't* load
[01:24:19] <cradek> the non-realtime load does not affect the realtime programs on a system that's working properly.
[01:24:59] <cradek> AXIS, your X server, GL drivers (mesa?) are all non-realtime.
[01:26:22] <cradek> I'd say start from square one - check your BIOS, make sure all power management is off
[01:26:48] <cradek> if you're using BDI you can be relatively sure the problem is your hardware or BIOS setup
[01:27:12] <daryl> Sure...
[01:27:28] <daryl> I'm setting up for the glxgears test.
[01:30:30] <daryl> cradek: glxgears kills it (really accentuates the problem)
[01:30:37] <cradek> great!
[01:30:42] <cradek> then you'll really know when it's fixed.
[01:30:43] <nevyn> no hardware gl...
[01:30:58] <cradek> I use AXIS with software GL on a very old video card
[01:31:02] <nevyn> but even so mesa shouldn't affect rt performance
[01:31:05] <cradek> like I said, none of that should affect the realtime
[01:31:12] <nevyn> right
[01:31:13] <cradek> yes, exactly
[01:31:16] <nevyn> something's whack
[01:31:21] <cradek> haha
[01:31:23] <cradek> I think he knows that
[01:32:37] <cradek> daryl: I bet your lose steps "less often" or even "very rarely" with tkemc. I bet you will see errors on a very long job.
[01:32:42] <paul_c> onboard video & shared memory is the problem
[01:32:44] <cradek> err, "you"
[01:32:54] <daryl> So... does the fact that it only appears to affect the x-axis indicate anything?
[01:33:09] <daryl> cradek: Sure... wouldn't suprise me.
[01:33:12] <cradek> daryl: doesn't ring a bell for me
[01:33:36] <daryl> So... suggestions on how to go about solving the problem?
[01:33:53] <cradek> 20:32:01 < paul_c> onboard video & shared memory is the problem
[01:34:00] <cradek> 20:25:41 < cradek> I'd say start from square one - check your BIOS, make sure
[01:34:00] <cradek> all power management is off
[01:34:21] <paul_c> Turn "Legacy USB support" off too
[01:34:35] <daryl> cradek: ok... will look at the power management in a sec.
[01:34:38] <daryl> paul_c: usb in bios?
[01:34:40] <paul_c> and then try a plug in video card.
[01:34:52] <paul_c> (USB in bios, yes.)
[01:35:31] <daryl> Hmm... can't try the video card thing today. I'll have to go buy one. Before I do that, is there anything I need to stay away from?
[01:36:30] <cradek> daryl: you don't have any old PCI piece of junk video card? Just about anything will work
[01:36:53] <cradek> I don't know much about modern video cards - I salvage everything
[01:37:22] <daryl> I'll look. But I think the only video cards I have laying around are from ISA days. Except for the one in this machine (not the emc machine), which I suppose I could borrow for a bit but I'd rather leave it together. :)
[01:38:47] <daryl> cpu internal and external caches enabled. Sensible
[01:38:48] <daryl> ?
[01:38:55] <cradek> sure
[01:39:59] <daryl> "Fast A20 Gate option" was set to fast. Other option is normal. Does it matter?
[01:40:09] <cradek> probably not
[01:40:29] <daryl> APIC mode... disable?
[01:40:38] <cradek> is it SMP?
[01:40:53] <cradek> (dual processor)?
[01:40:57] <daryl> no
[01:41:08] <cradek> I don't know - paul?
[01:41:25] <cradek> daryl: is it hyperthreaded?
[01:41:39] <daryl> No idea
[01:41:44] <cradek> daryl: pentium 4?
[01:41:48] <daryl> Athlon xp
[01:41:56] <cradek> * cradek shrugs
[01:41:59] <cradek> I don't know then
[01:42:17] <daryl> What is "APIC Mode"?
[01:42:17] <cradek> you might try turning off the APIC
[01:42:30] <cradek> the APIC routes interrupts between the (several) processors on an SMP system
[01:42:51] <daryl> I'll try disabling it.
[01:42:56] <cradek> I have no idea what it does without SMP or HT
[01:43:04] <cradek> can't hurt
[01:43:41] <cradek> brb
[01:43:43] <daryl> Should video bios be cacheable?
[01:43:59] <cradek> I don't think it matters
[01:46:08] <daryl> parallel port mode matter? It's set to SPP right now.
[01:49:09] <fenn> cradek, while you're talking about axis, i'm also having problems..
[01:49:31] <fenn> it gets stuck in a loop and hogs cpu when i start emc
[01:50:15] <fenn> i can hit interrupt and it will tell me where it is. it used to complain about "execute_code" not being in some file.. cant remember which file
[01:50:41] <Phydbleep> APIC? Or APCI?
[01:51:37] <Phydbleep> * Phydbleep pokes daryl with a stick.
[01:52:39] <fenn> the file was rs274
[01:53:39] <daryl> Wakes up.
[01:53:43] <daryl> There were both
[01:53:58] <Phydbleep> Turn them both off I think.
[01:54:06] <daryl> I did
[01:54:09] <daryl> No luck
[01:54:40] <daryl> It seems very odd to me that the y-axis is fine, but the x isn't.
[01:54:43] <Phydbleep> Disable all the caching, bios/video mem/rom.
[01:55:01] <daryl> Including the processor caches?
[01:55:30] <Phydbleep> For a test? yeah, Then re-enable them one at a time.
[01:55:53] <Phydbleep> * Phydbleep has seen bad L1/L2 cache and cache controllers.
[01:56:11] <daryl> hmm. well, worth a shot.
[01:58:42] <daryl> Does agp mode 1x, 2x, or 4x matter?
[01:59:08] <CIA-12> 03paul_c * 10emc2/src/emc/motion/motion.h: Change the command handler returns in to #defines rather than an enum - Removes one style argument..
[01:59:39] <Phydbleep> 4x should be ok
[02:02:13] <daryl> hmm... rebooting with 1x atm (didn'
[02:02:19] <daryl> t see your response early enough)
[02:03:29] <fenn> daryl your y axis is probably losing steps too but you don't notice as much
[02:03:52] <daryl> maybe... except that it's _really_ bad on the x and not detectable on the y. They have identical setups
[02:04:08] <cradek> I agree that sounds strange.
[02:04:28] <fenn> cradek axis has no way to set offsets?
[02:04:43] <cradek> sure, hit f5
[02:04:52] <cradek> now type g92
[02:04:58] <cradek> :-)
[02:05:31] <jmkasunich4> no gui here...irc on one tty, shell on the other
[02:05:33] <jmkasunich4> trying configure
[02:06:10] <fenn> sorry i'm new to gcode.. trying to set the origin somewhere near the program plot so i can look it, rotate, etc
[02:06:27] <cradek> you mean you just want to move the view? Drag it with the mouse
[02:06:51] <cradek> maybe I still don't understand what you're asking
[02:06:58] <fenn> the plot always seems to move to z=-100 or so just when i rotate it
[02:07:01] <daryl> Phydbleep: no luck
[02:07:15] <fenn> so it looks like a little tiny square far away
[02:07:41] <cradek> if you hit the preset view icons does it look right?
[02:07:46] <fenn> yeah
[02:07:56] <cradek> but then you can't drag with the left mouse button?
[02:08:34] <daryl> It's almost like the writes to the parallel port aren't working right
[02:08:47] <fenn> cradek, i can drag with left and right buttons but not middle button
[02:09:08] <fenn> (using a regular 3 button mouse, no fancy mouse wheel stuff)
[02:09:17] <cradek> right button should zoom
[02:09:22] <cradek> middle button should rotate
[02:09:41] <cradek> if you choose view "P" (perspective) and then rotate there should be no jump
[02:10:09] <cradek> if you rotate from X Y or Z there will be a slight jump as it switches from isometric to perspective
[02:11:31] <cradek> daryl: are you using step/dir?
[02:13:17] <daryl> yes
[02:13:31] <cradek> daryl: then it writes all four axes at the same time - all to the same IO port
[02:13:47] <daryl> I see bursts of steps on x... y looks fine
[02:14:02] <cradek> that's pretty strange.
[02:14:26] <daryl> Also see dir changing for x when it shouldn't be (I think). My test is just drawing a circle with g2
[02:15:10] <daryl> How tough would it be go get emc to put step/dir for x out on different bits on that port? (i.e.: can it be done in the ini file)?
[02:15:23] <cradek> no
[02:15:27] <cradek> it's a C change
[02:15:31] <daryl> bummer
[02:15:48] <fenn> seems like that sort of thing should be soft-coded
[02:15:57] <cradek> fenn: it is in emc2.
[02:16:00] <daryl> Maybe another day I'll checkout the code and try that.
[02:17:52] <daryl> It seems like either the parallel port is buggy or there's some kind of race condition somewhere in the code.... but if the latter was true, I'd expect other people to have the same problem.
[02:19:29] <cradek> daryl: step/dir works right - trust me on this
[02:20:24] <daryl> Sure... I believe you. I'm just telling it like it is.
[02:20:58] <cradek> sure, I agree it's weird
[02:21:21] <cradek> but there's no problem in the step/dir code of the form "go look and see if glxgears is running, and if so, screw up X"
[02:21:46] <cradek> I wish you had a video card to try so we could see if Paul is right
[02:23:13] <daryl> Just tried slowing down some clocks to see what happens... no luck.
[02:23:20] <daryl> I'll go look through my boxes of crap... bbias
[02:26:24] <fenn> can't seem to get it out of e-stop, therefore can't input MDI commands and can't change offsets
[02:27:06] <cradek> I think we were talking about different kinds of offsets
[02:27:13] <cradek> I was talking about G92 offsets
[02:27:13] <fenn> yes
[02:27:19] <cradek> you are talking about the preview window (I think)
[02:27:35] <fenn> i was hoping g92 offsets would move the preview window's origin around
[02:27:46] <cradek> no, but they will move the cone
[02:27:52] <daryl> No pci or agp cards. Found two isa video cards though.
[02:27:52] <cradek> you move the preview around by draggin
[02:27:59] <cradek> daryl: do you have isa slots?
[02:28:09] <daryl> Doubt it...
[02:28:35] <daryl> no
[02:28:57] <fenn> well, i'll be back later
[02:29:03] <fenn> fenn is now known as fenn_afk
[02:29:41] <daryl> cradek: While I'm out buying a video card tomorrow... do you think it's worth getting a multi-io card in case the parallel port is screwed up?
[02:30:39] <cradek> well you can get a pci printer port for about $20... The changes of it being bad seem pretty slim though. Maybe you could try printing something?
[02:31:15] <daryl> Heh heh... too bad I don't have a working printer
[02:31:48] <cradek> seems like all my troubleshooting skills are based on having huge piles of old computer junk around
[02:32:06] <daryl> In the bios there were a few modes for the parallel port (ecp, spp, etc)... It's set to spp. That right?
[02:32:19] <cradek> I think you want EPP
[02:32:21] <daryl> Yeah.. well, I have huge piles. It's just really old.
[02:32:43] <asdfqwega> My piles are growing moss :)
[02:32:46] <daryl> And lacking in some some odd areas.
[02:46:40] <daryl> EPP eh? ok.. will try that. Also just tried disabling the on-board ethernet. no difference
[02:51:12] <daryl> No difference for epp.
[02:51:19] <daryl> with epp
[02:54:47] <daryl> Time it call it quits. G'night all.
[02:54:53] <CIA-12> 03jmkasunich * 10emc2/src/emc/motion/motion.h: reverted change from enum to #defines - when this stuff is changed, all affected files must be changed to match, not just this one
[02:55:01] <daryl> * daryl can't type.
[02:55:22] <jmkasunich> goodnight ;-)
[03:39:02] <CIA-12> 03jmkasunich * 10emc2/src/hal/components/blocks.c:
[03:39:02] <CIA-12> add first, second, and third order limiter blocks to HAL (the third order
[03:39:02] <CIA-12> limiter is actually needed to solve a problem with backlash in emc1, but it was
[03:39:02] <CIA-12> easier to develop and test the algorithm in the HAL environment. The algorithm
[03:39:02] <CIA-12> will be de-HALified for use in emc1, but the blocks may be usefull in HAL so
[03:39:03] <CIA-12> here they are.)
[08:10:18] <Phydbleep> logger_aj: If you keep doing that you'll go blind..
[08:10:18] <Phydbleep> I'm logging. I don't understand 'If you keep doing that you'll go blind..', Phydbleep. Try /msg logger_aj help
[08:10:30] <alex_joni> lol
[08:10:40] <alex_joni> stop messing with my logger ;)
[08:11:04] <Phydbleep> It's worse than i thought.. It's gone Blonde! :)
[08:11:09] <alex_joni> heh
[08:11:25] <alex_joni> from the discussions it witnessed.. I'm not surprised
[08:12:19] <Phydbleep> From the discussions it witnessed, i'm surprised it's not traumatized and in need of therapy. :)
[08:12:48] <alex_joni> yeah
[08:15:17] <Phydbleep> asdfqwega: Congratulations. It's a box.. 10 lb 2 oz. :)
[08:16:09] <alex_joni> how big?
[08:16:16] <anonimasu> * anonimasu nods
[08:16:22] <alex_joni> do you know who the father is?
[08:16:23] <anonimasu> I just handed a servo to a customer..
[08:16:25] <anonimasu> *drools*
[08:16:28] <alex_joni> nice
[08:16:31] <anonimasu> a jvl one..
[08:16:58] <anonimasu> nice little things
[08:17:02] <anonimasu> integrated drives
[08:17:07] <Phydbleep> alex_joni: asdfqwega is the proud poppa.. My junque closet was the mother. :)
[08:17:43] <alex_joni> lol
[08:18:04] <Phydbleep> 14" cube. :)
[08:20:10] <anonimasu> very cute ones..
[08:20:16] <anonimasu> way too expensive for me to own
[08:20:27] <anonimasu> about 1000$ per servo..
[08:20:49] <anonimasu> hm, my qt book might land today
[08:20:56] <alex_joni> the ones I trash are more expensive *g*
[08:21:09] <alex_joni> .errr.. make that repair ;)
[08:21:19] <Phydbleep> alex_joni: Dibs on the next set you trash. :)
[08:21:57] <alex_joni> dibs?
[08:22:37] <Phydbleep> Yeah, It's like yelling "Shotgun!" when you're racing for the front passenger seat.
[08:23:16] <Phydbleep> I.E. "Dibs on the last slice of pizza!" :)
[08:24:20] <Phydbleep> Simple translation.. "dibs" == "Mine! Mine! Mine!" :)
[08:24:37] <Phydbleep> alex_joni: Get it now?
[08:28:17] <Phydbleep> * Phydbleep wonders if alex_joni is now suffing from an 'information overdose'...
[08:35:27] <anonimasu> heh
[08:35:28] <anonimasu> alex_joni: nice
[08:36:19] <anonimasu> hm, the cad program I am testing us unusable with the mini license
[08:36:26] <anonimasu> cant sweep a surface.
[08:36:36] <anonimasu> or sweep along a path.
[08:52:32] <robin_sz> meep?
[08:53:14] <Phydbleep> * Phydbleep hands robin_sz a pair of Wellingtons..
[08:53:18] <robin_sz> anonimasu: sweeping along a path is easy in SW
[08:54:40] <anonimasu> robin_sz: oh I know. but the feature is disabled in the software I use.
[08:54:51] <anonimasu> or well solidedge(minimum version)
[08:55:12] <robin_sz> how handy
[08:55:30] <anonimasu> or well the demo I am trying atleast..
[08:55:43] <anonimasu> it seems like it matches solidworks.. pretty much
[08:56:14] <robin_sz> today is a better day, yesterday we saturated our connection, today, with a little more compression, its half full .. thats better
[08:56:59] <anonimasu> :)
[08:57:13] <robin_sz> when you saturate a 3mb line for 8hrs solid, you need to rethink things :)
[08:57:33] <anonimasu> oh I saturate 10..
[08:57:34] <anonimasu> ;)
[08:57:47] <anonimasu> easily
[08:57:51] <robin_sz> heh
[08:58:02] <robin_sz> you running 'doze there?
[08:58:14] <anonimasu> doze?
[08:58:18] <robin_sz> win
[08:58:34] <anonimasu> a bit..
[08:58:47] <anonimasu> I'll call the dealer so I get a unlocked demo.
[08:58:51] <robin_sz> you got audio speakers?
[08:58:58] <anonimasu> yes
[08:59:00] <anonimasu> headphone
[08:59:01] <anonimasu> s
[08:59:03] <anonimasu> :)
[08:59:04] <robin_sz> handy?
[08:59:16] <anonimasu> yeah.. very close..
[08:59:20] <anonimasu> (head)
[08:59:32] <robin_sz> ok /msg coming up :)
[09:00:05] <anonimasu> but I have lunch in a bit
[09:00:14] <robin_sz> this takes 30 seconds ..
[09:00:19] <anonimasu> ok
[09:00:23] <anonimasu> what are you going to show me?
[09:00:39] <robin_sz> see the /msg :)
[09:00:48] <robin_sz> the ting I'm doing in Geneva
[09:01:07] <anonimasu> cant see it.. wait a sec..
[09:01:40] <anonimasu> ah
[09:01:40] <anonimasu> nice
[09:01:46] <robin_sz> you got sound?
[09:01:56] <anonimasu> yes
[09:02:05] <robin_sz> 500 for me ..
[09:02:07] <robin_sz> etc
[09:02:12] <anonimasu> but it does not seem to initialize
[09:02:17] <robin_sz> oh
[09:02:29] <anonimasu> auction
[09:02:33] <robin_sz> using explorer?
[09:02:33] <anonimasu> trying it in ie
[09:02:36] <robin_sz> right
[09:02:40] <robin_sz> that will help
[09:02:56] <robin_sz> it uses an activeX control
[09:03:10] <anonimasu> brb lunch
[09:03:13] <robin_sz> 'k
[09:06:05] <alex_joni> * alex_joni is back
[09:06:11] <alex_joni> Fido: sorry. was away ;)
[09:09:42] <alex_joni> robin: how's ch?
[09:56:41] <anonimasu> iab
[09:56:42] <anonimasu> :)
[09:57:09] <alex_joni> yo anders
[10:02:03] <anonimasu> wuzzah!?
[10:02:04] <robin_sz> alex_joni: just fine, ta :)
[10:02:10] <anonimasu> :)
[10:02:29] <robin_sz> alex_joni: sunshine, and mountains :)
[10:02:35] <anonimasu> wiring some
[10:02:49] <robin_sz> I can see the Jura in one direction, La Saleve in the other
[10:03:10] <anonimasu> I wonder if this fries.. if I plug the power in
[10:04:05] <alex_joni> just try it
[10:04:07] <alex_joni> then run
[10:04:13] <alex_joni> La Saleve?
[10:06:31] <anonimasu> yep
[10:11:28] <anonimasu> YAY NO SMOKE!
[10:13:16] <alex_joni> nice
[10:13:24] <alex_joni> no frying sound either?
[10:21:26] <anonimasu> oh just a bit
[10:40:17] <robin_sz> alex_joni: La Saleve, a 1000m limestone cliff near Geneva
[10:41:59] <alex_joni> ahh.. that La Saleve
[10:42:00] <alex_joni> ;)
[10:43:26] <robin_sz> I've flown my paraglider from there :)
[10:43:35] <alex_joni> nice
[10:43:40] <alex_joni> with you on board?
[10:44:02] <robin_sz> run .. run .. run .. ooh lookk, a 1000m vertical drop wheeee......
[10:44:12] <robin_sz> of course with me on board
[10:46:27] <alex_joni> thought it was RC ;)
[10:46:38] <robin_sz> nah, 6m span
[10:46:46] <alex_joni> nice
[10:55:19] <alex_joni> darn.. it's too hot already
[10:55:26] <alex_joni> and it's only may :(
[10:59:25] <robin_sz> turn up the air conditioning ..
[11:02:14] <alex_joni> yeah.. but how about outside?
[11:04:28] <anonimasu> :)
[11:04:34] <anonimasu> cable-hell.
[11:06:52] <robin_sz> you don't have outdoor air-conditioning? what sort of 3rd world place is that ?? ;))
[11:08:55] <alex_joni> unfortunately not :)
[11:14:46] <anonimasu> it's hot ove here also :/
[11:14:52] <anonimasu> and I am finishing somthing tricky
[11:30:28] <les> hello all
[11:30:45] <les> how's Geneva Robin?
[11:30:53] <les> Find a house?
[11:32:14] <alex_joni> hey les
[11:32:53] <robin_sz> les: looking at houses on Thursday
[11:33:52] <les> Oh, Robin, just as I thought the cnc plans were about dead...I found this:
[11:34:17] <les> http://www.dynomotion.com/Help/
[11:34:38] <les> it uses the emc g-code interpreter.
[11:34:50] <les> I had a good talk with them.
[11:35:07] <les> They are shipping an eveluation unit to me.
[11:35:19] <les> Might have a product again!
[11:35:34] <robin_sz> how much is retial?
[11:36:13] <robin_sz> so its basically the same as a Baldor ESB in function
[11:36:18] <les> I was quoted $699 quan 10
[11:36:18] <robin_sz> but not in a box
[11:36:30] <robin_sz> thats more than the Baldor isnt it?
[11:36:39] <les> not bad considering it has 8 servo amps...
[11:36:51] <robin_sz> oh it has amps?
[11:36:56] <robin_sz> thats kewl then
[11:36:56] <les> yeah.
[11:37:06] <robin_sz> I though it was just -10-0-10
[11:37:45] <les> Well it is good enough that I should invest some time with it
[11:37:51] <robin_sz> yeah
[11:38:10] <les> I think it is not quite there yet...but we can work on it
[11:38:41] <les> Gives me some confidence to go ahead and bring the iron over
[11:39:10] <les> before...I basically did not have a product...because I had no control
[11:39:28] <robin_sz> yep
[11:39:44] <robin_sz> personally I would have gone G200X and steppers .. but thats just me
[11:39:51] <robin_sz> on the small machine anyway
[11:40:46] <les> I am still entertaining the idea that I can sell higher performance...whether the user needs it or not
[11:40:48] <les> hmmm
[11:40:58] <les> sure works with cars and such...
[11:41:17] <robin_sz> for leisure yes
[11:41:20] <robin_sz> for work?
[11:41:47] <robin_sz> how many comapanies you know who buy their delivery drivers nicer vehicles with faster engines?
[11:41:58] <les> good question.
[11:42:26] <robin_sz> and ...
[11:42:38] <robin_sz> you might be strapping a ferrari engine into a ford chassis :)
[11:42:59] <les> heh
[11:43:00] <alex_joni> what's wrong with that?
[11:43:12] <alex_joni> ;)
[11:43:53] <les> If the ferrari version was thr same price as the regular ford....
[11:44:34] <alex_joni> alex_joni is now known as alex_joni_away
[11:44:45] <robin_sz> and if I could produce a "regular ford" copy for half the price ??
[11:44:54] <robin_sz> you'd pick up the leisure buyers,
[11:44:59] <robin_sz> I'd pick up the fleets
[11:45:16] <les> $699 for amps, dsp board, and control software....seems pretty cheap
[11:45:56] <les> Since I have analyzed oem tredmill motors and found that I can get .3g....
[11:45:57] <robin_sz> does indeed
[11:46:29] <les> Seems I have the makings of a servo system that is as cheap as stepper
[11:46:54] <robin_sz> well, you are already at twice the price of 3 G201 and a G200x
[11:47:15] <les> hmm
[11:47:28] <robin_sz> how much the motors come in for?
[11:48:02] <les> I have to check. Some are well under $100
[11:48:09] <robin_sz> right
[11:48:16] <robin_sz> and encoders are $20
[11:48:17] <les> perhaps under $50
[11:48:20] <robin_sz> wow
[11:48:45] <les> I am not counting the $29 surplus ones
[11:49:00] <les> although there are thousands of them about
[11:49:08] <robin_sz> hmm
[11:49:19] <robin_sz> might even be worth looking at for my lpasmas at that price
[11:49:25] <robin_sz> are they CE marked?
[11:49:33] <les> yeah.
[11:49:53] <les> I think they are UL/CSA/CE
[11:50:25] <les> I talked to a manufacturer.
[11:51:14] <robin_sz> so you;ve written EMC off for the moment then?
[11:52:14] <les> Robin to avoid getting upset I had to have an attitude change.
[11:53:35] <robin_sz> use what works?
[11:53:37] <les> When I saw work being done with things like tool changer code etc when the TP is trash smoke came out the ears
[11:53:48] <robin_sz> yeah
[11:53:57] <les> So here is the change:
[11:54:15] <les> The emc stuff is a hobby activity.
[11:54:43] <les> The folks working with it are hobbyists
[11:55:00] <les> And it has hobby level performance.
[11:55:09] <les> Hobbies are a good thing.
[11:55:12] <robin_sz> yep
[11:55:58] <les> That way I will not get upset.
[11:56:12] <robin_sz> * robin_sz nods
[11:57:02] <robin_sz> I had great hopes for emc
[11:57:08] <robin_sz> emc2 in particular
[11:57:25] <robin_sz> looks like they'll keep for emc3 ;)
[11:58:00] <les> heh
[12:01:05] <les> I will pull emc from the router.
[12:01:35] <les> I can still use it on the vertical mill for simple shapes though
[12:06:30] <les> That way I can keep using emc, and 4 hr days will no longer turn into 12 hr days in the turkey call production because of code.
[12:07:54] <robin_sz> yeah
[12:08:05] <robin_sz> what will you use on the router?
[12:08:20] <les> camsoft prob
[12:09:30] <les> it's a $$ ouchie...but in the business sense fairly negligible cost
[12:09:36] <robin_sz> hmmm
[12:09:46] <robin_sz> looks like a version of Mach2 with bad grpahics ...
[12:09:57] <les> haha
[12:10:20] <les> I am trying to evaluate it
[12:10:33] <les> talking to lots of users
[12:11:13] <anonimasu> hm, there has to be some way to fix emc.
[12:11:14] <robin_sz> not always worthwhile
[12:11:19] <les> Their agressive marketing practices are an initial turnoff
[12:11:29] <robin_sz> eg mach2 users actually think its great
[12:11:42] <les> anon, I hope we can fix emc.
[12:11:49] <anonimasu> les: although not "now"
[12:12:31] <les> I just can't run at onr third productivity any more. Turkey production starts up again soon.
[12:12:43] <anonimasu> Day changed to 19 Dec 2021
[12:12:45] <anonimasu> ^_^
[12:12:54] <robin_sz> well, I think the only way it can be fixed is good foundations .. dont try to build castles on dosgy piling. but, since the decision is to keep the underlying crud, I think its phucked.
[12:14:38] <les> Well as far as the TP...I have come to the conclusion that calculating a current segment plan in RT is just plain wrong.
[12:14:58] <les> Talked with the kmotion guys about that
[12:15:01] <robin_sz> yep
[12:15:05] <anonimasu> * anonimasu nods
[12:15:24] <robin_sz> we have OODLES of offline time to make up the traj befre we run
[12:15:25] <les> The looked at the tp and quickly junked the whole thing
[12:15:36] <robin_sz> heh
[12:15:42] <robin_sz> did they keep NML?
[12:15:48] <les> no.
[12:16:01] <robin_sz> quelle suprise
[12:16:06] <les> haha
[12:17:27] <anonimasu> robin_sz: why do you always get back at nml.. it does work..
[12:17:46] <anonimasu> robin_sz: and it's not NML's fault that the tp is broken..
[12:17:58] <robin_sz> anonimasu: it is.
[12:18:04] <robin_sz> look its very very simple
[12:18:09] <robin_sz> NML is fine
[12:18:23] <robin_sz> the *implenmentation* of NML sucks donkey whang.
[12:18:40] <robin_sz> that is the foundation on which the rest of it is built
[12:18:40] <anonimasu> robin_sz: I know but you keep getting at it whenever we talk about any problems..
[12:19:03] <robin_sz> you build on crappy foundations, dont be suprised whern the whole thing falls down
[12:19:15] <les> Well the kmotion guys are using the TI 320x dsp with it's c compiler
[12:19:26] <les> so different thing
[12:19:29] <robin_sz> ooh, interesting.
[12:19:44] <robin_sz> dsp is a cute way to do stuff
[12:19:51] <robin_sz> explains a lot about htier servo loop
[12:20:04] <robin_sz> i wondered where all those IIR filters cam from ;)
[12:20:26] <anonimasu> I started digging about how the TP gets segments yesterday
[12:20:32] <les> They claim 4 axis PIDFF with 3 biquad fir filters in 90 microseconds flat.
[12:20:58] <robin_sz> anonimasu: listen up. 30 years coding experinece, I know when I see bad design in code.
[12:21:20] <les> TP gets them from the cannonicals ...
[12:22:04] <anonimasu> and how does the canonicals feed the tp?
[12:22:13] <robin_sz> from the interp
[12:22:15] <anonimasu> one motion at a time?
[12:22:19] <les> But calcvulates individual current segment plans in real time every nth servo cycle
[12:22:29] <anonimasu> or does it push a whole array over the the tp with motion?
[12:23:14] <les> where the proper way is to have time stamped traj data in a queue that the servo cycle clock can point to
[12:23:51] <anonimasu> yes, I am trying to make out if it would be possible to re-write/move the tp to process a array of data before the program states..
[12:24:10] <anonimasu> and just copy the data from the array every nth servo cycle..
[12:24:18] <les> right
[12:24:37] <anonimasu> avoiding realtime calcs..
[12:25:07] <les> That way there is no breakdown if the trajectory period is less that the requested segment motion period
[12:25:11] <anonimasu> yep
[12:25:19] <robin_sz> les: re camsoft, my advice would be to give them a spec and get them to gurantee performance within the spec.
[12:25:21] <anonimasu> it could be done with the current planner..
[12:25:47] <anonimasu> just make it output segments into a memory area instead and store them..
[12:25:58] <les> kmotion did a segmentqueue kind of thing where many segments are joined and splined
[12:26:05] <robin_sz> anonimasu: theres a much easier way of doing that
[12:26:17] <anonimasu> robin_sz: g100?
[12:26:24] <robin_sz> write the segments down in a line ...
[12:26:44] <robin_sz> run alonmg it limiting accellerations in your chosen scheme
[12:26:50] <robin_sz> then run down it
[12:26:57] <robin_sz> up and down .. swapping direction
[12:27:06] <robin_sz> until theres noting left to change
[12:27:21] <anonimasu> robin_sz: I dont understand how the math involved in SQ works..
[12:27:37] <robin_sz> anonimasu: that 50% of the problem .. no one does
[12:27:51] <robin_sz> and the code is so cluttered and cobble dup its not easy to fix
[12:28:04] <anonimasu> the code works fine, if you dont run it in realtime I think..
[12:28:06] <robin_sz> hats off to cradek for doing a great job on it ..
[12:28:47] <anonimasu> how it calcs isnt important if you are going to stuff the segments into memory..
[12:28:52] <robin_sz> maybe cradek doesnt waer a hat ...
[12:28:56] <anonimasu> :)
[12:28:57] <les> I understand the math...but implementing it into the existing code structure seemingly was impossible
[12:29:07] <les> 6 years work on and off!
[12:29:16] <robin_sz> les: exactly
[12:29:33] <robin_sz> les: which is what I keep saying, you cant build new castles on dodgy foundations
[12:29:48] <robin_sz> WTF do you tink the HAL stuff went so well?
[12:29:50] <les> Remember I had the SQ author HERE
[12:30:16] <robin_sz> answer: beacuse HAL was written on jmk's own fress pieces of paper
[12:30:27] <les> yeah.
[12:30:29] <anonimasu> I am going to give it a shot.
[12:30:35] <les> great
[12:30:40] <anonimasu> but the trouble is the damn math..
[12:31:30] <les> Don't get me wrong...I still have hopes that emc can be something other than hobby level performance.
[12:31:38] <robin_sz> the maths would be easier to understand with clean code
[12:32:35] <robin_sz> well, to my mind it seems plain worng to build more onto these foundations, if you get it to work, its actually a bad tihng, because it means the foundatiuons are more unlikely to be fixed.
[12:33:15] <les> you can write cubic planner maths on one sheet of paper.
[12:33:59] <les> not with big letters though heh
[12:34:21] <anonimasu> hehe
[12:35:39] <robin_sz> well, to my mind it seems plain worng to build more onto these foundations, if you get it to work, its actually a bad tihng, because it means the foundatiuons are more unlikely to be fixed.
[12:35:41] <robin_sz> oops
[12:35:44] <robin_sz> sorry
[12:37:09] <les> by all means fix foundatiuons....
[12:37:18] <les> haha
[12:38:14] <anonimasu> yeah, but that required a new start(emc3)
[12:39:29] <anonimasu> err that would..
[12:40:10] <anonimasu> hm, I have a thought about the switch statement..
[12:40:28] <anonimasu> ah nevermind.. dosent matter
[12:41:15] <les> It was interesting to talk to the kmotion guys that wiped the slate clean...started from the interp canonicals, and went from there
[12:41:21] <anonimasu> les: if emc cant push along a machine at >400ipm I'll just have to save up for a high speed machine..
[12:41:33] <les> heh
[12:42:03] <anonimasu> but well that might not be a sane goal.
[12:43:26] <anonimasu> :D
[12:44:02] <les> Well, I hope to make light industreial cnc more affordable
[12:44:12] <les> the market has to want it though
[12:44:23] <les> and I need to make money doing it
[12:45:00] <les> we'll see...
[12:45:03] <anonimasu> yeah
[12:46:05] <anonimasu> eah
[12:46:13] <les> I have to get around this thought:
[12:46:19] <anonimasu> ofcourse..
[12:46:51] <les> QUESTION: What is the worst possible startup business scenario?
[12:47:19] <les> ANSWER: Manufacturing machine tools in the United States
[12:47:20] <les> haha
[12:47:27] <anonimasu> I would think, that it's if the market's flooded..
[12:52:43] <les> well off to get some work done
[12:52:45] <les> bbiaw
[12:55:33] <anonimasu> ok
[12:55:34] <anonimasu> laters
[15:19:05] <A-L-P-H-A> heheh.. british are fun. http://www.mirror.co.uk/news/showbiz/tm_objectid=15552841&method=full&siteid=94762&headline=light-sabre-duel-puts-two-in-hospital-name_page.html%5B/url%5D
[15:19:41] <A-L-P-H-A> americans and their tinfoil houses... and brits playing with petro. hahah... Why can't Aussies or Canucks be as fun?
[15:20:17] <A-L-P-H-A> like you don't hear too much from South Africans... or say, Norway.
[15:28:25] <an0n> an0n is now known as anonimasu
[15:28:42] <anonimasu> hi
[15:44:57] <A-L-P-H-A> ola
[15:46:18] <anonimasu> what's up?
[15:47:08] <A-L-P-H-A> got my endmills today! :) finally
[15:47:20] <anonimasu> nice
[15:47:24] <A-L-P-H-A> yeah.
[15:47:45] <A-L-P-H-A> at $3.00USD a piece, + $4 shipping. I bought 12. So it came out to $40 USD to me. for 12.
[15:47:47] <A-L-P-H-A> not bad at all.
[15:47:59] <A-L-P-H-A> 1/32" endmills
[15:47:59] <anonimasu> nice
[15:48:12] <A-L-P-H-A> now all I need to do is build that highspeed spindle.
[15:48:16] <anonimasu> it's cheaper then 1 dormer endmill :
[15:48:19] <anonimasu> :)
[15:48:21] <A-L-P-H-A> and I'm about to go out and pick up those retaining rings. hahaha.
[15:48:36] <A-L-P-H-A> I don't think a dormer is going to last 12x longer than these.
[15:48:37] <anonimasu> ah well dormer is good, and I can afford to break them.
[15:48:44] <A-L-P-H-A> 'can'?
[15:48:49] <anonimasu> yeah
[15:48:53] <A-L-P-H-A> bastard.
[15:48:58] <A-L-P-H-A> share the wealth.
[15:49:21] <anonimasu> A-L-P-H-A: I worked 13 hours yesterday,,
[15:49:39] <anonimasu> that's where it comes from
[15:49:49] <anonimasu> :)
[15:49:54] <anonimasu> I want a highspeed spindle..
[15:50:00] <anonimasu> although I have no clue how to build a good one
[15:50:06] <A-L-P-H-A> anonimasu. well, if you want to break them... I would buy dormer, if it were only 2x the cost... as I love their quality. Their highspeed stuff is like 4x the cost of the shitty import I can get locally. so I bought it.
[15:50:15] <A-L-P-H-A> the shitty import, I drilled two holes, and the tip broke.
[15:50:21] <A-L-P-H-A> I've had this dormer for MONTHs now...
[15:50:43] <anonimasu> oh I dont want to break them, but I manage to do that pretty often
[15:50:59] <A-L-P-H-A> check backlash!!! and your feedrates.
[15:51:07] <A-L-P-H-A> backlash is killer on endmills.
[15:51:09] <anonimasu> oh, spin welding of alu.
[15:51:16] <anonimasu> and too little spindle power.
[15:51:32] <anonimasu> if I had 2-4kw more ;)
[15:51:53] <A-L-P-H-A> just go the recommend SFM of the end mills.
[15:52:02] <A-L-P-H-A> like hss on alu, is 200SFM.
[15:52:16] <anonimasu> hm, I keep it at the speed where it sounds well..
[15:52:29] <anonimasu> and where I can dry mill..
[15:52:53] <A-L-P-H-A> 'ight... you know your machine better then me.
[15:53:05] <anonimasu> I tried keeping thoose feedrated
[15:53:28] <anonimasu> but since I've got my spindle geared lots to get the speed required I end up spin welding or stalling the spindle..
[15:54:05] <A-L-P-H-A> your SFM is toooo fast. or your bit is too dull. or combination of both.
[15:54:21] <anonimasu> dull but + too little spindle..
[15:54:23] <anonimasu> bit
[15:54:39] <anonimasu> well, I havent milled any alu with the dormer ones except for the slotdrill's I have..
[15:54:47] <anonimasu> I broke a few though when testing..
[15:55:18] <anonimasu> I use some cheap HSS.. I found at the hardware store..
[15:55:25] <anonimasu> since I havent gotten around to making a new order at dormer :)
[15:55:58] <anonimasu> as long as it makes parts I am happy
[15:55:59] <anonimasu> :)
[16:34:32] <CIA-12> 03paul_c 07bdi-4 * 10emc2/src/emc/drivers/ppmc/ppmcparport.c: Minor adjustments to get rid of some compile time warnings.
[16:36:44] <CIA-12> 03paul_c 07bdi-4 * 10emc2/src/emc/task/ (bridgeporttaskintf.cc emctask.cc): KR's fix applied for Bug 1171692 - This is the branch where it was originally reported, so the bug tracker can now be closed.
[16:38:42] <A-L-P-H-A> anyone wanna be a postal relay for me in the USA?
[16:53:56] <robin_sz> A-L-P-H-A: I can be a relay,
[16:54:05] <robin_sz> 12V DPCO ??
[16:55:44] <A-L-P-H-A> :)
[16:55:44] <A-L-P-H-A> cute.
[17:02:36] <anonimasu> *yawns*
[17:03:21] <anonimasu> more making parts for work..
[17:37:12] <mcra> mcra is now known as soso
[17:37:28] <soso> soso is now known as mcra
[17:38:10] <mcra> mcra is now known as soso
[17:38:26] <soso> soso is now known as mcra
[18:47:04] <SWPadnos> Hiya, Paul
[18:47:29] <SWPadnos> Lots of commits in the past couple of days, huh :)
[18:47:29] <paul_c> Hi Steve(n)
[18:48:02] <paul_c> just trying to merge the bdi-4 branch with HEAD where I can.
[18:48:10] <SWPadnos> So I've noticed.
[18:48:37] <SWPadnos> Does the join basically link file/projects, or are there still separate modofication trees?
[18:49:02] <SWPadnos> that made no sense - I need more coffee
[18:51:19] <paul_c> They are still separate branches - It just means the code is the same on both (for the files that have been merged)
[18:52:02] <SWPadnos> So this is a "glue" point, but they can still have separate modifications going forward
[18:53:16] <paul_c> yes.
[19:08:54] <anonimasu> hello
[19:09:00] <SWPadnos> hi
[19:09:46] <anonimasu> work is done for today :)
[19:10:25] <SWPadnos> lucky @#&^%$
[19:10:33] <anonimasu> heh
[19:10:40] <anonimasu> SWPadnos: I started working at 07:00..
[19:11:02] <SWPadnos> That's around when I went to bed last night :) (with the time difference)
[19:11:18] <anonimasu> project deadline at work comming up
[19:11:39] <SWPadnos> I hate those
[19:11:42] <anonimasu> ordered stuff starts to show up..
[19:11:43] <anonimasu> :D
[19:11:52] <anonimasu> like some cylinders we had to order to spec..
[19:11:54] <anonimasu> comes thursday..
[19:12:03] <anonimasu> I am going to finish the code on friday.. and over the weekend..
[19:12:05] <SWPadnos> *then* the fun begins
[19:12:14] <anonimasu> then the machine is going to the customer..
[19:12:29] <anonimasu> and I'll have a 5 day hell ;D
[19:12:33] <anonimasu> setting it up for them
[19:12:46] <anonimasu> make that 5 days and nights.
[19:12:57] <anonimasu> well, it's fun :)
[19:15:24] <SWPadnos> and that's the important part
[19:15:28] <SWPadnos> (or at least most of it)
[19:16:40] <anonimasu> hm I wonder who it was that I talked PLC's with
[19:17:09] <anonimasu> http://www.bojn.net/~an0n/lasal01.jpg
[19:17:29] <anonimasu> that's how the development env look slike
[19:17:57] <A-L-P-H-A> you know, worse comes to worse, I use a dremel clone to engrave crap.
[19:18:00] <SWPadnos> what's the vertical dashed line?
[19:18:10] <A-L-P-H-A> make a mount to the CNC Z axis quil.
[19:18:14] <anonimasu> one a4 if you print it..
[19:18:16] <anonimasu> that's objects..
[19:18:20] <SWPadnos> ah
[19:18:21] <anonimasu> they contain code and functions..
[19:18:39] <anonimasu> some of the lines are for variables, some for functions..
[19:19:01] <SWPadnos> it looks like a somewhat reduced LabView
[19:19:16] <anonimasu> I've got a panel on the side..
[19:19:29] <SWPadnos> yep - I see the objects palette on the right
[19:19:31] <anonimasu> but the vendor produced classes doesnt fit anywhere..
[19:19:33] <anonimasu> :)
[19:19:43] <anonimasu> only for the hardware support..
[19:20:09] <SWPadnos> What PLC is this for (or is it a more generic tool)?
[19:20:18] <anonimasu> Sigmatek
[19:20:22] <anonimasu> www.sigmatek.at
[19:20:28] <SWPadnos> well - I could have seen that :)
[19:20:40] <anonimasu> expensive PLC's..
[19:20:49] <anonimasu> very good :)
[19:21:38] <SWPadnos> looks similar to Allen Bradley SLC500
[19:21:47] <SWPadnos> (or something like that)
[19:22:20] <anonimasu> :)
[19:32:49] <anonimasu> well I guess I should continue to work on my code.
[19:33:01] <anonimasu> and take a drive to the kiosk
[19:34:07] <anonimasu> SWPadnos: do you have any idea about cycle time requirement for a handwheel.
[19:34:11] <anonimasu> err jogwheel..
[19:34:17] <SWPadnos> nope :)
[19:34:35] <SWPadnos> I guess it would depend on what you want to use it for, and how fast you intend to crank it.
[19:34:51] <anonimasu> not too fast, just for jogging into position..
[19:34:56] <anonimasu> 2ms?
[19:35:00] <anonimasu> 2ms polling rate..
[19:35:10] <SWPadnos> directly connected to a port, or with counting hardware?
[19:35:18] <anonimasu> to a plc..
[19:35:27] <anonimasu> and then interpolate it in the plc and send it off via serial..
[19:35:42] <SWPadnos> what resolution handwheel?
[19:36:12] <anonimasu> 500ppr
[19:36:33] <SWPadnos> 500 = 2000 quadrature, or 125*4 = 500?
[19:36:53] <anonimasu> 2000 quadrature..
[19:37:03] <anonimasu> scrap off work :)
[19:37:26] <anonimasu> I think it's 1000 in quad..
[19:37:27] <SWPadnos> OK - then I'd say 2 ms may be a bit slow. In normal use, it wouldn't matter, but fast spins would lose steps
[19:38:02] <anonimasu> I am not counting quadrature though
[19:38:07] <SWPadnos> turning a wheel in one second is pretty reasonable, and it could certainly go faster than that.
[19:38:32] <SWPadnos> if you look at changes, then you are in quadrature (whether you like it or not :) )
[19:38:50] <anonimasu> hm, ah.. yeah
[19:38:57] <anonimasu> cant poll it faster then that..
[19:39:04] <anonimasu> or well.
[19:39:06] <anonimasu> I can..
[19:39:13] <anonimasu> that's the cycletime of the plc..
[19:39:14] <SWPadnos> so take the number of state changes when turning at the maximum rate you want, then multiply by 2, and you have the number of updates per second you need.
[19:39:26] <anonimasu> but if I sample it with a loop..
[19:39:48] <anonimasu> in the cycle.. I can count way faster..
[19:40:07] <anonimasu> or I could just get one of the newer plc's with counter inputs..
[19:40:09] <SWPadnos> but you'll miss any counts that happen when your cycle loo pisn't executing
[19:40:18] <SWPadnos> counter input is a good thing
[19:40:31] <anonimasu> but I dont have any of thoose I can take right now :)
[19:40:34] <SWPadnos> the phase signals become a clock and direction input then
[19:40:48] <anonimasu> hm, it's a encoder input. .
[19:40:51] <SWPadnos> and you don't get quadrature resolution
[19:41:17] <anonimasu> the plc i have now is good because I have a operator panel
[19:41:18] <anonimasu> :)
[19:41:20] <A-L-P-H-A> SWPadnos, remember that digital tach. :) hahah... I still haven't built it. sad. Time to build it.
[19:41:30] <SWPadnos> get to work :)
[19:41:50] <anonimasu> or I might use the midi handwheel and use the plc for panel input and IO..
[19:41:55] <anonimasu> spindle speed spindle on..
[19:41:59] <anonimasu> drive enable..
[19:45:00] <SWPadnos> Well - I should get back to figuring out how o probe this connector: http://rocky.digikey.com/WebLib/Hirose/Web%20Data/FH18%20Series.pdf
[19:45:21] <SWPadnos> how to, that is
[19:45:24] <anonimasu> hehe
[19:45:46] <SWPadnos> I just love 0.3 mm pitch, 39-contact connectors
[19:45:49] <anonimasu> :D
[19:45:52] <SWPadnos> and manual probing
[19:46:02] <SWPadnos> I need more coffee
[19:46:26] <anonimasu> what is it you are trying to interface?
[19:46:49] <SWPadnos> I'm trying to make a modification to the Fuji FinePix E550 camera
[19:46:55] <daryl> SWPadnos: I've found that beer works much better when an afternoon of delicate work is ahead of you.
[19:47:11] <anonimasu> ah
[19:47:11] <SWPadnos> that's the connector that the imager is attached to the control board with
[19:47:20] <anonimasu> how cute :D
[19:47:30] <SWPadnos> daryl: that would be great, except that I can't stand beer :)
[19:47:48] <daryl> Bummer. Scotch?
[19:48:24] <SWPadnos> Actually, the only alcoholic beverage I like much is Bailey's - which happens to go great in coffee :D
[19:48:33] <daryl> :)
[19:48:40] <SWPadnos> brb
[19:53:02] <anonimasu> ok
[19:55:46] <SWPadnos> It's so fun having to look at parts in a microscope :)
[19:56:05] <anonimasu> just order a nanoscale probe ffs.
[19:56:51] <SWPadnos> ffs?
[19:57:00] <SWPadnos> (not Flash File System, I;m assuming)
[19:57:15] <anonimasu> for f*cks sake :D
[19:57:20] <SWPadnos> heh
[19:57:32] <anonimasu> dont prod around with large stuff :D
[19:57:55] <anonimasu> I am just kidding
[19:58:11] <SWPadnos> I sort of made my own zebra strip - used 0.003" shim stock and some sticky plastic sheet
[19:58:22] <anonimasu> hm ok
[20:07:41] <CIA-12> 03paul_c 07bdi-4 * 10emc2/src/Make.rules: Wee error in Make.rules and the default clean rule..
[20:21:44] <daryl> In bdi-4.20 is there some kind of X auto configure program I can run? (Added a new graphics card)
[20:22:31] <anonimasu> xf86cfg should be there..
[20:22:40] <anonimasu> or Xconfigurator
[20:22:46] <anonimasu> but it's not automatic
[20:49:16] <daryl> I feel stupid asking this one, but how do you restart X on bdi?
[20:52:08] <anonimasu> ctrl + alt + backspace for a hard kill of x..
[20:52:17] <anonimasu> if you just want a normal restart do it via the menu
[20:52:53] <daryl> Maybe restart
[20:53:05] <daryl> 's the wrong term... it hasn't yet properly started
[20:53:15] <daryl> telinit 3 and then telinit 5 doesn't work, as far as I can tell.
[20:53:27] <anonimasu> did you fsck up your graphics drivers?
[20:53:41] <daryl> Installed a new card.
[20:53:52] <anonimasu> yeah but you need to set it up
[20:54:19] <daryl> I'm trying... and I'd like an easy way to re-start x to test changes to XF86Config
[20:54:25] <anonimasu> startx+
[20:54:26] <anonimasu> `
[20:54:27] <anonimasu> ?
[20:54:28] <daryl> The way I do it on redhat releases doesn't work.
[20:54:40] <anonimasu> just type startx in the console..
[20:54:42] <anonimasu> that should work
[20:55:23] <daryl> Oh... maybe don't need to anymore. This reboot it worked (more or less)
[20:56:41] <cradek> * cradek waits for the results of the glxgears test
[20:59:08] <daryl> cradek: No worky.
[20:59:15] <cradek> same problem?
[20:59:18] <daryl> yeah
[20:59:21] <cradek> yugh.
[20:59:30] <daryl> heh
[20:59:38] <A-L-P-H-A> this hurts... I put a groove (intentionally) into a $100 tool. glad I did it right the first time.
[20:59:40] <daryl> I also got a parallel port card... so I'll plop that in.
[21:00:06] <cradek> daryl: I think the wiki has some information about how to configure emc to work with one of those pci parallel port cards.
[21:00:19] <daryl> ok...
[21:00:35] <cradek> (I think they can show up at a funny address)
[21:00:43] <daryl> I was hoping to just disable the built in one and get this one to go at the same address... wishful thinking?
[21:00:48] <daryl> ah
[21:00:55] <anonimasu> most likely not
[21:04:49] <daryl> Should the MOTION_IO_ADDRESS be pointing off into space?
[21:05:44] <daryl> It's set to 0x3bc... and as far as I know I have nothing at that address. (but I'm often wrong ;)
[21:06:43] <CIA-12> 03paul_c 07bdi-4 * 10emc2/src/ (7 files in 3 dirs): Damit... Looks like some of the sources didn't get fixed correctly during the "merge"
[21:07:19] <paul_c> daryl: As long as you don't have anything using that IO address, you'll be OK.
[21:07:42] <paul_c> 0x03bc is reserved for parallel ports anyway.
[21:08:05] <daryl> If I end up with an unused parallel port there, is that ok?
[21:09:33] <paul_c> sure.
[21:11:06] <anonimasu> paul_c: got a bit of time?
[21:11:52] <paul_c> does it involve NML & coding ?
[21:12:01] <anonimasu> no
[21:13:02] <paul_c> \&\&/or\
[21:13:08] <anonimasu> ah well, nevermind.. was a bit curious about the TP..
[21:13:21] <paul_c> in what way ?
[21:14:46] <anonimasu> well, why dont we run the top before the program starts to run and place the data into the memory? and just copy it on each servo cycle
[21:16:54] <paul_c> the g-code file is currently parsed, and the moves passed down to the RT code as a series of end points
[21:17:09] <anonimasu> ah, that's a major problem with that approach..
[21:17:40] <paul_c> To take the path data and pre-process in to way points for each servo cycle in usr space is do-able, but.....
[21:17:41] <daryl> Wasn't the parport
[21:18:07] <daryl> Or, at least, the new one didn't fix it.
[21:18:49] <paul_c> you end up having to pass data at such a high rate, the limitations of communications speed kill the idea.
[21:19:45] <daryl> cradek: Tried the pci parport card. Didn't help.
[21:19:57] <anonimasu> if the data is already in the memory, wouldnt that help
[21:20:05] <paul_c> and a new video card ?
[21:20:15] <daryl> yes
[21:20:21] <anonimasu> refilling the queue would take less time then doing the calcs in rt..
[21:20:31] <paul_c> anonimasu: There is a limit on how much memory can be assigned.
[21:21:18] <paul_c> You've been talking to Les haven't you.....
[21:24:10] <anonimasu> yeah was talking about it, if that's the case there's no way around it..
[21:24:20] <paul_c> anyways.... It doesn't matter where the TP calculations are done, the real bottleneck is in the comms speed.
[21:24:30] <anonimasu> except maybe to build a DSP board..
[21:24:48] <paul_c> need to look at reducing the amount of data that is being passed, not increasing it.
[21:25:07] <anonimasu> paul_c: thanks for clarifying it :)
[21:25:44] <paul_c> Tell me how to generate a bspline or bezier curve from the data in a g-code file
[21:25:59] <paul_c> and I can do a TP that will handle it.
[21:26:17] <anonimasu> I dont know the math behind it...
[21:27:42] <SWPadnos> the (or more accurately, one) trouble is that you need more data the faster the machine goes, and you also have less time to process it.
[21:28:16] <SWPadnos> you may need to smooth more points at high machining speed, but you also have to have a faster smoothing cycle cycle, because of the speed
[21:28:37] <paul_c> contrary to some comments, I have given PLC & toolchanger functions minimal thoughts and been working on how to do a better TP.
[21:28:47] <anonimasu> * anonimasu nods
[21:28:51] <A-L-P-H-A> how do I move a directory toanother location?
[21:29:06] <paul_c> mv x n
[21:29:18] <SWPadnos> moves x to n
[21:29:20] <A-L-P-H-A> did'tseetowok
[21:29:31] <SWPadnos> (description, not a command named "moves")
[21:29:54] <SWPadnos> though moves is an assembler instruction for some chips
[21:30:41] <paul_c> Unix command "mv" with the "from" dir and the "to" dir.
[21:31:12] <A-L-P-H-A> nm. it works. I just couldn't do rm *.* ..
[21:31:24] <A-L-P-H-A> I had to specify each dir implecitely.
[21:31:40] <SWPadnos> right - or combined onto one line, "the command 'mv x n' moves the contents of x to n, effectively renaming x to n"
[21:32:29] <anonimasu> hm, *thinking about where there might be any math behind bezier splines*
[21:32:40] <SWPadnos> google?
[21:33:14] <paul_c> the math to convert a bezier or bspline to individual points is trivial.
[21:33:25] <anonimasu> hm, ok?
[21:33:50] <anonimasu> got a link or a pdf or anything about it?
[21:33:51] <SWPadnos> http://www.ibiblio.org/e-notes/Splines/Bezier.htm
[21:33:56] <anonimasu> thanks
[21:34:00] <paul_c> converting a series of points back isn't so easy.
[21:34:48] <A-L-P-H-A> mc would be midnight commander right?
[21:34:52] <anonimasu> yes
[21:34:57] <SWPadnos> is it necessary? (hmmm - it is if you stop in mid-move, right?)
[21:36:41] <anonimasu> hm, no, but you would have to re-calculate the where you are and alter the connecting spline
[21:36:47] <anonimasu> spline/bezier..
[21:40:21] <paul_c> there are several math libs in linux for plotting points from bezier (and many other) splines
[21:40:51] <SWPadnos> right - but the interpolation method isn't the problem, is it?
[21:42:50] <paul_c> the current TP is less than optimal...
[21:43:47] <paul_c> but it is crippled by the slow speed of the usr<->RT comms
[21:44:28] <paul_c> Reduce the ammount of data that needs to be passed, and there is scope for huge increases in performance.
[21:46:35] <SWPadnos> are you thinking of passing spline data to the RT code, and having waypoints calculated there? (to reduce communications overhead)
[21:47:44] <paul_c> that is one train of thought, yes.
[21:48:58] <SWPadnos> which would then increase the lag between user and RT space, among other things
[21:49:29] <SWPadnos> (user presses stop, for instance, ad the RT code has 30 seconds of work to do rather than 2 seconds)
[21:50:17] <paul_c> nope. usr presses Stop, the RT code stops.
[21:50:32] <paul_c> press start, the RT code knows where it was.
[21:51:34] <SWPadnos> hmmm - maybe stop wasn't the best choice of an example. I was thinking of the issues with the GUI updating based on the RT execution state verssu the userspace state - like readaheaad and things of that nature.
[21:52:08] <paul_c> I know where you're going....
[21:53:06] <SWPadnos> yup
[21:53:09] <les> I was talking to the kmotion folks about what they did on their new emc interpreter based system
[21:53:20] <les> they junked the emc TP
[21:53:32] <SWPadnos> step 1 - throw out the old code :)
[21:53:33] <les> and do a simplified SQ sort of thing
[21:54:05] <SWPadnos> what machine performance is being targeted for the trajectory planner?
[21:54:18] <les> emc?
[21:54:29] <SWPadnos> no - mechanical perfomance of the machine
[21:54:37] <les> oh.
[21:55:00] <les> Well I can only speak for routers and other high speed machines
[21:55:19] <les> the norm...that is not slow and not high end...
[21:55:55] <les> is about 1000 ipm with at least several hundred points per second
[21:56:09] <les> ofen several thousand though.
[21:56:17] <SWPadnos> one sec - phone
[21:56:20] <les> k
[21:56:40] <paul_c> * paul_c needs 10 metres/min
[21:56:54] <anonimasu> 400ipm..
[21:56:57] <paul_c> target, 20-30
[21:57:25] <paul_c> (and this is on a lathe, not some slow old plasma cutter.)
[21:57:44] <anonimasu> paul_c: you have the same target as I want
[22:00:19] <les> that would do nicely
[22:01:00] <les> Oh I chatted up the kmotion guy enough to get him to send me a $1000 board gratis
[22:01:54] <les> Currently the host pc talks to the board by usb flashing the memory
[22:03:00] <les> Since the emc stand alone interp. and their TP are on the host (NOT RT) they will need a pretty big buffer.
[22:03:36] <les> should not be a problem
[22:03:40] <anonimasu> les: can you come up with a calculation to join a series of bezier spliens..
[22:03:52] <anonimasu> splines..
[22:03:53] <anonimasu> that is..
[22:04:12] <les> well yeah
[22:04:25] <les> that mcfarland paper does it
[22:04:32] <anonimasu> do you have it handy?
[22:04:33] <les> lots of math
[22:04:41] <les> let me look
[22:04:57] <paul_c> a^2+b^3+a = x,y,z
[22:05:39] <les> http://batman.mech.ubc.ca/~ial/publication/theses/sonja.pdf
[22:05:40] <daryl> Any more suggestions on what to do about this bad x-axis?
[22:05:47] <paul_c> McFarland only talks about going from spline to way points fwicr
[22:06:01] <les> yeah
[22:06:13] <les> my robotics book is better
[22:06:18] <paul_c> daryl: Swap the motors round
[22:06:33] <paul_c> If you can re-wire the stepper drives
[22:06:34] <daryl> Why? I can see the pulses from the parport are bad on the scope.
[22:06:45] <paul_c> swap X to Y and try that too.
[22:06:55] <daryl> How do I swap x to y?
[22:07:05] <paul_c> even better if you have a scope...
[22:07:17] <daryl> You mean physically swap the wires?
[22:07:24] <paul_c> If the scope is showing a bad signal
[22:07:40] <paul_c> try another MoBo.
[22:07:45] <daryl> heh
[22:07:48] <anonimasu> hm maybe psu..
[22:07:55] <daryl> psu?
[22:08:05] <anonimasu> I wouldnt think it's the mobo if it shows up with another paralell port card
[22:08:07] <anonimasu> power supply unit
[22:08:24] <daryl> It can't be psu. The pulses are clearly valid logic signals from the port, but are just wrong.
[22:09:10] <anonimasu> does the pulses show up when you close emc?
[22:09:16] <daryl> no
[22:09:26] <anonimasu> hm, re-locate the pin
[22:09:27] <anonimasu> :)
[22:09:33] <anonimasu> I dont know how you do it in emc1 though
[22:09:57] <paul_c> (BDI-4.20)
[22:09:59] <Phydbleep> daryl: Flatten the drive and rebuild the system from scratch to see it that fixes it?
[22:10:19] <daryl> Phydbleep: ?
[22:10:24] <Phydbleep> s/see it/see if
[22:10:41] <daryl> Flatten?
[22:10:48] <daryl> * daryl looks around for a hammer.
[22:10:51] <Phydbleep> daryl: Fdisk/format/reload == flatten. :)
[22:11:02] <daryl> It's a fresh bdi-4.20 install
[22:11:12] <Phydbleep> daryl: No user mods at all?
[22:11:37] <daryl> Except for what I've done since discovering the problem (adjust the video settings and bios settings), no.
[22:11:42] <Phydbleep> modifations
[22:12:08] <Phydbleep> OK.. I agrre with paul_c, Try it on another machine..
[22:12:19] <daryl> Yeah.. well, that may be the simplest solution.
[22:12:29] <daryl> Though the fact that y-axis works fine makes me think software is the problem.
[22:12:43] <daryl> Changing the mobo may also "fix" the software though.
[22:12:55] <Phydbleep> It might be software/hardware problem on that board.
[22:12:56] <paul_c> If it works on another MoBo, post details of the old one as a warning to others.
[22:15:01] <daryl> The cheapest way for me to get a new mobo would be to get another one that supports this processor... Does anyone know if athlon xp works with emc/rtai?
[22:15:39] <SWPadnos> um - if one axis has correct waveform generation, then the software would be less suspect, IMO
[22:15:48] <SWPadnos> (unless it's a configuration thing)
[22:15:57] <Phydbleep> daryl: Not a clew.. I'm stuck with junque.:)
[22:17:42] <zwisk> hmm... has anybody ever considered using svn instead of cvs for emc / emc2 ?
[22:18:22] <SWPadnos> I believe it does - I think Paul has mentioned getting the cycle time down to 6 usec on an Athlon board
[22:18:23] <Phydbleep> daryl: I've got a Compaq hernia^H^H^H^H^H^Hserver I'll let you have real cheap. :)
[22:18:44] <zwisk> (I think I saw paul_c jump under his table with that question.)
[22:18:48] <zwisk> Howdy jmk...
[22:19:17] <jmkasunich> hi
[22:19:26] <SWPadnos> hi
[22:19:26] <les> hi John.
[22:19:49] <SWPadnos> (still on phone, and thus a little slow)
[22:20:05] <jmkasunich> busy day on the list ;-)
[22:20:12] <SWPadnos> heh ;)
[22:20:15] <zwisk> indeed. Silly G92...
[22:20:21] <les> yeah
[22:20:29] <jmkasunich> I think I've said my last on that subject
[22:20:52] <jmkasunich> but hell will freeze over before I do anything for hubin
[22:20:57] <zwisk> We seem to have a tad of an image problem. :(
[22:21:19] <les> I use it a lot...but have no problems really providing that I donot use M02
[22:21:34] <Phydbleep> zwisk: We're looked on as freaks and misfits?
[22:21:37] <jmkasunich> if it indeed doesn't match the nist docs, that is a problem
[22:21:40] <les> I really do not want the basic behavior changed.
[22:22:18] <zwisk> Phydlbeep: something like that. We're seen as not being on the same side as users. This is not the first time the developers have been seen as "arrogant", despite the fact that none of us really are...
[22:22:46] <les> The only problem I have found is that an active g92 does not show up on the offset display
[22:23:14] <anonimasu> yep
[22:23:20] <les> after an M02
[22:23:24] <anonimasu> I belive g92 works exactly as it should..
[22:23:31] <anonimasu> although when g92 is active, it has to say so..
[22:23:32] <anonimasu> :)
[22:23:37] <les> otherr than that it seems fine
[22:24:00] <les> All the turkey call stuff uses a G92 touch off
[22:24:02] <anonimasu> les: did you find anything?
[22:24:02] <paul_c> There is (was) a bug in G92
[22:24:17] <les> It persists in any selected coord system
[22:24:22] <paul_c> G92 sets an offset. M02 & M30 should clear it
[22:24:22] <les> which is good.
[22:24:29] <anonimasu> I am dead scared to use offsets since I milled some clamps off..
[22:24:31] <anonimasu> :D
[22:25:03] <les> M02 clears the display...but not the g92.
[22:25:17] <les> I will agree that is a problem.
[22:25:31] <les> We looked at it a long time ago
[22:25:35] <paul_c> Like Tom, you are also on a pre-bug fix version
[22:25:50] <SWPadnos> the table Tom posted shows the error - G92 is (was) cumulative after an M02
[22:25:52] <les> I may be.
[22:26:12] <jmkasunich> you almost certainly are - Paul incorporated the fix today...
[22:26:30] <jmkasunich> something hubin almost certainly doesn't know about
[22:26:37] <les> Well repeated g92 is supposed to sum per rs 274 right?
[22:27:04] <anonimasu> * anonimasu nods
[22:27:24] <les> Religion, politics, and G92
[22:27:25] <les> heh
[22:27:28] <jmkasunich> lol
[22:27:48] <Phydbleep> Uhhh... It's all Saddam's fault! :)
[22:27:54] <les> haha
[22:28:21] <paul_c> gotta run some tests...
[22:28:28] <Phydbleep> If he'd rolled over and taken it like a man, we wouldn't be in this mess now. :)
[22:28:59] <zwisk> Is there a good summary of Fest anywhere?
[22:29:22] <paul_c> (please don't start any political posturing)
[22:35:09] <SWPadnos> repeated G92 should sum, but M2 should clear the offsets, which it didn't
[22:35:13] <zwisk> jmk, I'm thinking of work with hal-refactor again, but want to make sure to take into account what happened at fest. "Tabularizing pin setup" ?
[22:35:43] <SWPadnos> that was me, I think
[22:36:30] <SWPadnos> are you wondering what in hell we were thinking when the phrase "tabularizing pin setup" was written? :)
[22:36:35] <jmkasunich> tabularizing pin setup is a level above the basic "hal_pin_new" calls
[22:37:20] <SWPadnos> but the idea suffers from a similar problem as the emc_format function - compile-time type checking
[22:37:28] <jmkasunich> if you look at things like blocks.s:export_some_block(), you'll see the same 4-5 lines repeated over and over again, with slighly different snprintf args and variable names
[22:37:44] <jmkasunich> s/blocks.s/blocks.c
[22:37:55] <zwisk> hmm...
[22:38:26] <jmkasunich> the goal was to come up with some functions that can be passed a list of pins and would avoid all the code duplication
[22:38:33] <SWPadnos> It would be nice to be able to export all 8 parallel port data pins in a single statement, for example
[22:39:07] <SWPadnos> and even more ideal to describe all the pins in a single array of structs, and have a function walk that table to create the pins
[22:39:14] <jmkasunich> right
[22:39:45] <zwisk> So, i did some of that in my refactor.
[22:39:57] <zwisk> The refactor, though, was really my way of learning the system.
[22:40:10] <zwisk> Now I think it's time (from my perspective) to work on something closer to the 'real thing'.
[22:40:28] <SWPadnos> the snag that prevented it from being done at fest was that there's no really good way (that I know of) to do any type checking on something that needs to be able to have different types (the pin type must be variable)
[22:40:34] <zwisk> Arrays of pins is a good idea, I think.
[22:40:49] <zwisk> The refactor allows for arbitrary components to be created after setup time as well.
[22:41:23] <zwisk> Compile time typechecking is a problem.
[22:41:32] <SWPadnos> yep
[22:41:47] <SWPadnos> and since this is C, there's no such thing as run-time type checking
[22:41:55] <A-L-P-H-A> I need dmess to contact me.
[22:42:18] <zwisk> well, you can do runtime type checking, but ... you'd have to do it all yourself.
[22:42:19] <A-L-P-H-A> anyone got a 1-1/8" chucking reamer?
[22:43:18] <zwisk> Really what you're describing is wanting to do a databus with the pins for an 8 bit parallel port. Which is completely reasonable.
[22:43:32] <daryl> Hmm. If I drop PERIOD down to 15us, seems to work.
[22:43:34] <SWPadnos> well - that too
[22:44:23] <SWPadnos> I think it would be great to be able to grab a group of pins, and use them as a number (for a toolchanger, for example) - but that can be done at a level above the pins themselves
[22:45:06] <zwisk> yes, it can. Though the tendancy is to want to have those in a byte rather than in some random number of bit structures.
[22:45:35] <SWPadnos> yes - efficiency is greatly reduced by splitting a byte into bits, then putting them back into a byte for physical output to the port :)
[22:45:38] <zwisk> Is emc2 with 2.6 all happy now?
[22:45:48] <jmkasunich> a bits to byte/word etc component might be a good thing
[22:46:07] <jmkasunich> I personally am willing to live with the efficiency hit
[22:46:40] <jmkasunich> in some cases it might be bad, bit many physical things aren't 1 of 256
[22:46:46] <zwisk> Taking the hit in efficiency definetly results in cleaner conecptual implementations.
[22:47:06] <jmkasunich> a toolchanger that has 40 positions can be addressed in 6 bits.. the other 2 should be available for general IO
[22:47:32] <SWPadnos> well - I would want the ability to grab 5 bits for a toolchanger position, and combine those with the additional 3 bits on the port (possibly used for other things)
[22:47:55] <zwisk> Much of this must be solved in the world of netlists...
[22:47:57] <jmkasunich> that's why I would keep the intermediate bits representation
[22:48:30] <jmkasunich> byte->splitter component->bits->hw driver
[22:48:49] <zwisk> So, is anyone actively working on hal at the moment? (Who should I make sure I'm in regualr contact with?)
[22:49:04] <jmkasunich> I'm pretty much the HAL leader
[22:49:16] <SWPadnos> actually, I would have at least two components - one would take the N lowest bits, and the other would limit to 2^n-1
[22:49:30] <jmkasunich> short term I'll be working on drivers for the existing HAL implementation
[22:49:35] <SWPadnos> (ie, if a larger number is written, it clips)
[22:49:55] <jmkasunich> swp: sounds good
[22:50:16] <jmkasunich> zwisk: you asked about 2.6,,, emc2(HEAD) now compiles under 2.6
[22:50:23] <zwisk> ok. I want to make sure to push out the concept of initilaization at times other than module loading time. (Refactor does that, but refactor is now old, and was never ready for prime time.)
[22:50:34] <jmkasunich> (or if it doesn't, the problems are temporary - check the compile farm if in doubt)
[22:50:55] <zwisk> ahh yes... the compile farm. So quickly I forget the ways of emc. :)
[22:50:58] <jmkasunich> right - we need a new branch for any future refactor work
[22:51:20] <jmkasunich> one that branches after the point where we got it to compile on 2.6 ;-)
[22:51:21] <zwisk> The new branch should come off of a tree that works with 2.6...
[22:51:25] <zwisk> yes. exactly.
[22:52:00] <zwisk> Has anyone thought of using svn instead of cvs? (I asked earlier, but nobody responded.)
[22:52:16] <zwisk> It has some nice enahancements when dealing with tags, branches, and directories which cvs doesn't do so well with.
[22:52:16] <SWPadnos> since SourceForge uses CVS, EMC uses CVS :)
[22:52:25] <jmkasunich> SF uses cvs... I don't think we want to change our hosting
[22:52:47] <SWPadnos> I don't know if there are options for SVN or any other SCM on SF
[22:52:48] <zwisk> Fair enough.
[22:53:09] <jmkasunich> I know what you are talking about tho... CVS fu is not fun
[22:53:32] <zwisk> I don't know either. I suspect they will move in that direction thuogh. I've gotten a bit spoiled lately using svn. It's still not the greatest, but it does feel a lot better than cvs.
[22:54:33] <SWPadnos> I've tried out Cervisia,a nd it seems to work pretty well (though I'm not sure about some updates)
[22:55:04] <zwisk> cervisia is very nice.
[22:55:23] <zwisk> It's not really that I need a gui for cvs, though. It
[22:55:39] <jmkasunich> no guis pleas
[22:55:43] <zwisk> is just that svn is better designed for snapshots of trees rather than files.
[22:55:51] <SWPadnos> ah - I thought you were talking about usability, not capability :)
[22:56:30] <zwisk> Well, as a stupid example, with svn, I have no problem removing, renaming, creating tags, and branches, and generally committing a LOT... like every time i do anything.
[22:56:45] <zwisk> That gives me a lot of 'insurance' against mistakes, as I can go back and see what I was doing and where things went bad if things fail.
[22:57:17] <jmkasunich> agreed, svn is more capable (I was reading some svn docs a few days ago)
[22:57:30] <zwisk> With CVS, renaming is a problem. You lose history. Conflicting names also can be a big problem. And, with CVS, I feel like I need to make sure it always works when I commit. With SVN, I have a private tag that I can break all I want.
[22:58:11] <jmkasunich> when SF has svn then this discussion will be profitable... right now, not so much
[22:58:28] <zwisk> yeah... sorry... don't mean to distract.
[22:58:48] <zwisk> So, jmk, how best can I help the cause?
[22:59:09] <jmkasunich> sorry, I have to make a phone call before weyland leaves his shop
[22:59:18] <jmkasunich> I'll be here all evening tho
[22:59:25] <zwisk> ok. I'll check back.
[22:59:55] <anonimasu> night everyone
[23:01:22] <SWPadnos> see ya
[23:02:09] <SWPadnos> oops - hit ctrl-W in the wrong window :)
[23:04:25] <A-L-P-H-A> heh
[23:12:30] <jmkasunich> * jmkasunich is back
[23:12:38] <SWPadnos> emailing, I see :0
[23:13:05] <jmkasunich> had to make one last post... it's a sickness, I tell you
[23:13:19] <SWPadnos> indeed - I hope it's not contagious
[23:14:03] <jmkasunich> fortunately I had good news today to offset that mess
[23:14:13] <SWPadnos> good deal
[23:14:21] <SWPadnos> (no pun intended, I hope)
[23:14:30] <jmkasunich> managed to get Weyland running with emc2 on his mill - he's under the gun to get some parts make for a motorcycle
[23:14:56] <SWPadnos> cool. I think things are at the point where I will use EMC2 when I set up my mill
[23:15:15] <jmkasunich> a combination of backlash comp issues and PID tuning was giving him fits with emc1
[23:15:26] <SWPadnos> That will either be in 6 months (if I can figure out how to control timing on a cheap digital camera), or next week (if I can't)
[23:15:58] <SWPadnos> unless I decide it's better to look for work ;)
[23:16:01] <jmkasunich> IOW, depending on whether you get a project to do?
[23:16:17] <SWPadnos> well - I have the project - it's a matter of whether it's really feasible or not
[23:16:35] <SWPadnos> (I know it is, but not necessarily withing the time and budget constraints)
[23:16:42] <SWPadnos> within
[23:16:51] <jmkasunich> good, fast cheap...
[23:17:05] <SWPadnos> crap, soon, cheap is this customer's mantra
[23:18:07] <jmkasunich> I know you never get more than two, but I prefer when the customer wants good along with one of the other two
[23:18:32] <SWPadnos> it's amazingly hard to tell what's happening inside a chip, especially when its a proprietary one that can't be found on the net
[23:18:48] <SWPadnos> yeah - if we could use $2000-$4000 cameras, it would be easy
[23:19:21] <SWPadnos> with $250 cameras, the entire imager and optics assemblies are integrated, and therefore mostly unknowable
[23:19:41] <jmkasunich> you need to take a picture at a precisely controlled time?
[23:20:02] <SWPadnos> yep - 60 cameras, one moment
[23:20:07] <jmkasunich> how precise? 0.1sec, or mS (or uS?)
[23:20:11] <zwisk> ooh... bullettime :)
[23:20:14] <SWPadnos> +- 50 uS
[23:20:17] <SWPadnos> exactly
[23:20:28] <zwisk> You work in the video biz?
[23:20:31] <SWPadnos> we already have the film camera
[23:20:33] <SWPadnos> sometimes
[23:20:51] <zwisk> Are you in california?
[23:20:54] <SWPadnos> I've shot parts of a couple dozen commercials, and 2 movies
[23:20:59] <SWPadnos> nope - Vermont
[23:21:04] <SWPadnos> I travel :)
[23:21:19] <zwisk> That was goint to be my second guess :/
[23:21:31] <jmkasunich> only matching the cameras to each other, or do they need to be at a specific absolute time?
[23:21:33] <SWPadnos> of course - it's the movie capital of western New England ;)
[23:21:50] <SWPadnos> yes - but that's considerably less of an issue
[23:22:08] <A-L-P-H-A> anyone know how well shell reamers work?
[23:22:23] <zwisk> I've done just a little bit with cameras. You're right. the $2k version lets you sync to other camras. The <$500 ones... well ... good luck.
[23:22:41] <zwisk> shell reamers? Hmm... very carefully :)
[23:22:50] <jmkasunich> autofocus is probably one of the bigest problems
[23:22:55] <A-L-P-H-A> zwisk, ?
[23:22:57] <SWPadnos> the thing that's giving me fits is the fact that there are several processors on the control board, and a DSP. I'm trying to follow the train of events that causes the shutter to get popped, but it's difficult with 0.3 mm pin spacing and other things
[23:23:04] <SWPadnos> I have everything on manual
[23:23:13] <zwisk> A-L-P-H-A: just teasing. I know nothing of shell reamers.
[23:23:29] <A-L-P-H-A> I hate manual focus... especially on digital cams. As you can never get the focus perfect. better off with just autofocus.
[23:23:40] <A-L-P-H-A> my old digital SLR, 5mp, dimage was awesome.
[23:23:43] <A-L-P-H-A> dimage 7i.
[23:23:46] <jmkasunich> if everything is on manual, isn't the delay pretty constant? just measure it and compensate
[23:23:47] <SWPadnos> It's so easy with mechanical systems - you just delay the "mirror up" signal, and everything is golden
[23:23:58] <A-L-P-H-A> sold it. $360CDN.
[23:24:08] <SWPadnos> bope - it varies by at least 20 ms from shot to shot, even on the same camera
[23:24:15] <SWPadnos> this is true of many pro SLRs as well
[23:24:27] <SWPadnos> nope, I mean
[23:24:57] <jmkasunich> so you have to actually hack the camera, not just push the button at the right time
[23:25:02] <SWPadnos> yep
[23:25:33] <zwisk> What kind of camera are we talking about? Does firewire or usb enter the picture anyplace, or does it go straight to flash of some sort?
[23:25:33] <SWPadnos> the cameras run without the LCD, so I can get access to the connectors, and have space to mount a board (and I can even see it through the glass)
[23:25:39] <jmkasunich> I guess the old "open the shutter in the dark, fire a flash, close the shutter" trick won't work?
[23:25:48] <SWPadnos> not at a Rodeo :)
[23:26:00] <jmkasunich> lol
[23:26:07] <SWPadnos> I'm trying the Fuji Finepix E550 at the moment
[23:26:34] <SWPadnos> USB is the other problem - when you connect the camera to the computer, it turns into a storage device, and won't take pictures
[23:26:41] <jmkasunich> you're aiming for the matrix "bullet time" effect?
[23:26:53] <SWPadnos> you need to get to the $500+ range to prevent from happening
[23:27:11] <SWPadnos> jmkasunich: yes - we have a film system, and are trying to make a cheap digital system now
[23:27:20] <SWPadnos> (actually, we did it first)
[23:27:21] <zwisk> wow... fun project.
[23:27:26] <SWPadnos> yes
[23:27:35] <SWPadnos> unless it doesn't work
[23:27:37] <jmkasunich> I imagine you need multiple megapixel resolution
[23:27:52] <SWPadnos> these are 6 MP, interpolated up to 12
[23:28:08] <SWPadnos> but that's overkill - we're only looking for HD at the moment
[23:28:15] <SWPadnos> (1920x1080)
[23:28:26] <jmkasunich> still pretty high for what I was thinking
[23:28:39] <zwisk> Using 60 of them, I wonder if you can't get a vendor to sell you the ccd chips and do the storage yourself. $200 * 60 = 12k, which makes things interesting, though you obviously don't have lots of leverage.
[23:28:59] <SWPadnos> yeah - the next fun part is getting all the data out of the cameras in 45 seconds or less (60x14M ~= 1 GB per shot)
[23:29:17] <zwisk> why 45 seconds or less? :) (This gets more and more interesting all the time!)
[23:29:18] <jmkasunich> I was thinking about the same thing... some astronomical hobbiests make their own CCD cameras for telescope use
[23:29:44] <SWPadnos> too long, and too expensive (for something that has to be portable and reliable)
[23:29:52] <jmkasunich> http://www.dimensional.com/~ashe/ccd-astro.html
[23:30:07] <SWPadnos> I've gone over just about everything from designing a camera to using the $4000 Kodak 14N
[23:30:45] <jmkasunich> the astro cameras aren
[23:30:48] <zwisk> Getting 60 cameras to talk on the same usb bus is going to be a challenge all it's own.
[23:31:00] <SWPadnos> usb = !realtime
[23:31:12] <jmkasunich> aren't terribly expensive, and can be used without telescopes (just use SLR lenses)
[23:31:18] <jmkasunich> but they are monochrome
[23:31:20] <zwisk> right. But you don't need realtime, do you? You're taking 60, then using 45 seconds to get all the data.... right?
[23:31:42] <SWPadnos> realtime should be necessary for the triggering (can't be done over USB)
[23:32:03] <zwisk> I was just thinking about collecting the data afterwards, not triggering! :)
[23:32:13] <SWPadnos> that's the easy part! :)
[23:32:13] <jmkasunich> triggering = HARDWARE...
[23:32:25] <jmkasunich> bit-twiddlers... sheesh
[23:32:37] <zwisk> sneakernet with SD cards? :)
[23:32:54] <SWPadnos> sort of - there have to be ways of triggering through software as well
[23:33:15] <jmkasunich> SW trigger to a single point, then do the split in HW
[23:33:16] <SWPadnos> sneakernet - that's good (until you put the rig 60 feet up over a bullpen :) )
[23:33:17] <zwisk> If you're triggering in software, I can easily see where your delays are coming from.
[23:33:46] <jmkasunich> hey ray!
[23:33:50] <SWPadnos> I'm triggering by hand, triggering the scope on the button press, and looking at signals that result
[23:33:52] <SWPadnos> Hi Ray
[23:33:57] <SWPadnos> Used G92 lately ;)
[23:33:59] <SWPadnos> ?
[23:34:36] <jmkasunich> SWP: taking a picture of a moving target so you know when the actual image was captured?
[23:34:48] <rayh> Hi SWPadnos
[23:34:51] <SWPadnos> nope - checking when the flash is fired
[23:35:14] <jmkasunich> are you actually gonna be firing 60 flashes at the event?
[23:35:15] <zwisk> Hmm... on my crappy digital, the flahs has *very* little to do with when the CCD takes it's image. :(
[23:35:16] <rayh> Hi John.
[23:35:26] <SWPadnos> I should be checking based on the shutter solenoid, but it's a lot harder to probe at this point
[23:35:37] <jmkasunich> heck - the faslt might be contributing to the delay variation
[23:35:50] <SWPadnos> I may need to lay out a flex circuit to take a breakout pin array
[23:36:00] <SWPadnos> true enough
[23:36:02] <rayh> No g92. Is that a proof?
[23:36:10] <SWPadnos> my experience is that there will be variation
[23:36:49] <SWPadnos> there is significant variation on top of the line Nikon and Canon film cameras, Hasselblads, and just about every other camera you can name
[23:37:14] <SWPadnos> (Rolleis are the best we've measured, with 3 ms shutter lag, and almost no variation, in the right mode)
[23:39:25] <SWPadnos> rayh: no proof required
[23:39:52] <jmkasunich> bizarre thought... mechanical shutter in front of the lense
[23:40:02] <SWPadnos> that is bizarre :)
[23:40:13] <jmkasunich> camera triggered, shutter opens... but it's dark, so you get a long exposure
[23:40:16] <rayh> Or at the focal plane.
[23:40:32] <jmkasunich> then the mech shutter opens, camera integrates light, terminates exposure
[23:40:39] <jmkasunich> mechanical shutter closes later
[23:41:04] <SWPadnos> that could ork, but would be a nightmare to make work (in a system that can be transported)
[23:41:13] <zwisk> not all cameras determine their exposure time by the CCD image intensity. Many have extra light sensors to do that...
[23:41:15] <SWPadnos> work, not Mork's home planet :)
[23:41:39] <SWPadnos> well, in manual mode, they should ignore any sensors anyway
[23:41:58] <SWPadnos> at least, with no flash that should be true
[23:42:10] <jmkasunich> it becomes a mechanical design project - light tight box, camers mounts inside using the tripod mount
[23:42:19] <SWPadnos> I'll get back to probing that once I figure out how to reliably probe the damned things
[23:42:30] <rayh> Well not entirely ignore as the first moon camera proved.
[23:42:34] <SWPadnos> yep, with holes for power, trigger, and data transfer
[23:42:52] <rayh> Evening roletk
[23:43:04] <rayh> Something about that didn't come out right.
[23:43:12] <SWPadnos> s/et/te/
[23:43:48] <SWPadnos> you don't get a lot of atmospheric dispersion on the moon :)
[23:43:56] <SWPadnos> (or on the way)
[23:44:26] <rayh> Took NASA about 30 minutes to confirm that they had pointed the tube at the sun.
[23:44:31] <rayh> I saw it go by.
[23:44:34] <jmkasunich> oops
[23:44:45] <SWPadnos> yeah - at least it didn't go bye-bye
[23:46:33] <rayh> Just talked with Roland regarding the integrationFest
[23:46:44] <jmkasunich> * jmkasunich is all ears
[23:46:49] <rayh> That is what I call our part of this whole week.
[23:47:47] <rayh> DSL is in place as is wireless throughout the school.
[23:48:08] <jmkasunich> ethernet for those of use who still use wires?
[23:48:18] <SWPadnos> ah - plenty of access to cvs
[23:48:38] <rayh> You bet. That was a bottom line requirement for us.
[23:48:44] <SWPadnos> (hopefully unnecessary)
[23:49:09] <SWPadnos> you can show off cool stuff like having the GUI on a separate machine and stuff
[23:49:15] <jmkasunich> you never know... "fetch" access is good to have, even if you aren't gonna commit anything
[23:49:38] <rayh> Yes and sharing the software and issues burden will help.
[23:49:51] <SWPadnos> well - it's ideal if an install can be done without access, but I agree it's useful
[23:49:52] <rayh> I'm supposed to get a disk of images by thursday.
[23:50:06] <rayh> I want to put a retrofit page on the wiki so we can all have at it.
[23:50:25] <jmkasunich> side note - do you have motel reservations yet>
[23:50:27] <jmkasunich> ?
[23:50:42] <rayh> I've got a camper that I plan to use right on the grounds.
[23:50:49] <jmkasunich> ah
[23:51:06] <jmkasunich> * jmkasunich needs to find a room
[23:51:24] <rayh> Tent?
[23:51:41] <jmkasunich> not much of a camper
[23:52:01] <rayh> Okay. The econo?? was great when I was there last time.
[23:52:23] <jmkasunich> econo-inn?
[23:52:33] <zwisk> Is this a follow on to CodeFest?
[23:52:45] <jmkasunich> http://www.cnc-workshop.com/
[23:54:01] <zwisk> cool. A MAZAK, eh? :)
[23:54:07] <rayh> I've got a download in progress so things are very slow here.
[23:54:16] <SWPadnos> that would be fun to attend, but for some reason I don't think my wife would appreciate it for our anniversary :)
[23:54:56] <rayh> Bring her. We'll all try to help entertain.
[23:55:04] <SWPadnos> heh
[23:55:13] <rayh> She isn't into geneology by chance?
[23:55:20] <SWPadnos> I'm sure she'd be entertained
[23:55:38] <SWPadnos> I'm just not sure she'd *like* it :)
[23:55:53] <jmkasunich> econo-inn - $40.95+tax
[23:56:18] <rayh> Dave's wife and a bunch of her relatives are in town also.
[23:56:36] <SWPadnos> and yours?
[23:56:39] <jmkasunich> when are you arriving ray? sunday? monday?
[23:56:42] <rayh> Some sort of famil tree thing.
[23:56:58] <rayh> I'll probably be there by thursday or friday at the latest.
[23:57:10] <jmkasunich> getting a head start ;-)
[23:57:12] <rayh> Get all of my junk in place and networked.
[23:57:30] <rayh> and then take a big hammer to the Mazak.
[23:57:31] <jmkasunich> staying thru the 26th?
[23:58:06] <rayh> "econo-inn - $40.95+tax" that's it. They had a weekly rate.