Back
[00:12:44] <rayh-away> SWPadnos: your note to sherline got to the boss and he got to me.
[00:12:56] <SWPadnos> heh - funny
[00:12:58] <SWPadnos> is that Joe?
[00:13:33] <SWPadnos> (the emails I got were from Joe Martin)
[00:13:34] <rayh-away> Yep. It made three stops in sherline.
[00:13:50] <SWPadnos> trying to find out if it's for real? :)
[00:14:12] <rayh-away> Right. I told him you were a good guy.
[00:14:40] <icee> swp: i use orcad capture and layout.
[00:14:42] <icee> It's awful.
[00:14:49] <icee> like.. worse than it's ever been.
[00:15:06] <rayh-away> just got a confirmation from Joe that they'll put the link on their site.
[00:15:08] <SWPadnos> good thing I gave it up as soon as I could :)
[00:15:10] <icee> SPECCTRA is awesome, and capture is usable and nice.. but dealing with orcad layout for the pcb stuff is pure hell
[00:15:11] <SWPadnos> cool
[00:15:40] <SWPadnos> I was looking for something that would work natively on Linux, and has good support for BGA and other more modern packages
[00:15:47] <SWPadnos> also, FPGA integration is a plus
[00:16:22] <SWPadnos> for less than $15K, preferably way less :)
[00:17:14] <fenn> SWP what do you make?
[00:17:42] <SWPadnos> whatever a customer pays me for. right now, a digital camera array
[00:18:23] <alex_joni> array?
[00:18:37] <SWPadnos> ever seen the movie "The Matrix"?
[00:25:28] <SWPadnos> out of curiosity, what kind of frame rates do people here get from glxgears?
[00:26:21] <alex_joni> 92 over here
[00:26:59] <alex_joni> running 'nv'
[00:27:02] <SWPadnos> hmm.
[00:27:17] <k4ts> night all
[00:27:19] <SWPadnos> I'm running the nvidia drivers (ubuntu linux)
[00:27:21] <SWPadnos> night
[00:27:28] <alex_joni> night k4ts
[00:27:32] <SWPadnos> I get around 11650
[00:27:36] <alex_joni> SWPadnos: I didn't bother :)
[00:27:39] <alex_joni> it's all software
[00:27:49] <alex_joni> that seems awfully high :)
[00:27:58] <Jacky^> G night k4ts
[00:28:05] <SWPadnos> the "official" (and closed) driver actually uses the hardware :)
[00:28:13] <Jacky^> k4ts: good luck
[00:28:22] <k4ts> spero
[00:28:31] <Jacky^> k4ts: you know waht to do ..
[00:28:33] <Jacky^> ;)
[00:28:43] <k4ts> pvt what?
[00:29:01] <Jacky^> in bocca al lupo
[00:29:24] <k4ts> in culo alla balenaaaa
[00:29:30] <Jacky^> ;)
[00:29:35] <SWPadnos> of course, the rate goes down if I make it full screen
[00:29:39] <k4ts> sorry
[00:30:41] <Mje> hi all
[00:30:59] <SWPadnos> hello
[00:31:41] <Mje> does minimillio use the same lpt1 connections as bridgeport io lpt1? no estop, etc?
[00:32:28] <Jacky^> Mje: where ?
[00:32:30] <SWPadnos> bridgeportio uses a second parallel port for the added functions, and it does try to use estop
[00:33:02] <SWPadnos> I believe that minimillio uses the same connections for step output, but I'm not sure about other functions
[00:34:54] <rayh-away> minimill has no other functions. it is axis related variables only.
[00:35:17] <rayh-away> limits homes, probe.
[00:35:21] <Mje> alright. i looked in the faq and has the pinout for bridgeport, but nothing for minimill. i just wanted to make sure the lpt1 pinout for bridgeport is what's used for minimill.
[00:35:34] <Mje> before i started connecting wires
[00:36:36] <Mje> eventually retrofitting a D&M 3 axis mill and a D&M lathe
[00:36:50] <SWPadnos> ah - okay. I thought it had some e-stop functionality
[00:37:18] <rayh-away> If you use emc2, you could swap around the pins to your liking rather than having to use what is hard coded in.
[00:38:23] <alex_joni> also add estop & spindle control
[00:39:18] <Mje> unfortunately "the powers that be" want me to use emc1 :-/ i also thought emc2 would be better
[00:40:02] <rayh-away> Powers are Powers.
[00:40:21] <Mje> haha. yes. yes.
[00:40:21] <alex_joni> powers?
[00:40:28] <jepler_> I get around 800fps with open-source drivers for an ATI chipset
[00:40:28] <rayh-away> Once you get it going, you can quietly switch a prototype in.
[00:40:33] <alex_joni> there are no greater powers than in here :)
[00:40:40] <jepler_> (glxgears)
[00:41:12] <rayh-away> alex_joni: And that's the truth!
[00:41:18] <Mje> is there a bdi for emc2 yet?
[00:41:46] <alex_joni> Mje: not yet
[00:41:56] <alex_joni> probably not in the near future, but there will be debian packages
[00:42:10] <alex_joni> so an simple apt-get install emc2 should be enough :P
[00:42:34] <Mje> ok. i'm pretty sure that's why they're against emc2, and i don't have controll of the boxen doing the controlling :-/
[00:42:47] <alex_joni> ok then
[00:42:54] <Mje> sad. :-(
[00:44:42] <alex_joni> it'll get there..
[00:44:49] <Mje> i'll be happy if i can push for emc2. but for now i'll just get it to move.
[00:45:06] <Mje> then when the estop doesnt work... maybe they'll upgrade
[00:45:07] <Mje> haha
[00:45:15] <Mje> thanks for all the help everyone :-)
[00:45:20] <alex_joni> np
[00:45:25] <alex_joni> Mje: where from?
[00:45:33] <Mje> PA
[00:45:41] <Mje> USA
[00:45:54] <alex_joni> might want to add yourself:
http://www.frappr.com/emctheenhancedmachinecontroller
[00:47:34] <Mje> alright. thanks alex_joni
[00:47:49] <alex_joni> thank you for using emc ;)
[00:48:12] <Jacky^> tahnl you for developing emc :P
[00:48:17] <Jacky^> thank
[00:52:32] <rayh-away> Mje: It is possible to use bridgeportio on a single parport and get the estop in and out pins.
[00:54:50] <Mje> i belive those functions are on the second parallel port for bridgeportio. lpt1 functions stay the same.
[00:55:37] <Mje> emc2 would be excellent for this :-)
[00:56:26] <alex_joni> Mje: yes but you can assign both ports at the same address
[00:56:36] <alex_joni> e.g. using only one physical parport
[00:56:39] <rayh-away> They can be overlapped to a single port.
[00:56:54] <rayh-away> I did that for the Smithy 1240 Mill.
[00:58:28] <Mje> ooooo
[01:01:21] <Mje> that would work. how does emc arbitrate which pin goes to which port?
[01:01:40] <alex_joni> it doesn't ..
[01:01:45] <alex_joni> make sure they don't overlap
[01:02:12] <alex_joni> you still will have standard pinout for the first logical parport
[01:02:35] <alex_joni> and you will be able to set the pins needed for ESTOP & the like for the second logical parport
[01:02:46] <alex_joni> make sure you don't place them on the taken pins
[01:05:38] <rayh-away> Smithy used estop, spindle forward, spindle reverse, and aux (either coolant) outputs
[01:06:38] <rayh-away> on parport pins 1,14,16,17
[01:07:12] <rayh-away> and an estop in signal on parport pin 11
[01:07:16] <Mje> ahhh. you can change the pinout in bridgeportio?
[01:08:08] <alex_joni> MIST_COOLANT_INDEX = 6
[01:08:09] <alex_joni> FLOOD_COOLANT_INDEX = 7
[01:08:09] <alex_joni> SPINDLE_DECREASE_INDEX = 8
[01:08:09] <alex_joni> SPINDLE_INCREASE_INDEX = 9
[01:08:09] <alex_joni> ESTOP_WRITE_INDEX = 10
[01:08:09] <alex_joni> SPINDLE_BRAKE_INDEX = 11
[01:08:18] <alex_joni> a snip from emc.ini (EMC1)
[01:09:05] <Mje> awesome. that will definately work
[01:09:24] <rayh-away> just assign the pins you don't want to use a value larger than say 20
[01:10:03] <alex_joni> I wonder what happens then..
[01:10:06] <rayh-away> I don't remember what the real largest number is.
[01:10:16] <rayh-away> The code ignores them.
[01:10:38] <alex_joni> really? coo
[01:11:16] <rayh-away> Matt and I had FredP do that when we pointed out a big error he made in lube.
[01:11:43] <rayh-away> It was cycling on and off estop every second when estop had been pressed.
[01:12:09] <rayh-away> some hard coded quick fix screw up.
[01:12:52] <SWPadnos> we love hard-coded quick fix screwups :)
[01:12:52] <alex_joni> lol
[01:13:38] <SWPadnos> wow - this is one slow autorouter
[01:13:48] <Jacky^> ;-)
[01:13:48] <SWPadnos> (eagle)
[01:14:04] <rayh-away> I just about s&*t when it started doing that. Had a bunch of "suits" watching.
[01:14:12] <Jacky^> SWPadnos: need a crack ?
[01:14:25] <rayh-away> Boy did I have to fast talk.
[01:14:30] <Jacky^> eagle is proprietary sw
[01:14:33] <Jacky^> :/
[01:14:34] <SWPadnos> heh - suits always seem to bring out the problems in (anything)
[01:14:44] <rayh-away> Yes they do.
[01:14:49] <Jacky^> kidding
[01:14:50] <SWPadnos> I'm trying out the freeware version. I'll buy it if I want to use it professionally
[01:15:09] <rayh-away> I've got to run. It was fun guys.
[01:15:20] <SWPadnos> I put down one chip and 6 test points, and the autorouter is taking miunutes to get it done
[01:15:22] <Jacky^> free versione is limited
[01:15:23] <SWPadnos> see ya Ray
[01:15:33] <Jacky^> how much ?
[01:15:51] <SWPadnos> of course, I did use a 208-pin FPGA as the one chip ;)
[01:16:17] <anonimasu> hello
[01:16:29] <LawrenceG> SWPadnos: I like eagle, but it really is worth doing the tutuorial from their web site... it makes more sense once you work through the excercises
[01:16:34] <Jacky^> hey anonimasu
[01:16:59] <SWPadnos> I'll do that. If I can save around $10k, it'll be well worth it :)
[01:17:14] <anonimasu> what's up?
[01:18:37] <anonimasu> * anonimasu is drawing parts in he's head
[01:21:22] <anonimasu> :)
[01:21:49] <SWPadnos> cool. here's the link to frappr on Sherline (bottom of the page)
[01:21:54] <SWPadnos> http://www.sherline.com/CNClinks.htm
[01:24:40] <alex_joni> hmmm.. probably frappr is not the best place to ask for help.. is it?
[01:24:41] <alex_joni> "Please make EMC understanding other files like step dxf dwg and other.
[01:24:42] <alex_joni> What mean all features of INI file en how do i make it to fit to my CNC machine.
[01:25:04] <alex_joni> an user from maastricht (netherlands)
[01:26:32] <anonimasu> :/
[01:26:37] <SWPadnos> hmmm - that's kind of funny
[01:27:04] <SWPadnos> luckily, Chris at Sherline put in the description of frappr, and the links to the sourceforge lists
[01:27:09] <SWPadnos> maybe that's unlucky :)
[01:29:45] <fenn> SWPadnos:
http://catb.org/~esr/jargon/html/Q/quantum-bogodynamics.html
[01:30:24] <SWPadnos> heh - I like that one
[01:31:12] <CIA-5> 03alex_joni * 10emc2/ (15 files in 5 dirs):
[01:31:12] <CIA-5> further work on make install (updated config files with proper dirs). shortly
[01:31:12] <CIA-5> scripts/emc.run will be replaced by scripts/emc.run.in (currently known as
[01:31:12] <CIA-5> scripts/install.run.in) install.run seems to be working ok as an installed
[01:31:12] <CIA-5> script, and as a run-in-place script.
[01:32:31] <fenn> maybe emc.run.local would be less confusing than .in
[01:32:59] <SWPadnos> it's a .in because it's used by configure (or make) to create an emc.run file
[01:32:59] <alex_joni> fenn: if you patch autoconf to parse a .local file
[01:33:16] <alex_joni> configure
[01:33:16] <SWPadnos> or autoconf :)
[01:33:16] <fenn> ah n/m
[01:33:34] <alex_joni> configure created by autoconf from configure.in ;)
[01:33:36] <fenn> autoconf and configure will duke it out at runtime
[01:33:44] <SWPadnos> yeah
[01:34:00] <SWPadnos> hopefully, any quarrel between them will be sorted out long before runtime :)
[01:34:05] <alex_joni> so you need to patch autoconf to create a proper version of configure, which will use .local files :D
[01:34:19] <alex_joni> autoconf always wins :D
[01:34:29] <alex_joni> * alex_joni doesn't..
[01:34:36] <alex_joni> * alex_joni goes to bed
[01:34:39] <alex_joni> night all
[01:34:47] <SWPadnos> man - pushing 30 minutes to route 7 parts
[01:34:49] <SWPadnos> good night
[01:34:54] <SWPadnos> (and not done yet)
[01:35:12] <SWPadnos> and 6 of htem have exactly one pin
[01:35:14] <SWPadnos> them
[01:35:35] <fenn> are you cutting circuit boards?
[01:35:41] <SWPadnos> not yet
[01:35:41] <alex_joni> autoroute?
[01:35:42] <alex_joni> :D
[01:35:50] <fenn> oh route route
[01:35:55] <fenn> er, rout
[01:35:57] <anonimasu> * anonimasu sighs
[01:36:02] <anonimasu> so many projects so little money
[01:36:04] <SWPadnos> yeah - I wasn't nice to it - it's a 28-pin FPGA, with 1-mil routing grid
[01:36:24] <alex_joni> get BGA's
[01:36:28] <SWPadnos> 208 pins, that is
[01:36:30] <alex_joni> those are nicer to route :D
[01:36:40] <alex_joni> 900 pins that is :P
[01:36:46] <SWPadnos> I will, but I'd definitely need more than the 2 layers the freewaere version gives me
[01:37:00] <anonimasu> damn.
[01:37:05] <SWPadnos> I've seen $6000 ones from DigiKey - 1600 pins or so
[01:37:07] <SWPadnos> yuck
[01:37:48] <alex_joni> ROFL...
[01:37:49] <alex_joni> With ball counts exceeding 1000 and approaching more than 2000 there are huge forces when inserting the male device. The force to mate conventional adapters can exceed 98 pounds or 436 Newtons for a 1000 pin device. The Giga-snaP� BGA Surface Mount Feet Adapters require half the force of 48.5 pounds or 215 Newtons for a 1000 pin device.
[01:38:15] <SWPadnos> hmmm - a BGA socket - interesting
[01:38:44] <SWPadnos> ooooh - here's a $9100 FPGA
[01:38:54] <SWPadnos> only 1156 balls
[01:39:01] <alex_joni> * alex_joni goes to bed.. now for real
[01:39:10] <SWPadnos> thunk :)
[01:39:10] <alex_joni> I'll regret this in the morning
[01:39:17] <alex_joni> it's 3am again :/
[01:39:25] <SWPadnos> not yet :)
[01:39:36] <alex_joni> [03:00] <SWPadnos> not yet :)
[01:39:41] <SWPadnos> hah - it couldn't finish the routing
[01:39:50] <alex_joni> bye
[01:39:54] <SWPadnos> left two testpoints unconnected
[01:41:37] <richo> morning all
[01:43:17] <fenn> nobody here but us chickens
[01:43:43] <fenn> * fenn meeps
[01:47:14] <richo> :)
[01:47:27] <anonimasu> night all
[01:47:37] <richo> I actually logged the channel last night, because no-one's here during my daytime...
[01:47:46] <richo> night..
[01:48:23] <fenn> logger_aj: bookmark
[01:48:23] <fenn> See
http://solaris.cs.utt.ro/irc/irc.freenode.net:6667/emc/2005-11-11#T01-48-23
[01:48:30] <fenn> there be logs in them thar hills
[01:50:09] <richo> great, thanks...
[01:50:28] <SWPadnos> they're good, but not always complete - the logger sometimes gets dropped from the channel
[01:50:36] <richo> is there an index of the logs by any chance? I'm hoping to review the developers meeting from Sunday..
[01:50:58] <richo> ahh ok...
[01:51:07] <SWPadnos> not really. they're there in txt and rdf format, so if you have something that can make use of RDF, it may help
[01:51:19] <SWPadnos> otherwise, just substitute the date you want in the URL
[01:52:08] <SWPadnos> and note that the date is according to timezone GMT+2 (it's 3:15 AM now, as the logger sees it)
[01:56:47] <richo> ok, thanks.. am looking through them now...
[01:57:38] <richo> am i going crazy or is the date on the logger wrong? 11-11? has anywhere reached the 11th november yet?
[01:57:43] <fenn> i thought rdf was just text with formatting
[01:57:48] <fenn> it's the 11th in romania
[01:57:58] <fenn> er, maybe not
[01:59:09] <richo> isn't NZ the first to see the next day? it's the 10th over there...
[02:11:26] <SWPadnos> rdf is some XML schema, but unfortunately, I don't have an appropriate stylesheet for Mozilla, so it takes a long time, and then gives me all sorts of stuff I don't need (nicely structured, though)
[02:31:41] <Jymmm> richo: No, some Island in the Pacific is.
[02:32:33] <richo> true, just the east of NZ :)
[02:33:04] <SWPadnos> actually, it was chosen (and isn't straight) so that it doesn't hit land anywhere (except Antarctica, where you can't help it)
[02:33:16] <fenn> SWP i'm reading logs a couple days ago
[02:33:24] <SWPadnos> uh-oh
[02:33:24] <fenn> you were asking about why hal has signals
[02:33:41] <fenn> a hal pin is just a pointer, and a signal is a register
[02:33:41] <SWPadnos> no - why output pins can't just *be* signals
[02:34:15] <fenn> this way "all pins are created equal"
[02:34:17] <SWPadnos> I was thinking about it from the standpoint of configuration
[02:34:30] <fenn> and also you can name the signals
[02:34:31] <SWPadnos> but they're not - you can't link two outputs together, for instance
[02:34:48] <fenn> motenc.0.35.out isn't very descriptive
[02:35:07] <fenn> ok but what if you have a bidirectional pin?
[02:35:14] <SWPadnos> true, but motenc.0.conn1.pin3 would be
[02:35:22] <SWPadnos> or .j1.p3
[02:35:51] <fenn> not as descriptive as "amp-offset" or some such
[02:35:56] <SWPadnos> there are no bidirectional HAL pins, AFAIK
[02:36:10] <SWPadnos> nor are there tri-states, though JMK and I discussed that
[02:47:04] <SWPadnos> fenn - you still there?
[02:47:07] <fenn> yeah
[02:47:13] <SWPadnos> ah - on the signals thing
[02:47:29] <SWPadnos> I was approaching it from the standpoint of a user trying to configure emc2
[02:48:00] <fenn> well, that's not a bad thing really
[02:48:05] <SWPadnos> right now, to set up the step output for an axis (once the stepper and PID and motion and all that are loaded), you need three halcmd commands
[02:48:12] <richo> hi guys, who is generally responsible for generating the BDI CDs?
[02:48:19] <SWPadnos> addsig XStep
[02:48:19] <fenn> richo: paul_c
[02:48:40] <SWPadnos> linkps stepper.0.Step-out XStep
[02:48:56] <SWPadnos> linksp XStep parport.0.pin.7.out
[02:49:00] <SWPadnos> (or the like)
[02:49:04] <richo> The suggestion on the developers list is that he won't really be doing too much with it in the future.. does that sound right?
[02:49:14] <fenn> looks like it
[02:49:41] <fenn> there is a push towards .rpms and .debs, or a live distro
[02:49:53] <richo> ok, i would be interested in having a look at what's involved in generating the CDs...
[02:50:12] <richo> ok, the puppy distro was interesting... runs lightnight fast...
[02:50:17] <richo> lightning...
[02:50:22] <SWPadnos> it's non-trivial to figure out, but it's just time once you do manage that :)
[02:50:38] <SWPadnos> I think there were a few tricks Paul had to learn to get things going
[02:50:52] <SWPadnos> generically, you (1) create a signal, (2) link a single output to that signal (since you can't connect more than one), and (3) link one or more inputs to the signal
[02:50:55] <richo> yeah, i've been playing around with getting all the right components on a gentoo system and even that's a trial :)
[02:51:08] <SWPadnos> I had made a wiki page for that, but it seems lost
[02:51:15] <fenn> SWPadnos: you cant connect more than one? says who?
[02:51:31] <SWPadnos> the real trick at the time was to not get the version of Adeos that had -DO_NOT_USE in the name
[02:51:38] <SWPadnos> not more than one output pin
[02:51:46] <SWPadnos> says HAL documentation and JMK
[02:51:58] <Jacky^> -.-
[02:52:01] <fenn> hmmmm
[02:52:24] <richo> hmm ok... the adeos and rtai stuff is where i've been struggling a bit...
[02:53:00] <SWPadnos> At the time (6-10 months ago), you couldn't use the fusion (development) branch
[02:53:04] <SWPadnos> you have to use magma
[02:53:22] <SWPadnos> also, be sure to get the patch for the exact kernel
[02:53:36] <fenn> halcmd is annoying to use on its own.. you cant make a new thread
[02:53:52] <SWPadnos> I downloaded a generic kernel, since there were a couple of hunks that didn't patch corectly against the Gentoo kernel (though I think they were in documentation files)
[02:54:44] <richo> yep... i'm leaning towards a debian system really... gentoo doesn't really seem to be used with RTAI/ADEOS much, so there's not a lot of help on it...
[02:55:06] <richo> i found a howto on it, but it's quite dated...
[02:55:50] <richo> brb... food...
[02:55:56] <SWPadnos> it works fine, once you "get" it :)
[02:56:32] <SWPadnos> fenn, I'm looking at the hal doc and I don't see the limitation - maybe it was from a conversation with JMK
[02:56:57] <SWPadnos> I know that you can connect as many inputs to a signal as you like
[02:57:26] <SWPadnos> anyway - the idea was that those three steps can be shortened to one, if output pins *are* signals
[02:57:47] <fenn> i just tried it and you can connect as many "readers" to a pin as you like, but only one writer
[02:57:56] <SWPadnos> linksp (or linkpp) stepgen.0.Step-out parport.0.pin-2
[02:58:04] <fenn> er, s/pin/signal
[02:58:08] <SWPadnos> right :)
[02:58:33] <SWPadnos> there are two reasons I can see to not make that change:
[02:58:57] <SWPadnos> 1) implementing tri-states or bidirectional pins later could be an issue
[02:59:40] <SWPadnos> 2) you can pretty easily change a group of input pins to a different output pin quickly, by removing the first output and adding the second to the signal
[02:59:53] <SWPadnos> that would be a PITA if there were no signals
[03:00:21] <fenn> i think the other part might be that each hal component uses no memory of its own to store data
[03:01:02] <SWPadnos> actually, they do, but you're right - the actual pin data is in shmem
[03:01:16] <fenn> besides params i mean
[03:01:26] <fenn> not sure if that counts as data, since its not going to change
[03:01:29] <SWPadnos> they create structs and the like, using hal_malloc
[03:01:43] <SWPadnos> (I was looking at blocks.c this afternoon)
[03:02:19] <fenn> that's a fun one
[03:02:32] <SWPadnos> heh - especially with the copy/paste errors :)
[03:03:50] <Jacky^> * Jacky^ smoke
[03:03:58] <SWPadnos> no, thanks
[03:04:12] <Jacky^> ?
[03:05:00] <SWPadnos> well - thanks for the discussion - I guess that removing signals isn't necessarily a good idea, but maybe adding a linkpp command (as ray had suggested) may make sense
[03:05:12] <SWPadnos> or it isn't a necessary good idea :)
[03:05:36] <fenn> i think when graphical configurator comes into the picture it will be a lot quicker and nobody will whine
[03:06:00] <Jacky^> SWPadnos: please remove signals ...
[03:06:05] <Jacky^> come on
[03:06:08] <fenn> then you can click on pins to get info about the parameters, and signals to get the data in the signal
[03:06:09] <Jacky^> :)
[03:06:46] <Jacky^> fenn: you smoked ?
[03:06:59] <fenn> Jacky^: tried it once, didn't like it
[03:07:03] <SWPadnos> yes, but a 3700 line .hal file might be caunting (for support issues)
[03:07:13] <SWPadnos> daunting
[03:07:32] <Jacky^> :)
[03:07:38] <fenn> anyone with a 3700 line hal file has more problems than some redundant lines
[03:08:01] <fenn> like, probably will be writing it with a script anywway
[03:08:08] <SWPadnos> well - the redundant lines, plus some comments, can easily make a huge file (not 3700 lines, but in the same order of magnitude)
[03:08:11] <Jacky^> yeah
[03:08:17] <Jacky^> use lib better
[03:08:28] <Jacky^> hey les !
[03:08:39] <les_w> hi jacky
[03:08:52] <SWPadnos> hi Les
[03:08:56] <Jacky^> hoe the thing are going there ?
[03:09:16] <Jacky^> how
[03:09:19] <les_w> pretty good. tookthe suits back to the hotel. Thing went well.
[03:09:24] <SWPadnos> cool
[03:09:37] <SWPadnos> as long as they left a check, things are good
[03:09:51] <Jymm> boingy boingy boingy
[03:09:52] <fenn> that conflicts with the bulk of evidence supporting quantum bogodynamics
[03:09:53] <Jacky^> les_w: hotel ? nice :)
[03:10:17] <SWPadnos> jymmm - you lost an 'm'
[03:10:33] <Jacky^> wb Jymm
[03:10:47] <les_w> haha well if the thing works I think I will get to manufacture it.
[03:11:00] <fenn> then you will really need a micromanipulator
[03:11:06] <fenn> a cnc controlled one
[03:11:11] <Jacky^> les good
[03:11:28] <les_w> and a 120 mile commute to atlanta
[03:12:11] <Jacky^> thats really good
[03:12:35] <les_w> anyway, in the mean time, research funding continues.so les eats.
[03:12:46] <SWPadnos> mmmmm - food
[03:14:17] <Jymm> les_w: For the cost of a coffee you can feed me (tooling ) for a month =)
[03:15:52] <les_w> The only thing I had trouble with is time off. I have to wire spindles and bring in iron. I got two weeks.
[03:16:32] <les_w> Wait...that is not time off...isit?
[03:16:33] <Jymm> * Jymm is good at wiring anything
[03:16:33] <les_w> haha
[03:17:05] <Jymm> les_w with enough beer it is =)
[03:17:12] <les_w> heh
[03:17:55] <Jacky^> les_w:
http://digilander.libero.it/jackydgl0/annam2.jpg
[03:18:03] <les_w> looking
[03:18:05] <Jacky^> latest job
[03:18:17] <Jacky^> with my toy :)
[03:18:52] <Jacky^> les_w: do ypu know thi wood ?
[03:19:09] <Jacky^> you*
[03:20:01] <les_w> Very nice. Wood..hmm large tengential rays. an oak?
[03:20:03] <Jacky^> italian term i 'faggio'
[03:20:19] <les_w> let me check
[03:20:19] <Jacky^> no clue about english etmr
[03:20:55] <Jymm> I thought oak too
[03:21:06] <les_w> beech...translation is beech wood
[03:21:09] <Jacky^> its very strong
[03:21:38] <Jacky^> broken 2 bit during testing :/
[03:21:53] <les_w> did you use a round nose?
[03:22:13] <fenn> round nose bbits are bad for roughing because the cutting pressure is distributed across a wide area
[03:22:16] <Jacky^> les_w: for the first test I used 6 mm ball nose
[03:22:37] <Jacky^> here the result:
http://digilander.libero.it/jackydgl0/annamaria.jpg
[03:22:43] <Jacky^> not good at all
[03:23:03] <les_w> fenn one trick with round (ball) nose is to tilt it
[03:23:06] <fenn> all i see is a simulation
[03:23:08] <les_w> at least with wood
[03:23:13] <Jacky^> in the second time, I used 3 mm ballnose cmt cutter
[03:23:29] <fenn> les_w: tilt it into the direction of travel?
[03:23:45] <fenn> or 90 degrees to that?
[03:23:52] <Jacky^> here I used 3 mm ballnose and the results is pretty nice:
http://digilander.libero.it/jackydgl0/annam2.jpg
[03:24:31] <fenn> oh oops gotta scroll over :)
[03:25:44] <les_w> good gray scale to z!
[03:26:07] <fenn> i think that's artsoft portrait-o-matic or whatever its called
[03:26:26] <les_w> Fenn...tilting a little just to get the semi-dead center off the work
[03:27:19] <les_w> I v-cut mostly, so I cannot do that
[03:27:39] <les_w> so the bottom of the v is more embossed than cut
[03:28:14] <Jacky^> les_w: what tilting mean ?
[03:28:25] <Jacky^> fourth axis needed ?
[03:28:41] <SWPadnos> SWPadnos is now known as SWP_Away
[03:31:15] <fenn> jacky do you use artcam pro?
[03:31:33] <Jacky^> fenn: yes.
[03:31:51] <les_w> the center of the round nose does not cut much, because the edge velocity goes very low. If you tilt the bit a little such that the center is out of the work cuts are better
[03:31:55] <Jacky^> face wizard
[03:31:57] <les_w> and still round
[03:34:29] <Jacky^> les_w: yeah
[03:35:12] <les_w> only for shallow cuts of course
[03:36:05] <Jacky^> yeah, think i've used only ony bit ..
[03:36:55] <Jacky^> oh, 2, but the second just for cut the profile
[03:37:38] <les_w> artcam usually automatically cuts a finishing pass
[03:37:42] <Jacky^> i like tish wood because it remain smoothness
[03:38:15] <Jacky^> uhm.. artcam has some feature about finish pass
[03:38:44] <les_w> for most stuff we use walnut. It cut's smooth and crisp, has a nice look , and is cheap.
[03:38:59] <Jacky^> usually it calculate a second toolpath to finish
[03:39:17] <les_w> V cut seems to do a second pass always
[03:39:32] <les_w> ny software is old though
[03:39:39] <les_w> my
[03:39:43] <Jacky^> V bit ? never used :/
[03:39:50] <Jacky^> for finish
[03:40:07] <Jymm> les_w: My only beef with walnut is it's dark... no contrast
[03:40:24] <les_w> we color fill it
[03:40:33] <Jymm> les_w: with?
[03:40:36] <Jacky^> yeah
[03:41:14] <les_w> an acryilic formulated to be very quick to sand
[03:41:16] <Jacky^> Jymm: there are a lot of water based colourant, i think
[03:41:28] <Jymm> Jacky^: FOR GODS SAKE... get some light in there when you're taking photographics!!!
[03:41:44] <les_w> blast it on the whole plaque then sand off the high spots
[03:41:50] <Jacky^> Jymm: its too dark ?
[03:42:15] <les_w> this is typical:
[03:42:16] <Jymm> les_w: Blast what? paint?
[03:42:38] <Jymm> silly putty? bondo? drywall mud?
[03:43:08] <Jacky^> Jymm: think the pic I posted is not vernished yet
[03:43:34] <Jymm> Jacky^ you need LOTS of light when taking a photograph.
[03:43:35] <les_w> http://www.lmwatts.com/signwp.html
[03:43:43] <les_w> second and third picture
[03:43:50] <les_w> artcam vcut
[03:44:06] <Jymm> les_w: Yeah, but WHAT are you color filling it with?
[03:44:22] <Jacky^> Jymm: ouch :/ I bought right last week a sony 4 mp camera :(
[03:44:52] <Jymm> Jacky^: Even with *MY* camera, you need lots of light.
[03:45:22] <Jymm> Jacky^: I have a $350 flash on mine too!
[03:45:23] <Jacky^> Jymm: uhm.. thats sound strange to me
[03:45:33] <Jacky^> les_w:
http://digilander.libero.it/jackydgl0/annam2.jpg
[03:45:49] <Jacky^> how's the brightness for you ?
[03:46:11] <Jacky^> dark ?
[03:46:20] <fenn> i dunno it looks kinda like the last one to me ;)
[03:46:34] <Jacky^> :/
[03:46:37] <Jymm> * Jymm smacks fenn for being ambigous!
[03:46:47] <les_w> jymm, I formulate my own stuff. It is porous and chalky so it sands off the high spots quickly. When the clear finish goes on after, it soaks in and hardens it.
[03:47:17] <Jymm> les_w: What are you using for a base compound?
[03:47:25] <les_w> I have two three roll paint mills.
[03:47:35] <les_w> Acryilic latex
[03:48:01] <Jymm> les_w: just acrylic paint. That's it?
[03:48:36] <les_w> basically similar to interior wall paint...but more pigment and less binder.
[03:48:50] <les_w> and other things like mica pearl
[03:48:54] <Jacky^> niceee , i know
[03:49:03] <Jymm> les_w mica?
[03:49:11] <Jymm> pearl of essence?
[03:49:47] <les_w> By itsself, it is weak. But when the clearcoat soaks in after the next spray, it becomes strong.
[03:50:21] <les_w> Mearle titanium dioxide sputtered mica
[03:50:28] <Jymm> ah, ok. Maybe I'll give that a shot. I've been buying a lot of crafters acrylic paint lately
[03:50:41] <Jacky^> wow, to paint its an art too
[03:51:05] <Jymm> Jacky^ I cheat, I roll the shit on =)
[03:51:23] <Jacky^> i'm a newbie on that
[03:51:38] <Jymm> Jacky^: 3" wide foam roller
[03:51:40] <Jacky^> interesting a lot
[03:52:58] <Jymm> Jacky^: I'm in the middle of transfering some files. When I get done I'll post a pic of my latest
[03:53:32] <Jacky^> good, im too.
[03:55:45] <Jacky^> right totady ive seen the frappr site for the fistr time, its nice
[03:56:17] <Jacky^> les_w: i'm losting the hope to find servomotors I need here :(
[03:56:28] <Jacky^> heheh
[03:56:33] <Jacky^> question:
[03:56:52] <Jacky^> les_w: where I can find the motors I need here around ? :/
[03:57:20] <Jacky^> colombo produces servos too ?
[03:57:55] <les_w> danaher
[03:58:13] <Jacky^> in eu ?
[03:58:39] <les_w> If low inertia servos are too expensive or hard to find we can relax specs a bit
[03:58:54] <les_w> I gave you specs for a very fast machine
[03:58:59] <les_w> very very fast
[03:59:04] <Jacky^> I know
[03:59:08] <Jacky^> i like it
[03:59:19] <Jacky^> but i dont knoe where to search ..
[03:59:27] <les_w> let me check
[03:59:45] <Jacky^> no.. dont worry
[03:59:47] <fenn> jacky go find that cncitalia and barge down their door
[04:00:03] <fenn> the guys who won't sell anything to anyone
[04:00:06] <Jacky^> i will search some wek yet
[04:00:41] <Jacky^> fenn: seems hard to find a good servo here
[04:01:00] <Jacky^> I really dont think cncitalia can help :P
[04:01:11] <fenn> sorry cncitalia was the wrong name
[04:01:19] <Jacky^> hehe
[04:01:27] <les_w> http://products.danahermotion.com/danaher/advisor.asp?Rnd=490
[04:02:43] <Jacky^> mm get blank page
[04:03:03] <Jacky^> aybe it use javascript
[04:03:49] <Jacky^> oh.. ok, it work
[04:04:11] <Jacky^> wow
[04:04:23] <Jacky^> like googe :P
[04:04:27] <Jacky^> google
[04:04:50] <Jacky^> great
[04:05:54] <Jacky^> les_w: at this point we will buld a very good machine, no compromise ;P
[04:06:20] <Jacky^> thats what i want
[04:08:28] <fenn> i want some bodine e-torq motors
[04:09:26] <fenn> actually e-torq is a bit wussy
[04:09:38] <fenn> the original prototypes were much better
[04:11:21] <Jacky^> well.. 4:32 here bedtime
[04:11:28] <Jacky^> g night
[04:11:41] <Jacky^> see later
[04:11:44] <les_w> night
[04:11:56] <Jacky^> thanks les_w
[04:12:01] <les_w> yw
[04:12:02] <Jacky^> night guys
[04:12:13] <Jacky^> Jacky^ is now known as Jacky^afk
[04:13:37] <les_w> for these hot HSM machines high torque to polar moment of inertia ratio is what we need
[04:13:50] <les_w> that aften means coreless rotors
[04:14:04] <les_w> often
[04:14:12] <Jymm> * Jymm read that as CORDless routers =)
[04:14:36] <les_w> no core less...for once not a typo
[04:14:52] <Jymm> just a brain fart on my part =)
[04:14:57] <les_w> haha
[04:15:36] <fenn> why isn't active cooling more common in high-perf servos?
[04:15:53] <fenn> isn't peak current higher if you cool the case?
[04:16:08] <les_w> mine have higher ratings for external fan cooling
[04:16:33] <les_w> Naw peak is limited usually by demag current
[04:16:50] <les_w> if a permanent magnet motor
[04:16:58] <fenn> what about field motors?
[04:17:21] <fenn> are field motors even in the same ballpark as p/m motors?
[04:17:28] <les_w> no demag problem...just the 1.7 Tesla saturation of iron
[04:17:46] <Jymm> tesla coil?
[04:17:54] <fenn> jymmm tesla is a unit of magnetic flux
[04:18:10] <Jymm> * Jymm peeks up at the sound of seriouly high voltage =)
[04:18:10] <les_w> 10,000 gauss
[04:19:15] <fenn> 1.7 tesla isn't exactly low.. what's a run-of-the-mill rare earth field strength?
[04:20:02] <les_w> depends on the magnetic circuit. If it has iron in it, 1.7 tesla.
[04:20:12] <les_w> in air 0.5 or so
[04:20:28] <les_w> something like that
[04:21:22] <les_w> but for air, there is no saturation for electromagnets. so magnetizers are usually air core
[04:21:46] <les_w> giant vapacitor and big solid copper rod
[04:21:55] <les_w> capacitor.
[04:22:17] <les_w> what is a vapacitor? did I invent something?
[04:22:49] <les_w> register trade name?
[04:23:21] <les_w> sounds wicked huh?
[04:23:52] <les_w> v is next too c.
[04:24:41] <Jymm> les_w: 8" x 6"
[04:26:14] <les_w> link is dead
[04:26:24] <les_w> have not identified
[04:26:32] <les_w> either
[04:27:06] <Jymm> les_w: link is valid, try again.
[04:27:20] <Jymm> please =)
[04:27:29] <les_w> k
[04:27:31] <fenn> oo i wanna poke fun at jymm's stuff too
[04:28:09] <Jymm> fenn shush you!
[04:28:25] <Jymm> Jymm is now known as Jymmm
[04:28:52] <Jymmm> les_w ok, gimme a sec
[04:29:06] <les_w> " sorry jymm has not enabled public access"
[04:31:42] <Jymmm> les_w better?
[04:34:28] <fenn> it looks like it was printed.. can't see any routing marks at all
[04:34:49] <fenn> low resolution image though
[04:34:51] <Jymmm> fenn: Heh, no it's carved.
[04:35:13] <Jymmm> I was playing with a pearl white paint, so that looks a lil out of place.
[04:37:43] <les_w> pearl works well for 911 signs and such...kinda retroreflective
[04:42:35] <les_w> looks nice. you are finally getting the thing going with good results
[04:42:50] <fenn> i thought the speckles in the orange was a jpg artifact, but it's from the mdf right?
[04:42:51] <les_w> what is the material?
[04:43:49] <Jymmm> fenn: It's not from the MDF, it's during the painting process. But I actually think it adds a "rustic" feel to it.
[04:43:52] <Jymmm> les_w MDF
[04:44:12] <Jymmm> fenn: That's why I was saying the peral white is wrong for it.
[04:44:57] <Jymmm> pearl white is looking like silver there.
[04:45:54] <les_w> get medex. waterproof MDF. good stuff.
[04:46:12] <Jymmm> les_w and 4x the price too
[04:46:38] <les_w> you know, I forgot to take a pic of the last sign dlivered for the gallery.
[04:46:47] <les_w> oh well I have enough.
[04:47:20] <Jymmm> les_w My biggest issue is logistics. If I can't get the material readily it does me no good as I dont have the storage to stockhold it.
[04:47:37] <Jymmm> les_w But I did find signfoam available about 5 miles away.
[04:47:54] <les_w> anyway had to turn down an order, Too busy making "vapacitors"
[04:48:01] <Jymmm> lol
[04:48:55] <fenn> flying saucer parts
[04:49:35] <Jymmm> Leave it to les_w to find a market in UFO's
[04:49:51] <les_w> Aw, today the suits took their digital cameras and photographed my blackboard in the office.
[04:50:06] <les_w> ook shots of me in the lab too.
[04:50:12] <les_w> took
[04:50:26] <Jymmm> les_w stealing
[04:50:34] <les_w> hah.
[04:50:57] <les_w> Outlined "phase three research"
[04:50:58] <Jymmm> les_w stealing les' trade secrets right off the chalk board.
[04:51:12] <les_w> I get paid.
[04:51:44] <Jymmm> les is a technology whore
[04:53:02] <les_w> I guess. I have to eat food and drink water, or i'll die.
[04:53:30] <Jymmm> you mean chard flesh and brewed hopps dont you?
[04:53:39] <les_w> hahaha
[04:53:43] <les_w> yeah.
[04:54:13] <Jymmm> les_w what do you think of the orange?
[04:54:25] <Jymmm> fenn you too
[04:54:41] <les_w> it's a fine fruit I guess. Tastes great
[04:54:47] <Jymmm> lol
[04:55:25] <fenn> it looks like speckly mdf to me... orange shouldn't have green spots in it
[04:55:25] <Jymmm> I meant the orange paint effect
[04:55:41] <les_w> picture looke dgood to me
[04:55:46] <les_w> oops
[04:56:09] <les_w> not oops this keyboard is sticking
[04:56:13] <fenn> i'm looking at these e-torq motor specs, and i dont get why rpm is lower for a higher bus voltage
[04:56:24] <les_w> still eveluating prototypes
[04:56:52] <fenn> les_w: was that to me?
[04:57:03] <les_w> high volt, low rpm? sounds a bit strange
[04:57:16] <Jymmm> fenn servos ?
[04:57:20] <les_w> prototype keyboards
[04:57:26] <les_w> and they are not good
[04:57:37] <fenn> the inventor's prototypes had like 2x the power rating at a higher voltage
[04:58:10] <fenn> jymmm it's a new kind of brushless servo
[04:58:23] <Jymmm> fenn: Ah, ok.
[04:58:27] <fenn> but the torque/weight ratings are really high
[04:58:39] <les_w> High voltage is good. Power lines are 500 kV for a reason!
[04:58:53] <Jymmm> les_w long transmissions
[04:59:29] <les_w> and low I^2 R...just like motors
[04:59:40] <fenn> i wonder if bodine screwed it up by standardizing the design for all voltages
[05:01:18] <Jymmm> bovine?
[05:01:20] <les_w> Some suppliers just give angular accel...that is torque / moment of inertia
[05:01:30] <fenn> does a high inductance mean higher efficiency?
[05:01:40] <les_w> yes bovine electric motors
[05:01:43] <fenn> jymmm bodine is the licensed manufacturer of these motors
[05:01:58] <fenn> http://www.bodine-electric.com/etorq/?view=2
[05:02:08] <Jymmm> fenn Ah, thought it was some inventor like tesla, edison, etc
[05:02:40] <fenn> this is the original prototype
http://lynxmotiontechnology.com/e225.htm
[05:02:47] <fenn> well, one of them
[05:03:03] <les_w> fenn: hmmm...no. Inductance means energy storage. An I deal motor would appear resistive at constant speed, and capacitive otherwisw (1/s)
[05:03:22] <les_w> damn it
[05:03:34] <les_w> keystick
[05:03:58] <les_w> I only have 4 of these prototype keyboards left
[05:04:13] <les_w> they live about a month.
[05:04:16] <Jymmm> les_w maybe use them for kindling
[05:04:40] <les_w> There is a stack of bad ones in the corner.
[05:04:50] <les_w> it's about to get higher.
[05:05:29] <les_w> ABS on ABS makes a poor linear bearing.
[05:07:06] <les_w> well, i'm gonna hit the hay. stressful day, bu things came out ok.
[05:07:41] <Jymmm> G'Night les_w
[05:08:00] <les_w> night jymm and fenn
[05:08:45] <fenn> g'night
[05:08:46] <les_w> les_w is now known as les_w_away
[05:09:30] <fenn> man i'm drooling just reading these motor specs
[05:09:44] <Jymmm> any idea on the pricing?
[05:09:55] <Jymmm> brb... coffee
[05:10:04] <fenn> sub $10k
[05:10:10] <fenn> not sure exactly
[05:11:19] <fenn> apparently you can't just "buy" it
[05:11:38] <fenn> it's been like 3 years, wtf are they waiting for
[05:14:46] <fenn> bodine has one of the more frustrating websites i've ever seen
[05:18:40] <Jymmm> the pic looks like a rendering too
[05:19:30] <fenn> i dont think they actually make them :)
[05:19:43] <fenn> the only real pictures i've seen were the NDSU solar car
[05:20:14] <Jymmm> MAybe they're going to sell the technology to GE or something.
[05:20:27] <fenn> they can't, they're just licensed resellers
[05:20:33] <fenn> er licensed manufacturer i mean
[05:20:44] <fenn> for motors less than xxx watts
[05:21:01] <Jymmm> ah
[05:21:17] <fenn> the inventor's shop is like an hour away from me.. i should just go say whats up
[05:22:17] <Jymmm> fenn go for it
[05:46:12] <fenn> this is interesting:
http://www.zero-max.com/products/rohlix/rohlixmain.asp
[05:59:11] <Jymmm> * Jymmm looks
[06:00:43] <richo> hi guys, has anyone ever had the BDI installed EMC freeze when running EMC2?
[06:00:59] <richo> I've got one box that seems to do it constantly...
[06:01:20] <fenn> what's your BASE_PERIOD set to?
[06:01:42] <fenn> mine is fine down to about .000025 but hangs below that
[06:02:11] <fenn> wait, are you running EMC and emc2 at the same time?
[06:02:16] <richo> ok, just checking... i have to reboot to get this thing reponsive again :)
[06:02:24] <richo> nope, just EMC2
[06:04:05] <fenn> try hitting ctrl-alt-backspace
[06:04:07] <richo> it's set to 0.000050
[06:04:23] <fenn> it will kill the X server if that's what the problem is
[06:05:05] <fenn> it's supposed to at least, never works for me
[06:05:17] <richo> i've increased the base period and am seeing if that works...
[06:05:32] <fenn> it's probably not that
[06:05:35] <richo> nope, still crashes...
[06:05:46] <richo> it's a full system crash, not just X also...
[06:05:52] <fenn> if you keep the console open, could you say when it crashes?
[06:06:06] <fenn> so you can see what the debug messages are
[06:06:09] <richo> i have an SSH terminal connected that also dies...
[06:06:15] <richo> ok, i'll try...
[06:10:32] <richo> all it says before it crashes is: Starting EMC
[06:10:39] <richo> Version: 1.39
[06:10:43] <richo> EMC-HAL
[06:10:50] <richo> iniFind is deprecated
[06:10:55] <richo> that's it...
[06:11:04] <richo> perhaps the HAL is causing it to crash?
[06:18:15] <fenn> * fenn looks through emc.run to see what's going on at that point
[06:19:54] <fenn> uh, mornin?
[06:20:10] <rayh> Hi fenn
[06:20:23] <rayh> working late or early
[06:20:34] <fenn> neither, I wake up at 6 pm
[06:21:09] <rayh> ah. okay. I guess that works. My ma was that night owl sort.
[06:22:14] <fenn> can HAL run commands like linkps and such from the .ini file?
[06:22:23] <rayh> working on the classicladder example
[06:29:16] <fenn> richo: welp looks like just about everything uses the iniFind function, so that doesn't really help us
[06:29:40] <fenn> EMC-HAL is just the machine's nickname
[06:30:49] <richo> hmm ok, thanks anyway... i''ll try to get more info... i've only ever seen it happen on this one PC... it's very stable on the other PCs that i've run it on...
[06:31:05] <fenn> have you tried a memory test?
[06:31:08] <richo> is there a requirements for a minimum number of timers or something?
[06:31:22] <fenn> i have no idea
[06:31:28] <richo> no i haven't actually... i'll give it a shot...
[06:32:28] <rayh> richo: Your's is the post just now?
[06:32:49] <rayh> on the emc lists
[06:33:51] <richo> yep, i've been chasing this one for a little while, so thought someone else might have seen it...
[06:34:03] <richo> although it could be a hardware problem...
[06:34:10] <richo> i'm just about to do some testing...
[06:34:33] <rayh> The next line should report the hal file that it is going to read.
[06:35:04] <richo> perhaps it's missing a hal file?
[06:35:05] <rayh> If this were emc I'd say it was a PERIOD problem
[06:35:28] <rayh> Does it freeze and cause you to reboot.
[06:36:51] <rayh> In my experience, errors inside the hal file cause at least some info to be reported in the terminal.
[06:37:14] <rayh> So I'd think that it is not getting that far.
[06:37:16] <fenn> does that change if your debug level is set differently?
[06:37:27] <rayh> I don't know.
[06:37:33] <rayh> looking
[06:37:54] <SWP_Away> not that I'm here, but dmesg output could be useful
[06:38:17] <fenn> thanks whoever that was
[06:38:34] <SWP_Away> any time
[06:38:37] <rayh> i do have debug set 0x7fffff....
[06:39:10] <fenn> default is 0x7fffff
[06:39:18] <rayh> But I don't think that it has really started emc at that point either.
[06:39:55] <SWP_Away> that should be printed for everyone - they may just not notice it
[06:40:02] <SWP_Away> and the inifind message is harmless
[06:40:20] <rayh> The IniFind message is just bogus chatter caused by some changes to the inivar stuff.
[06:40:59] <SWP_Away> was it actually spelled "deprecated" as you had in your email, or "depreciated"
[06:42:29] <SWP_Away> what's going on with inivar?
[06:43:02] <rayh> I know nothing!
[06:43:44] <SWP_Away> I see, Sgt. Shultz
[06:44:08] <rayh> You got it.
[06:44:28] <fenn> rayh: what do you know about the masonic order!
[06:45:16] <rayh> Very little. Have several friends who are.
[06:47:57] <rayh> My lube timers are working. Just set the on time to short or the off time to long and got a lube alarm.
[06:48:35] <fenn> how does a "lube alarm" manifest? flashing lights and klaxons?
[06:48:40] <rayh> No more need for those little clock switches.
[06:48:56] <rayh> A message on the scratch pad of mini.
[06:49:20] <rayh> But you could connect external stuff to it or even put it in the computers stop chain.
[06:49:32] <rayh> you like the way I said that SWP_Away?
[06:50:09] <fenn> yes, proper lubrication is a very serious matter, and must be rectified immediately! within microseconds!
[06:50:24] <rayh> CL is watching a lube pressure switch and resetting a timer on pressure up.
[06:50:49] <fenn> oh, i thought you meant like regular maintenance timers
[06:51:11] <fenn> someone was asking how he could log the total distance traveled on the ways so he's know when to re-lube
[06:51:18] <rayh> I gave it 20 minutes to see a pressure up signal or it raises the alarm.
[06:51:55] <rayh> Need some sort of ratchet counter reading absolute value.
[06:52:15] <rayh> We could do it in tickle without much trouble.
[06:52:15] <fenn> like a charge-pump doohickey?
[06:52:24] <fenn> (an integrator)
[06:52:35] <fenn> or is that "integrater"
[06:52:42] <rayh> Could be, when the var reaches xxx it sends a message.
[06:53:52] <rayh> lube me, lube me, LUBE ME... damnit.
[06:54:04] <fenn> i don't even wanna go there
[06:54:25] <rayh> I offered to write a set of error messages for a cusome app a while ago.
[06:54:46] <rayh> Guy looked at me and slowly shook his head.
[06:55:02] <fenn> too many grunts and moans?
[06:55:50] <fenn> richo: how's it going?
[06:59:15] <rayh> I'm done in. See you.
[07:16:17] <richo> sorry guys, back now... i'm just trying a fresh installation and seeing if it behaves a bit differently...
[07:16:27] <richo> i'll also try increasing the debug level...
[07:18:19] <fenn> you might want to look at puppy, if you're only running emc2
[07:18:28] <fenn> it sure installs faster :)
[07:26:02] <richo> true :) it runs pretty nicely too...
[07:32:58] <fenn> * fenn flees in terror from segmentqueue.c
[08:44:27] <fenn> wakey wakey alex
[08:44:43] <alex_joni> long time awake
[08:44:44] <alex_joni> :)
[08:44:49] <alex_joni> about 2hours+
[08:45:06] <fenn> that's what, 5 hrs sleep?
[08:46:57] <alex_joni> plenty
[08:57:26] <fenn> hmm i've never heard of this orocos before
[08:57:44] <alex_joni> cocoros
[09:24:36] <fenn> heh we need an ascii interface to classicladder
[09:24:51] <alex_joni> that's what I said long ago
[09:35:27] <fenn> first time i've seen poetry in a discussion of machine control logic
[10:08:47] <fenn> "strut geometry should reside in the joints sections" how do you do that?
[10:10:07] <fenn> right now the axes section is set up so that each entry describes one joint
[10:10:35] <fenn> but you must describe the relationship between joints to describe the kinematics
[10:11:52] <fenn> describing joint geometry for each joint works fine for serial mechanisms but not parallel mechanisms
[10:11:55] <morlenxus> Hi all
[10:12:04] <fenn> 'alo
[10:13:49] <fenn> maybe i should add what "joints" are to kinematics 101
[10:15:05] <alex_joni> hello
[10:21:45] <fenn> heh maybe i should finish reading the mail for today before i spout my mouth off :)
[10:29:28] <alex_joni> lol
[10:36:52] <morlenxus> We wanted to use a pc as a controlling for a sorting machine. That means we need exactly to send an impulse exactly after 0.2 seconds. Is that a scenario for realtime processing?
[10:37:11] <fenn> 0.2 is a looong time in electronics terms
[10:37:20] <fenn> you could do that without any realtime code
[10:37:54] <morlenxus> But is is garanted that the 0.2 time is everytime correct? I mean no 0.3 or something?
[10:37:58] <fenn> right
[10:38:05] <morlenxus> Even if the machine has high load?
[10:38:17] <fenn> to within xxx nanoseconds, depending on your pc
[10:38:47] <morlenxus> hm interesting
[10:38:58] <fenn> if the machine is also running other tasks, those other taks just wait until the realtime code is done
[10:39:22] <fenn> so your video game will slow down but the machine tool keeps going fine
[10:39:30] <morlenxus> ah
[10:40:21] <morlenxus> So if i want exactly every time a process doing something after 0.2 seconds i need realtime processing, because with a normal linux kernel the time could sometimes be 0.3 or 0.25?
[10:41:44] <fenn> * fenn scrambles around for the link he had like 3 seconds ago
[10:42:05] <morlenxus> :)
[10:42:22] <fenn> http://www.isw.uni-stuttgart.de/personen/t_franit/echtzeitlinux/
[10:42:48] <fenn> btw you don't need that "gadget" it can be done in software
[10:45:08] <morlenxus> So emc is only a live cd for testing?
[10:45:22] <morlenxus> And i should get the bdiemc iso?
[10:45:30] <fenn> the live cd runs a realtime os
[10:46:15] <fenn> the live cd uses more memory, and is kinda out of date
[10:46:38] <fenn> we're working on a new version of the live cd using the "puppy" distro as a base instead of debian
[10:46:44] <fenn> er morphix, not debian
[10:49:02] <fenn> since it sounds like you are doing something a little more advanced than just moving x/y/z you should have a look at emc2
[10:49:04] <morlenxus> Well i mean, on the main emc page there is an iso bdi 4.30 based on debian for downloading, and on the page you give me, i can download bdiemc isos, which are based on readhat 7.2
[10:49:23] <morlenxus> Which should i use?
[10:49:29] <fenn> 4.30
[10:49:31] <morlenxus> I would prefer an hdd installation.
[10:49:33] <morlenxus> ah ok
[10:49:55] <morlenxus> So on the page
http://www.isw.uni-stuttgart.de/personen/t_franit/echtzeitlinux/ i should read to solve my questions?
[10:50:11] <fenn> uh, that's just a neat picture
[10:50:31] <morlenxus> ah ok
[10:50:32] <morlenxus> (=
[10:50:42] <fenn> it shows the "jitter" which is the rance of different amounts of latency you might see
[10:50:50] <fenn> range
[10:51:15] <fenn> you should see my bookmark file.. egad
[10:51:29] <morlenxus> where is it?
[10:53:07] <fenn> on my hard drive of course
[10:53:26] <morlenxus> Btw. we want to run speech recorgnising and on the same machine a process which gots the speech output. He get's also an impulse from a light barrier and response 0.2 seconds after that with another impulse.
[10:53:29] <fenn> it's actually on two hard drives, hence the difficulties
[10:55:35] <morlenxus> Thanks for you're help for now.
[10:56:30] <fenn> your average computer these days is about 10ms maximum latency
[10:56:40] <fenn> oops 10 microseconds
[10:57:15] <morlenxus> Hm maybe we don't need realtime processing.
[10:57:45] <fenn> emc can get a signal in and out of the parallel port in about .00002 sec
[10:57:54] <morlenxus> wow
[10:58:04] <fenn> it's not that fast
[10:58:10] <morlenxus> oO
[10:58:20] <morlenxus> Making fun, eh? :)
[10:58:29] <fenn> no, actually it makes a big difference
[10:58:59] <fenn> that .00002 sec is the minimum resolution of a pwm pulse for instance
[10:59:07] <morlenxus> What is fast in realtime processing?
[10:59:38] <fenn> like, what is the fastest computer out there?
[10:59:51] <fenn> it's a complicated answer
[10:59:59] <CIA-5> 03yabosukz * 10emc2/src/ (Makefile.inc.in rtapi/rtai_rtapi.c): i add missin modules. show you how use module_param.
[11:00:13] <fenn> i wish that guy knew english
[11:01:51] <morlenxus> Hm so if the computers are going faster, the response time is decreasing?
[11:02:09] <fenn> you can do like 1 microsecond on a microcontroller, because it has less data to slop around, and because it's designed for low-latency
[11:02:39] <fenn> modern high-end computers have more to worry about, basically
[11:02:54] <fenn> i'm not really that savvy about the internals of CPU's
[11:04:36] <morlenxus> When i install bdi do i need to define a process to run in realtime? Like `nice +19 <command>`?
[11:04:47] <fenn> right now i'm designing a circuit to keep track of optical encoder pulses, and i'm running into problems with latency even in microcontrollers
[11:05:01] <fenn> you can't do it that easily
[11:05:02] <morlenxus> Sorry for bothering you so much with questions.
[11:05:11] <fenn> realtime processes have to be run as a kernel module
[11:05:16] <morlenxus> oh
[11:05:18] <morlenxus> oO
[11:05:47] <fenn> you should talk to jmkasunich if you see him around
[11:05:52] <fenn> he's been busy lately though
[11:05:59] <morlenxus> will do
[11:06:32] <fenn> many others will be able to help also.. i dont want to name any names for fear of leaving someone out :)
[11:06:42] <morlenxus> ;)
[11:07:13] <fenn> you should sign up to the mailing lists also
[11:07:29] <fenn> it's not bad if you get it in a daily digest format
[11:08:02] <fenn> btw what kind of sorting machine has speech recognition?
[11:08:14] <morlenxus> Hm maybe i'm wrong but i thought it's just the scheduler, whcih is in realtime more exactly. Like when every process can have between 5-20 milliseconds each cycle, in realtime the time is restictred to 5-10?
[11:08:29] <morlenxus> We do software speech recognition.
[11:09:22] <morlenxus> The result will be used in an application to send impulses to gates.
[11:09:41] <fenn> sounds fun
[11:09:46] <morlenxus> Like you say "one two" and the gate one will get opend.
[11:10:13] <morlenxus> It's for brief sorting.
[11:10:31] <fenn> brief sorting?
[11:10:35] <morlenxus> yepp
[11:10:42] <fenn> what's a brief? :)
[11:10:46] <morlenxus> letter
[11:10:52] <fenn> ok
[11:10:53] <chinamill> * chinamill is away: working
[11:13:10] <morlenxus> There is a long treadmill, people put the letters on the treadmill, others read the zip code of each letter and say the first two numbers, the numbers will be send to a printer, who prints a code on the letter and then the letter gets sorted by gates which gets open by the realtime process.
[11:14:36] <fenn> you will definitely not be using emc1 for this
[11:15:28] <morlenxus> hm
[11:15:35] <fenn> i dont know if there is software designed for that sort of thing
[11:15:41] <morlenxus> Because to much processes?
[11:15:53] <fenn> actually, classicladder is good for that stuff
[11:16:08] <fenn> and classicladder is built into emc right now
[11:16:13] <fenn> er emc2
[11:17:31] <fenn> http://membres.lycos.fr/mavati/classicladder/
[11:17:36] <morlenxus> Well we still have the speech recognising software, the printer is connected via lpt, so we can just push out the jobs. So the only point which should be in realtime is when the letter comes to the gates. There is an electronic eye, which see's the letter, sends an impulse to the pc and the pc has a process running which checks if it's the correct gate, if yes, he should send an impulse withing 0.2 seconds.
[11:18:36] <fenn> how does the data from the electronic eye get into the pc?
[11:18:44] <fenn> is it an image? or a number? or what?
[11:19:10] <morlenxus> Well there is an isa card which about 10 inputs and 10 outputs.
[11:19:37] <morlenxus> The applications checks the input ports and send an response if the gate should be opened.
[11:20:57] <fenn> you should be looking at PLC emulators, or buy a real plc maybe
[11:21:41] <morlenxus> plc?
[11:22:08] <fenn> back in the good old days they did this kind of stuff by using relays and timers
[11:22:24] <fenn> then someone had the bright idea to make "virtual relays" on a chip
[11:22:48] <morlenxus> hm
[11:23:13] <fenn> a PLC takes care of the interface between high-powered stuff like relays, and logic programs
[11:23:20] <fenn> they are kinda expensive though
[11:23:29] <fenn> and you have to learn this wacky "ladder language"
[11:23:34] <fenn> but it's pretty easy
[11:23:42] <morlenxus> Btw. i can't find much information about realtime processing, like the information that i need a module doing the realtime stuff which is normally inside of an application.
[11:23:58] <morlenxus> Do you have some information?
[11:26:17] <fenn> you should write a message to the mailing list
[11:26:34] <morlenxus> ok
[11:26:36] <morlenxus> will do
[11:26:46] <morlenxus> Need to search for more informations for now.
[11:27:03] <fenn> check out rtai.org if you haven't already
[11:27:13] <fenn> that's the realtime interface emc uses
[11:27:35] <fenn> i'll admit that the documentation sucks
[11:27:42] <morlenxus> ah ok (=
[11:30:06] <fenn> i'm reading it right now, and i dont see anything that describes how to develop a realtime application
[11:34:06] <fenn> you could start by looking at how hal is implemented
[11:35:52] <fenn> but why reinvent the wheel?
[11:36:02] <fenn> classicladder does what you want it to, pretty much
[11:36:14] <fenn> just need to figure out how to get the numbers into hal
[11:37:59] <morlenxus> Well i don't know what hal is. :)
[11:38:12] <morlenxus> I think i miss some basic knoweledge.
[11:38:21] <morlenxus> Like what realtime processing really is.
[11:41:12] <fenn> mat is a good starting point also
[11:41:14] <fenn> http://mat.sourceforge.net/
[11:41:53] <fenn> realtime means you can suspend hardware interrupts
[11:42:23] <fenn> say you are running a process, and all of a sudden the hard drive needs to know what to do with its data
[11:42:40] <fenn> what do you do? help the hard drive or run your process?
[11:42:58] <fenn> if it's a realtime process, then it has higher priority than (just about) everything else
[11:43:17] <fenn> including other kernel processes
[11:43:38] <fenn> this is because the linux kernel itself is a process running in the rt operating system
[11:43:55] <fenn> so the kernel is "scheduled" in right next to your realtime process
[11:44:18] <morlenxus> Ah i read about that before. There are different concepts on doing realtime.
[11:44:27] <fenn> yes
[11:44:40] <fenn> that's just how rtai is implemented
[11:45:21] <fenn> now do you see why the realtime application can't be just any old userspace application?
[11:46:42] <fenn> since basically all of userspace depends on the kernel for scheduling
[11:47:17] <morlenxus> Well i thought the realtime just means the kernel scheduling is optimized.
[11:48:07] <fenn> is this in the new 2.6.15(?) kernel?
[11:48:19] <fenn> * fenn doesn't follow kernel-happenings too closely
[11:48:43] <morlenxus> I don't know, i just thought it.
[11:49:24] <fenn> they are trying to improve latency in the standard kernel for stuff like audio/video
[11:53:04] <chinamill> * chinamill is away: working
[12:03:38] <alex_joni> wtf?
[12:21:51] <fenn> sourceforge is a little slow today
[12:22:47] <alex_joni> not that..
[12:23:05] <alex_joni> * alex_joni wonders about yabosukz again
[12:23:16] <alex_joni> he just removed some modules from the compile script..
[12:23:30] <alex_joni> and I'm wondering wtf he was thinking?
[12:28:32] <fenn> he probably thought classicladder was a real plc module
[12:28:53] <alex_joni> so what did he do with stg & m5i20 ?
[12:29:01] <alex_joni> probably working off an very old repository
[12:29:03] <fenn> damned if i know
[12:44:00] <fenn> g-code is so lame
[12:44:20] <fenn> i can't even believe people run cnc lathes with gcode
[12:45:28] <fenn> emc needs a new programming layer in order to be at all useful for robotics
[12:45:46] <alex_joni> that's why the interpreter needs to be interchangeable
[12:45:57] <fenn> but i think it will impact more than just the interpreter
[12:46:06] <fenn> for instance consider a robot with two end effectors
[12:46:07] <alex_joni> I agree...
[12:46:23] <alex_joni> motion and kins is also a candidate
[12:46:29] <alex_joni> but more important task
[12:46:33] <alex_joni> and how emc behaves
[12:47:33] <fenn> kins needs to be updated to use arbitrary transformation matrices
[12:47:48] <fenn> motion will probably be fine, if you run multiple modules when necessary
[12:49:13] <fenn> i think each set of cartesian coords should have its own motion planner
[12:49:44] <fenn> like, one set of coords for each set of stacked actuators
[12:49:58] <fenn> so a live tailstock would need its own motion planner
[12:50:12] <fenn> since it can move independently of the tool bit
[12:51:40] <fenn> the confusion between axes and joints is particularly bad when you try to do lathe stuff
[12:53:28] <fenn> i see lathe threading as being different from coordinated motion as in a hexapod, because the part and the tool slide each have their own separate cartesian frame of reference
[12:53:51] <fenn> relative to the lathe bed
[12:54:31] <fenn> aha! :)
[12:54:52] <fenn> i will formulate a letter to the list when i am more awake
[12:58:03] <fenn> * fenn goes to bed
[13:33:44] <morlenxus> Is win2k a real realtime system? I can set some processes to process priority 'realtime'.
[13:38:32] <alex_joni> morlenxus: good one..
[13:38:35] <alex_joni> nice joke
[13:39:25] <morlenxus> So it isn't really working?
[13:42:41] <alex_joni> realtime means highest priority
[13:42:49] <alex_joni> but even is usual latecy is good
[13:43:03] <alex_joni> some times you might have a task waiting for a few milliseconds
[13:43:05] <alex_joni> or even more
[13:43:15] <alex_joni> which totally busts RT performance
[13:44:19] <morlenxus> hm ok
[13:45:19] <alex_joni> say you want to output pulses for stepper control
[13:45:31] <alex_joni> instead of having 500 pulses at 10 usecs difference
[13:45:48] <alex_joni> you'll get a whole bunch of them at a time
[13:45:55] <alex_joni> then some pause, then another bunch, etc
[13:47:55] <morlenxus> So the realtime is a fake from windows?
[13:49:03] <alex_joni> it does work but with a very severe hack to the kernel
[13:49:09] <alex_joni> * alex_joni wouldn't trust that...
[13:49:28] <alex_joni> especially because you don't have any documentation about the kernel
[13:49:35] <alex_joni> and you can break everything :)
[13:51:36] <morlenxus> :)
[13:51:38] <morlenxus> thanks
[13:51:48] <alex_joni> no problem..
[13:51:57] <alex_joni> there are some extensions to win2k
[13:52:16] <alex_joni> m$ released some XP embedded and 2k embedded, which are supposed to have some sort of RT in them
[13:52:27] <alex_joni> but .. I never tested / seen any of those
[14:36:33] <fenn> arg i can never sleep once i get thinking about something
[14:37:22] <fenn> luckily, thinking about the craziest part i could imagine doing on a lathe turned out to solve another problem i had
[14:40:15] <lerman> fenn: You said, "is this in the new 2.6.15(?) kernel?" -- The 2.6 kernels have real-time kernel preemption. It is my understanding that you can have user space processes that are flagged as real-time. (Solaris has had this forever.) That's why I'm lobbying to switch to support only 2.6 and above kernels. That would (1) obviate the need for real-time extensions, (2) move a lot of crap out of...
[14:40:16] <lerman> ...user space, (3) make systems easier to build and install.
[14:40:37] <alex_joni> not by a far shot...
[14:40:43] <alex_joni> and emc2 works on 2.6
[14:41:41] <lerman> The issue isn't whether it works -- its whether you need to put stuff in the kernel that belongs in user space.
[14:43:20] <fenn> is pre-emption the same as hard realtime?
[14:43:49] <lerman> Herding cats is easy compared to trying to get this stuff organized. One person bemoans the fact that we lose potential users because we don't have threading for lathes. Another wants to move kinematic control to the .ini file. In my not so humble opinion, we probably have more user people who run lathes than run robots.
[14:44:12] <lerman> Preemtion isn't the same as hard realtime, but it might be required for it.
[14:44:56] <fenn> lerman: i think kinematics and lathe threading are a related problem
[14:45:36] <fenn> lathe threading is different from regular coordinated motion in that you have to sync two different sets of cartesian coordinates together
[14:46:15] <lerman> Older kernels start a 'task' and finish it to completion (also true for drivers under those kernels). While that is happening, the kernel can't do anything else. Preemption (more properly, kernel preemption) lets the kernel operation be preempted for a more important one. For instance, a core dump might be interrupted so that a user space process switch might take place.
[14:51:14] <fenn> it would be super-neato if all kinematics were defined as sets of 6x6 matrices; serial mechanisms would multiply simple matrices (containing for example the distance between arms) together to arrive at the complete cart->joint space transformation matrix
[14:51:24] <jepler_> just ducking in for a second, but the "low latency" patches look like they only get down to the realm of ms, not us, latencies. see this graph:
http://kpreempt.sourceforge.net/benno/linux+kp-2.4.6/3x256.html
[14:51:39] <lerman> Some of us tend to look for large generic solutions rather than simple special purpose solutions. HAL is probably a good example -- although it is not very large. Generalized kinematics might just be too big for most of us to understand.
[14:52:05] <fenn> yes, but that's what example files are for :)
[14:52:51] <fenn> it would help to clear up all this joint/axis confusion if every machine had a kinematics description
[14:53:17] <lerman> jepler_: I posted something early by Ingo Molar? (I'm not sure of last name) that described 25 usec max latency using 2.6 kernels.
[14:53:21] <alex_joni> lerman: who spoke about generalized kins?
[14:53:24] <fenn> and you could easily do stuff like correct for out-of square errors
[14:53:34] <fenn> * fenn is talking about generalized kins right now!
[14:53:37] <alex_joni> well.. besides fenn ;)
[14:53:56] <alex_joni> the thing is.. the kins stuff is only concearning the build/run process
[14:54:06] <alex_joni> no other issue in what jmk stated
[14:54:22] <fenn> you guys suck
[14:54:39] <alex_joni> fenn: why?
[14:54:49] <alex_joni> let's stay on ground for a bit
[14:54:53] <fenn> you have to have easily-updated kins to do automatic calibration of hexapods & such
[14:55:04] <alex_joni> yes.. and I totally agree on that
[14:55:10] <fenn> i'm not gonna go edit a source file every time i re-calibrate the machine
[14:55:49] <alex_joni> right..
[14:56:19] <alex_joni> the main thing is.. I tried to point out to ken that the easily-update-able kin stuff is merely a matter of a few minutes to do
[14:56:19] <lerman> Someone on the developer lis raised the issue.
[14:56:36] <alex_joni> yeah.. and like usuall there is more talks then it's needed
[14:56:58] <alex_joni> with that energy it could have been done a long time
[14:57:18] <lerman> Sure, you can change some 'constants', And I suppose you could add a matrix multiplication.
[14:57:37] <alex_joni> so .. where's the problem?
[14:57:50] <alex_joni> it's one thing to do such a change..
[14:58:05] <alex_joni> and the lathe stuff (although I have no idea how that should work)
[14:58:13] <lerman> That's for the easy stuff. There are probably some hard parts, also.
[14:58:25] <alex_joni> and another idea to change the whole concept of how emc gets run
[14:58:47] <alex_joni> lerman: don't think there are hard parts involving kins (at least not for the standard stuff)
[14:59:09] <alex_joni> and who needs the extra 12-strut oligopod shout take the fsck care of what he needs
[14:59:29] <fenn> heh i like that.. oligopod
[14:59:43] <alex_joni> or whatever it's called :)
[15:00:00] <alex_joni> lerman: the main problem is: how many developers you got?
[15:00:08] <lerman> I, for one, would like to see simple coordinate transformation built in. -- So I could clamp a part to a table, hit three points with a probe, and then just run my program that is written in normalized x, y coordinates.
[15:00:21] <fenn> well dammit that's what i'm saying lerman
[15:00:28] <fenn> that's a transformation matrix
[15:01:07] <fenn> are you not changing the relationship between cartesian coords and joint space?
[15:01:10] <alex_joni> ok.. will leave you guys to sort it out
[15:01:26] <lerman> The main problem isn't the number of developers. It's that unless you are willing to do the work yourself (and able to do it), it probably won't get done. (And I'm not referring to any particular 'you').
[15:01:38] <alex_joni> I totally agree
[15:01:51] <alex_joni> that's why I fscking hate people saying.. why it doesn't get done?
[15:02:09] <alex_joni> well.. maybe hate is a bit harsh (dislike)
[15:04:03] <lerman> It's tougher, though, when you see people who contribute in a big way (say, Jon Elson) asking for something. If he were to ask for something in the interpreter, I'd be inclined to try to include it -- because when I ask for something in his area of expertise, he might help there.
[15:05:27] <alex_joni> anyways.. I agree that it's ok for him to ask for lathe and threading
[15:05:46] <alex_joni> but asking if anybody did a driver for his hardware.. seems a bit .. strange
[15:06:35] <lerman> fenn: asked are you notchanging the relationship... Yes, I am. But it's a little more complex if the number of joints is more than three. Hell, if you just have both a knee and a quill on your milling machine, the game is very different.
[15:06:36] <alex_joni> to put it nicely
[15:07:37] <alex_joni> * alex_joni needs to go home...
[15:07:55] <alex_joni> will talk later
[15:08:03] <lerman> See you alex.
[15:09:07] <lerman> I'm going to work. See you all.
[15:09:13] <fenn> nice talking to you
[15:26:02] <jepler_> lerman: I think his name is Ingo Molnar. I glanced in my scrollback and didn't find what you're talking about, though.
[15:38:23] <SWP_Away> yes, Ingo Molnar is the guy maintaining the RT kernel patches
[15:48:41] <jepler_> I found this, but in it, Ingo mentions situations where you can easily cause a "1ms blip":
http://kerneltrap.org/node/5466
[15:48:48] <jepler_> It has tables, but on most of them the units are unclear
[15:52:16] <SWP_Away> the units are specified as (us) in the first column headers: Latency +/- SD (us)
[15:53:14] <fenn> geez this orocos stuff is really nice
[15:53:43] <fenn> well documented, object oriented, etc etc
[15:57:46] <lerman> For tests on kernel latency, see:
http://kerneltrap.org/node/5466 -- 25 usec.
[15:58:56] <SWP_Away> SWP_Away is now known as SWPadnos
[15:59:09] <SWPadnos> jepler mentioned that :)
[15:59:36] <SWPadnos> the thing that jumps out at me from those tables is the max latency numbers in the hundreds of microseconds
[16:00:14] <SWPadnos> although it would be better for me to look at the -preempt tables :)
[16:00:48] <lerman> Yes, I was about to say that. :-)
[16:01:22] <SWPadnos> this would be useful for servo update rates up to2 KHz for sure, 5KHz without too much trouble, and maybe even pushing 10 KHz if you're careful about phase errors
[16:01:56] <jepler_> lerman: and here's what Ingo says near the bottom: many of the worst-case latencies relate to some sort of extreme situation within a particular algorithm. E.g. lots of tasks being around. Do this for example: "hackbench 50" and Ctrl-Z it after a couple of seconds. You'll see a 1msec (or larger) blip.
[16:02:02] <SWPadnos> of course - that's with analog serovs or dedicated step generation hardware
[16:02:09] <jepler_> 1ms blips are probably not good even with servos
[16:03:51] <lerman> Oops. I missed that. :-(
[16:03:57] <k4ts> hi
[16:04:03] <SWPadnos> 1ms blips are only acceptable with audio (and that's only because of buffering)
[16:04:08] <SWPadnos> hi k4ts
[16:04:39] <SWPadnos> those tables are from July, and a fair amound has happened since then
[16:04:54] <SWPadnos> there have been some big threads on RT on LKML
[16:05:29] <lerman> Also, we probably won't be running thousands of tasks. -- But that's still an issue.
[16:06:00] <jepler_> though it's nice to know that you could run thousands of tasks and not worry that you'll miss RT deadlines
[16:06:19] <SWPadnos> as long as those deadlines are > 25 us :)
[16:18:50] <fenn> math question: is impedance the inverse of jerk?
[16:19:20] <SWPadnos> good question. what is impedance in this context?
[16:19:45] <fenn> "The APIs cover: the instantaneous transformations of position, velocity, acceleration, force and impedance between the joint space and the Cartesian space of the kinematic chain"
[16:20:19] <SWPadnos> hmmm
[16:20:41] <SWPadnos> just a hunch, but I don't think that jerk and impedance are related
[16:21:38] <SWPadnos> jerk is a joint-specific thing, a change in acceleration on that joint (at least, that's how I've been understanding it)
[16:22:25] <fenn> jerk/force/acceleration/etc are all proportional when going between cartesian and joint space
[16:22:52] <SWPadnos> I'd say related, but not proportional
[16:23:40] <SWPadnos> (a straight line in cartesian space is actually an elliptical curve in cylindrical space)
[16:24:29] <SWPadnos> unfortunately, they don't have "impedacne" in their glossary
[16:25:16] <SWPadnos> ah - I think they're talking about things like cviscous clutches and that type of thing
[16:25:20] <SWPadnos> look on this page:
[16:25:25] <SWPadnos> http://www.orocos.org/documentation/kindyn-doc.html
[16:25:35] <fenn> right
[16:25:46] <fenn> it has to do with force transfer
[16:25:48] <SWPadnos> section 1.4 Kinematic Interconnections
[16:26:27] <SWPadnos> even better, section 2.4 Nonrigid link and joint
[16:26:43] <fenn> one step ahead of ya :)
[16:26:54] <SWPadnos> (I'm low on coffee :) )
[16:27:48] <SWPadnos> well, impedance is the opposite of jerk, only if you'd also say that friction is the opposite of velocity
[16:29:09] <fenn> this is weird that i've never heard of this software library
[16:29:25] <SWPadnos> yes. where have you been? you should be on top of these things
[16:30:11] <fenn> not enough funding!
[16:30:20] <fenn> time is money :)
[16:30:29] <SWPadnos> it's been proved!
[16:44:55] <fenn> so they proceed from trivial kinematics to a full-blown physics model of a scene containing objects
[16:51:36] <les_w_away> blah phase 2 final report written and off. "I ain't gonna work no more this week"
[16:59:21] <SWPadnos> well - tomorrow is Veteran's Day, so you should have it off anyway
[16:59:36] <les_w_away> hmm yeah
[16:59:46] <les_w_away> reading the orocos stuff i see
[17:00:26] <les_w_away> les_w_away is now known as les_w
[17:02:02] <les_w> I guess Till pulled the emc page that made improper reference to it
[17:02:09] <les_w> hope he fixes that soon
[17:02:25] <les_w> want to see it
[17:05:37] <cradek> does jon elson do any development?
[17:05:47] <SWPadnos> yes, as time permits
[17:05:59] <SWPadnos> but from what I've seen, mostly on his own drivers
[17:06:18] <cradek> that's understandable
[17:06:43] <SWPadnos> I think he's a better electrical engineer than a programmer :)
[17:06:58] <lerman> I, for one, am pleased to say that I do the stuff that I need.
[17:07:24] <lerman> (And/or am interested in.) :-)
[17:07:32] <cradek> I'm sure most of us are like that
[17:07:34] <SWPadnos> need is a relative term
[17:07:59] <lerman> I need lunch. I want sushi. :-)
[17:08:08] <SWPadnos> oooh - that sounds good
[17:08:28] <SWPadnos> tuna, mackerel, salmon, eel - mmmmm (maybe I'll head down to the store)
[17:08:31] <lerman> I'll have left over pizza (cold).
[17:08:52] <SWPadnos> heh - can-o-chili, anyone? :)
[17:09:23] <SWPadnos> I wish touchscreen LCDs weren't so expensive
[17:09:58] <lerman> Earth LCD has some relatively inexpensive ones I've used.
[17:10:15] <SWPadnos> 15" and up, like monitors?
[17:10:23] <lerman> See the marmalade product.
[17:10:37] <lerman> No... 7.8 inch.
[17:11:37] <lerman> I used it for development, then went to an 8+ inch TFT display. The DSTN (I think) display they had wasn't bright enough for use in an operating room.
[17:11:52] <SWPadnos> heh - need good visibility there :)
[17:12:42] <lerman> Well, it was visible, but didn't pop out at you. Sometimes pizzazz is necessary to sell a product (even if it isn't needed to use it).
[17:12:44] <SWPadnos> they do have some 12.1" touch PCs - could be useful for a kiosk project I have in mind
[17:13:11] <SWPadnos> like an animated heart beating (next to the BP / heart rate numbers)
[17:13:43] <lerman> Hell, add an ultrasound probe and you could show a live heartbeat.
[17:14:08] <SWPadnos> but that's monochrome - no pizzaz
[17:14:35] <fenn> add a doppler probe for extra pizzaz
[17:15:05] <lerman> And the average touchscreen LCD will have the crap beat out of it in a kiosk.
[17:15:24] <Jymmm> Tonka Touchscreen
[17:15:29] <lerman> As will the average non-touch LCD in a machine shop.
[17:15:30] <SWPadnos> this is for an in-store consumer information display
[17:15:38] <SWPadnos> not some outdoor / airport internet kiosk
[17:16:02] <SWPadnos> I was thinking about that - how do touchscrens hold up in a machining environment?
[17:16:04] <lerman> Once a consumer can touch it, it's toast unless built with vandals in mind.
[17:16:12] <SWPadnos> with non-touch, you can use screen protectors
[17:16:42] <SWPadnos> yeah - I'm looking at stainless steel KB and mouse, even for my machine controller
[17:16:57] <lerman> I'm using a Xerox 17 inch LCD on my EMC system. It has a built in glass cover plate. Looks real nice.
[17:17:09] <SWPadnos> non-touch?
[17:17:17] <fenn> some touchscreens use infrared finger-sensors
[17:17:31] <lerman> My machine controller has a cheap rubber keyboard. The old one died of the chip disease.
[17:17:49] <lerman> Yeah -- non-touch for my Xerox.
[17:17:51] <SWPadnos> those are (were) pretty low-res (in terms of determining actual finger position)
[17:19:21] <SWPadnos> I like this, but it's a bit expensive:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=5827527756
[17:19:37] <SWPadnos> and no F-keys
[17:20:31] <cradek> that's very neat
[17:20:55] <SWPadnos> yeah - if you look at his other items, he also has just the trackball (but it's $67)
[17:21:20] <lerman> Are etched keys the same as double shot molded?
[17:22:02] <SWPadnos> in plastic?
[17:22:55] <lerman> Ah. I didn't catch that the keys were also stainless.
[17:22:58] <SWPadnos> I think etched just have the legend on top, whereas double-shot molded have the legend molded in - you can still read it if the keycaps get worn down
[17:23:20] <SWPadnos> yeah - even the ball is apparently stainless
[17:24:52] <fenn> funny how shipping costs go up with price
[17:25:12] <SWPadnos> yeah - it's like insurance is 10% of the product value :)
[17:25:57] <fenn> i have a rubber keyboard and don't like it at all
[17:26:28] <fenn> have to push really hard on the buttons, and they flop over instead of going straight down
[17:26:36] <SWPadnos> I bought one also - $20, so it's a throwaway.
[17:27:17] <SWPadnos> there were two types where I bought mine. One worked well, the other, even though it's almost identical in construction, was hardly usable.
[17:31:07] <Jymmm> sounds like a capacitance switch
[17:31:25] <SWPadnos> what does? the keyboard?
[17:31:35] <Jymmm> yeah, if all SS
[17:32:09] <SWPadnos> nope - look at the ebay link. it's stainless keycaps (probably on a standard resistive mat keyboard)
[17:34:04] <Jymmm> cool, other than USB
[17:34:15] <SWPadnos> and the lack of F-keys
[17:34:44] <lerman> fenn: yup. the rubber keybaord is NG for typing a lot. But I do my programming in the office, so the keyboard gets relatively little use.
[17:34:59] <Jymmm> screw it, get a roll-up kybd instead. cheaper
[17:35:20] <SWPadnos> those can suck
[17:35:34] <SWPadnos> (see 9 lines back)
[17:36:04] <SWPadnos> I bought at Micro Center in Boston. the small keyboard (without numeric keypad) was terrible
[17:36:23] <SWPadnos> I kept the full size one, because it seemed like you could actually type on it
[17:37:39] <Jymmm> SWPadnos: Well then... learn from the arcade industry...
http://www.ultimarc.com/ipac1.html
[17:37:59] <SWPadnos> yeah - if you want good controllers, that's the industry to look at
[17:38:16] <SWPadnos> surprisingly, there's a stand-up arcade machine available at Costco
[17:38:28] <SWPadnos> uses MAME or something, has 81 arcade games in it
[17:38:46] <Jymmm> how much?
[17:38:52] <SWPadnos> $2k
[17:39:19] <Jymmm> not bad, if it's not "locked" system.
[17:39:33] <SWPadnos> supposedly upgradable to 200+ games
[17:39:39] <SWPadnos> licensed, even :)
[17:39:56] <SWPadnos> here's the tabletop version:
http://www.costco.com/Browse/Product.aspx?prodid=11041445&whse=&topnav=&cat=&s=1
[17:41:19] <SWPadnos> hmm - loks like it's only 50 games (a friend told me 81)
[17:41:47] <cradek> I think most of those games are not in the public domain
[17:42:01] <cradek> I wonder how they got permission to include all of them
[17:42:02] <SWPadnos> no - but this has licensed versions of all of them
[17:43:42] <Jymmm> cradek: Just like older movies, residual licensing. Doesn't make any money sitting in the file cabinet. Especially when the kids want newer games.
[17:44:14] <SWPadnos> yep - if you can make $3 per game, you're doing better than $0 per game
[17:44:29] <SWPadnos> OK - it's oil change time. see you later
[17:44:33] <SWPadnos> SWPadnos is now known as SWP_Away
[17:46:44] <alex_joni> evening
[17:48:32] <Jymmm> howdy alex_joni
[17:48:37] <alex_joni> howdy
[18:15:11] <les_w> I see Dr. Sep kiani posted on the user group
[18:15:33] <alex_joni> hey les
[18:15:36] <Jymmm> who?
[18:15:47] <les_w> he is faculty with Alex Slocum at MIT precision machine group
[18:16:12] <les_w> They kinda "wrote the book"
[18:17:03] <fenn> "are writing the book"
[18:17:09] <les_w> Wonder if they are messing with emc
[18:17:22] <fenn> i doubt it
[18:17:24] <Jymmm> ah, ok.
[18:17:43] <fenn> sep mentioned that he had some chinese mill he wanted to use emc with
[18:17:56] <les_w> really
[18:18:11] <fenn> that was several months ago
[18:18:36] <les_w> wish they would put it on something high speed...then they might help fix the TP!
[18:18:42] <fenn> les_w: have you looked at orocos?
[18:18:43] <les_w> oh that reminds me
[18:18:55] <les_w> yeshave looked
[18:19:00] <anonimasu> hi
[18:19:33] <les_w> Want to see what Till did with it.
[18:19:38] <les_w> hi anon
[18:19:44] <anonimasu> what's up?
[18:19:56] <fenn> made a bastardized version of their trajectory planner
[18:20:12] <les_w> not much...I am off for a couple days. Grinding up leaves with the tractor.
[18:20:25] <anonimasu> fenn: explain it a bit more
[18:20:36] <fenn> i'm just reading up on the trajectory code in orocos right now
[18:20:40] <anonimasu> orocos?
[18:21:04] <fenn> a generalized robotics/kinematics library/application
[18:21:14] <fenn> hard to say exactly what it is
[18:21:14] <anonimasu> is it fast/good
[18:21:17] <fenn> no idea
[18:21:18] <anonimasu> the tp..
[18:21:21] <fenn> the code looks nice
[18:21:27] <fenn> i havent looked at the tp code yet
[18:21:31] <fenn> (if there is any)
[18:21:33] <anonimasu> ah :/
[18:22:12] <fenn> i see a lot of octave stuff, i dunno if that is supposed to be run interactively or what
[18:22:32] <etla> octave is an opensource matlab I think
[18:23:06] <anonimasu> hm ok
[18:23:38] <fenn> http://www.orocos.org/documentation/interpolation-api.html
[18:23:40] <etla> les_w: are you still thinking about going the dsp route for PID loops ?
[18:24:49] <etla> fenn: that looks like a jerk-limited tp
[18:25:05] <fenn> etla: and?
[18:25:08] <etla> the next step in 'smoothness' is double-jerk limited
[18:25:15] <fenn> meh
[18:25:24] <alex_joni> jerk-limited is ok
[18:25:28] <fenn> i think i can live without double-jerk limited motion for the next couple hundred years
[18:25:41] <etla> has anyone tried/seen both ?
[18:26:12] <fenn> i've seen some movies on the internet demonstrating jerk limited
[18:26:22] <fenn> not seen how double-jerk is useful
[18:26:27] <etla> the math for the jerk limited tp is not that hard
[18:26:27] <anonimasu> hm
[18:26:32] <anonimasu> yeah
[18:26:54] <anonimasu> although writing that in c isnt as easy ,)
[18:26:55] <anonimasu> ;)
[18:27:06] <etla> just need to satisfy all the boundary conditions from one segment to the other if you want to do lookahead
[18:27:26] <etla> I think a lookahead planner needs to always plan until the middle of the last move in the buffer
[18:27:34] <anonimasu> hm
[18:27:47] <anonimasu> you guys should have a look at some toshiba papers..
[18:27:51] <etla> then when moves get added to the buffer you complete the move and again plan to the middle of the last move in the buffer
[18:28:14] <etla> anon: URLs?
[18:28:29] <anonimasu> no
[18:28:33] <les_w> etla: sorry...was reading the octave code
[18:28:36] <anonimasu> I got some off dmess earlier
[18:28:46] <anonimasu> I'll look them up if you remind me after I've had dinner
[18:28:55] <les_w> I will go any route that willlgive good servo update
[18:29:21] <fenn> i was looking at orocos to implement generalized kinematics
[18:29:22] <les_w> I still have no Idea really why emc has to be so slow
[18:29:47] <etla> so what are the servo update rates with different emc-supported hardware right now
[18:29:54] <etla> servo-cards I mean
[18:29:59] <etla> or PPMC
[18:30:25] <les_w> They SEEM to max out at about 2kHz (allaxes) with any box and hardware
[18:30:53] <les_w> We have seen old boxes that run emc a little faster than newer ones
[18:30:58] <etla> ok, and in your opinion, what's 'good' ?
[18:31:16] <anonimasu> heh
[18:31:27] <les_w> Well, 10k is pretty standard for HSM
[18:31:39] <les_w> about 5 times better
[18:32:20] <les_w> a number of motion boards can do that
[18:32:42] <les_w> but
[18:32:55] <les_w> they are motion boards...not machine controls
[18:33:25] <les_w> galil accelera is an example
[18:33:38] <les_w> as is dynomotion
[18:34:02] <lerman> Hey, Les_w: Here we go again. Anyone knows that it is pointless to argue about how many angels can dance on the head of a pin. -- You have to get out there and count them. I'd like to see someone do some real measurement/analysis of where the time goes in EMC.
[18:34:08] <les_w> These are about the price of an STG card...or a little less
[18:34:51] <alex_joni> les_w:
http://www.kontron.com/products/pdproductdetail.cfm?keyProduct=30166
[18:34:55] <les_w> Paul and I only had 3 machines to test..all pretty old due to the requirements for ISA
[18:35:15] <fenn> lerman: how would you suggest going about measuring that?
[18:35:16] <les_w> I would like to see more benchmarks too
[18:35:43] <lerman> I've heard it said that the pid loop takes roughly the same amount of time (400usec) on a 400Mhz machine as on a 2 ghz machine. Why? Where is the time going. Unless you know where the time goes, you can't intelligently hope to make it faster.
[18:36:37] <alex_joni> there's a big black timehole
[18:36:40] <anonimasu> ^_^
[18:36:43] <alex_joni> that sucks time from you
[18:37:27] <les_w> another one: kontron
[18:37:32] <lerman> Well, gprof could be used for non RT stuff. I'll bet if you knew what you were doing, you could make something similar work in a RT environment.
[18:37:48] <alex_joni> what's gprof?
[18:38:21] <anonimasu> gnu profiler
[18:38:29] <anonimasu> http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html
[18:39:00] <etla> les_w: if dedicated hardware is going to be any 'fun' it needs to run opensource sw...
[18:39:33] <alex_joni> lerman: did you look at HAL stuff?
[18:39:42] <alex_joni> there are some hooks in it that determine timings
[18:39:45] <alex_joni> of the threads running
[18:39:56] <lerman> "man gprof". (I think it is for graph profiling). A previous program called prof simply showed what percentage of time was spent in each function. Gprof looks at the call graph and determines on whose behalf the time was spent.
[18:40:58] <les_w> None of the two card manufacturers I talked to had any problem with open source SW that uses their product
[18:40:58] <lerman> I've just skimmed parts of HAL. I don't have an overall view of how it works (internally), although I've been familiar with the concept for about 30 years.
[18:41:38] <alex_joni> well.. halscope & the mentioned hooks provide some helping stuff to determine where time goes
[18:41:40] <etla> les: how advaced are the onboard trajectory generators then ? or did you mean completely rewrite the firmware as opensource
[18:41:47] <alex_joni> it just needs someone to do that
[18:42:06] <les_w> Paul and I just incrementally lowered the servo time till funny things happened
[18:42:37] <les_w> the non rt stuff typically went wacky as the rt thread used all the resources
[18:43:08] <les_w> much further and it would just lock
[18:43:20] <etla> and yo got to around 2kHz ?
[18:43:25] <alex_joni> the kontron will give you Windows NT support, win2000 coming soon..
[18:43:33] <alex_joni> so I guess linux is out of the question
[18:43:43] <les_w> 400 microsecond is the best we got
[18:43:53] <alex_joni> for all RT
[18:43:59] <alex_joni> not only servo update
[18:44:11] <alex_joni> or?
[18:44:39] <etla> a_j: what do you mean ?
[18:44:42] <les_w> well, again, we did not test newer fast machines due to our STG requirement.
[18:45:20] <alex_joni> etla: lots of stuff happening in RT
[18:45:25] <alex_joni> not only servo-updates
[18:45:25] <les_w> Paul seemed to think there would be no improvement beyond a few hundred MHz
[18:45:43] <les_w> well the whole rt thread
[18:46:02] <lerman> I've heard that message, but I'd like to know why that happens.
[18:46:10] <les_w> me too.
[18:46:25] <alex_joni> lerman: too complex architecture
[18:46:30] <lerman> Just what aspect of a machine that is nominally twice as fast causes it to not be any faster.
[18:46:36] <alex_joni> and you need worst case performance
[18:46:41] <anonimasu> heh
[18:46:41] <anonimasu> yeah
[18:46:55] <alex_joni> because if you miss one RT deadline, the machine is locked
[18:47:05] <alex_joni> it's not like going 100% in 98% of the cases
[18:47:14] <les_w> so caches, pipeline, etc don't help
[18:47:15] <alex_joni> it's more like going 60% in 100% of the cases
[18:47:23] <alex_joni> les_w: those make it WORSE
[18:47:26] <alex_joni> lots worse
[18:47:46] <alex_joni> a common P4 has a 20 stages pipeline
[18:48:04] <alex_joni> a false branch prediction, and you can sit for 20 cycles for it to load again
[18:48:13] <lerman> Is anyone running EMC on non x86 architectures? Say a RISC processor? How fast do the power PCs run?
[18:48:26] <les_w> sounds like a glum outlook for emc in pcs
[18:48:35] <alex_joni> les_w: not glum
[18:48:48] <alex_joni> a P4 still runs twice as fast RT stuff than an old PI
[18:48:58] <alex_joni> PI-100 compared to P4-3000
[18:49:12] <alex_joni> maybe more than twice.. but not 30 times faster
[18:49:29] <lerman> With the right tools, you would see which branch predictions are wrong and fix them.
[18:49:34] <alex_joni> even normal (usermode) stuff doesn't run 30 times faster
[18:49:43] <alex_joni> lerman: kidding.. right?
[18:49:56] <fenn> emc3 will be programmed in asm :)
[18:50:02] <anonimasu> lol
[18:50:05] <alex_joni> fenn: asm is not good
[18:50:17] <les_w> Is anyone running servo emc on a newer fast machine?
[18:50:23] <les_w> what about Dave?
[18:50:29] <alex_joni> even if you do it in machine code.. still not gonna help
[18:50:41] <alex_joni> the whole point is.. why do you have if's in your program?
[18:50:49] <alex_joni> because some data is simply run-time dependent
[18:50:56] <alex_joni> like feedback from the machine, etc
[18:51:01] <les_w> yeah
[18:51:02] <alex_joni> you can't PREDICT that
[18:51:08] <lerman> No. People DO write hand optimized inner loops that worry about proper branch optimization. That's why it is important to understand where the time is going. If 80% of the time is going to a small part of the code, you might be able to optimize it better.
[18:51:35] <alex_joni> lerman: I agree on that, but not on "see which branch predictions are wrong and fix them"
[18:51:40] <anonimasu> hm, the only way to solve it is to get more _data_
[18:52:05] <alex_joni> every point in the program where you have an if, or an while or whatever involves a decision, implies a branch and a branch-prediction
[18:52:35] <alex_joni> the branch-prediction is done in hardware (a special part of the processor) which looks at current op-codes, and remembers a few past ones
[18:52:53] <alex_joni> and then it uses silly little tricks to take a shot about where the program should go
[18:53:21] <alex_joni> * alex_joni read an article a few years ago about P4 processors
[18:53:25] <alex_joni> just as they were released
[18:53:37] <lerman> You can see where in your code the compiler predicts the branch one way but you KNOW that 90% of the time the branch will be the other way. That could be important in an inner loop. Yes.. it's done in hardware. But can't you force it to expect a particular direction?
[18:53:48] <alex_joni> no
[18:53:53] <alex_joni> it's not compiler-time
[18:53:59] <alex_joni> it's run-time inside the processor
[18:54:04] <fenn> so, if you choose the wrong path it results in like 20 cycles, which is about 20ns, so what?
[18:54:15] <alex_joni> fenn: probably
[18:55:01] <alex_joni> http://www.x86.org/articles/branch/branchprediction.htm
[18:55:14] <fenn> i doubt the servo loop calculates (400us/20ns) wrong branches each loop cycle
[18:55:18] <alex_joni> fenn: but you need to multiply that with the number of branches..
[18:55:48] <alex_joni> when the P4 first came out, a processor doing nothing wasted 30% of it's power on wrong branch predictions
[18:56:56] <alex_joni> also, another big problem
[18:57:04] <alex_joni> the CPU caches (L1 & L2)
[18:57:22] <alex_joni> you don't have control over the methods to swap out data/code from the caches
[18:57:38] <alex_joni> so if you got an cache miss.. you get to wait till the data is brought from memory
[18:57:57] <alex_joni> in that particular case it takes more time then if you would have gotten it directly from the memora
[18:57:59] <alex_joni> memory..
[19:00:35] <les_w> I wonder how many are actually physically controling servos with emc
[19:00:41] <les_w> and what they use
[19:00:49] <les_w> only a few I think
[19:01:21] <etla> I'm only at the planning stage...
[19:01:30] <les_w> Dave, Abdul, Me, john E.,...
[19:01:31] <fenn> ditto
[19:01:39] <les_w> trying to think of anyone else
[19:01:49] <alex_joni> yay..the new Prescott has 31 pipeline stages
[19:01:50] <etla> les: did you say dynomotion kmotion card has a G-code interp onboard ?
[19:02:09] <les_w> it uses the emc code on the host pc
[19:02:16] <alex_joni> les_w: think mshaver too
[19:02:20] <les_w> yeas
[19:02:22] <les_w> matt
[19:02:27] <lerman> What does the phrase physicall controlling mean in this context? You do need an interface. I'm using John Elson's UnivPWM boards. Does that count as using EMC to physically control the servos?
[19:02:41] <fenn> jon could probably give you a list of customers if you asked the right way
[19:03:14] <les_w> tlerman: yeah that counts I think. If the pc is taking in encoder pulses...it's full servo
[19:03:47] <alex_joni> les_w: then a DRO board makes it a servo?
[19:03:51] <alex_joni> even when running steppers?
[19:04:08] <les_w> hmm no
[19:04:15] <anonimasu> hm, why not?
[19:04:19] <etla> having the postition PID loop run in emc I think is the issue
[19:04:28] <etla> position
[19:04:32] <les_w> right
[19:04:32] <anonimasu> brb dinner
[19:04:35] <les_w> k
[19:04:56] <les_w> does the univPWM do this?
[19:04:57] <lerman> How about if it is closed loop (using DRO) but not PID (using steppers)?
[19:05:54] <les_w> I think pid in the pc defines it
[19:06:03] <alex_joni> "if they increase the clockspeed to 4ghz by lengthinng it to 30 piplines then it will have a lower ipc meaning it will perform about the same as a lower clocked p4 with a bigger ipc number right now the pentium 4 is 6 ipc i think. Correct me if im wrong. so if they increased the pipeleght by 1/3 to get from 3 to 4ghz then the ipc will be 4."
[19:06:37] <alex_joni> so... a P4 - running 2GHz is actually doing one instruction every 6 cycles
[19:07:03] <fenn> what about amd chips?
[19:07:13] <alex_joni> it easily adds up
[19:07:19] <lerman> No... increasing the length of the pipeline doesn't affect the instructions per clock.
[19:07:28] <les_w> The whole concept I think with emc was to run pid loops for machine control in a pc with only dumb io
[19:07:35] <alex_joni> lerman: care to explain why not?
[19:07:50] <etla> les: did you know the dynomotion manufacturer ? I'm interested in something like that but not the (too small) power-amps
[19:08:11] <les_w> Yes I know the developer/manufacturer
[19:08:55] <les_w> and yes the small servo amps could be depopulated
[19:09:07] <Jacky^> heloo
[19:09:20] <les_w> He also has one with fewer larger amps as well
[19:09:30] <Jacky^> hi les_w
[19:09:35] <les_w> hi jacky
[19:09:36] <lerman> Each clock, another instruction is entered into the pipeline. Each clock one part of the execution of each instruction takes place. At the end of 1000 clocks, 1000 instructions have gone into the pipeline and 1000 have come out. The instructions per clock depend on how many pipelines run in parallel.
[19:10:51] <lerman> However, if you have a long pipeline and you have to restart it, that can affect the average number of instructions per clock for a real program.
[19:11:26] <alex_joni> yes.. also having dependencies in the instructions
[19:11:37] <alex_joni> one instruction waiting for the previous one to finish..
[19:11:43] <alex_joni> also lots of troubles
[19:12:02] <alex_joni> like I said.. recent processors are designed to be very fast in most of the cases
[19:12:08] <alex_joni> but you cannot do RT like that
[19:12:26] <les_w> The entire TP also runs in real time, right? What about the inverse kinematics?
[19:12:29] <alex_joni> if you are doing REALTIME, you need to get the results when they are needed
[19:12:34] <alex_joni> les_w: that too
[19:12:47] <les_w> a lot of stuff.
[19:12:48] <alex_joni> but with trivkins that's only one instruction/axis
[19:12:55] <les_w> right
[19:13:18] <alex_joni> one assignment
[19:13:18] <alex_joni> les_w: I agree, what we discuss here is only the tip of the iceberg
[19:13:25] <alex_joni> there is a LOT of stuff that needs to be done..
[19:13:30] <alex_joni> and sooo little time ;)
[19:13:36] <les_w> heh
[19:13:53] <alex_joni> even at 5GHz, I can't type any faster :D
[19:14:03] <alex_joni> so.. I'll be the limiting factor :)
[19:14:16] <fenn> should'a picked AI instead
[19:14:17] <alex_joni> same is true for harddisk access..
[19:14:35] <alex_joni> if you need the data and you look for it in a cache,
[19:14:54] <alex_joni> it's not there (cache miss), get it from memory (not there either, has been swapped out)
[19:14:58] <alex_joni> you're in deep SH*T
[19:15:07] <fenn> can't swap out rt stuff because it's kernel memory
[19:15:17] <alex_joni> fenn: true for RT stuff..
[19:16:01] <alex_joni> but move it to user-space .. as you? suggested earlier?
[19:16:08] <fenn> if you try hard enough you can break it
[19:16:20] <alex_joni> * alex_joni doesn't usually break things
[19:16:26] <alex_joni> I leave that for the users..
[19:16:34] <alex_joni> and boy do they break things..
[19:16:39] <fenn> (lerman wanted to do everything in userspace btw)
[19:16:58] <alex_joni> fenn: sorry.. thought it was you ;)
[19:17:10] <alex_joni> lerman: I am exagerating a bit..
[19:17:11] <fenn> it sounds like something i would say
[19:17:18] <alex_joni> but only to prove my point..
[19:17:37] <alex_joni> I agree that maybe one day it will be doable.. but right now it doesn't look like that
[19:18:44] <CIA-5> 03alex_joni * 10emc2/src/Makefile.inc.in: restored the removed driver-configs
[19:19:41] <alex_joni> hmm.. seems I remembered it right: "Normal processors can waste up to 30 percent of their time recovering from mistaken predictions..."
[19:19:57] <fenn> * fenn wonders why anyone would buy the servotogo if the kontron is only $100 more
[19:20:06] <alex_joni> http://64.233.183.104/search?q=cache:d_odnSMgkzYJ:reviews.zdnet.co.uk/hardware/processorsmemory/0,39024015,10003237,00.htm+processor+branch+prediction+p4+waste+time&hl=en&client=opera
[19:20:28] <alex_joni> fenn: dunno ;) maybe because it's supported, and has open-source software?
[19:20:40] <alex_joni> the kontron seems.. forgotten
[19:20:45] <les_w> Fenn: years ago it was the only game in town for emc
[19:20:45] <alex_joni> the STG surely is ;)
[19:21:00] <les_w> kontron, etc are not turn key machine controls
[19:21:24] <etla> and, for HSM you want some fancy trajectories and lookahead etc.
[19:21:35] <les_w> yes.
[19:21:35] <etla> I'd not be happy with at tp that does only exact stop moves
[19:21:46] <anonimasu> hmm
[19:22:08] <etla> so you need to have a flexible interface btw. the PID hardware and the TP which could run on a pc
[19:22:11] <les_w> I can do HSM up to the new spindle's limit with long lines and arcs
[19:22:17] <alex_joni> how fast is HSM?
[19:22:26] <etla> heh
[19:22:34] <alex_joni> * alex_joni did some welds on his robots with 3-4m/min
[19:22:38] <alex_joni> is that HSM ?
[19:22:45] <les_w> but for any kind of contouring, like v carving or molds and I have to slow to a crawl.
[19:22:51] <anonimasu> alex_joni: want me to get a exact figure?
[19:22:55] <fenn> HSM is usually considered 1g acceleration
[19:23:01] <anonimasu> heh
[19:23:23] <anonimasu> hold on a little bit
[19:23:49] <les_w> I designed for one, but derated to 0.5 for x. Y and z can do multiple g.
[19:24:12] <anonimasu> depends on material
[19:25:06] <etla> so we'd need a servocard/DSP which has opensource firmware in it.
[19:25:22] <etla> so that the machine control, running on a pc, can communicate arbitrary trajectories to it
[19:25:33] <les_w> right
[19:25:45] <anonimasu> cutting speed about 1000m/min for alu
[19:25:55] <alex_joni> 1000m/min ????
[19:25:58] <anonimasu> yeah..
[19:26:02] <anonimasu> that's where it begins..
[19:26:15] <fenn> sure that's not surface speed?
[19:26:16] <alex_joni> that's 16 m/sec ??
[19:26:23] <anonimasu> ~3000 - 5000 is suitable..
[19:26:28] <les_w> I see the cards like the accelra send things like buffer half full flag
[19:26:37] <alex_joni> anonimasu: that's mm/min not m/min
[19:26:39] <anonimasu> that's what the machinist handbool says..
[19:26:48] <anonimasu> alex_joni: no m/min
[19:26:53] <alex_joni> oddd
[19:27:01] <fenn> machinist handbook talks about stuff like the speed of the cutter, not feedrates
[19:27:18] <etla> les: in the polynomial schemes, i.e. jerk-limited or double-jerk limited, you'd need to send only two numbers, a time-period and a jerk/djerk value
[19:27:18] <fenn> so divide that by the diameter and rpm, and you get feedrates
[19:27:25] <etla> that defines the trajectory
[19:27:29] <anonimasu> that's cutting speed..
[19:27:50] <anonimasu> yeah..
[19:28:57] <fenn> the reason HSM is better is because machining forces go down with increasing surface speed
[19:29:12] <etla> so communication would be maybe one 16-bit time value + one 32-bit jerk/djerk value. you need 8 or 16 of those per segment depending on jerk/djerk-limited
[19:29:20] <fenn> until you reach the speed of sound in the material being cut, and then machining forces become negative
[19:29:28] <les_w> I see
[19:30:05] <les_w> well, on most of the dsp cards the tp is run on the card
[19:30:19] <les_w> looking at galil optima
[19:30:22] <djb_rh> damn
[19:30:30] <djb_rh> rec.crafts.metalworking is one interesting newsgroup
[19:30:52] <les_w> you send it Galil language...not unlike rs274 but more versitile
[19:31:06] <les_w> but only 2000 lines can be held
[19:31:26] <etla> you would have to specify feed,acc,jerk at beginning and end of each segment also ?
[19:31:45] <les_w> on the dsp cards?
[19:31:50] <etla> yes
[19:31:54] <les_w> checking
[19:32:16] <les_w> http://www.galilmc.com/products/accelera/dmc18x6.html
[19:33:14] <les_w> you just send a destination. blending stuff is modal
[19:33:31] <les_w> it does the TP
[19:33:31] <anonimasu> hm..
[19:33:47] <anonimasu> so have anyone tried running the test spiral on a faster machine?
[19:33:56] <alex_joni> alex_joni is now known as alex_joni_away
[19:34:01] <les_w> I think not
[19:34:13] <etla> ok... but galil is a little $teep...
[19:34:38] <les_w> relative, etla. It's about the same price as an STG card.
[19:35:02] <etla> if you buy a hundred ??
[19:35:09] <les_w> let me check
[19:35:33] <fenn> if you know the secret handshake
[19:35:49] <anonimasu> heh
[19:36:22] <les_w> right 100 is 995. 1 is 1895
[19:36:33] <etla> well, an opensource servocard/board would be nice
[19:36:46] <les_w> In talking with them I think I could get a serious break.
[19:36:46] <fenn> PCI boards are hell to design
[19:37:02] <etla> there's the 5i20, which is only $200, but I guess the 200k gate fpga is a little limiting
[19:37:13] <etla> although there's vhdl for a 4-axis motion controller available
[19:37:31] <les_w> the dynomotion and others seem to be in the $900 or so unit cost
[19:38:35] <etla> have you looked at
http://www.mesanet.com/pdf/motion/softdmc.pdf
[19:38:58] <etla> the vhdl is distributed with the card
[19:39:13] <etla> and apparently xilinks supplied the compiler for free
[19:39:22] <les_w> This stuff is not hobby material, and most emc users are hobbyists. So realistically nothing is gonna get done as a hobby activity.
[19:39:45] <les_w> yeah have looked at the mesanet. Has promise
[19:40:37] <etla> I wonder how full/used the fpga is by the current softdmc
[19:41:33] <les_w> however if EMC cannon.cc or whatever was spitting out commands for one of these cards it would be a killer PRODUCT
[19:41:59] <les_w> closest closed source commercial stuf is thousands. Just for the Software.
[19:42:14] <etla> it can't be that hard :)
[19:42:31] <etla> I'd still think that the trajectory planning would be best done in the pc
[19:42:41] <les_w> I don't think it would be for a programmer
[19:42:58] <etla> and then the interpolation, coord transform, and PID would be on the card
[19:43:11] <etla> what would not be for a programmer ?
[19:43:20] <les_w> It would be fine to do it in the pc.
[19:43:34] <etla> ok
[19:43:47] <les_w> It's just these cards just do a pretty good job on their own.
[19:43:47] <etla> I think I'll get one of the 5i20 boards since they are so cheap.
[19:44:00] <les_w> mesa?
[19:44:05] <etla> yes
[19:44:33] <etla> and the source is available
[19:44:36] <etla> and the compiler
[19:44:46] <etla> only drawback is that it is fully digital
[19:44:58] <etla> so servo amps need to be controlled by pwm duty cycle
[19:45:22] <fenn> what's wrong with that?
[19:45:28] <les_w> no problem at all there
[19:45:48] <etla> hmm... I don't know, I guess it's ok
[19:46:08] <etla> pwm decoding should be pretty straightforward in digital drives ?
[19:46:12] <les_w> etla, PWM demodulation is just about a nothing thing.
[19:46:31] <etla> or do they lp filter and treat it as analog ?? :) I hope not
[19:47:09] <etla> then there's the issue of resolution
[19:47:18] <etla> say the servo loop runs at 10 kHz
[19:47:37] <etla> then the servo torque command pwm has a frequency of 10kHz also ?
[19:48:14] <fenn> that depends on the vhdl doesn't it?
[19:48:30] <etla> sure, but in principle, wouldn't that be ok ?
[19:48:35] <les_w> Well my analog amps have a BW of about 3 kHz as set. PWM frequency is 22 kHz I think.
[19:49:24] <fenn> PWM frequency should match your FET's or whatever
[19:49:30] <etla> what I'm getting at is that the servo drive that decodes the pwm command from the controller needs to run at quite a high clock frequency
[19:49:45] <etla> I'm not talking about the pwm command to the motor coils
[19:49:53] <etla> I'm talking between pci card and servodrive
[19:50:01] <les_w> understand
[19:50:12] <etla> for fancy 3-phase ac servos that can't be the same thing
[19:50:35] <etla> les: I understand what you say, although the servo loop runs at 10kHz the reasonable bw of the amp is not that high
[19:51:18] <etla> anyway, with a servodrive (dsPIC based) running at 30 MHz clock I would get about 9-10 bit accuracy for the torque command
[19:51:22] <etla> would that be enough ?
[19:51:24] <les_w> right. It needs to be twice the BW minimum.
[19:51:39] <les_w> 10 bits is enough I think.
[19:52:05] <etla> the AD for monitoring the currents in the dsPIC is 10-bits so no point in going much beyond that
[19:52:25] <les_w> the stg is 10 or 12
[19:52:28] <les_w> I think 12
[19:52:34] <etla> OK
[19:52:40] <les_w> plenty
[19:53:09] <les_w> lower would icrease following error at some point
[19:54:05] <fenn> smooth curves get more zig-zaggy
[19:54:17] <les_w> A big issue with emc is that trajectory rate is linked to servo rate.
[19:54:24] <les_w> some integer fraction
[19:54:55] <etla> for pwm with 10 kHz frequency I calculate 3000 clocks at 30Mhz, so should be "11,5 bits"
[19:54:56] <les_w> when requested motion is faster than that the algo breaks down
[19:55:13] <etla> explain trajectory rate
[19:55:18] <etla> please.
[19:55:36] <les_w> block read rate
[19:55:40] <les_w> basically
[19:56:17] <etla> but realistically you would not want a segment (movement) that is shorter than one servo clock tick ?
[19:56:27] <etla> ofcourse there can be other blocks...
[19:57:55] <les_w> segment length can be as short as 2 servo cycles in emc.but if that is done, the cubic sub interpolation is effectively shut down
[19:58:16] <les_w> typical is to run a trajectory point every 10 servo cycles
[19:58:52] <les_w> so 4 millisecond for each segment plan
[19:59:49] <etla> how did you calculate that ?
[20:00:12] <les_w> 10 * 400 microseconds
[20:00:22] <les_w> right?
[20:00:48] <etla> right, but at only 2.5kHz servo update rate
[20:01:01] <fenn> * fenn falls sleep...
[20:01:10] <les_w> yes. So that is the fastest ...at least for me.
[20:02:45] <etla> ok, nice talking to you, I need to eat/watch TV now :), let us know on the emc-users list if there is high-performance servo hardware that many people are buying for use with emc. would be nice to have the same.
[20:03:38] <les_w> I will create a post about that.
[20:28:26] <alex_joni_away> * alex_joni_away really needs to try this:
http://www.zippyvideos.com/4005959911974226/colaandmentos/
[20:28:29] <alex_joni_away> alex_joni_away is now known as alex_joni
[20:31:05] <les_w> haha funny
[20:52:02] <k4ts> hello
[20:53:10] <alex_joni> les_w: any idea how PID gets done?
[20:53:29] <alex_joni> newratio = ratio + P * (ratioerror - lasterror + I * ratioerror + D
[20:53:29] <alex_joni> > *
[20:53:29] <alex_joni> >> (ratioerror - (lasterror * 2) + last2error));
[20:53:40] <alex_joni> how does that sound?
[20:57:42] <etla> ? define your variables.
[20:58:46] <les_w> well in the most general terms
[20:59:04] <les_w> the contol output is the sum of
[20:59:21] <les_w> the value of the error
[20:59:29] <alex_joni> I meant if the formula sounds right?.. it does sound ok to me
[20:59:54] <les_w> plus the value of the time derivative of the error
[21:00:27] <les_w> plus a value equal to the error magnitude time the time the error has existed
[21:00:57] <les_w> with a torque command the P is just like a restoring spring
[21:01:11] <les_w> the d is just like a damper
[21:01:38] <les_w> and the I is kind of like a restoring spring that gets stiffer with time
[21:02:46] <alex_joni> les_w: I know how a pid works
[21:03:51] <les_w> so force= P*error + D* derror/dt + I * integral (error* dt)
[21:06:36] <les_w> art is right...PID seems not to be his forte.
[21:08:20] <les_w> typically in a digital system d is differences of moving averages,. rather than an unrealizable ideal differentiator it is practically a band pass filter.
[21:09:24] <les_w> Similsrly the integral in I cannot be allowed to wind up forever, or the control will saturate. So it is a bandpass filter too. It does not go to dc.
[21:12:19] <les_w> If the pid feedback in in a real system with resonances there is a limit to the gains to keep enough phase margin to keep the system stable. With too much gain the control will alpply the correction out of phase...in the wrong direction.
[21:12:46] <alex_joni> so you still think emc has problems?
[21:13:05] <les_w> Feedforward does not suffer from that limitation since it is an open loop model of the machine dynamics.
[21:13:12] <alex_joni> seems the competition has even deeper ones
[21:13:38] <les_w> yeah many have problems.
[21:13:58] <alex_joni> so I think we should focus on the serious ones
[21:14:30] <les_w> I was imagining a machine with let's say a bit over 100 hz bandwidth
[21:14:32] <les_w> ok?
[21:14:47] <alex_joni> define bandwidth
[21:15:27] <les_w> that means commanded sinusoidal motions of 100 hz can get through the system and move the end affector.
[21:15:32] <alex_joni> les_w: more serious (= drivers, stability, functionality)
[21:16:34] <les_w> now, a circle is sines and cosine so such a machine could cut a circle 100 times a second
[21:16:43] <les_w> so lets do that in emc
[21:16:58] <les_w> with a g2 or g3
[21:17:29] <les_w> It will do it...the diameter it can cut depends on the max velocity.
[21:18:29] <les_w> Now let's approx that circle with g code of a number of points on the locus of the circle as cam systems often do
[21:18:43] <les_w> you need at least two points
[21:18:52] <les_w> but typivcally much more
[21:19:03] <alex_joni> say 4 for a very bad approx.
[21:19:08] <les_w> ok
[21:19:39] <les_w> We will try some thought HSM
[21:20:19] <les_w> at 100 hz, that needs 400 hz block rate
[21:20:45] <les_w> 2.5 millisecong period
[21:21:28] <les_w> typically emc cannot do that...it is more like the 4 millisecond I mentioned earlier.
[21:21:35] <les_w> What does it do?
[21:21:48] <les_w> It violently stutters about
[21:22:02] <les_w> because the velocity algo has broken down
[21:23:12] <les_w> now it was intended that emc slow down the circle till the points need more than 4 milliseconds each.
[21:23:23] <les_w> But it does not do this!
[21:24:03] <les_w> There was code that was supposed to do this....but it had a very bad math error that created those nasty accel spikes.
[21:24:05] <les_w> So
[21:24:24] <les_w> we #ifdefed it out
[21:25:04] <cradek> les_w: did you ever call about that?
[21:25:04] <les_w> the math error spikes were improved...mostly eliminated
[21:25:17] <les_w> but so was proper velocity adaptation
[21:25:48] <les_w> no I got busy from the suit visit.
[21:25:56] <les_w> Tx for reminding me
[21:26:04] <les_w> I will call right now!
[21:26:11] <les_w> bbiaw
[21:28:27] <les_w> he is away
[21:28:44] <les_w> didn't want to leave a message...better to catch him there
[21:28:52] <les_w> I'll try again
[21:28:58] <les_w> are they off tommorow?
[21:32:19] <les_w> So...with arbitrary curve and radius of curvature that must be decribed by segments...there are some serious problems.
[21:32:44] <les_w> It can be improved by upping the servo rate which ups the trajectory rate
[21:33:00] <les_w> or fixing the velocity adaptation
[21:33:07] <les_w> or even better...both.
[21:35:10] <Jymmm> Hmmmm. v-cutting aluminum
[21:35:21] <les_w> you?
[21:35:22] <Jymmm> err carving I mean
[21:35:27] <Jymmm> I'm thinking about it
[21:35:37] <les_w> i'm all eyes
[21:35:48] <Jymmm> Not sure about tooling though
[21:35:59] <Jymmm> nor rpms and feedrates
[21:36:36] <les_w> slow....not sure how much
[21:37:10] <Jymmm> I think my biggest issue would be cooling
[21:37:34] <Jymmm> squirt gun at 20 paces?!
[21:37:43] <les_w> air gun on the cutter at the very least
[21:38:17] <Jymmm> air gun or air exhaust from router motor?
[21:40:31] <les_w> air gun. I have a high pressure air nozzle on the head
[21:41:04] <les_w> blows chips packed in grooves to
[21:41:09] <les_w> too
[21:41:11] <Jymmm> ah ok
[21:41:33] <les_w> (also blows them away from the vacuum pickup)
[21:41:35] <Jymmm> carbide tipped v cutter (as used on wood)?
[21:41:52] <les_w> hmm
[21:41:57] <les_w> perhaps
[21:42:02] <les_w> stand back...
[21:42:08] <Jymmm> lol
[21:42:32] <Jymmm> stepdown 0.05"
[21:42:34] <Jymmm> =)
[21:42:51] <les_w> yeah
[21:43:30] <Jymmm> The thing I would LOVE to do is polish the aluminum to a mirror finish, but no buffer available =(
[22:14:26] <CIA-5> 03alex_joni * 10emc2/src/Makefile: added some docs
[22:16:59] <CIA-5> 03alex_joni * 10emc2/tcl/bin/ (emccalib.tcl emcdebug.tcl emclog.tcl): change the way emcsh gets run in tcl scripts, so that an installed version gets found
[22:27:37] <anonimasu> hi
[22:27:52] <alex_joni> 'lo
[22:27:59] <Jymmm> med well
[22:28:44] <Jymmm> ok... med rare
[22:43:22] <alex_joni> hrmm.. seems rayh is not around today :(
[22:43:24] <alex_joni> too bad
[23:02:52] <SWP_Away> alex_joni, he was on pretty late last night - he may be catching up on sleep
[23:02:56] <SWP_Away> SWP_Away is now known as SWPadnos
[23:03:09] <alex_joni> right.. so was I
[23:03:15] <SWPadnos> (though he did just post a message to emc-dev)
[23:03:21] <alex_joni> and.. so should I (catching up on sleep)
[23:03:26] <SWPadnos> heh - so you were (just a different time for night :) )
[23:03:30] <alex_joni> yeah.. seen that, that's why I am waiting a bit longer
[23:03:36] <alex_joni> what time you got over there?
[23:03:43] <SWPadnos> 17:26
[23:04:00] <alex_joni> don't think anyone is sleeping that late :D
[23:04:06] <alex_joni> although I did once ;)
[23:04:16] <SWPadnos> heh - he may just be "tired of it" :)
[23:04:32] <SWPadnos> he's an hour before me, so it's only 16:26 for him
[23:06:09] <SWPadnos> do you know if anyone has tried ADEOS on (a) Opteron machines, or (b) SMP machines?
[23:06:21] <SWPadnos> (or (c) SMP Opterons ;) )
[23:06:30] <alex_joni> don't think so
[23:06:41] <SWPadnos> hmmm - I'm not sure I want to be the first
[23:07:02] <Jymmm> SWPadnos <--- poultry
[23:07:02] <alex_joni> why not?
[23:07:15] <SWPadnos> because I'm poultry :)
[23:07:17] <alex_joni> yeah.. be carefull with that chicken fever lately
[23:07:31] <SWPadnos> I actually want the machine to continue to work :)
[23:08:09] <SWPadnos> I had tried installing BDI 4.30 under VMWare, but the SCSI problem bit me
[23:21:22] <Jymmm> SCSI?! That relic POS still being used ?!
[23:21:31] <Jymmm> * Jymmm snickers *
[23:21:48] <SWPadnos> no - VMWare just makes the guest *think* that SCSI is being used
[23:21:57] <SWPadnos> (it's actually an SATA drive)
[23:22:04] <Jymmm> ah, ok.
[23:23:33] <Jymmm> sounds like you need a updated driver
[23:23:42] <SWPadnos> it's kind of a bummer. you can set the CD-ROM emulation to SCSI or ATA/IDE (and point it at a physical device or an ISO image)
[23:24:05] <SWPadnos> but you can't set the hard disk hardware emulation to anything other than BusLogic or LSI Logic SCSI
[23:24:23] <SWPadnos> it's not a driver issue (except on the BDI install)
[23:24:36] <Jymmm> well, that sucks.
[23:24:39] <SWPadnos> I think there were some discussions about using BDI on SCSI systems
[23:25:18] <SWPadnos> yes, because I have a stomping fast machine that I'd like to use for EMC development, but I don't really need or want (and may not be able to use) an RT kernel on it
[23:25:24] <Jymmm> I can't think of any benefit to that, unless some scsi card comes with a parallel port =)
[23:25:37] <SWPadnos> SCSI is parallel, just a lot faster ;)
[23:25:50] <Jymmm> IEEE bitch!
[23:26:01] <SWPadnos> too expensive
[23:26:21] <Jymmm> I have scsi cards that have a floppy connector
[23:26:53] <SWPadnos> heh
[23:27:29] <SWPadnos> I have about 6 SCSI cards sitting around, everything from an ISA card that I got with my first CD burner, to a 3-channel RAID, to a U160 dual-channel card, etc.
[23:27:36] <SWPadnos> (no U320)
[23:28:04] <SWPadnos> and a tape drive I can't use, because the eBay seller was wrong, and I didn't research it far enough
[23:28:05] <Jymmm> I have a 8bit ISA scsi card. Top that! HA!
[23:28:40] <SWPadnos> yes - 8-bit ISA card, no BIOS, for the CD-RW (this is *the* original CD-RW, the Ricoh MP-6200S)
[23:29:18] <Jymmm> no bios?! what a POS... this one is completely bootable and has a floppy port too =)
[23:29:38] <SWPadnos> see - mine sucks more than yours :P
[23:29:49] <Jymmm> lol
[23:30:43] <SWPadnos> my new machine, however, doesn't suck much
[23:31:22] <SWPadnos> I finally managed to get something good (though I'll probably have to upgrade the CPUs to the latest stepping)
[23:31:39] <Jymmm> SWPadnos: Since you seem to have alot of things that suck, I'm thinking you either have a ShopVac or a Hooker on your christmas list this year.
[23:31:59] <SWPadnos> I have the shop-Vac :(
[23:32:23] <Jymmm> lol
[23:32:26] <SWPadnos> check out this motherboard:
http://www.supermicro.com/Aplus/motherboard/Opteron/nForce/H8DCE.cfm
[23:32:53] <Jymmm> oh no... I don't look at PC hardware... just gives me a headache anymore.
[23:33:05] <SWPadnos> heh
[23:33:13] <Jymmm> 20 years is enough for me.
[23:33:19] <SWPadnos> you're not a Dell fanboy are you? :)
[23:33:36] <Jymmm> Dell desktops are ok, laptops are POS.
[23:34:15] <SWPadnos> I just don't like the fact that they refuse to sell AMD and Linux systems well (they have both available from time to time, but never with the push behind Wintel)
[23:35:58] <Jymmm> Well, unless my system dies, I'm not buying a desktop unless the bitch can support 8GB ram, and 2MB+ of L2 cache
[23:36:13] <k4ts> night all
[23:36:16] <Jymmm> prefer 8mb L2 cache
[23:37:13] <SWPadnos> My system supports 32G ram, and the processors each have 1MB on-chip cache (per core, if I use dual-core)
[23:37:34] <anonimasu> hm
[23:37:46] <SWPadnos> plus 8 SATA channels (and the hot-swap bays to use them)
[23:38:28] <Jymmm> SWPadnos: See, only Xeon aand 7xx cpu's have the 2mb cache - bastards.
[23:38:44] <SWPadnos> 7xx?
[23:38:56] <anonimasu> hmm
[23:39:20] <Jymmm> SWPadnos: The Intel Pentium 4 700m series cpus (mobile)
[23:39:52] <SWPadnos> the Opterons work just fine with "only" 1M - I think it runs at full core speed, whereas the P4 runs at half speed (I think - it's been a while since I looked at that type of spec)
[23:39:58] <Jymmm> 1.8GHz 745M ~= P4 3.2GHz
[23:40:21] <SWPadnos> 1.8GHz Opteron ~= 3GHz P4 as well :)
[23:40:27] <Jymmm> SWPadnos: Get you paws on a cpu with 2M, it FUCKING SCREAMS!!!!
[23:41:16] <Jymmm> SWPadnos: Had one with 2GB ram, so turned off the swap file in XP.... ZERO delay
[23:41:23] <Jymmm> except hdd
[23:41:23] <SWPadnos> I have to use earplugs with dual opterons as well (from the screaming, not the fan noise :) )
[23:41:50] <SWPadnos> I haven't put any good benchmarks to this one, but it's a dual Opteron 244 with 4G
[23:42:20] <Jymmm> do you have anything that can utilize the dual cpu?
[23:42:29] <SWPadnos> (7800GT graphics, 300G SATA HD, SATA DVD+-...RW, and dual Dell 2405FPW monitors)
[23:42:29] <Jymmm> truely utilize it
[23:42:37] <SWPadnos> I'll be writing code that does
[23:42:48] <SWPadnos> massively parallel image processing
[23:43:01] <SWPadnos> (or code that could be massively parallel, if needed)
[23:43:07] <Jymmm> I guess that's cool. It does my no good in crypto work.
[23:43:12] <Jymmm> s/my/me/
[23:43:30] <SWPadnos> de-crypto (cracking) would be sped up, but crypto - maybe not
[23:43:54] <SWPadnos> though each block is usually independent, right? (depending on the algorithm)
[23:44:02] <Jymmm> not even brute force is effected THAT much.
[23:44:11] <SWPadnos> eff would care to differ
[23:44:21] <Jymmm> not to justify the cost of a dual cpu machine that is.
[23:44:26] <SWPadnos> nope
[23:44:28] <jepler> SWPadnos: what kind of image processing are you doing?
[23:45:02] <Jymmm> SWPadnos Well, dual cpu and distributed processing are totally two different things there =)
[23:45:22] <SWPadnos> rotation, color correction, and scaling on 100 images at a time (5MP each)
[23:45:33] <SWPadnos> also raw -> (other) conversion
[23:45:44] <jepler> astronomy?
[23:45:51] <Jymmm> jepler porn
[23:45:52] <SWPadnos> commercials :)
[23:45:56] <jepler> oh, video?
[23:45:58] <SWPadnos> yep
[23:46:02] <SWPadnos> sort of
[23:46:28] <Jymmm> SWPadnos 7800, is that ATI?
[23:46:34] <SWPadnos> ever seen "The Matrix"?
[23:46:37] <SWPadnos> no - NVidia
[23:46:49] <jepler> sure, I've seen it.
[23:46:51] <Jymmm> SWPadnos how is of DV ?
[23:46:57] <SWPadnos> ?
[23:46:57] <Jymmm> SWPadnos how is it for DV ?
[23:47:11] <SWPadnos> good question - I haven't gotten that far yet
[23:47:30] <Jymmm> what about 3D rendering? GL ?
[23:47:35] <SWPadnos> this project is a digital version of a Freeze camera - the thing used to do "Bullet Time"
[23:47:54] <SWPadnos> GL is *FAST*
[23:48:04] <SWPadnos> close to 12000 FPS in glxgears
[23:48:30] <Jymmm> lol.... I can only get 12FPS if it's 600x600
[23:48:34] <jepler> are you using the gl hardware in the image processing pipeline?
[23:48:52] <SWPadnos> I might - that's one reason I got a good video card
[23:49:05] <jepler> I get around 1300, and I thought this was a fast card.
[23:49:24] <jepler> seems to be a FX 5700LE, which I suppose is old by now
[23:49:42] <SWPadnos> the 7800GT (PCI Express) is a pretty fast card, as is the Opteron 244 (both of them)
[23:49:42] <Jymmm> jepler not as old as mine is =)
[23:50:22] <SWPadnos> What I really like is the dual 1920x1200 monitors on DVI - very nice looking
[23:56:12] <alex_joni> ok.. going to bed now
[23:56:14] <alex_joni> night guys
[23:56:17] <SWPadnos> noght
[23:56:20] <SWPadnos> night, even
[23:56:34] <alex_joni> nighty or noghty ..
[23:57:27] <LawrenceG> hi guys... I just got my servo motors from surplus center... they look very nice... wish I had bought more
[23:57:38] <SWPadnos> which ones?
[23:57:41] <anonimasu> I wish they didnt sell mine.
[23:57:44] <anonimasu> fsckers.
[23:58:12] <LawrenceG> I bought 3 of the 300w ones... they are about the size of double stack nema 34 steppers
[23:58:37] <cradek> I noticed they were all completely gone
[23:58:52] <SWPadnos> hmm. I had looked there (and even bought a couple of motors for experimentation), but nothing seemed big enough
[23:59:01] <SWPadnos> or "servo-ish" enough
[23:59:05] <LawrenceG> yea, I just checked.... they have quite a few 100w ones left but they are kind of small
[23:59:17] <SWPadnos> (expecially for a Bridgeport)
[23:59:22] <SWPadnos> especially
[23:59:49] <LawrenceG> very small for a bp.... would be good for a maxnc or taig or similar
