Back
[00:59:02] <robin_sz> meep?
[01:03:20] <robin_sz> so many meeps, so little time
[01:21:30] <cradek> hello robin
[01:25:30] <robin_sz> hi ...
[01:25:35] <robin_sz> still there?
[01:25:45] <cradek> yes
[01:26:01] <robin_sz> wow ... there is life out hthere :)
[01:26:09] <cradek> a little anyway
[01:26:31] <robin_sz> I had a tough day today ...
[01:26:42] <cradek> howso?
[01:26:55] <robin_sz> guy bought one of my plasma systems off a customer who went bust ...
[01:27:17] <robin_sz> technically, its secondhand, I have no real responisbility to him
[01:27:33] <cradek> he thinks differently?
[01:27:34] <robin_sz> anyway, stupidly, I said Id help him out and set it up ...
[01:27:55] <robin_sz> turns out he cant even do a simple cad drawing ...
[01:28:03] <cradek> uh-oh
[01:28:28] <robin_sz> ctrl-c / ctrl-v to copy files just blew his mind
[01:28:47] <cradek> doing support for those folks takes SO much time
[01:28:52] <robin_sz> hell, I even had to show him where the - sign was ...
[01:29:24] <robin_sz> * robin_sz nods
[01:29:27] <robin_sz> hes doomed
[01:30:00] <cradek> sounds like he needs to get someone to help him in person
[01:30:14] <robin_sz> sounds like hes unsuited to cnc technology
[01:30:18] <cradek> too bad you committed without knowing what you were getting into
[01:30:34] <cradek> I guess you could always duck out
[01:30:53] <robin_sz> nah, he'll get the machine set up, I'll give him two afternoon sessions of hand holding
[01:31:16] <robin_sz> after that ... well its phone support and "see the manual" ...
[01:31:42] <robin_sz> I do machine support, not compter literacy classes
[01:32:01] <cradek> yeah
[01:32:10] <cradek> he must understand that at some level
[01:32:14] <robin_sz> * robin_sz thnaks his lucky stars he stopped selling them to people
[01:33:37] <robin_sz> so .. what gives at your end?
[01:33:54] <cradek> still working on axis
[01:34:01] <cradek> jeff's going on vacation tomorrow morning so I'm on my own
[01:34:28] <cradek> I might try to get it fixed up and release beta2 before he gets back
[01:34:31] <cradek> depends how the testing goes
[01:34:39] <robin_sz> this is the back plotter?
[01:34:46] <cradek> the new gui
[01:34:47] <robin_sz> * robin_sz hasnt been keeping track
[01:34:50] <robin_sz> oh right
[01:34:52] <robin_sz> kewl
[01:34:54] <cradek> http://axis.unpy.net
[01:35:24] <cradek> got some good feedback after last weekend (released it Sat.) but I don't think most people will use it until it's on BDI
[01:36:53] <cradek> bizarre
[01:36:58] <cradek> I get a following error in nist.ngc
[01:37:02] <cradek> I *never* get following errors
[01:38:33] <robin_sz> looks kewl
[01:38:57] <cradek> thanks
[01:39:16] <robin_sz> is it fairly modular? eg easy to add custom tabs, different controls etc?
[01:39:17] <cradek> the beta works great, I'll help you get it running if you want to try it
[01:39:34] <cradek> well it's written in python so it's fairly easy to work on
[01:39:39] <cradek> adding stuff to the gui: not so easy
[01:40:05] <robin_sz> my next emc project will likely be for a press
[01:40:42] <robin_sz> * robin_sz nods
[01:41:40] <robin_sz> im likely to add various extra signals to emc, light guards on, pressure, bend angle, etc
[01:41:55] <cradek> cool
[01:42:03] <cradek> signals?
[01:42:06] <robin_sz> being able to hook them into GUI components in a snae way would be a big plus
[01:42:19] <robin_sz> signals => messages
[01:42:44] <cradek> sounds like the gui is the least of your problems
[01:42:51] <robin_sz> yeah,
[01:42:53] <robin_sz> saldy
[01:43:08] <cradek> well you have to start somewhere, and if my choices were tcl, X/athena, or python, I'd pick python
[01:43:16] <robin_sz> the biggest problem emc has is the hard coding of messages
[01:43:44] <robin_sz> I re-wrote tkemc in a modular form
[01:43:44] <cradek> and all the places you have to deal with each one explicitly
[01:43:49] <robin_sz> exactly
[01:43:56] <robin_sz> thats pure madness that is
[01:44:15] <robin_sz> which is basically the reason ive not done much with emc of late
[01:45:23] <robin_sz> I did start trying to re-write a lot of it to handle messages based on a single message type/class and the routing of the message based on some property of the message, not the actual static type
[01:45:32] <robin_sz> but it was too much for me ...
[01:46:00] <cradek> yeah that would be beyond me too
[01:46:18] <robin_sz> and sadly, I see no real future for emc until that is solved
[01:47:32] <robin_sz> I should be able to add a new spindle message, say, spindle_wibble_on
[01:47:48] <robin_sz> (assuming I have a spindle that can wibble)
[01:48:16] <robin_sz> adding a button to the GUI and a bit of code to the spindle module to handle that
[01:48:27] <robin_sz> shold not involve any other changes to the core of emc
[01:48:36] <cradek> that would sure be nice
[01:48:45] <robin_sz> thats the way it has to be ...
[01:49:15] <robin_sz> otherwise, it all fills up with weird messages no one needs, or you cant add messages you do need
[01:49:34] <robin_sz> like a pressbrake for example ...
[01:50:16] <robin_sz> I'll probably end up having to fork just to make up a pressbrak version
[01:50:26] <robin_sz> either that, or use existing messages
[01:50:36] <robin_sz> and try and remember what I used them for
[01:50:40] <cradek> there's plenty to choose from
[01:50:44] <robin_sz> too many
[01:50:57] <robin_sz> but it gets very messy, very quickly
[01:51:12] <robin_sz> and .. I'd like a neat GUI
[01:52:00] <robin_sz> so I can do stuff to show exactly waht the metal orientation should be going into the press, simulate it bending etc etc etc
[01:52:08] <robin_sz> you are GUI look swell neeat :)
[01:52:27] <cradek> ooh
[01:52:29] <cradek> that sounds neat
[01:52:40] <cradek> axis has all of GL at its command
[01:52:48] <robin_sz> right
[01:52:49] <cradek> so it's a "simple matter of programming" as a coworker used to say
[01:52:55] <robin_sz> heh
[01:53:06] <robin_sz> did you consider QT?
[01:54:16] <cradek> nope, I think it has a strange license
[01:54:36] <cradek> ugh
[01:54:41] <cradek> I just found a bug
[01:54:44] <robin_sz> that doesnt bother me much
[01:55:01] <cradek> oh it does me
[01:55:08] <cradek> you mean the bug, or the license?
[01:56:09] <cradek> helical arcs will cause following errors because the extra dimension isn't taken into account for the speed
[01:56:29] <robin_sz> the license
[01:58:01] <robin_sz> if it involves paying, then so be it .. if its the best solution
[01:58:17] <cradek> If I felt that way I doubt I would be using or working on emc
[01:58:36] <robin_sz> 'k
[01:58:54] <robin_sz> you are just in it for the 'hobby' side of it then?
[01:59:12] <cradek> yep
[01:59:23] <robin_sz> 'k
[01:59:35] <cradek> my real job is administering computers
[01:59:54] <robin_sz> I'd like to see it develop into to something useful for hobbyists and small businesses
[02:00:16] <cradek> I get the feeling most emc folks don't care about hobbyists
[02:00:28] <robin_sz> no, other way around I think
[02:00:33] <robin_sz> well, it complicated
[02:00:46] <cradek> I often hear things like "their machines are toys and I don't care about toy machines"
[02:00:55] <robin_sz> hmmm
[02:01:12] <robin_sz> theres a lot of disagreement in various places regarding the code
[02:01:22] <les_away> thunderstorm here...losing the dsl line
[02:01:43] <robin_sz> personally, I'd like to see an 'open source' emc core
[02:02:12] <robin_sz> with a published LGPL interface to say, allow developers to write closed source GUIs
[02:02:46] <robin_sz> so a manufacturer of say small mills could have there own funky GUI
[02:03:12] <robin_sz> but any modifications to the core of emc would be gpl, so have to be made source avaialble
[02:04:04] <robin_sz> but that aint gonna happen
[02:04:14] <cradek> that might be a good idea, but why should we let them do closed source guis? That work can benefit the project
[02:04:25] <cradek> they still get the benefit of not having to write the engine
[02:04:46] <cradek> both the company and the emc project benefit then
[02:05:29] <robin_sz> no company is going to pay to have a GUI for their product written if they have to give the code away so their competitor can duplicate their product
[02:06:07] <robin_sz> have you heard of a small and partially succesful webserver called 'Apache' ?
[02:06:07] <les_away> funding is a reason...I have been pushing rtlinux apps in general with a large corporation
[02:06:12] <les_away> tough sell
[02:06:51] <robin_sz> yep
[02:07:24] <cradek> anyone know why I can't assign a bug to myself in the tracker?
[02:08:10] <robin_sz> the reason Apache is sooooo succesful is because you can build commercial apps on the apache core ... and many many compaonies contribute to the apache project because of that, thats why it is probanbly the most succesful open source project ever
[02:09:09] <les_away> argh really close thunderstorm...must go away a while...later
[02:09:15] <cradek> goodnight
[02:09:21] <robin_sz> * robin_sz waves
[02:09:45] <cradek> I never worry about the weather bothering my computer or connection
[02:09:54] <robin_sz> me neiter
[02:12:07] <cradek> as someone who likes to use emc for free, what does it do for me if a business can profit from emc?
[02:12:18] <robin_sz> it improves emc for you
[02:15:11] <robin_sz> say a company decides to build some emc powered maachines
[02:15:18] <robin_sz> they need a custome GUI
[02:16:16] <robin_sz> and say the motion queue fixing for 'segmotqueue'
[02:16:22] <robin_sz> so they hire a programmer ...
[02:16:28] <robin_sz> he fixes the core
[02:16:36] <robin_sz> and writes their gui
[02:16:55] <cradek> ok, point taken
[02:17:02] <robin_sz> as it is ...
[02:17:10] <robin_sz> that cant happen in emc2
[02:17:27] <robin_sz> so thats why companies will just use emcq
[02:17:31] <robin_sz> emc1
[02:17:36] <robin_sz> fix what they need
[02:17:42] <robin_sz> write the gui they nees
[02:17:48] <robin_sz> and keep the whole lot closed
[02:18:07] <robin_sz> I thnk we're missing out on possibilities
[02:18:34] <cradek> well, that's not what sherline did
[02:18:50] <cradek> I can download all their mods (but they're not anything useful)
[02:19:01] <robin_sz> well ...
[02:19:08] <cradek> I think you should talk about this at the Sunday meeting
[02:19:14] <fenn> um how many companies write their own cnc programs anyway? (this isn't web hosting)
[02:19:16] <robin_sz> no point
[02:20:18] <robin_sz> fenn: almost all comapnies that use commercial CNC products write their own front ends
[02:20:36] <robin_sz> look at any modern cnc product
[02:20:43] <robin_sz> eg the Baldor 'MINT' stuff
[02:20:59] <robin_sz> Baldor provide the framework,
[02:21:12] <robin_sz> people develop their own front ends and apps
[02:21:21] <robin_sz> its a bit liek ...
[02:21:27] <robin_sz> well. say Python or Perl
[02:21:45] <robin_sz> the Perl/Python crews build the language
[02:21:58] <robin_sz> but devlopers use that to buld products
[02:22:11] <fenn> what license do the perl/python use?
[02:22:38] <robin_sz> Perl uses an 'artistic' license
[02:22:54] <robin_sz> duuno about python
[02:23:02] <robin_sz> the perl and python cores are GPL's
[02:23:11] <robin_sz> but not the stuff thats written in them
[02:23:21] <robin_sz> that could be any licence you choose
[02:23:37] <fenn> i'm not really sure about what counts as a "derivative work' or not
[02:23:48] <robin_sz> right
[02:24:17] <robin_sz> if some one took emc and cloned or modified the core .. that should be GPL, 100% certian
[02:24:20] <robin_sz> but ...
[02:25:14] <robin_sz> I think you should be able to build something with it thats not GPLd
[02:25:22] <robin_sz> like a GUI
[02:25:44] <robin_sz> that way companies can 'invest' a programmer
[02:25:57] <robin_sz> and still have something they can 'own' at the end of it
[02:26:12] <robin_sz> obviously, any GUI would have to be written form scratch
[02:26:31] <fenn> yeah but that should be really easy in emc2
[02:26:35] <robin_sz> no
[02:26:38] <robin_sz> impossible in emc2
[02:27:10] <fenn> because you have to use emc2 headers or something?
[02:27:18] <robin_sz> basically, yes
[02:28:18] <asdfqwega> * asdfqwega needs to read more on GPL and OSS
[02:28:43] <robin_sz> in my opinion that limits emc2 to the hobby market
[02:28:56] <robin_sz> and will limit any potential commercialinvolvment to emc1
[02:29:11] <robin_sz> and probably means we'll never see any of the results
[02:29:21] <fenn> can't you re-license code if all of th contributors agree to do so?
[02:29:28] <robin_sz> (like that job that was advertised on the list)
[02:29:39] <robin_sz> yes you *could*
[02:29:56] <asdfqwega> I imagine that would be like trying to herd cats...
[02:30:01] <robin_sz> yep
[02:30:01] <fenn> you'd only have to do that to the signals and threading code right?
[02:30:07] <robin_sz> right
[02:30:09] <fenn> (blindlyguessing at code structure)
[02:30:29] <robin_sz> basically, youd need just the signals interface to be LGPL
[02:30:48] <robin_sz> so you could send commands on and see signals come back when stuff hapaned
[02:31:13] <fenn> are there really that many developers?
[02:31:14] <robin_sz> but thats pur GPL and unlikely to chaneg from what I gather
[02:31:22] <robin_sz> mmm no
[02:32:01] <robin_sz> anyway ... I'll get moaned at for stirring soon :))
[02:32:32] <fenn> yeah its about bedtime
[02:32:53] <robin_sz> we ended up using Mach2 instead
[02:33:27] <robin_sz> its windows, but we write our own custom macros and screens for it ...
[02:33:41] <robin_sz> which was good.
[02:33:48] <robin_sz> but being windows it was bad
[02:34:08] <robin_sz> pseudo real time
[02:34:18] <robin_sz> (with emphasis on the pseudo)
[02:34:48] <fenn> i thought mach2 had some way of getting past the so-called "hardware abbstraction layer' and wasn't allthat bad
[02:35:02] <robin_sz> weell ... it almost does
[02:35:10] <fenn> compared to other windows controllers
[02:35:23] <robin_sz> but you still occasionally get no pulses for say 2 seconds
[02:35:33] <robin_sz> and then all the missing pulses turn up in a bunch
[02:35:36] <fenn> * fenn chokes
[02:35:49] <fenn> thats pretty bad
[02:35:52] <robin_sz> yep
[02:36:05] <robin_sz> and the motion can be bad in places
[02:36:39] <fenn> i find it hard to believe that people wlil pay that mch money for stuff that doesn't even work
[02:36:47] <robin_sz> its dirt cheap
[02:36:59] <robin_sz> liek ... 50 dollars or something
[02:37:02] <fenn> oh
[02:37:12] <robin_sz> infact
[02:37:22] <robin_sz> up to 1000 lines of code per program
[02:37:25] <robin_sz> its free
[02:37:49] <robin_sz> most of my gcode is sub 1000 lines anyway
[02:37:55] <robin_sz> so effectively its free
[02:38:27] <robin_sz> just a pity windows sucks so badly
[02:40:07] <fenn> well i'm off to bed
[02:40:16] <fenn> will be back in a month or two :)
[02:40:22] <robin_sz> heh
[02:40:25] <robin_sz> sleep well :)
[02:40:32] <robin_sz> * robin_sz goes off to bed too
[02:40:35] <fenn> fenn is now known as rumplestiltskin
[03:53:37] <dave-e> cradek you there
[04:00:25] <jepler> I can't quite figure out whether robin is in favor of GPL ("we'll never see any of the results [of commercial involvement in emc1]") or against it ("that limits emc2 to the hobby market").
[04:01:01] <dave-e> hard telling
[04:01:45] <dave-e> GPL gets interpeted different ways by different people
[04:02:39] <dave-e> jeff ... how much do you know about emc1
[04:02:48] <jepler> dave-e: the internals? Not much.
[04:03:02] <jepler> emc2 either for that matter
[04:03:30] <dave-e> well, it is my impression that even when there is no movement commanded the servo loop should sample the encoder registers every cycle
[04:04:03] <jepler> You're already getting a blank look from me.
[04:04:28] <dave-e> OK...maybe that is why no one has jumped on my post on the dev list.
[04:04:55] <jepler> I'm sorry I can't help you
[04:05:04] <dave-e> the system does commanded movement...but then the axis drifts but the display doesn't update.
[04:05:31] <dave-e> I keep hoping to get someone hooked by this so we can solve it.
[04:05:33] <jepler> are you displaying "commanded" or "actual"?
[04:05:42] <dave-e> actual
[04:06:28] <dave-e> relative...actual...world
[04:07:22] <dave-e> Maybe Fred or Will will answer.
[04:09:10] <dave-e> going to bail...see you tomorrow
[04:09:20] <jepler> see you .. probably not tomorrow
[14:11:46] <les> testing
[14:12:07] <les> hmm bad ethernet connection
[15:42:46] <cradek> hi paul, how's bdi-4 coming?
[15:43:50] <paul_c> trying another install on a 433MHz board with a paltry 64Meg of memory.
[15:44:43] <cradek> ouch
[15:46:08] <paul_c> Bombed out on me last night after running out of memory.
[15:46:48] <pemmet> hello!
[15:46:54] <paul_c> Afternoon pemmet
[15:47:04] <pemmet> this is the linux cnc ish right?
[15:47:12] <paul_c> Yup
[15:47:15] <pemmet> nice!
[15:47:47] <pemmet> i'm an engineering student... and i'm thinking about doing a EMC project for my graduating Major Project...
[15:48:03] <paul_c> The topic kinda serves as a good description of what goes on in here ;)
[15:48:43] <pemmet> hmm... i should definatly show up then...
[15:49:03] <pemmet> i do have one quick question, though.... if it's ok...
[15:49:22] <paul_c> We talk most days, so don't limit your self to Sundays
[15:49:48] <pemmet> do you think six months would be enough time to get a small cnc robot up and running?
[15:49:53] <pemmet> well not six months
[15:49:56] <pemmet> more like 4.5
[15:49:58] <paul_c> back in a bit - Have to hange a lightbulb
[15:50:03] <pemmet> heh
[15:50:03] <pemmet> mkay
[15:50:18] <cradek> pemmet: do you mean you want to build the robot?
[15:50:35] <pemmet> well i have access to some stand alone 3 axis robots...
[15:50:42] <pemmet> that i could use with a linux box
[15:50:47] <cradek> steppers?
[15:50:50] <pemmet> and I have an old computer at home..
[15:51:23] <pemmet> i'm not entirely sure what, the professor didn't give me all that information, but i could find out
[15:51:43] <pemmet> it was actualy his idea, but it sounded like a really cool idea... and I think it would be fun to do..
[15:51:51] <cradek> wait, let me try to read his mind
[15:51:56] <cradek> MMMMM MMMMMMMMMM MMMMMMMMM
[15:51:57] <pemmet> heh would you?
[15:52:00] <pemmet> thanks!
[15:52:02] <cradek> nope, didn't work
[15:52:10] <pemmet> well.. nice try though
[15:52:16] <cradek> I need more practice
[15:52:23] <pemmet> i'm sure you'll get it in time
[15:52:51] <cradek> at the most basic level, EMC puts out step and direction signals on a parallel port. You will have to figure out of you can get this to run your robot
[15:53:24] <pemmet> but anyway, over the next semester, i would get a linux box, a 3 axis robot (which the profesor said woudl be perfect) and maybe make it mill a small little something by the end of the year...
[15:53:24] <cradek> if you want it to be useful, you'll have to write inverse kinematics so the robot can move to a spot on an XY grid, for instance
[15:53:31] <pemmet> yea
[15:53:32] <pemmet> exactly
[15:53:43] <cradek> if you only want to impress your professor by making the robot wave around, you probably don't have to do that
[15:53:48] <pemmet> haha
[15:53:55] <pemmet> it's not that kind of robot, i dont think
[15:54:01] <pemmet> it can move x,y
[15:54:05] <pemmet> and then spindle feed z
[15:54:15] <cradek> so the axes are all orthogonal?
[15:54:19] <pemmet> so it'd be perfect for vertical milling on a small scale
[15:54:26] <cradek> ok
[15:54:34] <pemmet> but it's the concept that counts most
[15:54:35] <cradek> then it's child's play
[15:54:37] <pemmet> heh
[15:54:48] <pemmet> well i'm also planning to throw some of my own machining into the mix...
[15:54:49] <pemmet> but yea
[15:54:54] <pemmet> i guess that's the plan in a nutshell
[15:55:17] <pemmet> sounds by what you're saying, that i'm definatly not going to get in over my head...
[15:55:43] <cradek> probably not
[15:56:01] <pemmet> my ideal oucome would be a fully functional machine, and then i could acutaly create something with it to prove the point
[15:56:16] <pemmet> great!
[15:56:22] <cradek> if nothing else, you could give it a felt-tip pen and draw a picture
[15:56:31] <pemmet> haha i guess so...
[15:56:44] <cradek> much neater and quieter than cutting something
[15:56:46] <pemmet> i'm sure i'll just end up stealing some scrap aluminum, and making something fun
[15:56:48] <pemmet> eh
[15:56:53] <pemmet> we got loud machine shops for this anyway
[15:56:57] <pemmet> so nobody'd notice
[15:57:25] <pemmet> but as long as i can complete it over the next semester, i'd be all set!
[15:57:29] <cradek> yeah easy or hard on this project all comes down to the motors and drivers on the robot
[15:57:33] <paul_c> pemmet: Google for Puma and Scara robots
[15:57:50] <pemmet> mkay.. i'll also find out what kind of robots my prof has layin' around doing nothing
[15:58:07] <pemmet> because he said they were putting several small ones into storage.. and i could have one of them
[15:58:09] <paul_c> hexapods are cool
[15:58:12] <pemmet> (they'd be free)
[15:58:26] <paul_c> Which Uni are you at ??
[15:58:29] <pemmet> but anyway.. i got class right now...
[15:58:29] <pemmet> WPI
[15:58:33] <pemmet> worcester polytech
[15:58:42] <paul_c> UK ?
[15:58:51] <pemmet> Massachusettes
[15:58:54] <pemmet> US
[15:59:17] <paul_c> bummer... shipping on a bot would be wayyy pricey
[15:59:31] <pemmet> which is why i wanna get one that's already on capus
[16:00:20] <pemmet> but yea.. anyway, i got an industrial robotics class to head upto... thanks for all your help, i'm going to see if i can make this happen, and i'm sure i'll be in here plenty in the future as a result!
[16:00:43] <paul_c> If you know what type of machine it is, we can certainly help with the kinematics
[16:00:50] <pemmet> cool!
[16:00:54] <pemmet> that'd be a great help
[16:01:09] <pemmet> alright i'm leavin' for real, this time.. bye
[16:01:22] <paul_c> N.B. Scara, Puma, & hexapod are allready coded up.
[16:01:30] <cradek> paul_c: he said it's an orthogonal machine
[16:01:54] <paul_c> bog standard XYZ is trivial.
[16:02:22] <paul_c> was just giving him some ideas to play with.
[16:03:02] <cradek> so if I did an axis release, could it still go on bdi-4, or are you way past that stage?
[16:03:38] <paul_c> can rebuild at any time - Still have loads of work to before it is ready for public release.
[16:03:41] <cradek> I'm not ready yet, I just am wondering if I should bother trying to get it wrapped up
[16:03:53] <cradek> ok, I will keep it in mind
[16:04:00] <cradek> what did jepler end up giving you? was it a deb?
[16:04:30] <cradek> could you build it from source?
[16:04:38] <paul_c> I'm hoping Ray & Co will do loads of testing over the next three weeks, and we can aim for a mid Jan release.
[16:05:00] <cradek> ok, great, we should have 1.0 easily ready by then no matter what
[16:05:01] <paul_c> Jepler sent me the Debian rules and I built it here.
[16:05:17] <cradek> so you built a deb from the source?
[16:05:23] <paul_c> Needed to do some tweeks for the 2.6.9 emc build.
[18:09:55] <les_away> dsl keeps droppin out today
[20:28:36] <CIA-3> 03Zathras 07BDI build system * 10Babylon Cluster/04-slide.png: File changed. New revision:1.2
[21:04:27] <paul_c> Yo Mike.
[21:04:55] <paul_c> How's it hanging ?
[21:06:39] <tbl> good
[21:06:53] <tbl> hey sherline was telling me they were having trouble in fetching an iso from you
[21:07:29] <tbl> if you'd like i can set you up with an ftp account or something
[21:07:31] <tbl> so you can dump it
[21:08:24] <paul_c> uploaded it last night.
[21:08:36] <tbl> oh good
[21:08:53] <tbl> i talked to joe this morning and he said that he thought matt might be having trouble getting or something
[21:08:56] <tbl> not sure what that's about
[21:09:17] <paul_c> Do you have access to kane ?
[21:09:22] <tbl> yes
[21:10:18] <paul_c> cane you check the default dir for sherline...
[21:10:56] <tbl> i don't have root
[21:11:04] <tbl> what do you want me to check?
[21:11:26] <paul_c> that bdi*.iso is in the home dir
[21:11:35] <tbl> in ~ ?
[21:11:44] <paul_c> yes
[21:11:49] <tbl> can't
[21:11:54] <tbl> can you ftp in?
[21:12:12] <tbl> that dir is 700
[21:14:22] <tbl> what's the name of the file exactly?
[21:16:57] <paul_c> currently ftp'd in.... Can seebdi-4.02.iso clearly.
[21:18:17] <Imperator_> Imperator_ is now known as Imperator_away
[21:20:55] <paul_c> -rw-rw-r-- 1 sherline webusers 633100288 Dec 10 07:09 bdi-4.02.iso
[21:31:29] <paul_c> tbl seems to have gone very quiet...
[23:00:36] <paul_c> Evening SpeedBump
[23:00:54] <SpeedBump> * SpeedBump waves
[23:05:33] <paul_c> SpeedBump: using EMC ?
[23:18:36] <SpeedBump> not yet. I'm working for a custom machine tool manufacturer and we are considering the use of EMC (or EMC2) as a control system for some of our systems.
[23:19:30] <paul_c> emc2 is a long way from being ready for serious use.
[23:19:32] <SpeedBump> I'm having some difficulty getting RTAI/fusion working on my system at the moment, but I'll eventually figure it out (some problem with hyperthreading/SMP I think)
[23:19:56] <paul_c> You need a BDI install
[23:21:26] <SpeedBump> ok I'll bite: what is a BDI install (or RTAI I assume)?
[23:21:44] <SpeedBump> ah...brain dead install...got it
[23:22:12] <paul_c> http://www.linuxcnc.org/bdi/
[23:22:39] <paul_c> the next release uses 2.6.9 and RTAI with all the trimmings
[23:24:19] <SpeedBump> I'm also looking into ways of generating higher step rates using dedicated CPU's in a multiprocessor system...that's sort of why I hadn't really looked at the brain dead install (I'd seen it mentioned before)
[23:25:37] <paul_c> lock freqmod to CPU2, and use CPU1 for everything else...
[23:26:42] <SpeedBump> do you believe that will reliably generate step rates exceeding 400kHz?
[23:27:42] <paul_c> 1.25uSec base period...
[23:27:57] <paul_c> Using a standard parport ?
[23:28:01] <SpeedBump> yes.
[23:28:18] <paul_c> not a cat in hells chance.
[23:28:23] <SpeedBump> * SpeedBump grins
[23:28:45] <paul_c> your average parport write takes one to two uSecs
[23:28:50] <SpeedBump> that's what I was given to believe from my research
[23:29:46] <paul_c> 100KHz might be attainable, but I wouldn't bet on it being stable.
[23:31:19] <paul_c> why do you need 400KHz step rates ?
[23:31:36] <SpeedBump> I've reliably gotten 500kHz out of this laptop just locking a processor and using the TSC to time output. nearly 70% of the time is inside the kernel's parallel port routines...but that's plenty of time left over for trajectory updates per cycle...
[23:33:24] <SpeedBump> because I have to sell the idea up the chain of command, and I know it will be a question. our current CNC can easilly outperform even that, but that number is sufficiently beyond our typical needs that it will be enough.
[23:33:37] <paul_c> didn't think the kernel's parport routines were realtime thread safe.... Or do you mean inb() & outb() calls ?
[23:33:52] <SpeedBump> outb()
[23:34:12] <paul_c> That's a standard C function.
[23:34:33] <SpeedBump> though I haven't seen any problems just using the parport routines...and they are thread and SMP safe
[23:34:56] <SpeedBump> you can lock the port for exclusive access...it complains alot but it will do it
[23:35:27] <paul_c> outb() gets replaced at compile time with trivial assembler code.
[23:35:37] <SpeedBump> * SpeedBump nods
[23:35:48] <SpeedBump> I've tried it both ways for timing comparison...
[23:36:12] <SpeedBump> the overhead of using the parport routines is negligable given the massive delays incurred by doing port access
[23:37:22] <SpeedBump> and I'm not doing anything with realtime stuff yet...I'm just breaking out a really big hammer and stealing with processor from the scheduler to run my tests
[23:37:46] <paul_c> If you are not worried with code portability, you could macro outb() to the simplest asm call.
[23:38:55] <paul_c> Use a PCI IO card, and save a bit more time.
[23:39:01] <SpeedBump> yeah, but it's not worth it...as I said, just the outb assembly instruction has a fixed overhead (from what I can tell). The overhead of going through the parport subsystem is unimportant by comparison
[23:39:05] <SpeedBump> * SpeedBump nods
[23:40:29] <SpeedBump> I don't know that much about the PCI protocol...when I started my investigations I was under the impression that PCI used a negotiated protocol for bus control, implying relatively long delays for bus acquisition
[23:41:00] <paul_c> the PCI bus is message based, yes.
[23:41:29] <SpeedBump> I've learned that is not the case, but noone has yet given me verifiable numbers on response times, so I am going with the worst case for now.
[23:41:36] <paul_c> but a 33MHz, the contention times are fairly low.
[23:41:41] <SpeedBump> * SpeedBump nods
[23:42:06] <paul_c> depending on what else is on the PCI bus.
[23:42:31] <SpeedBump> I've done some with with PCI video capture cards and run into the bus latency problem with onboard data buffers that would overflow under heavy loads
[23:44:10] <paul_c> To be honest, if you want reliable high speed pulse rates, an FPGA is the way to go.
[23:44:19] <SpeedBump> * SpeedBump nods
[23:45:01] <paul_c> bung it on a PCI card and open source the driver code...
[23:45:14] <SpeedBump> yeah, that's a slightly harder sell (custom hardware development) but I might go that way. I've used motion cards from Motion Engineering Inc that were FPGA based
[23:45:18] <paul_c> the code is of little value without the hardware.
[23:46:37] <SpeedBump> having custom hardware does make the investment of business time in the idea a little less scary to those here who don't really "get" the GPL
[23:48:38] <paul_c> and it also removes you a little from the problems of using commodity motherboards...
[23:48:47] <SpeedBump> out of curiosity, are there any libraries or frontends that handle kerf offset calculations? I've got some ideas on how to do it, but it is one more thing we have to develop if so
[23:49:35] <paul_c> You mean tool offsets ?
[23:49:39] <SpeedBump> yes
[23:49:58] <paul_c> EMC handles that internally.
[23:50:36] <SpeedBump> really...interesting. Is it documented anywhere? I'd need to evaluate its behaviour in corner cases (no pun intended)
[23:51:32] <paul_c> G40,41,42 - Some notes in the Handbook...
[23:52:49] <SpeedBump> right, but the exact behaviour of G41&42 aren't really specifically defained anywhere...I'd need to verify that the algorithm behaves properly in cases where the offset paths overlap
[23:53:42] <SpeedBump> many NC's do this in a variety of wrong ways :)
[23:53:57] <paul_c> not sure I follow "where the offset paths overlap"
[23:54:24] <SpeedBump> difficult to describe a graphic...
[23:55:17] <SpeedBump> imagine a 1" circle with a .25" slot going into it (looks like a lollipop)
[23:55:43] <SpeedBump> If I offset to the interior with a tool width > .25" what happens to the slot?
[23:55:53] <paul_c> and a 6mm offset..
[23:56:44] <paul_c> I would say that that kind of error should have been picked up at the CAM stage.
[23:57:51] <SpeedBump> well...it isn't really an error...the control *should* provide a warning to the operator and cut the circle without the entry slot (at least in most of our cases)
[23:58:13] <SpeedBump> for example, when a waterjet is cutting the kerf width grows over time...
[23:58:32] <SpeedBump> what you could cut when you start you can't necessarilly cut by the end of your run...
[23:59:09] <SpeedBump> it's complex. this is one of the reasons we like the idea of PC based CNC...we get more flexibility in handling these conflicts
[23:59:20] <paul_c> Ooo... Adaptive tool offset...
[23:59:25] <SpeedBump> * SpeedBump nods