Back
[00:00:59] <jmkasunich> the mazak is true servo, right ray?
[00:01:14] <rayh> Yes it is.
[00:01:28] <jmkasunich> what kind of drives and servo card are you planning to use?
[00:01:42] <rayh> All the way servo. Like 1.5-2kw dc axis drives.
[00:02:04] <jmkasunich> nice little motors
[00:02:05] <rayh> Encoders are already in place.
[00:02:52] <rayh> Yes I'm staying through the 26'th.
[00:03:14] <rayh> I suspect that there will be a lot of cleanup on the retrofit over the weekend.
[00:03:29] <jmkasunich> the machine is dave E's?
[00:04:39] <rayh> No Roland owns two of them.
[00:04:49] <rayh> One is an 81 the other an 86
[00:04:56] <jmkasunich> ok, I must have gotten my mill mixed up
[00:05:06] <rayh> He has a mazak service guy coming in tomorrrow.
[00:05:18] <rayh> to tell him if they are any good at all.
[00:05:31] <rayh> both will move some but not under full auto program control.
[00:05:42] <jmkasunich> what if he says "yes, you should keep running the exsiting controls" ;-)
[00:06:29] <SWPadnos> then you say "Thank You", and retrofit anyway :)
[00:06:35] <rayh> Roland promised one for us.
[00:06:55] <jmkasunich> send mazak guy home with a control stuffed in his pocked (or elsewhere)
[00:07:53] <rayh> The mazak guy is going to be there for the week. Don't know if he wants to work with us or the other guys.
[00:08:07] <jmkasunich> that will be "interesting"
[00:09:45] <rayh> Think EMC2 is up to the task.
[00:11:05] <jmkasunich> you bet
[00:26:07] <paul_c> rayh: You should have those CDs by then.
[01:00:00] <rayh> Hi Paul\
[01:00:23] <rayh> Just upgraded 2.20 with the disks you gave me at fest.
[01:00:49] <paul_c> * paul_c is wasting too much time on that damned G92
[01:00:58] <rayh> I did some experimentation with tk8.5 and the display is much better.
[01:01:09] <rayh> Me too.
[01:01:19] <rayh> I'm just kinda ignoring the guy.
[01:01:30] <jmkasunich> I probably should have
[01:01:56] <paul_c> just to show how often I use mini....
[01:01:59] <rayh> He is a very difficult person to change once he gets a notion
[01:02:17] <zwisk> hehe... and we aren't ? (I'll speak for myself :) )
[01:02:33] <paul_c> where is the "ahead" function for restarting in the middle of a program ?
[01:02:37] <rayh> Oh I'm always up for something new!
[01:02:53] <rayh> In mini?
[01:02:57] <paul_c> yes
[01:03:11] <rayh> They appear when you hit abort or estop.
[01:03:29] <rayh> but you can show them under the view menu -- I think.
[01:03:49] <rayh> shows how often i use mini...
[01:12:28] <paul_c> nope - No restart popup or in
[01:13:23] <rayh> you in auto mode?
[01:13:49] <paul_c> yes
[01:14:04] <rayh> Should be a set of buttons to the right of the g-code text display.
[01:14:32] <paul_c> gah... need to expand the window.
[01:15:21] <rayh> Oh. They are lower space priority than most of the display.
[01:16:49] <rayh> That get's ugly in a big hurry when you reduce the size.
[01:17:04] <rayh> Size is sorta autoset during startup.
[01:46:21] <paul_c> G92 does what it says on the tin - The only quible I have is the call to G92.2 on an M2 or M30 - It should be G92.1 in my opinion.
[01:47:16] <paul_c> Yes, there was a minor bug where the offsets were not being zero'd correctly on Y & Z....
[01:49:45] <paul_c> * paul_c goes to bed.
[01:53:14] <weyland> I'd like to publicly thank John Kasunich for all his hard work and time helping me get my machine running smoothly and better than it has EVER run before~! John, you are a credit to yourself, your family, and the EMC community. Thank you~!
[01:54:02] <jmkasunich> * jmkasunich blushes
[01:54:18] <weyland> lol
[01:54:37] <weyland> ran a quickee program just before I left
[01:54:45] <weyland> will post a pic in a minute
[01:57:41] <weyland> pic here -
http://solutionsmachining.com/images/cnc_mill/emc2.jpg
[01:57:49] <weyland> took all of about 45 seconds
[01:57:57] <weyland> times four
[01:58:09] <jmkasunich> oops... bandwidth limit exceeded
[01:58:24] <jmkasunich> (I guess I shouldn't have browsed your site this afternoon)
[01:58:38] <weyland> really? holy sh|t... brb
[02:00:09] <rayh> If you need we could put the pic up on linuxcnc.org/Dropbox
[02:00:56] <weyland> done, its up
[02:01:04] <weyland> feel free to copy it to there, too
[02:01:44] <weyland> I'll have some "hard parts" (functional) stuff in the next few days that should be a nice addition to anyone's EMC album
[02:02:30] <jmkasunich> nice to see the parts... thanks Weyland
[02:03:07] <weyland> Actually, if you go to the "store", you'll see a really nice example of one
[02:03:20] <weyland> it's the mag cover
[02:03:42] <rayh> Then you can report your findings to the list and make a wiki link.
[02:04:09] <weyland> I'll be happy to, Ray
[02:04:18] <rayh> Great.
[02:04:24] <weyland> don't know how to do the wiki thing, but whatever I can do to help
[02:04:35] <rayh> I'll catch you guys later.
[02:04:43] <jmkasunich> goodnight ray
[02:05:04] <rayh> Good to see thing moving forward.
[02:05:21] <Phydbleep> * Phydbleep sends a wheelie-bin chasing asdf-qwee.
[02:07:42] <weyland> gotta get baq to work
[02:07:48] <weyland> Thanks again, John
[02:07:55] <jmkasunich> you're welcome
[02:08:01] <weyland> 'nite
[02:08:07] <jmkasunich> goodnight
[02:17:31] <zwisk> so, jmk, how best can I help the cause?
[02:18:22] <jmkasunich> good question
[02:18:35] <jmkasunich> the short term need is hal drivers
[02:18:40] <zwisk> ok...
[02:18:54] <zwisk> the problem with drivers is that without the hardware, they're hard to test.
[02:18:59] <jmkasunich> longer term I want to continue what you started with the refactor
[02:19:04] <jmkasunich> true
[02:19:30] <jmkasunich> somewhere between long and short term is some other changes to HAL, things that aren't as disruptive as the refactor
[02:19:38] <jmkasunich> for example - locking
[02:19:59] <zwisk> The refactor is disruptive. What are your thoughts on locking? (Did we speak of this before? Time to dig out notes...)
[02:20:11] <jmkasunich> locking is new
[02:20:20] <jmkasunich> came out of an IRC discussion this weekend
[02:20:22] <zwisk> We spoke of having the kernel manage everything, which is a form of defactor locking.
[02:20:31] <zwisk> s/defactor/defacto/
[02:21:03] <jmkasunich> right now, you can have a complete hal/emc system running, and do "rmmod stpgen" right in the middle
[02:21:20] <zwisk> ahh... that kind of locking.
[02:21:36] <jmkasunich> hal_lib ensures that stepgen is removed cleanly (no hanging tasks, no crashes, etc) but the emc machine certainly won't work right afterwards
[02:21:36] <zwisk> You want things to shut down in a graceful way at a graceful point in time rather than just being slammed.
[02:21:55] <jmkasunich> likewise, you can unlink signals, add functions to threads, etc
[02:22:04] <jmkasunich> locking would be a flag (maybe two) in hal shmem
[02:22:20] <jmkasunich> hal_lib would refuse to do things if the flag is set
[02:22:28] <jmkasunich> one flag would lock everything
[02:22:48] <jmkasunich> the other might lock everything except setp, to allow for tuning
[02:23:23] <jmkasunich> flags would be set/cleared by "halcmd lock", "halcmd unlock", perhaps with a qualifier to identify which flag
[02:23:55] <zwisk> makes good sense.
[02:24:16] <zwisk> unfortunately, a coworker just came by, so I have to attend to work things... more later, I hope...
[02:24:39] <jmkasunich> I'll be here for a little while... or you an email and we can go into more detail
[02:25:02] <zwisk> Email is probably best. We'll see what happens though :)
[03:07:43] <A-L-P-H-A> SWPadnos, turbocnc guys are asking for a external jogger for CNC machines.
[03:07:50] <A-L-P-H-A> * A-L-P-H-A pokes SWPadnos
[03:22:15] <SWPadnos> ouch
[03:23:51] <jmkasunich> anybody here know what happens with a signal (say SIGINT) interrupts a fgets() call?
[03:26:08] <SWPadnos> the signal handler should get called, and then the behavior depends on what it does
[03:26:24] <SWPadnos> if it just returns, then the fgets shouldn't be affected
[03:26:30] <jmkasunich> in this case, all it does is sets a global flag and returns
[03:26:46] <jmkasunich> that's the problem... prog is sitting in fgets waiting for input
[03:26:53] <SWPadnos> ah
[03:26:57] <jmkasunich> SIGINT wants to end the prog
[03:27:18] <jmkasunich> the handler sets a flag that will break it out of it's line handling loo
[03:27:20] <jmkasunich> loop
[03:27:22] <SWPadnos> waiting at a prompt?
[03:27:26] <jmkasunich> yeah
[03:27:37] <jmkasunich> halcmd is the prog...
[03:27:39] <SWPadnos> you might be able to use select or poll for that
[03:27:55] <jmkasunich> it has provisions to get it's input from stdin, but usually takes it from a file
[03:28:04] <jmkasunich> the stdin case is the one I'm dealing with now
[03:28:20] <SWPadnos> right - I'm not sure if select works on console, but I
[03:28:28] <SWPadnos> I'm not sure why it wouldn't
[03:28:32] <jmkasunich> when getting from a file, fgets always returns quickly, either due to having a line, or eof
[03:29:04] <A-L-P-H-A> SWPadnos, what's your drive train generator do again?
[03:29:18] <SWPadnos> yes - you should be able to do a select on stdin with a timeout
[03:29:31] <SWPadnos> it generates a stream of pulses at a rate set by the user.
[03:29:49] <SWPadnos> it also has a serial port, so it could do just about anything under program control as well
[03:29:54] <SWPadnos> (computer program, that is)
[03:29:54] <A-L-P-H-A> SWPadnos, so not really that useful for a manual jogger for a CNC machine? or yes?
[03:30:06] <SWPadnos> not really, in its present form
[03:30:45] <SWPadnos> The software could be rewritten to just act as an encoder counter, and upload counts to the cmputer
[03:36:03] <weyland> baq briefly... wanted to ask a quest about Ray's request of me
[03:36:21] <jmkasunich> ray's gone, but shoot
[03:36:47] <weyland> he wants me to post an update, right? I'm kewl with that, but how? on the list?
[03:36:52] <weyland> as an email?
[03:37:09] <jmkasunich> I'm not sure what he had in mind
[03:37:24] <jmkasunich> one thing would be to link from the wiki to your work
[03:37:29] <weyland> what's his addy? is it public?
[03:38:36] <weyland> okay, got it, I'll write him
[03:38:53] <SWPadnos> I think he was suggesting a wiki page
[03:38:59] <weyland> also, (I'll ask him too) how would I do the wiki thing?
[03:39:02] <weyland> ha
[03:39:05] <dan_falck> hi john
[03:39:06] <weyland> timing
[03:39:17] <jmkasunich> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Case_Studies
[03:39:24] <jmkasunich> you might want to add a link from there
[03:39:32] <jmkasunich> hi dan
[03:39:40] <weyland> okay, I'll go read that
[03:39:57] <SWPadnos> If you go to the wiki, select preferences (a link at the bottom of the page), give yourself a username, and enter the super-secret admin password: emc
[03:40:00] <dan_falck> I want put in a user request to delete G92 from EMC
[03:40:18] <dan_falck> that will piss him off
[03:40:18] <jmkasunich> send it to the list... we need more controversy
[03:40:18] <weyland> hahahaha
[03:40:22] <cradek> isn't that a little silly?
[03:40:27] <SWPadnos> he did :)
[03:40:28] <cradek> oh, as a joke, I get it
[03:41:06] <SWPadnos> then you can edit the pages - if you add a link like SolutionsMachining, (capitalized words stuck together), then a ? link will show up, and that will be a new page (click on the link, then edit this page)
[03:41:17] <cradek> I still think my advice (using home without switches) is the best
[03:41:33] <cradek> it sets the axis to 0, exactly what you want
[03:41:43] <SWPadnos> Using a set of toolholders with a datum plane would be even better
[03:42:04] <cradek> well, I have toolholders and I set the lengths all the same
[03:42:18] <cradek> but I still "home" at the top of the material
[03:42:19] <SWPadnos> He's looking for a way of making the offsets semi-automatic
[03:42:35] <SWPadnos> He must have people running the machine for him, and he wants to make it easy for them
[03:42:43] <SWPadnos> (ie - harder to screw up)
[03:43:15] <cradek> emc is hard to use if you have to reset Z at a tool change. You just about have to use separate programs for each tool.
[03:43:30] <cradek> my maxnc control software would let you pause, jog around and reset Z, then continue
[03:43:31] <SWPadnos> that's his gripe (I think)
[03:43:32] <jmkasunich> I dunno... I'm done with that discussion
[03:43:35] <cradek> it's the ONLY thing it got right
[03:44:08] <jmkasunich> blast... select is not a nice lightweight way to do things
[03:44:24] <SWPadnos> easy enough to use, but not really lightweight, no
[03:44:26] <cradek> jmkasunich: what are you using select for?
[03:44:36] <jmkasunich> I'm not (yet)
[03:44:45] <jmkasunich> halcmd can accept input from a file or from stdin
[03:44:54] <SWPadnos> my suggetion for an fgets that would stop looking for input (from stdin)
[03:44:56] <jmkasunich> today it uses fgets() to read a line
[03:45:12] <jmkasunich> problem: somebody hits ctrl-C while it is waiting for input
[03:45:25] <SWPadnos> any boneheadedness in the idea is mine :)
[03:45:28] <cradek> why is that a problem?
[03:45:29] <jmkasunich> I need to capture the ctrl-C so it will call hal_exit() and free shared memory
[03:45:36] <cradek> ohhh
[03:46:00] <jmkasunich> first attempt - capture the signal, set a flag that will drop out of the line processing loop
[03:46:12] <jmkasunich> but that won't happen until fgets() returns
[03:46:26] <jmkasunich> not a prob when reading from a file... but from stdin, it may take a long time
[03:47:13] <jmkasunich> I _could just call hal_exit() and _exit() from the signal handler, and never return to the main prog at all
[03:47:29] <jmkasunich> but the main prog may have been signaled while it was making a hal call and had the hal mutex
[03:47:41] <jmkasunich> better to let the hal call complete and drop out of the loop at the end
[03:47:53] <cradek> I hate to say it, but the traditional unix way to do this is with setjmp/longjmp
[03:48:30] <SWPadnos> better to use signal(), I'd say
[03:48:53] <SWPadnos> I assume you did try that, jmk?
[03:49:05] <jmkasunich> used signal to capture the ctrl-C, yes
[03:49:11] <cradek> SWPadnos: the problem is: what does the signal handler call?
[03:49:17] <jmkasunich> the sighandler sets a flag to end the loop
[03:49:23] <jmkasunich> then returns
[03:49:27] <SWPadnos> signal(SIGINT, myHandler) will call the handler
[03:49:37] <cradek> but, you're still stuck in the fgets at signal return?
[03:49:40] <jmkasunich> if I'm anywhere in the main loop except the fgets, it works
[03:49:41] <SWPadnos> the handler can just do the hal_exit, then exit(0)
[03:49:50] <jmkasunich> but if I'm in the fgets...
[03:50:08] <jmkasunich> cradek: yes
[03:50:31] <cradek> I think the two answers are: don't return, or use longjmp
[03:50:44] <cradek> but IANAP
[03:50:45] <SWPadnos> that brings up a larger point about interruptible / re-entrant code
[03:51:16] <SWPadnos> can 2 copies of halcmd be run safely at the same time?
[03:51:27] <weyland> WOW~! I was just reading... what's this about "AXIS"?
[03:51:30] <cradek> SWPadnos: huh? It's not multithreaded
[03:51:32] <jmkasunich> thats one of the things I'm working on
[03:51:42] <SWPadnos> a shell script can launch many simultaneous instances
[03:51:43] <weyland> ...really... do tell...
[03:51:46] <jmkasunich> all access to the hal shared memory is protected by a mutex
[03:51:50] <cradek> weyland: ??
[03:51:54] <SWPadnos> not AXIS - halcmd :)
[03:52:00] <jmkasunich> so in theory you can launch many halcmds
[03:52:07] <weyland> oops
[03:52:11] <cradek> weyland:
http://axis.unpy.net
[03:52:13] <weyland> sorry to butt in
[03:52:18] <cradek> no problem
[03:52:18] <weyland> just went there
[03:52:24] <cradek> I always like talking about it
[03:52:31] <weyland> is that your work?
[03:52:32] <jmkasunich> until about 20 mins ago, they all used the same module name, so when additional ones called hal_init(), it would fail
[03:52:43] <cradek> I'm half at fault for it, yes
[03:52:48] <jmkasunich> just fixed that (appended the process id, same trick I did to allow multiple halmeters)
[03:52:51] <SWPadnos> yes - halcmd frizzle ; halcmd frozzzle ; halcmd bebop would be capable of running those simultaeously
[03:53:02] <cradek> as different processes!
[03:53:21] <weyland> Boys, I've got to say that in the year and a half or so that I was away, you've REALLY brought EMC(2) a LONG LONG way
[03:53:27] <jmkasunich> so now I can have multple halcmd processes (for example in differnet shells)
[03:53:58] <SWPadnos> yes - do they each have their own hal mutex, or is that system-wide??
[03:54:11] <jmkasunich> and even if you issue say a "setp" command at the exact same instant in both, only one at a time gets to mess around in the shmem
[03:54:22] <SWPadnos> OK
[03:54:34] <jmkasunich> one mutex for any access to hal shmem that involved the data structures
[03:54:56] <SWPadnos> well - consider this - if the mutex is held, then the main loop is probably not waiting in an fgets
[03:55:05] <jmkasunich> normal pin-signal-pin connections don't mess with the data structs and are totally asynchronous
[03:55:21] <SWPadnos> unless it's held by another process - crap
[03:56:10] <SWPadnos> the HAL modules don't "depend" on one another (in the modprobe sense), do they?
[03:56:30] <jmkasunich> no - they all depend on hal_lib and rtapi, but not on each other
[03:56:33] <SWPadnos> (ie, stepgen doesn't depend on parport, because it could be attached to sensoray)
[03:56:59] <jmkasunich> in fact you can rmmod a stepgen even if it is connected to other things
[03:57:11] <jmkasunich> that can be a feature or a bug depending on your perspective
[03:57:23] <weyland> cradek: was reading - has the bug been worked out for using AXIS with EMC2?
[03:57:27] <SWPadnos> OK, and doing a pin-signal-pin connection consists of getting the address of one variable, and storing that pointer into another location (in a separate module, possibly)
[03:57:39] <cradek> weyland: which bug?
[03:57:54] <jmkasunich> yes, pretty much (the locations in question are all in shmem)
[03:57:57] <SWPadnos> nevermind - the addresses are all in shmem, so the problem I was thinking of isn't actually a probnlem
[03:58:10] <weyland> it speaks of position not being updated because EMC1 and EMC2 report location differently
[03:58:18] <SWPadnos> (module unload between getting the address and storing the pointer)
[03:58:29] <weyland> http://axis.unpy.net/index.cgi/01101998950
[03:58:32] <cradek> weyland: I'm pretty sure that was fixed long ago
[03:58:37] <weyland> kewl
[03:58:49] <weyland> looks nice
[03:59:05] <SWPadnos> re: Axis, I think I had it crash on my emc machine - does it reqiure OpenGL?
[03:59:08] <weyland> I'll have to check it out after I get these parts made
[03:59:12] <cradek> yes it uses GL
[03:59:19] <cradek> weyland: yes that's fixed for sure
[03:59:24] <weyland> danke
[03:59:30] <SWPadnos> hmmm - my crappy integrated video machine isn't really up to that :(
[03:59:32] <jmkasunich> nope - it's safe against model unload (much thought went into that, and the mutex is involved - cleanup_module() calls hal_exit() which gets the mutex then destroys all objects beloing to the module (including "neatly" breaking connections to those objects)
[03:59:50] <cradek> SWPadnos: I use software GL (Mesa) on a years-old video card
[04:00:10] <cradek> SWPadnos: it works just great. It's just some lines, not some complicated video game.
[04:00:18] <SWPadnos> hmmm - I'll look into it when I have copious amounts of free time :)
[04:00:50] <cradek> I don't think BDI has AXIS 1.0 - I recommend using 1.0
[04:01:14] <cradek> it has several bugfixes.
[04:01:43] <jmkasunich> I'm afraid that select may be the proper approach... but that is very messy
[04:01:57] <weyland> baq later.
[04:02:20] <cradek> jmkasunich: but you will probably have to switch to using read()
[04:02:20] <jmkasunich> not just select, but using fd's probalby means I need to use read() instead of nice buffered i/o like fgets()
[04:02:21] <SWPadnos> jmkasunich: I was thinking about the "library" function that connects pins. That could be in the process of adding a connection when it get interrupted (with a preemptible kernel), and the module it's connecting to gets unloaded before it stores the address of the pin(signal)
[04:02:25] <cradek> jmkasunich: surely that's not what you want
[04:02:40] <cradek> jmkasunich: heh
[04:03:07] <jmkasunich> swp: while hal_lib is in the process of adding a connection, it holds the mutex...
[04:03:17] <SWPadnos> and the module won't unload...
[04:03:18] <cradek> jmkasunich: read loops where you ask for some number of characters and get some other number, then put them in a buffer, and do something if you get a full line ... suck.
[04:03:38] <jmkasunich> if somebody else tries to rmmod the module, when it calls hal_exit(), it will block on the mutex until the connection is complete
[04:03:38] <cradek> jmkasunich: I've written that way too many times (usually for serial)
[04:04:20] <jmkasunich> cradek: you understand my overwhelimg enthusiasm for using select ;-(
[04:05:24] <cradek> can you get away with exiting from inside the signal handler?
[04:05:32] <jmkasunich> I believe so
[04:05:41] <jmkasunich> ugly hack alert:
[04:05:50] <cradek> then I think you should do that and wash your hands of it
[04:05:57] <jmkasunich> set a global flag on entry to fgets(), clear on exit from gets()
[04:06:19] <SWPadnos> that's sort of where I was headed with the hal_mutex
[04:06:35] <jmkasunich> if the signal happens while the flag is set, you know you were in fgets, NOT holding the mutex... call hal_exit, and bail
[04:06:50] <SWPadnos> if the mutex is held, then block on that in the handler, and just do hal_exit/exit when it frees up
[04:07:11] <jmkasunich> if the flag was clear, you might be holding the mutex, but are not in fgets, set the done flag which drops you out of the loop after you get done with the mutex
[04:07:42] <jmkasunich> swp: I like that...
[04:07:51] <SWPadnos> what could be happening while the mutex is held (ie, how long could the operation take?)
[04:07:54] <jmkasunich> on second thought, no
[04:08:31] <jmkasunich> if "I" have the mutex in my main thread, and the signal interrupts that, the signal handler will wait until hell freezes over for it to become available
[04:08:38] <SWPadnos> it's the "multiple controllers" problem all over again :)
[04:09:04] <SWPadnos> is the mutex manually grabbed, or is it automatic in the hal library functions?
[04:09:33] <jmkasunich> all operations where the mutex is held are "fast", they never make blocking calls (but may be suspended by a linux process switch)
[04:09:41] <jmkasunich> automatic by the lib routines
[04:09:48] <jmkasunich> (sort of)
[04:10:10] <jmkasunich> halcmd does some things that are beyond the core hal api (such as listing all signals)
[04:10:25] <jmkasunich> for those things it grabs the mutex and walks the data structures itself
[04:11:04] <SWPadnos> can the program tell if its process holds the mutex, or is it an all or nothing thing?
[04:11:09] <jmkasunich> in fact, those are probably the longest mutex holding operations... they are writing the list to stdout
[04:11:21] <jmkasunich> three mutex calls:
[04:11:30] <SWPadnos> ie, "somebody is using a hal function" vs. "I'm using a hal function"
[04:11:41] <jmkasunich> nope
[04:11:52] <SWPadnos> mmm
[04:11:53] <jmkasunich> somebody (might be me)
[04:12:00] <SWPadnos> ok
[04:12:22] <SWPadnos> then the "I'm about to go into silly mode, please exit for me" flag is the best bet
[04:12:31] <jmkasunich> but "I" can set a flag that only I see saying "I might have the mutex" vs "no, there's no way I have it"
[04:13:11] <jmkasunich> if "I" might have it, then I'm NOT in the fgets, set the loop terminating flag and return
[04:13:32] <jmkasunich> if I can't have it, it's safe to call hal_exit, and exit, the sig handler never returns
[04:14:08] <jmkasunich> silly more?
[04:14:14] <jmkasunich> you mean like fgets()?
[04:14:20] <SWPadnos> yes
[04:14:55] <SWPadnos> I should have said "stupid mode, waiting for something I may never get and ignoring all the fine information flowing around me" flag :)
[04:15:02] <jmkasunich> right ;-)
[04:15:27] <jmkasunich> thanks guys... these problems are always easier with multiple brains
[04:15:45] <SWPadnos> indeed they are
[04:16:22] <SWPadnos> actually, I'd just have a flag that you set when you *do* manually grab the mutex
[04:16:29] <jmkasunich> I think I'm gonna restructure the main loop while I'm at it
[04:16:48] <jmkasunich> when I "might" have the mutex
[04:16:57] <SWPadnos> any other time, the hal will return pretty quickly, so blocking on hal_exit isn't a problem
[04:17:36] <jmkasunich> the main loop calls a funct that parses and executes the command, which in turn might call a hal funct that grabs the mutex, or may grab it itself and start walking structures
[04:18:00] <jmkasunich> better to just set the flag before calling the parsing funct, and clear it on return
[04:18:10] <SWPadnos> are the hal_lib functions linked into this program, or are they kernel calls at that point?
[04:18:18] <jmkasunich> linked
[04:18:30] <SWPadnos> Ah - then do it your way :)
[04:18:43] <jmkasunich> the hal structures are in shmem and can be manipulated from user space or kernel space
[04:18:52] <jmkasunich> the mutex protects both types of access
[04:19:25] <SWPadnos> uh - it's single writer/multiple reader, right?
[04:19:35] <jmkasunich> single anything
[04:19:56] <SWPadnos> so if halcmd is changing something, then the kernel modules can't read anything?
[04:19:57] <jmkasunich> there are linked lists, and if a reader is traversing the list while a writer adds or deletes a node...
[04:20:07] <SWPadnos> yes - could be a problem
[04:20:20] <jmkasunich> the actual realtime data doesn't pass thru the data structures
[04:20:35] <SWPadnos> ah - phew!
[04:20:44] <jmkasunich> pins, signals, parameters, functions and threads all work independent of the mutex
[04:21:12] <jmkasunich> it's only when you want to change something (add a function to a thread, connect two pins, add a new parameter, etc) that the mutex comes into play
[04:21:14] <SWPadnos> I was going to say - something like "halcmd list" causing the RT system to choke wouldn't be the best thing
[04:21:33] <SWPadnos> but you knew that
[04:21:40] <jmkasunich> no... I covered that long ago (not my first trip around the RT block)
[04:21:57] <SWPadnos> heh - doesn't look like it
[04:22:18] <jmkasunich> but the gotchas are still there... like this signal thing
[04:22:40] <jmkasunich> the window was there all along - if you hit ctrl-C while halcmd was processing a file, it would exit without freeing shmem
[04:22:41] <SWPadnos> yes indeed
[04:23:09] <jmkasunich> just that when processing from a file it's pretty damned fast, and the situation "never" arises
[04:23:29] <jmkasunich> tried it with stdin for the first time today, and the light went on
[04:23:39] <SWPadnos> heh
[04:23:44] <jmkasunich> houston, we have a problem ;-)
[04:24:30] <jmkasunich> sounds like we have a solution now...
[04:24:34] <jmkasunich> * jmkasunich starts coding again
[04:24:52] <SWPadnos> good luck. I think I'll head for bed now.
[04:24:54] <SWPadnos> see you later
[04:25:09] <SWPadnos> SWPadnos is now known as SWP_Away
[04:25:14] <jmkasunich> thanks and goodnight
[04:25:19] <SWP_Away> no problem
[04:28:03] <anonimasu> * anonimasu sighs
[04:28:09] <anonimasu> good morning everyone
[04:49:37] <jmkasunich> goodnight all
[05:08:28] <CIA-4> 03jmkasunich * 10emc2/ (scripts/emc.run src/hal/utils/halcmd.c): modified halcmd to gracefully handle ctrl-C, especially when taking its input from stdin
[05:18:55] <anonimasu> wb
[05:21:41] <weyland> okay... help... wiki...
[05:22:07] <weyland> tap...tap...tap... this thing on?
[05:22:13] <A-L-P-H-A> who were the prostars with AVR stuff?
[05:22:23] <A-L-P-H-A> weyland, no.
[05:22:30] <weyland> hahaha
[05:22:33] <weyland> :)
[05:22:46] <A-L-P-H-A> anonimasu, you and AJ are play with AVR stuff right? I know swampy does.
[05:23:08] <anonimasu> yes
[05:23:12] <anonimasu> although not much lately
[05:23:20] <A-L-P-H-A> ever deal with the PWM on the 90s series?
[05:23:32] <anonimasu> hm, yeah
[05:23:40] <anonimasu> played with it a bit..
[05:23:45] <A-L-P-H-A> at90s? not the tiny or the megas.
[05:23:51] <anonimasu> wait a sec..
[05:23:54] <anonimasu> let me check
[05:24:46] <anonimasu> yeah
[05:24:49] <anonimasu> at90s8515
[05:25:01] <A-L-P-H-A> yeah, that'd be good.
[05:25:11] <A-L-P-H-A> weyland, was there something you needed?
[05:25:25] <weyland> yeah...
[05:25:43] <weyland> I'm trying tofigure out how to add a page to the wiki so I can start writing the page I agreed to
[05:25:58] <weyland> I don't see what John was talking about
[05:26:03] <weyland> it's late, and I'm a moron
[05:26:41] <A-L-P-H-A> Je ne sais pas, wiki.
[05:26:50] <weyland> cr@p
[05:26:57] <anonimasu> :)
[05:27:12] <weyland> what're *you* smilin' at?!?!?
[05:27:23] <weyland> don't make me spear you
[05:28:07] <anonimasu> do it and take me out of this misery
[05:28:11] <A-L-P-H-A> I think someone needs to give you permission to make a page.
[05:28:13] <A-L-P-H-A> before hand.
[05:28:22] <A-L-P-H-A> I don't think it's a random person can edit page type wiki
[05:28:28] <weyland> cr@p, again
[05:28:34] <anonimasu> * anonimasu slaps weyland with
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BasicSteps
[05:28:40] <weyland> actually, it says I can edit it
[05:28:43] <weyland> LOL
[05:28:46] <weyland> ouch
[05:28:57] <weyland> sheepishly - thank you...
[05:28:58] <anonimasu> yeah follow it :D
[05:29:27] <weyland> I'll be baq, I'm sure...
[05:29:54] <anonimasu> I hope paul has some thoughts about the algorithm I made up
[05:30:05] <A-L-P-H-A> which is?
[05:30:27] <anonimasu> one for joining/simplifying beziers
[05:30:37] <A-L-P-H-A> oh! sweet.
[05:30:43] <anonimasu> simplifying/matching mutliple beziers to one
[05:30:49] <A-L-P-H-A> so we'll soon be able to machine nurbs?
[05:30:54] <anonimasu> lol
[05:31:02] <anonimasu> I dont know I hope we will
[05:31:11] <A-L-P-H-A> that'd be fuck'n sick!
[05:31:33] <A-L-P-H-A> I can finaly make that silicon vigina casting I've been looking forward to.
[05:31:34] <A-L-P-H-A> j/k
[05:31:42] <anonimasu> my ides was that you remove control points, then tweak the remaining curve
[05:31:44] <anonimasu> until you en d
[05:31:53] <anonimasu> end up with a close enough match
[05:32:03] <A-L-P-H-A> see, I think perhaps there should be control points... just massive amounts of them.
[05:32:13] <A-L-P-H-A> like a ramen sum of the curve.
[05:32:16] <anonimasu> :D
[05:32:57] <A-L-P-H-A> you do know what I'm talking about right?
[05:33:02] <anonimasu> yeah
[05:33:04] <anonimasu> cr@p
[05:33:04] <anonimasu> ;)
[05:33:19] <A-L-P-H-A> f@ck y@u.
[05:33:20] <A-L-P-H-A> heh
[05:33:20] <anonimasu> the trouble is that we need to avoid moving massive ammounts of data..
[05:33:23] <A-L-P-H-A> that looks funny
[05:33:32] <anonimasu> yau?
[05:33:39] <A-L-P-H-A> anonimasu, gcode data??
[05:34:01] <A-L-P-H-A> could make it another gcode... but I know you guys would object to another funny G-code #.
[05:34:01] <anonimasu> A-L-P-H-A: you need to convert the points back to nurbs also..
[05:35:05] <anonimasu> err not nurbs bsplines..
[05:35:09] <anonimasu> another explain more
[05:35:40] <A-L-P-H-A> bsplines require what? 3 points? right?
[05:36:05] <anonimasu> 3 or more
[05:36:16] <A-L-P-H-A> well, each control point is 3 points.
[05:37:09] <A-L-P-H-A> start, bspline control point, end point. So each spline control point requires 5 points. and overlapping start/end points.
[05:37:14] <A-L-P-H-A> for subsequent points
[05:37:26] <anonimasu> no
[05:37:33] <anonimasu> you need one point for each control point
[05:37:36] <anonimasu> and 2 anchor points
[05:38:05] <A-L-P-H-A> that's that I have. Except your's is more brief.
[05:38:37] <A-L-P-H-A> mine's a convoluted way of describing it.
[05:38:54] <A-L-P-H-A> shit, I'm tired. I should sleep.
[05:40:49] <anonimasu> hehe
[05:41:01] <anonimasu> the control point is the midpoint of the curve..
[05:41:29] <anonimasu> do you think that algorithm will work?
[05:41:34] <A-L-P-H-A> I know what a bspline is... autocad, illustrator, inkscape, flash have them.
[05:42:47] <anonimasu> for simplifying them
[05:46:06] <anonimasu> that's what I am trying to find out
[05:48:16] <A-L-P-H-A> I don't know how you can really simplify them even more.
[05:48:25] <A-L-P-H-A> like you're gotta have those control points, and stuff.
[05:48:41] <A-L-P-H-A> with that information, you can create the movement points.
[05:48:48] <anonimasu> oh the trouble is if there's 20 in a short segment
[05:49:01] <anonimasu> like 1mm
[05:49:19] <A-L-P-H-A> that's a high detail bspline.
[05:49:32] <anonimasu> too much data to pass around..
[05:49:39] <A-L-P-H-A> see, you could make it, create G2/3 points, that have a specific line segment size only.
[05:50:06] <anonimasu> not possible..
[05:50:35] <anonimasu> you still end up passing too much data in the end
[05:50:48] <anonimasu> thats why you need to simplify them even more
[05:51:01] <A-L-P-H-A> that would be a post processor thing then, not a EMC thing.
[05:51:13] <anonimasu> theres no point in making splines if the spline has as many points as the orginal spline
[05:51:25] <anonimasu> err orginal path/line
[05:52:01] <A-L-P-H-A> think about it... the computer doesn't really give a shit how much data you push at it... it just chuggs it. Why do you care how much data is passed back and forth?
[05:52:25] <anonimasu> because the limit of the speed emc can acheieve is based on how much data you can pass at one servo cycle..
[05:53:12] <A-L-P-H-A> hmm.
[05:53:36] <anonimasu> the queue starvation that shows up in SQ at high speeds..
[05:53:44] <A-L-P-H-A> see if you toss some data, you lose precision.
[05:53:50] <A-L-P-H-A> how much precision do you want to loose?
[05:54:04] <anonimasu> that's a very good question
[05:54:36] <anonimasu> but since you average the remaining points, until you en up with a spline within t of the orginal one
[05:55:58] <A-L-P-H-A> or a flat line.
[05:56:10] <anonimasu> nope..
[05:56:15] <A-L-P-H-A> anonimasu, that's kinda bad... like what happens when you have a shark fin... you're gonna have a bump, instead of a fin.
[05:57:00] <anonimasu> heh
[05:57:09] <anonimasu> are your sharkfins that small..
[05:57:28] <A-L-P-H-A> could be... lets say I'm trying to make a saw blade pattern, in that scale.
[05:57:37] <anonimasu> yeah but it still large..
[05:57:39] <anonimasu> http://www.mmsonline.com/articles/079901.html
[05:58:51] <anonimasu> as I said earlyer the limit is how much data you can pass around
[05:59:00] <anonimasu> the less data the more speed
[05:59:47] <anonimasu> s/earlyer/earlier
[05:59:50] <A-L-P-H-A> again, it's a speed versus accuracy. Higher the tolerance, the higher everything else.
[06:00:01] <A-L-P-H-A> perhaps scale it to the resolution that each machine can handle.
[06:00:12] <anonimasu> well it's up to the user anyway..
[06:01:03] <A-L-P-H-A> well, there's really no point, if say the user can only get 0.0005" resolution. [and unlikely to be unrepeatable at that resolution ether].
[06:01:26] <A-L-P-H-A> what's my solution?
[06:02:02] <anonimasu> tweak your acceptable error down
[06:02:24] <anonimasu> if you can average 4 points to a spline it's still less data
[06:02:33] <anonimasu> average/join
[06:02:52] <A-L-P-H-A> I'm not exactly the best person to have this discussion, because I'm a step/dir guy. I don't know how servos should REALLY behave.
[06:02:58] <A-L-P-H-A> as they should in this case.
[06:03:04] <A-L-P-H-A> I'm a poor stepper motor man.
[06:03:18] <anonimasu> oh, it's not the servos, it's the planning of the motion
[06:03:36] <A-L-P-H-A> oh, like look ahead, continous motion.
[06:03:40] <anonimasu> yeah
[06:03:49] <A-L-P-H-A> I'm definitely interested in that.
[06:03:52] <anonimasu> the trajectory planner
[06:04:03] <A-L-P-H-A> I hate how turbocnc pauses after each entry.
[06:04:08] <anonimasu> yep :)
[06:04:17] <anonimasu> read the page I threw
[06:04:29] <A-L-P-H-A> I'm browsing it.
[06:04:37] <A-L-P-H-A> my eyes aren't focusing well... it's 2am.
[06:04:45] <anonimasu> if you can throw nurbs at the controller ^_^ joy!
[06:05:05] <A-L-P-H-A> definitely would be COOL. well, geek cool... but I'm a geek.
[06:05:38] <anonimasu> still would require a killer post..
[06:06:06] <A-L-P-H-A> it's all trajectories, and maintaining constant feedrate... the lookahead would really need to be slick.
[06:06:12] <anonimasu> and from what I understand you can scale nurbs up to as manu axis:es you want
[06:06:19] <anonimasu> s/manu/many
[06:06:24] <A-L-P-H-A> yup. you can.
[06:06:40] <anonimasu> # Nurbs interpolation offers an alternative to traditional chord interpolation for machining complex contoured forms, like dies or molds. If you are instead machining geometrically simple parts, nurbs interpolation can't help you.
[06:06:45] <anonimasu> # Nurbs interpolation may let you machine these complex forms at a higher average feed rate than you would achieve using chords, without compromising accuracy. CNC processing speed may provide the reason why, but there are other reasons, too.
[06:06:49] <anonimasu> # By itself, nurbs interpolation is not more accurate than chord interpolation. But when accuracy is required, nurbs can offer a more efficient way to achieve it
[06:07:28] <anonimasu> multiple control makers say that a typical nurbs block can replace five to ten blocks of straight-line moves.
[06:07:56] <A-L-P-H-A> actuall. nurbs3d... you'd need 3 control points for each axis. But could be define for each point in 3d space, you'd need 4 control points. and XYZ controll points, plus the original control point vertice, and then there could be another point for feedrate. And then another point for spindle direction.
[06:07:57] <A-L-P-H-A> wow.
[06:08:20] <A-L-P-H-A> that's 3, plus 5, that's 8 variables for each control point.
[06:08:21] <A-L-P-H-A> heh.
[06:08:52] <A-L-P-H-A> oh... could add another control point for acceleration for the feedrate.
[06:08:56] <anonimasu> I dont belive that they are passes as points..
[06:08:59] <anonimasu> control points
[06:09:17] <A-L-P-H-A> I'm thinking 3d visualization.
[06:09:24] <anonimasu> yeah, but I am not :)
[06:09:32] <anonimasu> but you could visualize it laso
[06:09:37] <A-L-P-H-A> they could be visually represented that way. :)
[06:09:38] <anonimasu> also..
[06:09:44] <anonimasu> with the same paths..
[06:10:09] <anonimasu> neat
[06:10:40] <A-L-P-H-A> sO just figured out a way to do 4d!!! :D woohoo.
[06:11:08] <A-L-P-H-A> actually, for this example it'd be like, 8D
[06:11:18] <A-L-P-H-A> and that wasn't meant to be a smily.
[06:11:40] <anonimasu> well, I dont care for that but you can easily visualize bsplines
[06:11:54] <A-L-P-H-A> position in space, time, excelleration, spline curvature in 3 axis, and spin direction.
[06:12:00] <anonimasu> and have 8 axis contouring
[06:12:05] <A-L-P-H-A> acceleration
[06:12:10] <anonimasu> at 900ipm
[06:12:11] <anonimasu> ;)
[06:12:36] <anonimasu> 22m/s
[06:12:48] <anonimasu> err min
[06:12:51] <anonimasu> my machine will do 1.5m/min now
[06:12:52] <A-L-P-H-A> I got 35m/min
[06:13:01] <anonimasu> did you?
[06:13:07] <anonimasu> 900*25.4
[06:13:27] <A-L-P-H-A> 900/25.4
[06:13:45] <A-L-P-H-A> shit.
[06:13:59] <anonimasu> 1" = 25.4mm
[06:13:59] <anonimasu> ;)
[06:14:16] <A-L-P-H-A> 22.86m/min.
[06:14:29] <A-L-P-H-A> I get 2m/min right now. :P
[06:14:34] <A-L-P-H-A> actually faster than that.
[06:14:56] <A-L-P-H-A> I think I'm getting 80-90ipm.
[06:15:26] <anonimasu> the datrondynamics machines does 400ipm..
[06:15:34] <anonimasu> *jealous*
[06:17:07] <A-L-P-H-A> I'm off to bed. later.
[06:19:11] <anonimasu> laters
[06:42:51] <asdf-qwee> Yes!
[06:42:55] <asdf-qwee> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=7517191614&rd=1&sspagename=STRK%3AMEBI%3AIT&rd=1
[06:49:08] <anonimasu> hm seems expensive for 1
[06:49:20] <anonimasu> but very nice
[06:49:21] <anonimasu> bbl..
[06:58:02] <Phydbleep> asdf-qwee Crap, I wish I'd known.. I saw a buttload of those at surplus for $0.25/section a while back.
[08:04:34] <Phydbleep> * Phydbleep sends a wheelie-bin chasing asdf-qwee.
[08:04:56] <asdf-qwee> And what's that supposed to be?
[08:06:46] <Phydbleep> Wheelie-bin? Plastic trash can with wheels, like they use for the trash-trucks with a grabber arm.
[08:06:48] <asdf-qwee> * asdf-qwee ties a package for Phydbleep to a stray dog, stamps "New Mexico" on it, and gives the dog a boot
[08:07:12] <Phydbleep> asdf-qwee: I glued yours to a snail. :)
[08:07:21] <Phydbleep> US-Snail. :)
[08:07:46] <Phydbleep> Should be there Thursday or Friday.
[08:08:16] <asdf-qwee> You should have gotten an email from UPS
[08:09:29] <Phydbleep> Yeah, I did, looking to see where it is and how many times it's been searched for illegal aliens. :)
[08:11:07] <Phydbleep> Man. I wished I'd known that you wanted DIN rail terminals.
[08:11:34] <anonimasu> *yawns*
[08:11:43] <asdf-qwee> Well, I could still go some DIN rail
[08:12:12] <Phydbleep> Yeah, But I won't be back up that way till next weekend.
[08:12:39] <asdf-qwee> Maybe a gift card for AutomationDirect.com? :P
[08:13:49] <Phydbleep> asdf-qwee: Is that the site with the blonde and the reworked Ford wiper motor? :)
[08:17:46] <Phydbleep> The surplus place here has a bunch of the din stuff.. I ended up useing miles of it for car stereo stuff for friends.
[08:19:05] <asdf-qwee> Well, if you REALLY like the toolpost, maybe you send me another wheelie-bin
[08:19:44] <asdf-qwee> I'm going to try using it for my next controller box(es)
[08:20:24] <Phydbleep> Oh that wasn't the package, that was a retriever. :)
[08:20:44] <Phydbleep> Funny you should say controller parts. :)
[08:21:11] <anonimasu> * anonimasu just got a toolpost
[08:21:23] <anonimasu> machined the orginal
[08:21:29] <anonimasu> mount on the lathe for it yesterday
[08:22:04] <Phydbleep> anonimasu: I'll have to use my old one to make a mount for the new one. :\
[08:22:35] <anonimasu> I milled the O with the rotary table..
[08:22:35] <anonimasu> :)
[08:22:37] <asdf-qwee> I thought ALPHA was going to send me 2 labs and 50lbs in pennies...
[08:22:55] <anonimasu> err the centresince I didnt feel like machining a whole new one..
[08:24:15] <Phydbleep> Anybody got a spare rotary index table or worm-drive to make one cheap?
[08:24:35] <anonimasu> no
[08:25:50] <anonimasu> :/
[08:27:29] <Phydbleep> Hmmmm... I wonder if I could harden/heat-treat MS (mild steel) to make a tap to hob a MS gear?
[08:27:51] <fenn_afk> Phydbleep, there's bunches of pages out there about doing just that type of thing
[08:28:24] <fenn_afk> probably better to start off with a brass gear
[08:28:33] <Phydbleep> fenn_afk: Yeah, but 99% of the ones I've seen use MS for the tap and Al for the gear. :\
[08:28:51] <fenn_afk> better than no rotary table
[08:28:58] <fenn_afk> fenn_afk is now known as fenn
[08:30:05] <anonimasu> :(
[08:30:10] <anonimasu> yeah
[08:31:42] <Phydbleep> IO'd rather use MS even if I have to wear out a tap and make a new one. :)
[08:31:49] <Phydbleep> I'd
[08:32:13] <anonimasu> yep
[08:32:19] <anonimasu> alu wouldnt work..
[08:32:29] <anonimasu> not for too long
[08:33:08] <Phydbleep> anonimasu: It works for telescope mounts and that kind of stuff, But I want something that will survive massive abuse.
[08:34:18] <asdf-qwee> I've got a worm and gear I bought to do the "Gingery Dividing Head"
[08:34:41] <Phydbleep> * Phydbleep may want to build a massive revolver cylinder like block for a wierd piston engine...
[08:34:57] <asdf-qwee> I've since bought myself a rotary table and an dividing head :)
[08:35:34] <anonimasu> when you've got your machine running you wont need a rotary table too mugh
[08:35:36] <anonimasu> much..
[08:35:37] <asdf-qwee> Phydbleep: What, a quad-piston Stirling?
[08:35:40] <anonimasu> I use it for quick half manual stuff
[08:36:12] <Phydbleep> 7 cyl radial with a 90 degree bend in the rods. :)
[08:36:28] <anonimasu> lol
[08:36:55] <Phydbleep> Cross between a radial and a "wobble-plate" torpedo motor.
[08:38:46] <Phydbleep> asdf-qwee: BTW.. Congratulations.. It's a box, 14" cube, 10.2 lbs. :)
[08:39:29] <Phydbleep> 10 of it you wanted, the 0.2 is something amusing. :)
[08:41:04] <anonimasu> lol
[08:41:46] <Phydbleep> anonimasu: Nothing that amusing, just spare parts. :)
[08:43:26] <asdf-qwee> "...In a discrete brown paper wrapping"
[08:44:03] <Phydbleep> Close.. Small white cardboard box.
[08:49:02] <anonimasu> *yawns*
[08:49:04] <anonimasu> lunch time
[08:50:18] <Phydbleep> Operator Error!
[08:59:46] <asdf-qwee> Well, it's about time for me to leave for work
[09:00:00] <asdf-qwee> And after work...I work some more!
[09:00:07] <Phydbleep> Work? That's a four letter word. :)
[09:00:46] <Phydbleep> You go wash your mouth out with beer right now young man!
[09:00:50] <asdf-qwee> First my day job, and then off to do some CNC freelancing
[09:01:18] <asdf-qwee> Yeah, THAT's just what I want on my breath when I walk through the door
[09:01:59] <Phydbleep> asdf-qwee: Question, Did you do that split in the boring bar block V or H?
[09:02:19] <asdf-qwee> Horizontal
[09:02:52] <asdf-qwee> It's quite solid
[09:03:02] <fenn> Phydbleep anonimasu: It works for telescope mounts and that kind of stuff, But I want something that will survive massive abuse.
[09:03:10] <anonimasu> what?
[09:03:16] <anonimasu> deja vu
[09:03:17] <fenn> sorry just quoting
[09:03:21] <Phydbleep> OK, Cool. i can get domed allen-heads for it..
[09:03:32] <fenn> don't rotary tables have spindle locks?
[09:03:52] <Phydbleep> fenn: Most do.
[09:03:57] <asdf-qwee> * asdf-qwee is away - stop talking to me!
[09:04:10] <fenn> so all the load goes on the spindle lock instead of onto the backlashy worm gear
[09:04:54] <Phydbleep> Yesss.. BUT, I want to be able to power the head later for spiral cuts/etc.
[09:05:32] <fenn> hmm.. is there such a thing as a "ball worm gear"
[09:05:39] <fenn> like a ball screw but for worm gears
[09:06:26] <fenn> it works in my mind but i might be overlooking some important kinematic requirement
[09:13:44] <Phydbleep> fenn: You're missing the important financial requirement.. Well, Actually I am.. I'm broke. :\
[09:14:24] <fenn> i'm thinking about power transmission designs for turboshafts.. will build some time in the future if it works out
[09:14:56] <fenn> worm gears are a neat idea but have terrible efficiencies due to low relative sliding motion
[09:16:31] <Phydbleep> fenn: I could give a rats ass about efficiency in this case. I want to be able to mount it on the cross-feed and play spirograph. :)
[09:17:43] <fenn> you're not trying to make a wankel engine are you?
[09:17:57] <Phydbleep> Not today. :)
[09:19:05] <fenn> you could use a universal joint linking the spindle and the rotary table, and use change gears to drive the (spur geared) rotary table
[09:19:13] <fenn> instead of a worm gear
[09:19:39] <fenn> might be more complicated though..
[09:27:52] <Phydbleep> fenn: You can also take 99.9% of the backalsh out of a worm system if you build it right.
[09:47:22] <anonimasu> fenn: yes, but they cost a arm..
[09:47:34] <anonimasu> fenn: or a small sized country
[09:48:43] <fenn> bah
[09:49:11] <fenn> anonimasu, what are they used for
[09:50:58] <anonimasu> fenn: higher end rotary tables
[09:51:02] <anonimasu> precision gearboxes..
[09:57:39] <anonimasu> :)
[10:39:28] <Phydbleep> Morning paul. :)
[10:41:26] <paul_c> Morning
[10:51:36] <anonimasu> morning paul
[10:54:09] <anonimasu> paul_c: got any thoughts about the last message I sent you yesterday
[10:56:06] <paul_c> way, way too much math being done.
[10:57:05] <anonimasu> paul_c: got a better solution to it?
[10:57:20] <anonimasu> dont think it'd be _THAT_ much math
[11:00:55] <anonimasu> paul_c: if you can come up with a way to aproximate the spline, you can do with less calculation
[11:03:15] <paul_c> 'xactly - There has to be a better way than to convert to way points & compare old and new...
[11:03:38] <anonimasu> yeah, you can do without converting them..
[11:04:03] <paul_c> must have missed that msg then...
[11:04:10] <anonimasu> I didnt send it...
[11:04:22] <anonimasu> I wrote some stuff on a paper besides my bed..
[11:58:27] <rayh> paul_c: You about?
[11:58:34] <paul_c> kinda
[11:58:42] <rayh> I know the feeling.
[11:58:55] <rayh> I don't have 2.6.10 anywhere.
[11:59:49] <rayh> Will the head of emc2 build on 9?
[12:00:30] <paul_c> it should do.
[12:00:57] <rayh> Okay. Then I won't worry about that right now.
[12:01:23] <rayh> Thanks.
[12:04:03] <anonimasu> paul_c: I guess it'll be a while before we solve this in a good way.
[12:04:34] <paul_c> did you ask on math ?
[12:07:33] <anonimasu> yeah
[12:07:52] <paul_c> and ??
[12:09:33] <anonimasu> didnt get a way to join/simplify spliens..
[12:09:40] <anonimasu> s/spliens/splines
[12:10:32] <paul_c> there isn't an easy way....
[12:11:03] <paul_c> It is going to involve trig and/or matrixes somewhere along the line.
[12:11:50] <anonimasu> yeah..
[12:15:04] <anonimasu> if somone could just explain how you do it..
[12:15:13] <anonimasu> or give us a formula for doing it..
[12:35:50] <anonimasu> bbl
[12:38:47] <fenn> it would probably be easier to just start out with splines in the CAD program, export to spline toolpath in the CAM program, and _then_ work on a spline gcode interpreter
[12:39:18] <fenn> instead of converting to hundreds-of-little-lines and trying to massage it back into spline format in the interpreter
[12:40:58] <anonimasu> fenn: give me the name of a program that does it :)
[12:41:07] <fenn> anonimasu, exactly ;)
[12:41:20] <anonimasu> it'd be easier but well, impossible if we dont have some program that can do it for us..
[12:41:34] <anonimasu> but nice hack ;)
[12:41:47] <fenn> why bother implementing spline interpolation if you can't even make a spline toolpath?
[12:42:25] <fenn> there is a severe need for a GPL'd CAM program
[12:42:26] <paul_c> generating a path from a spline is (almost) trivial.
[12:42:58] <paul_c> but that is not the problem...
[12:43:18] <fenn> huh?
[12:43:38] <fenn> spline toolpath== G0 K0 * * *
[12:43:39] <paul_c> imagine for a mo, someone sends you a g-code file
[12:44:12] <paul_c> there are sections where it does an arc of (say) 2"
[12:44:14] <anonimasu> yeah but loading it up in a cam program.. is neat..
[12:44:42] <anonimasu> if we were writing specialized control for a special machine perhaps it'd work..
[12:44:49] <paul_c> and the cam program they used split those arcs in to straight line moves of 0.00175" long
[12:45:11] <fenn> paul_c, i get it
[12:45:24] <fenn> your motion planner chokes on all the data
[12:45:51] <paul_c> Without overloading the usr<->RT comms, you've gotta reduce the amount of information.
[12:47:27] <fenn> anonimasu, it doesn't matter what machine you run it on, it's all in cartesian coordinates until you get to the kinematics section, right?
[12:48:20] <paul_c> unless you are jogging a strut on a hexapod.... But that is a special case that is easy to handle.
[12:48:32] <fenn> people do that on purpose??
[12:49:08] <paul_c> On the odd parallel kins machine, yes.
[12:49:26] <paul_c> (scara, puma, etc)
[12:50:48] <fenn> well, that has nothing to do with spline interpolation then
[12:51:07] <fenn> at least, i thought it was spherical motion, i might be wrong
[12:53:20] <anonimasu> fenn: hm, I have no idea how the kinematics are handled..
[12:53:21] <anonimasu> :)
[12:55:05] <fenn> well, anyway, spline interpolation doesn't seem all that hard to implement
[12:55:34] <fenn> getting hundreds of little lines back into a big spline seems somewhat harder
[12:56:35] <anonimasu> yep
[12:56:36] <anonimasu> ^_^
[13:01:00] <les> fenn, the purpose of the splining is not path accuracy...It is to insure that velocity and perhaps accel are continuous functions so the machine does not shudder
[13:01:15] <anonimasu> nope..
[13:01:35] <anonimasu> it's to reduce the ammount of data you pass between the userspace and rt part..
[13:01:50] <les> heh well that helps too
[13:02:03] <anonimasu> thus giving a higher block processing rate.
[13:02:30] <anonimasu> and well no queue starvation..
[13:02:55] <les> btw on your generation of points to prevent didtant points from being oversmoothed....
[13:03:23] <anonimasu> ?
[13:03:38] <les> if the traj planner is at a constant rate in RT that will kinda happen
[13:04:03] <les> so a big move is broken up into many pseudo points
[13:04:19] <les> that controls in zone path errors
[13:04:47] <anonimasu> les: you end up with way too much data.
[13:05:09] <les> error is the a function of traj rate and accel
[13:05:49] <les> yes it is a lot
[13:05:59] <rayh> libcsiro0 -- bivariate Cubic Spline Approximation library
[13:06:05] <les> but less than the raw points sometimes
[13:06:46] <anonimasu> les: but that stull avoids the real problem..
[13:07:00] <les> Note that Rogier first ran joint space points thru a three term FIR low pass filter before anything else
[13:07:14] <anonimasu> les: how do you convert the thousand segments to a spline with less data.
[13:07:40] <anonimasu> or well the 1000 move circle.
[13:08:09] <les> you resample the thousand points first
[13:08:18] <anonimasu> think about pocketing a 1" dia circle at 400ipm..
[13:08:32] <les> and based on desired rate of curvature...
[13:08:46] <les> create new and fewer psuedo points
[13:09:00] <anonimasu> can you come up with the math on it?
[13:09:16] <anonimasu> that's where the trouble lies..
[13:09:40] <les> yes I think I can
[13:10:05] <anonimasu> nice
[13:10:40] <les> It will take a bit but I should just write down the whole process as pseudocode
[13:11:02] <les> I would want to do this in joint space
[13:11:16] <les> much easier to understand
[13:11:51] <les> and of cource machine space can be created by running through forward kinematics
[13:12:21] <les> then that can be run though any desired inverse kinematics (like a hexapod)
[13:12:56] <fenn> i thought forward kinematics was rectangular -> joint space
[13:13:19] <anonimasu> paul_c: can you explain what stuff les needs to do I dont understand this..
[13:13:24] <fenn> cartesian -> six axes pointing toward one point, i mean
[13:13:29] <anonimasu> I dont get the "joint space, stuff"
[13:13:41] <anonimasu> :/
[13:14:05] <fenn> anonimasu, he's talking about non-perpendicular axis machines
[13:14:14] <anonimasu> or rather no time to look at it..
[13:14:25] <fenn> yeah that rogier blom paper is too long
[13:14:48] <fenn> les, why do you want to do it in joint space?
[13:14:54] <les> joint space is describing motions at things like robot elbow bearings
[13:15:31] <anonimasu> there's already a algorithm that's applicable.. but reducing the amount of data are the only trouble.
[13:15:44] <les> forward kins calculate end effector position from the joints
[13:15:50] <les> that is fairly easy
[13:16:12] <fenn> i guess i've got it backwards
[13:16:18] <les> inverse kins calculate the joint positions from the end effector
[13:16:24] <les> that is not easy
[13:16:29] <anonimasu> les: you just have to come up with that part..
[13:16:45] <les> there are sometimes multiple solutions
[13:16:53] <les> or solutions that blow up
[13:17:08] <fenn> les, there's always one solution if you take into account what position you were in before
[13:18:15] <anonimasu> I think you are overcomplicating this :)
[13:18:29] <fenn> yeah it would be easier to do it in cartesian coordinates so you only have to write the code once
[13:18:39] <les> Imagine moving shoulder, elbow, wrist etc but keeping your middle finger in one spot.
[13:19:15] <les> When you try to calculate all the joint positions from the fact that your finger is in one spot....
[13:19:31] <les> there are many combinations that will work
[13:19:57] <fenn> but the "Right" combination is the one that is closest to where you were before
[13:20:14] <fenn> closest usually defined in terms of time
[13:20:39] <fenn> but if it takes too long to calculate in terms of time, could be done other ways
[13:20:53] <les> yes..well I had my finger stationary
[13:20:59] <les> that is a subset
[13:22:03] <fenn> is emc2 planned to support more than 6 DOF?
[13:22:10] <les> just to show that inverse kins are not trivial...
[13:23:42] <les> anyway that was just to get an idea of the terms....trajectory planning should really be independent of kinematics
[13:23:55] <les> Now in Segmentqueue it was not....
[13:24:24] <fenn> no wonder it never worked
[13:24:29] <les> so it would not work on anything more than a 3 axis cartesian machine
[13:24:49] <les> heh let me modify that statement...
[13:24:58] <les> would not work at all!
[13:25:08] <les> oh well
[13:25:21] <fenn> better luck next time
[13:25:36] <les> yeah.
[13:25:46] <anonimasu> well, fenn possible new algorithm supports as manu axises as you would like.
[13:25:50] <anonimasu> err the.
[13:26:08] <les> It should.
[13:26:28] <anonimasu> les: the only thing you have to do is to reduce the amount of points and generate a spline off them.
[13:27:14] <les> well... something like this:
[13:27:43] <les> read ahead some points....
[13:27:58] <les> run them througha spatial filter....
[13:28:34] <les> resample at a constant rate (as slow as possible)
[13:28:42] <les> spline them...
[13:28:53] <les> put the coeficcients on a queue.
[13:29:14] <les> for each axis
[13:29:27] <fenn> what is the constant rate based on?
[13:29:31] <SWP_Away> SWP_Away is now known as SWPadnos
[13:29:43] <les> arc motion requires a little thought
[13:29:43] <rayh> Hey Paul. You got a adeos kernel set up that fixes the bug?
[13:30:06] <les> either use what is in there or spline an arc with a cubic
[13:30:14] <les> I think it will exactly fit
[13:30:18] <anonimasu> les: that's probably the best way..
[13:31:00] <SWPadnos> is it just the RT data rate that's the problem, or does the block processing rate come into play as well?
[13:31:44] <les> user/RT comms must be carefully managed I guess
[13:32:08] <SWPadnos> I know Paul has mentioned that as a hard limit on user->RT bocks
[13:32:33] <les> block processing rate in general would not have to be a problem because it can be done at any time
[13:32:41] <les> block meaning g-code
[13:32:43] <alex_joni_away> yo les
[13:32:49] <alex_joni_away> just the man I wanted to see
[13:32:55] <les> hi alex
[13:33:13] <SWPadnos> I guess my question is, with the pathological example Paul gave sometime back (a 2" circle output as a string of line segments 0.00175" long), those need to be processed quickly
[13:33:40] <SWPadnos> are the algorithms you're thinking of efficient enough for rapid processing of that kind of data
[13:33:46] <alex_joni_away> seems you guys are debating the hot topic
[13:33:47] <alex_joni_away> TP
[13:33:51] <SWPadnos> (given the 1000 ipm or 500 ipm speeds you want
[13:33:54] <SWPadnos> )
[13:33:56] <SWPadnos> yes
[13:33:57] <SWPadnos> :)
[13:34:07] <les> SWP it would be resampled at a greater spacing.
[13:34:17] <fenn> i got the idea that it would not be done in realtime
[13:34:45] <fenn> what's a possible realtime app of turning pathological sampling rates into splines?
[13:34:55] <SWPadnos> sure, but there remains the fact that you want the machine to burn through 10 inches/sec, with 1/600 inch segments - that's 6000 segments per second of processing (in that example)
[13:35:02] <les> alex...ask your question on chat
[13:36:16] <les> In the limiting sense an entire program would need to be preprocessed
[13:36:23] <fenn> what i mean is first you turn the crazy CAM output into a decent splined gcode file, then run it
[13:36:31] <SWPadnos> OK - that's what I was afraid of :)
[13:36:37] <les> I would thing that is possible...plenty of memory about
[13:36:45] <anonimasu> * anonimasu sighs
[13:36:47] <alex_joni_away> les: actually I wanted to bring the topic up
[13:36:54] <les> ok
[13:36:56] <alex_joni_away> and maybe get you to write a bitch-list about tp
[13:36:57] <anonimasu> SWPadnos: that's what I asked les to come up with..
[13:37:14] <alex_joni_away> alex_joni_away is now known as alex_joni
[13:37:31] <les> brb phone
[13:37:32] <SWPadnos> yeah - I was heading in that direction yesterday when I was interrupted by a phone call
[13:37:38] <SWPadnos> heh - contagious
[13:37:42] <alex_joni> seems like it
[13:37:47] <alex_joni> I just got off the phone
[13:38:02] <fenn> "telephones are a pox on all mankind"
[13:38:19] <alex_joni> fenn: don't dare to mention cellphones ;)
[13:38:37] <fenn> cellphones are like pissing in the drinking water
[13:38:47] <fenn> you're just asking for it
[13:39:16] <SWPadnos> who was it that said "I'll be happy when my computer is as easy to use as my telephone"
[13:39:35] <fenn> someone who will never be happy :)
[13:39:39] <SWPadnos> and then said "well - it's happened. My computer is as easy to use as my telephone - I can't figure out how to use this damn thing"
[13:40:02] <SWPadnos> I think it was Dennis Ritchie or someone like him :)
[13:40:28] <SWPadnos> the phone had become complicated enought that it caught up - too funny.
[13:42:52] <anonimasu> well off to customer
[13:45:52] <alex_joni> * alex_joni reads back
[13:46:33] <rayh> Hi Alex.
[13:47:15] <alex_joni> hey rayh
[13:47:23] <SWPadnos> phone
[13:47:28] <alex_joni> I really think we need urgent addressing on this matter :)
[13:47:33] <alex_joni> TP stuff
[13:48:38] <fenn> is there a hal interpreter yet?
[13:49:10] <alex_joni> A WHAT????
[13:49:20] <fenn> a hal-based gcode interpreter
[13:49:25] <fenn> is that too much to ask?
[13:49:52] <alex_joni> WTF would you need a HAL based gcode interp?
[13:49:59] <alex_joni> what would that be good for?
[13:50:11] <alex_joni> and how should it communicate with the rest of the world?
[13:50:21] <alex_joni> set a pin when we need a line, and another for circle?
[13:50:38] <fenn> yeah pretty much
[13:50:59] <alex_joni> well.. that's bogus
[13:51:44] <fenn> the reason it's important is that HAL makes the whole system transparent to the user
[13:51:54] <les> Folks I must make a client housecall
[13:52:06] <rayh> Catch you later.
[13:52:09] <alex_joni> right
[13:52:10] <alex_joni> bye les
[13:52:11] <fenn> it's also important because NML is a bunch of crap and needs to be replaced by something like HAL
[13:52:20] <les> k later
[13:52:25] <alex_joni> fenn: interp & motion don't talk NML
[13:52:33] <rayh> fenn: oops.
[13:52:50] <fenn> is someone going to beat me with a pointy stick now?
[13:52:57] <fenn> * fenn cringes in terror!
[13:53:34] <rayh> Ooh a pointy stick is good.
[13:53:43] <alex_joni> * alex_joni suspects robin hides under fenn's clothes
[13:54:07] <fenn> hrm..
[13:54:17] <rayh> In a monolythic program you do not need formal communication
[13:54:32] <fenn> that's the point, it shouldn't be monolithic
[13:54:33] <rayh> Cause it does what you wrote it to do and no more.
[13:55:06] <rayh> When you run more than one system at the same time
[13:55:11] <fenn> say i want to keep the motion planner, but chuck g-code out the window since it's been around 60 years too long
[13:55:20] <rayh> They have to communicate using formal language.
[13:55:41] <alex_joni> right, and HAL is definately no formal language
[13:55:53] <alex_joni> it's an ABSTRACTION LAYER
[13:56:01] <alex_joni> got nothing to do with communication
[13:56:04] <rayh> Formal language can be imposed upon HAL
[13:56:19] <fenn> probably should be imposed in fact
[13:56:22] <alex_joni> explain
[13:56:43] <rayh> Well there are a few formal elements like data typing.
[13:57:23] <rayh> But for the most part, when you connect a hal module to another,
[13:57:35] <alex_joni> it's just like connecting wires
[13:57:42] <alex_joni> with analog / digital components
[13:57:47] <rayh> the one doing it keeps in mind what the meaning of a change in pin state is.
[13:58:23] <rayh> With a formal language, the meaning is decided upon by h
[13:58:34] <rayh> a dictionary, canon if you will.
[13:59:19] <rayh> This is the semantic element of the language. "What does this message mean to me."
[13:59:34] <alex_joni> rayh: I know what a language is
[13:59:41] <rayh> The other half of the formal language is the syntax
[13:59:42] <alex_joni> but that's far from what HAL is / needs to be
[13:59:58] <rayh> Yes. True.
[14:00:10] <alex_joni> anyways.. getting back to TP
[14:00:16] <fenn> snarf
[14:00:28] <alex_joni> the poor bastard NML has no bad influence here
[14:00:31] <rayh> And that is why it would be a very bad idea to simply impose hal like structure on thw whole of emc
[14:00:42] <alex_joni> rayh: RIGHT
[14:01:03] <fenn> that's circular logic
[14:01:27] <fenn> "i think hal should be low-level, therefore hal should be low-level"
[14:01:27] <rayh> making certain that the sender of a pin(signal) and the receiver have the same sence of
[14:01:33] <alex_joni> fenn: HAL is ok to be wrapped around hardware drivers
[14:01:37] <rayh> what that signal means would be terrible.
[14:01:39] <alex_joni> to be able to connect them to EMC
[14:01:55] <rayh> fenn: has the right idea here.
[14:02:12] <fenn> rayh, i don't agree with what i just said
[14:02:17] <rayh> As I said yesterday, I like absolute in certain mixtures.
[14:02:19] <alex_joni> LOL
[14:02:32] <alex_joni> * alex_joni takes a note: <fenn> rayh, i don't agree with what i just said
[14:02:44] <fenn> * fenn hangs his head.
[14:02:45] <rayh> and you guys are all a figment of my imagination.
[14:03:23] <rayh> Jon Paul rears his ugly head again.
[14:03:56] <rayh> IMO NML needs an easy way to add words to its vocabulary.
[14:04:08] <alex_joni> rayh: can we PLEASE address NML another time?
[14:04:17] <rayh> Yes.
[14:04:21] <alex_joni> thx ;)
[14:04:38] <alex_joni> I really feel bad when people go away from EMC
[14:04:58] <alex_joni> and people going away are USERS
[14:04:59] <rayh> Who is going away?
[14:05:04] <alex_joni> hmm.. les?
[14:06:13] <alex_joni> the point is.. people that dislike EMC is because they don't like how it performs
[14:06:26] <alex_joni> not because some shitty library is used for communication
[14:06:39] <alex_joni> at least that's what I think
[14:06:58] <fenn> 99% use tkemc on the motion control machine anyway
[14:07:02] <alex_joni> the problem with NML is a pita for developers, I agree
[14:07:33] <alex_joni> but.. those are developers, and a decent developer should be able to handle it, or limit himself to other areas
[14:07:37] <alex_joni> or ask for help
[14:07:44] <alex_joni> or change the fscking thing
[14:08:35] <rayh> Agreed completely.
[14:10:16] <fenn> i can't make any useful comments about what will/wont work in order to fix the TP since I don't know what the overall layout of emc2 looks like
[14:11:09] <alex_joni> * alex_joni is not in the mood to make a decent suggestion to fenn
[14:11:15] <alex_joni> so I skip that ;)
[14:12:23] <alex_joni> but there is some documentation on the whole system
[14:15:15] <alex_joni> fenn: got some programming skills?
[14:15:20] <fenn> so "motion" has output to HAL, but regular hard-coded input from the interpreter?
[14:15:25] <fenn> alex_joni, maybe :)
[14:15:37] <alex_joni> motion has output to hal
[14:15:53] <alex_joni> there you can connect either a stepgen
[14:15:58] <alex_joni> or one for servos
[14:16:00] <alex_joni> etc
[14:16:13] <alex_joni> to command your hardware (be it servos, or steppers, etc)
[14:16:22] <alex_joni> motion is realtime
[14:16:30] <fenn> okay, now say i want to have something a little more interactive, like controlling a robot that responds to its environment
[14:16:50] <alex_joni> depends on where you want the feedback
[14:16:55] <alex_joni> "motion" is realtime
[14:17:08] <fenn> probably don't need realtime feedback
[14:17:14] <alex_joni> that means no (NO) communication libraries are suitable
[14:17:22] <alex_joni> all communication is done through shm
[14:18:11] <alex_joni> fenn: got it so far?
[14:18:32] <fenn> alex_joni, yeah
[14:18:48] <alex_joni> ok.. so TP needs to write motion commands in a SHM
[14:19:05] <alex_joni> on the other hand TP gets data from the interp
[14:20:17] <fenn> i like having flexibility though
[14:21:02] <fenn> right now emc only takes gcode in and spits out motion based on certain assumptions i may not agree with for the particular application
[14:21:24] <fenn> like, "adhere to path" is more important than "constant speed"
[14:22:29] <fenn> i feel like if the whole system were more modular and flexible, i could easily adapt it to my needs without bugging the developers about little things like that
[14:23:04] <SWPadnos> path following mode is settable with a G code
[14:23:17] <fenn> arg
[14:23:26] <SWPadnos> I agree that flexibility would be nice at a higher level like the interpreter
[14:23:54] <fenn> * fenn really hates G code.
[14:24:02] <SWPadnos> so you could connect a STEP interpreter to your motion system and/or a G code interpreter, and an STL interpreter, etc.
[14:24:10] <alex_joni> right
[14:24:11] <fenn> right!
[14:24:27] <SWPadnos> and, different trajectory planners as well
[14:24:33] <alex_joni> fenn: by the time you deliver the STEP interp. the TP will be ready
[14:24:35] <alex_joni> ;)
[14:24:39] <SWPadnos> (which are all compiled into task atm, I think)
[14:24:52] <alex_joni> SWP: but from different sourcefiles
[14:25:07] <SWPadnos> yes - the source is ,modular but the ex ecutable isn't
[14:25:22] <fenn> alex_joni, i have to learn "real world" programming first, dunno how long that will take
[14:25:26] <SWPadnos> which is kind of backwards
[14:26:25] <fenn> SWPadnos, it's that way because it's easier for the developers
[14:26:37] <fenn> if it were the other way around it would be easier for the users
[14:26:46] <SWPadnos> I know - it's just conceptually wrong :)
[14:27:06] <SWPadnos> but, the TP is more important than completely redesigning the interpreter at this point
[14:27:12] <fenn> yeah
[14:27:16] <alex_joni> agreed on that
[14:27:36] <SWPadnos> I should have my mother read the sonja and rogier documents
[14:27:47] <alex_joni> your mother?
[14:28:02] <SWPadnos> She's a mathematician/programmer (/chemist/physicist)
[14:28:09] <alex_joni> coo
[14:28:21] <SWPadnos> she likes the math a lot more tha n I do
[14:28:23] <alex_joni> * alex_joni joins the club urging SWP's mother to read the stuff
[14:28:43] <fenn> math is really easy when they show you the shortcuts
[14:28:43] <SWPadnos> but she has a mental block on geometry, and therefore 3-d stuff :)
[14:29:00] <alex_joni> can she do mental quintics?
[14:29:03] <alex_joni> ;)
[14:29:05] <SWPadnos> just for fun, she bought a couple of books on the calculus of variations (whatever that is)
[14:29:27] <alex_joni> * alex_joni goes home
[14:29:32] <SWPadnos> see ya later
[14:29:33] <alex_joni> I'll be online later tonight
[14:29:36] <fenn> * fenn waves
[14:29:36] <alex_joni> bye guys
[14:29:55] <alex_joni> if you get les around.. maybe you'll start a wiki, or a message to the dev list
[14:30:33] <fenn> both seems like a good idea
[14:30:54] <fenn> wikis get ignored, messages to the dev lists get thoroughly discussed then forgotten
[14:32:04] <SWPadnos> indeed
[14:32:35] <fenn> jmk is really good at writing documentation, so i understand hal very well, but the rest of it is all a big mystery to me
[14:33:07] <SWPadnos> do you have the emc2 diagram?
[14:33:24] <fenn> ah, the mystical emc2 diagram. is that a cabalistic document?
[14:33:32] <fenn> no i've never heard of it
[14:34:00] <SWPadnos> there's a pretty good block diagram showing where all the components fit, and what communicates with what
[14:34:17] <SWPadnos> I'll see if I can find it
[14:34:29] <rayh> We can do this now, excuse me Alex, within the confines of the canon available.
[14:34:40] <fenn> alex left
[14:34:48] <SWPadnos> are you waxing biblical again?
[14:35:04] <fenn> SWPadnos, yea.
[14:35:12] <rayh> Ah. Sorry guys.
[14:35:18] <SWPadnos> no - that's "Yea, verily"
[14:36:01] <rayh> Do we have some TP change plan?
[14:36:31] <fenn> first of all, what source file is the current TP in?
[14:36:33] <SWPadnos> yes.
[14:36:37] <SWPadnos> step 1: fix it :)
[14:36:46] <SWPadnos> step 2: tell the world it's fixed.
[14:36:55] <SWPadnos> step 3: profti!!!
[14:37:01] <SWPadnos> I mean profit!!!
[14:37:11] <rayh> Ah. The old US Gov ploy!
[14:37:25] <fenn> s/profti/deal with headaches from 500 new users
[14:37:25] <SWPadnos> no - that starts at step 2 :)
[14:39:54] <fenn> ah! tp.c was hiding in the "attic" all this time
[14:43:30] <SWPadnos> how about emc2/src/emc/kinematics/tp.[ch]
[14:44:55] <fenn> emc2/src/emc/motion/tp.c is version 1.2, versus version 1.11 in kinematics. dunno if version numbers mean anything
[14:45:52] <fenn> oh damn 1.11 is higher than 1.2 nevermind
[14:46:33] <fenn> i hate sub-versions greater than 9
[14:47:06] <paul_c> Get used to it - Those numbers are CVS versions
[14:48:34] <fenn> paul_c, any idea where i can find the emc2 block diagram?
[14:48:51] <paul_c> ask JMK
[14:49:24] <paul_c> Thers's also a pdf in docs/
[14:50:05] <fenn> found it, thanks
[14:50:33] <fenn> EMC2_Code_Notes.pdf
[14:51:34] <SWPadnos> that's not the one I'm thinking of - it's a jpeg, I think.
[14:52:45] <SWPadnos> OK - it's called emc_control_LG.gif
[14:53:13] <SWPadnos> http://home.att.net/~jmkasunich/EMC_Docs/EMC_Control_LG.gif
[14:54:05] <fenn> i never would've found that
[14:54:25] <fenn> the page isn't even there anymore
[14:54:34] <fenn> (the image still is)
[14:54:58] <SWPadnos> I found my local copy, googled, found an irc log, and got the link from there :)
[14:57:01] <fenn> thanks swp
[14:59:50] <fenn> interpolator runs in joint space??
[14:59:52] <fenn> that's dumb
[15:03:37] <fenn> i'd also think that unit conversion would be above kinematics; would simplify code since you don't need to remember which unit you're using
[15:03:47] <SWPadnos> well - if you are moving along a cartesian axis, but you have a polar robot (puma-like), then you really want to do smoothing based on the path the actuator will take
[15:04:28] <SWPadnos> I thought the same thing, but there's a problem with that - different machines have different mechanical unit systems
[15:05:09] <SWPadnos> there would be a small but measurable error if you always used inches, but your machine had a 2mm pitch ballscrew
[15:05:24] <SWPadnos> (or the other way around - I can't remember)
[15:05:41] <fenn> no, inches is defined at 25.4 mm exactly
[15:05:57] <fenn> so if your calculations are more than 3 sig figures there won't be any error
[15:06:00] <SWPadnos> yes, but what's amillimeter in inches?
[15:06:06] <SWPadnos> 0.0393407lkjasdhflkjasdhglaksjdfhg
[15:06:25] <SWPadnos> 1/25.4 isn't so nice a number
[15:06:56] <SWPadnos> (look at 1/3 - you need more than 1 sig dig to get accurate results)
[15:08:47] <fenn> just seems like a lot of realtime processing power going to waste
[15:08:49] <anonimasu> iab
[15:09:06] <anonimasu> finally back at work.
[15:09:23] <anonimasu> hm, did you come to a conclusion?
[15:09:29] <SWPadnos> well - conversions are easy - it's a single multiply or divide
[15:09:41] <fenn> simple * 1000 times a second
[15:09:45] <cradek> fenn: that error doesn't matter, as long as it's not cumulative.
[15:09:54] <cradek> err, SWPadnos:
[15:10:06] <SWPadnos> simple * 1000 times per sec / 1,000,000,000 cycles/sec :)
[15:10:19] <anonimasu> are you at the TP atm?
[15:10:35] <SWPadnos> no - I'm at the computer - the TP is in the bathroom
[15:10:40] <anonimasu> and what are you discussing please fill me in :D
[15:10:43] <fenn> we're talking about overall layout of emc2
[15:10:48] <anonimasu> ah ok
[15:12:03] <anonimasu> fenn: the trouble with modularity is that you cant make everyone happy..
[15:12:05] <anonimasu> ever
[15:12:28] <SWPadnos> right - it's either too inflexible or too hard to configure :)
[15:12:45] <anonimasu> everyep
[15:12:55] <anonimasu> it ends up at the skill of the developer in the end.
[15:13:19] <SWPadnos> I was just having a discussion about the phrase "easy to use"
[15:13:24] <SWPadnos> and what it means to different people
[15:14:07] <anonimasu> I'd define it as a efficient and self explaining but powerful interface..
[15:14:39] <anonimasu> if we are talking about GUI, but I assume that because that's what the user see..
[15:14:42] <SWPadnos> self explaining to whom? a programmer? a machinist? a photographer? etc. (it's harder than you think :) )
[15:15:08] <fenn> anonimasu, that definition should work for both text and graphical interfaces
[15:15:09] <anonimasu> "the user"
[15:15:12] <anonimasu> yeah
[15:15:32] <anonimasu> my customers dont give a shit what I stuff into the plc's as long as it works.
[15:15:49] <anonimasu> ;)
[15:16:20] <fenn> the user in this case probably doesn't know anything about Gcode, programming, or linux
[15:16:25] <anonimasu> yep
[15:16:31] <anonimasu> the user wants to crank out parts..
[15:16:48] <fenn> he wants it to "just work dammit"
[15:17:01] <anonimasu> yep
[15:17:05] <anonimasu> that's what I define easy to use as..
[15:17:10] <anonimasu> emc is not easy to use.
[15:17:11] <anonimasu> :D
[15:17:24] <SWPadnos> it seems easy for paul_c :)
[15:17:31] <fenn> i thought bdi 4.20 worked pretty well first time i used it
[15:17:40] <fenn> setting offsets was aggravating
[15:17:53] <anonimasu> yep
[15:18:13] <anonimasu> easy to use perhaps..
[15:18:16] <anonimasu> not to set up and tweak..
[15:18:54] <anonimasu> aunt tilly(tm)
[15:18:58] <anonimasu> ^_^
[15:19:17] <fenn> probably should trademark that if emc ever gets popular :)
[15:20:01] <anonimasu> hehe
[15:20:08] <anonimasu> users generally dont give a shit as long as things work..
[15:20:08] <anonimasu> :)
[15:20:31] <anonimasu> after all a mill is a tool..
[15:20:31] <A-L-P-H-A> anything stopping me from using O1 DRILL ROD, grinding it, heating it to a cherry read, and dunking it into oil, to product a boring bar?
[15:20:47] <fenn> A-L-P-H-A, worked for me :)
[15:20:48] <anonimasu> A-L-P-H-A: I wouldnt think anything does..
[15:21:13] <A-L-P-H-A> well, the better question is, will it work?
[15:21:22] <anonimasu> if you get it "hard"
[15:21:23] <anonimasu> it will
[15:21:36] <fenn> cherry red is a little hot imho
[15:21:37] <cradek> A-L-P-H-A: I think it might be a little brittle if you don't anneal it afterward
[15:21:38] <anonimasu> I dont know what's involved in hardening drillrod..
[15:21:50] <anonimasu> or how hard you have to harden it..
[15:21:53] <anonimasu> rc60 ;D
[15:22:11] <cradek> A-L-P-H-A: I think you get hardening instructions from the manufacturer
[15:22:51] <A-L-P-H-A> 'ight
[15:22:59] <cradek> A-L-P-H-A: if you're not cutting with it, you don't have to harden it, do you?
[15:23:06] <paul_c> temper to 450 Deg F
[15:24:00] <cradek> paul_c: that just means after the oil drop, bake it in the oven for a while, right?
[15:24:01] <A-L-P-H-A> I'm making it into a internal grooving tool
[15:24:21] <paul_c> cradek: yup.
[15:24:23] <cradek> A-L-P-H-A: oh so you are cutting with it
[15:24:28] <A-L-P-H-A> yes.
[15:25:20] <cradek> then try to just harden the cutting end.
[15:25:45] <A-L-P-H-A> that was what I was gonna try.
[15:25:46] <cradek> heat until the business end is barely red (don't burn it), drop in oil, anneal
[15:26:06] <A-L-P-H-A> anneal it is heat it up again?
[15:26:15] <cradek> yes, an extended bake at a lower temperature
[15:26:37] <A-L-P-H-A> hmm... I don't think I can do that... unless I leave it in the oven.
[15:26:55] <cradek> just throw it in your (kitchen) oven
[15:27:09] <A-L-P-H-A> hmm.
[15:27:24] <cradek> when you heat it to red with the torch, don't put the torch on the cutting edge - apply it to the underside and watch the cutting edge for color.
[15:27:44] <A-L-P-H-A> thanks. any more tips?
[15:28:20] <cradek> I think that's it
[15:28:22] <A-L-P-H-A> you know... maybe I'll just get a long piece of highspeed steel instead.
[15:28:34] <fenn> gotta polish off the black oxide so you can see what color the tip is when you're annealing it
[15:28:35] <A-L-P-H-A> seems easier right now, than heating and annealing all that.
[15:28:53] <cradek> well, that's what I do I guess
[15:28:59] <fenn> you should learn heat treating if you wanna be a machinist
[15:29:31] <fenn> never know when you might need it
[15:29:37] <A-L-P-H-A> true
[15:29:54] <anonimasu> do you heat treat tool steel yourself or do you send it in to do it?
[15:30:23] <fenn> depends on how critical it is that i get it right
[15:30:35] <fenn> nothing I do is critical so i do it myself
[15:31:23] <fenn> i wouldn't heat treat my own camlock pins cause my life is at risk if one of them breaks and a 50 lb chuck goes flying
[15:32:07] <anonimasu> wuzz! :D
[15:33:33] <anonimasu> *yawns*
[15:34:22] <anonimasu> maybe I should finish up my work and go and get some food
[15:34:23] <anonimasu> and a break
[15:53:19] <A-L-P-H-A> anyone think this is an AC or DC motor?
http://www.harborfreight.com/cpi/ctaf/Displayitem.taf?itemnumber=33833
[15:58:53] <fenn> look at the manual (green button on bottom of page)
[16:00:28] <fenn> it's got brushes..
[16:01:11] <robin_sz> afternoon
[16:01:19] <fenn> fenn is now known as fenn_afk
[16:22:05] <rayh> A-L-P-H-A: I'd be willing to bet it runs perfectly well on AC.
[16:57:07] <robin_sz> phew ... another job done
[16:57:19] <robin_sz> * robin_sz finishes another series of auctions
[16:58:22] <robin_sz> ooh, alex
[16:58:26] <alex_joni> hey robin
[16:58:37] <robin_sz> dude!
[16:58:41] <alex_joni> what's up?
[16:58:58] <robin_sz> we just cmpleted a series of auctions in Geneva .. no problems, me happy
[16:59:37] <alex_joni> nice
[16:59:45] <alex_joni> big comissions?
[16:59:54] <robin_sz> oh yeah :)
[17:00:02] <alex_joni> nice
[17:00:03] <robin_sz> 15% from the buyers
[17:00:10] <alex_joni> * alex_joni prepares to watch #3
[17:00:13] <robin_sz> plus a simialr amount forem sellers
[17:00:17] <robin_sz> :)
[17:05:20] <alex_joni> later guys
[17:05:32] <alex_joni> I'm off watching the final part of the saga
[17:06:46] <A-L-P-H-A> f@ck. just dropped another $100
[18:42:32] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/emc/Makefile:
[18:42:32] <CIA-4> Lost a few of the sanity checks on P & Q words during the merge - Some of the
[18:42:32] <CIA-4> canned cycles will fault out if passed a negative value (as will G04). Also
[18:42:33] <CIA-4> gained a few unwanted #ifdefs around some of the M functions - These should be
[18:42:33] <CIA-4> stubbed in the canonicals rather than the interpreter.
[18:42:52] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/emc/ (19 files in 2 dirs):
[18:42:52] <CIA-4> Lost a few of the sanity checks on P & Q words during the merge - Some of the
[18:42:52] <CIA-4> canned cycles will fault out if passed a negative value (as will G04). Also
[18:42:52] <CIA-4> gained a few unwanted #ifdefs around some of the M functions - These should be
[18:42:52] <CIA-4> stubbed in the canonicals rather than the interpreter.
[18:44:33] <CIA-4> 03paul_c 07bdi-4 * 10emc2/src/emc/global_defs.h: Need global_defs.h to go with the merged interp.
[18:51:30] <CIA-4> 03paul_c 07bdi-4 * 10emc2/generic.ini: Get rid of a couple of obsolete entries.
[19:00:34] <CIA-4> 03paul_c 07bdi-4 * 10emc2/generic.ini: Added notes about STEPPING_TYPE to the ini.
[19:43:47] <les> well I am back for a little while but everyone is gone?
[19:45:07] <les> was looking at g92/% thread on the list
[19:45:22] <les> good grief!
[19:45:39] <les> I think I will steer clear....
[19:46:26] <les> hi alex
[19:46:34] <les> back for a little while
[19:46:41] <alex_joni> hey les
[19:46:44] <alex_joni> same here
[19:46:50] <Phydbleep> * Phydbleep wakes up and looks out from under the flat rock..
[19:47:00] <alex_joni> anything interesting while I was gone?
[19:47:13] <Phydbleep> What are you people making all this noise about?
[19:47:19] <les> I just read back
[19:47:24] <alex_joni> trajectory planner
[19:47:48] <alex_joni> and the fact there are slight "imperfections" with emc
[19:47:52] <les> just a little TP discussion
[19:48:02] <alex_joni> to call it nicely ;)
[19:48:28] <les> I saw whether you were wondering if I was leaving emc
[19:48:33] <les> only kinda
[19:48:41] <Phydbleep> Ah, And I was just about to remind A-L-P-H-A that a drop of superglue will keep the $100 bill on the end of his finger instead of leaving it in the bra. :)
[19:48:43] <alex_joni> I think I read one of your posts
[19:48:54] <alex_joni> Fido: lol
[19:49:02] <les> I can use it on a bridgeport or something
[19:49:20] <alex_joni> les: it's a shame that you won't use it on your mill anymore :(
[19:49:39] <les> But I have to pull it from the big router pretty soon because production is beginning again
[19:50:10] <alex_joni> how come the change?
[19:50:17] <alex_joni> wanna go faster with it?
[19:50:24] <les> I sure don't want too...it's work and will cost many thousand dollars
[19:50:54] <les> alex, I am running at one third speed or less due to the TP
[19:50:58] <alex_joni> well.. you know how big blue puts it :)
[19:51:11] <alex_joni> never touch a running system :P
[19:51:19] <les> yeah
[19:51:20] <alex_joni> but I agree on the speed stuff :(
[19:51:34] <alex_joni> and in your case.. it's not running how it should
[19:51:35] <les> I would rather leave it alone for sure
[19:51:44] <alex_joni> still.. as I said.. it's a shame
[19:52:03] <alex_joni> * alex_joni wishes he paid more attention during those boring math classes
[19:52:23] <alex_joni> I vaguely remember how to solve integrals :)
[19:52:36] <les> I think emc will still be useful for some simple shapes on bridgeport
[19:52:51] <les> as long as I don't try to make molds or something
[19:53:11] <SWPadnos> regarding G92 - I think I may have found a work-around, and the source of the problem in the interpreter
[19:53:26] <SWPadnos> (sorry to steer back to that)
[19:53:27] <alex_joni> makes me wonder... did you always have this problems?
[19:53:34] <alex_joni> SWP: no sweat
[19:53:34] <les> It might still have it's problems on a BP at higher speeds cutting plastic and stuff
[19:53:45] <Phydbleep> alex_joni: I'm actually glad I ignore 90% of the math classes.. I didn't have any pre-conceptions about how quaternions should work when I had to learn them for VR stuff.
[19:54:11] <paul_c> SWPadnos: Problem. Some people have difficulty in using G92 correctly.
[19:54:18] <alex_joni> Phydbleep: heh.. well I think I'll need to read some old courses of mine :)
[19:54:28] <paul_c> SWPadnos: Answer: Remove user and/or G92
[19:54:30] <SWPadnos> true enough, but there is something that I consider a problem in the interpreter
[19:54:37] <les> I always had the problems. Fred confirmed years ago that it was the TP.
[19:54:49] <alex_joni> paul_c, SWP: send that guy a patch file, let's see if he does anything with it :)
[19:55:21] <SWPadnos> I didn't make a patch, but I think a workaround is to issue a G92.3 after the M02 (in his example code)
[19:56:02] <Phydbleep> What's the M30 do? I heard it will clear the G92 as well.
[19:56:20] <SWPadnos> it stops using offsets, but doesn't clear the variables
[19:56:42] <paul_c> http://www.isd.cme.nist.gov/personnel/kramer/pubs/RS274NGC_3.pdf - see P.38
[19:57:00] <les> I only use it to touch off in MDI...it's very handy for that. The turkey code uses an mdi g92, g10 and all 9 coordinate systems, and numerous G43
[19:58:39] <alex_joni> turkey?
[19:59:34] <Phydbleep> alex_joni: Turkey calls
[20:00:04] <cradek> les: for that same money, could you commission the work you want done on emc?
[20:00:07] <Phydbleep> What would G28/G30 do to G92?
[20:00:43] <alex_joni> les: maybe to cradek?
[20:00:48] <alex_joni> kidding :)
[20:00:50] <cradek> uh-oh
[20:01:02] <alex_joni> he wouldn't charge you, he's a nice fellow
[20:01:22] <SWPadnos> I would (and I'm still a nice fellow :) )
[20:01:33] <SWPadnos> this is business - heh heh
[20:01:41] <alex_joni> * alex_joni strikes SWPadnos from the nice fellows list
[20:02:03] <alex_joni> so.. what are we gonna do about TP?
[20:02:24] <les> whoops was away...
[20:02:40] <Phydbleep> * Phydbleep hands alex_joni a Sears-Roebuck catalog.
[20:02:44] <alex_joni> les: anything else bugging you about emc bad enough? or for now it's only TP?
[20:02:46] <les> $5000 buys very little software I think....
[20:02:56] <alex_joni> les: depends where you buy
[20:02:58] <les> custom written
[20:03:13] <alex_joni> les: a decent programmer gets about 4-500 / month here
[20:03:20] <SWPadnos> Thay's 60+ hours from me - easily several comment blocks :D
[20:03:27] <Phydbleep> les: Get you 200 hours here. :)
[20:03:47] <alex_joni> 5k = 10 months = 2000 hrs
[20:03:49] <les> No it's only the TP...the rest of emc is stable, versatile, and what I would consider to be fairly modern
[20:04:07] <alex_joni> well.. there are a few bits that need some bending imho
[20:04:09] <SWPadnos> all this toilet paper, and no place to ...
[20:04:14] <alex_joni> but that's ok :)
[20:04:32] <cradek> I wish I had a paper describing TP like I have for SQ
[20:05:07] <les> I'll tell you one thing...i'll put off chnging the router control as long as I can
[20:05:22] <cradek> I'd at least try to hack in arc blending
[20:05:22] <les> That is something very easy to put off!
[20:06:09] <cradek> les: what is the exact problem causing you to want to change? is it arc blending or jerk?
[20:06:15] <Phydbleep> les: You already have a control head that will drive it like you want?
[20:06:23] <alex_joni> cradek: it's queue starvation
[20:06:27] <les> Well I kinda offered to try a pseudocode document on a joint space planner
[20:06:35] <les> given the time
[20:06:48] <alex_joni> les: that would be great.. and something to code by
[20:07:04] <les> But I am worried that what I write up will not be easy to integrate into existing code
[20:07:16] <alex_joni> never mind that
[20:07:22] <alex_joni> you write it how it should be
[20:07:40] <cradek> I'd sure as heck read it
[20:07:48] <alex_joni> we'll figure out the rest (not wanting to sound like a smartass)
[20:07:55] <les> it starts with coordinated motion calcs
[20:07:57] <Phydbleep> les: Yeah, Other people will will have to tear their hair out.
[20:08:00] <Phydbleep> :)
[20:08:16] <les> then filtering with a fir
[20:08:21] <alex_joni> if it doesn't fit in.. we can still rip out the old code, and redo it
[20:08:22] <les> then resampling
[20:08:52] <les> then blended cubics
[20:09:51] <les> but I can't imagine doing all that in RT
[20:10:03] <paul_c> forget RT.
[20:10:08] <alex_joni> les: does it need to be in RT?
[20:10:19] <les> ok.
[20:10:24] <Phydbleep> * Phydbleep thought alll that should be pre-calc'd and canned to feed the queue.
[20:10:31] <alex_joni> I think given a big enough queue it can be done in non-RT
[20:10:32] <les> Given memory...no it does not
[20:10:52] <alex_joni> and motion should only grab one segment at a time, and move
[20:10:59] <alex_joni> that's it
[20:11:12] <alex_joni> would speed up the RT stuff
[20:11:20] <les> but that means perhaps the whole gcode program must be planned
[20:11:24] <alex_joni> maybe make it work faster (step pulse wise)
[20:11:41] <alex_joni> that will probably take a while on big programs
[20:12:03] <les> Unless there is a lot of spare time in the RT thread
[20:12:08] <SWPadnos> and the planning goes out the window if a feedrate over-ride is done (or pause/resume)
[20:12:23] <les> I have that covered SWP
[20:12:44] <les> plan using max over ride
[20:12:48] <SWPadnos> rihgt - you wanted to calculate for the max speed, then slow down
[20:13:18] <alex_joni> les: that way (planning from the beginning) you can warn the user if there are any problems
[20:13:25] <les> then if time scaling is done in the RT code the plan will still honor max vel and accel at lower speeds
[20:13:31] <alex_joni> say the machine can't keep up to the speed demanded
[20:13:32] <SWPadnos> it's like a super-verify
[20:13:43] <alex_joni> right
[20:14:06] <alex_joni> paul_c: what are you working on currently?
[20:14:08] <SWPadnos> that was one place I was headed yesterday (when I was so rudely interrupted by a phone call)
[20:14:14] <les> The planner is responsible for calculating moves that the machine can always do
[20:14:23] <les> it knows max vel and accel
[20:14:35] <A-L-P-H-A> that was a good nap.
[20:14:42] <A-L-P-H-A> les, hell well do shell reamers work?
[20:14:42] <SWPadnos> and can therefore tell you that a feature is too small or the speed is too high
[20:14:53] <alex_joni> there was an issue about max vel / path following
[20:15:16] <les> shell reamers work fine!
[20:15:40] <les> well path following issues I think would be a function of the resampling rate
[20:16:01] <alex_joni> how so?
[20:16:06] <les> note the low pass filter before resampling
[20:16:18] <les> that is for anti-alias
[20:16:21] <alex_joni> right
[20:16:45] <les> phone...
[20:16:50] <alex_joni> heh
[20:16:59] <Phydbleep> A-L-P-H-A: The ones i've use have been OK.
[20:17:51] <A-L-P-H-A> cool.
[20:18:24] <les> ok
[20:18:33] <alex_joni> short one
[20:18:42] <les> yeah
[20:18:52] <alex_joni> nice
[20:19:01] <les> Website creation and management lessons.
[20:19:06] <Phydbleep> A-L-P-H-A: I've actually got an adjustable dia reamer I use when it will fit.
[20:19:20] <alex_joni> lesson #1 : don't use flash
[20:19:37] <les> heh
[20:19:43] <Phydbleep> Lesson 2: See Lesson #1
[20:19:46] <alex_joni> lesson #2: whenever in doubt about graphics remember rule #1
[20:19:51] <A-L-P-H-A> see, I saw those, I don't wanna fiddle with adjusting the screw to get the exact dia I want.
[20:19:52] <les> this is more how ftp works, etc.
[20:20:10] <alex_joni> lesson #3: when using ftp, don't use flash
[20:20:17] <les> heh
[20:21:02] <les> they are set up with cuteftp, photofiltre, web album generator, and a couple other programs.
[20:21:21] <alex_joni> as long as it's not flashftp :)
[20:21:32] <alex_joni> right.. back to serious stuff
[20:21:38] <les> k heh
[20:21:43] <Phydbleep> Lesson 4: When thinking about using Flash, Seek competent psychiatric help.
[20:23:22] <alex_joni> Lesson 5: make sure shrink doesn't use flash
[20:24:42] <Phydbleep> Lesson 6: There is no Lesson 6.
[20:25:12] <les> Not using it...although the software can....
[20:25:17] <Phydbleep> And finally Lesson 7: NO FLASH!
[20:25:24] <les> gulp
[20:25:36] <alex_joni> wanna know a secret?
[20:25:38] <les> ok...calm down...haha
[20:25:49] <les> yeah.
[20:25:50] <alex_joni> * alex_joni did some flash :)
[20:26:02] <Phydbleep> alex_joni: You've been flashing your shrink?
[20:26:16] <alex_joni> I've been flashing strangers :))
[20:26:38] <Phydbleep> Pro-Vert!
[20:26:49] <Phydbleep> * Phydbleep is betting he got paid for it. :)
[20:27:06] <alex_joni> generously
[20:27:33] <les> oh no...just discovered I left the usb cable in the camera overnight
[20:27:40] <les> dead batteries!
[20:28:02] <les> oh well
[20:28:33] <les> have to run out for a minute
[20:28:40] <alex_joni> yet another one of those mysteries
[20:28:48] <alex_joni> USB should provide POWER
[20:28:56] <alex_joni> not drain :)
[20:30:01] <SWPadnos> may keep it from poering down
[20:30:07] <SWPadnos> powering, that is
[20:30:31] <Phydbleep> it should still not drain the batteries in the device. :\
[20:31:03] <SWPadnos> no, but the device itself would drain the batteries overnight (he didn't mention if the cable was plugged into a computer, or if the computer was on :) )
[20:31:51] <Phydbleep> There should be a disconnect like for the AC/Battery switching in a boombox.
[20:32:28] <Phydbleep> Plug the cable in and it cuts the internal battery connection.
[20:35:10] <SWPadnos> nope - not on a USB device
[20:35:51] <SWPadnos> it's generally done in logic, and the device may not be USB powered (most cameras probably draw more current than USB can provide)
[20:37:20] <Phydbleep> This Kodak has a xfer setting that just allows data xfer.
[20:38:32] <Phydbleep> It 'should' just turn the camera into a USB powered CF reader... Instead it eats batteries faster that using the flash/display.
[20:39:14] <alex_joni> heh
[20:39:23] <alex_joni> nice thingy for accumulators
[20:39:37] <alex_joni> need to discharge them fast? transfer some pictures
[20:39:39] <Phydbleep> So I pop the CF card out and stick it in a PCMCIA reader. :)
[20:39:42] <alex_joni> les: still around?
[20:39:51] <SWPadnos> USB can only provide either 100 or 500 mA t oa device - the camera probably takes 1A or more
[20:40:11] <alex_joni> Phydbleep: I liked CF.. until I switched to SD
[20:40:23] <Phydbleep> SWPadnos: Whaich is stupid for reading a CF card. :\
[20:40:25] <alex_joni> my laptop has an SD slot, that makes it just so easy
[20:40:44] <SWPadnos> that's why you have a bus-powered CF reader :)
[20:41:00] <Phydbleep> alex_joni: Yeah, That's why I spent $7 on the PCMCIA>CF adapter. :)
[20:41:18] <alex_joni> I wonder why I got me a docking station for the cam
[20:41:22] <alex_joni> and never unpacked it
[20:41:24] <alex_joni> :)
[20:41:46] <Phydbleep> alex_joni: Will it recharge the batteries in the camera?
[20:41:55] <alex_joni> sure it can turn the Camera to an USB master, and I would be able to connect it to a printer
[20:42:02] <alex_joni> but why the fsck would I want that
[20:42:07] <SWPadnos> what camera?
[20:42:21] <alex_joni> Phydbleep: plugging the AC adapter charges the batteries
[20:42:25] <alex_joni> HP 850
[20:42:36] <SWPadnos> ah - the PhotoSmart series?
[20:42:47] <SWPadnos> or something like that
[20:43:33] <alex_joni> yup
[20:43:40] <alex_joni> 4MP, 8x optical
[20:46:29] <alex_joni> pretty old too :)
[20:47:01] <SWPadnos> yeah - it looks big for a small acmera :)
[20:47:03] <SWPadnos> camera
[20:47:16] <alex_joni> it's not that small
[20:47:34] <alex_joni> neither big enough
[20:47:39] <alex_joni> *g*
[20:52:56] <alex_joni> SWP: how about TP?
[20:53:15] <SWPadnos> sorry - was AFK for a mo
[20:53:38] <alex_joni> nm
[20:55:35] <SWPadnos> well - starting at the machine, and working backwards to the planner...
[20:55:58] <SWPadnos> we have a certain feature size / feedrate that we want to support
[20:56:08] <alex_joni> right
[20:56:17] <SWPadnos> this implies (or is defined by) a max acecleration for the machine
[20:56:17] <alex_joni> not necessarely in m/min
[20:56:29] <alex_joni> or m/s^2
[20:57:01] <alex_joni> also need to remember smthg like : 10000 segments / sec
[20:57:05] <SWPadnos> so any feature has to be a certain size to be possible at a given feedrate
[20:57:52] <SWPadnos> the number of segments/sec is determined by the feature size and feedrate, for any non-trivial moves
[20:58:06] <SWPadnos> (ie, a single line split into many smaller segments)
[20:58:24] <SWPadnos> it should be trivial to combine that type of thing
[20:59:07] <SWPadnos> so now we're at the point where we need to decide how far ahead we need to look to get good planning
[20:59:30] <SWPadnos> unfortunately, the lookahead increases as the feedrate increases, because the limitation is the machine acceleration
[21:00:44] <SWPadnos> *then* we start talking about which algorithms to use to blend segments
[21:00:51] <SWPadnos> etc.
[21:02:04] <SWPadnos> It may be that the groundwork is already well understood and I missed it :)
[21:04:44] <SWPadnos> I also think there's a conceptual problem with the output to the motor drivers being a velocity - that implies to me that there can be a large discontinuity in acceleration every servo cycle
[21:05:08] <SWPadnos> (if the output were torwue or acceleration, then it would make more sense)
[21:05:12] <SWPadnos> torque
[21:05:31] <alex_joni> hmmm
[21:05:53] <alex_joni> if you make it accel, then you'll have jerk
[21:06:08] <SWPadnos> well - a change in velocity implies acceleration
[21:06:13] <alex_joni> right
[21:06:20] <alex_joni> and a change in accel implies jerk
[21:06:29] <paul_c> The solution is to increase the servo rate until you are above the bandwidth of the system.
[21:06:55] <paul_c> or feed the DAC o/p through a filter.
[21:07:02] <alex_joni> lemme get this straight
[21:07:22] <alex_joni> TP gets segments (lines / arcs) from the interp
[21:07:38] <alex_joni> he does his funky math on it (filters, blending, etc.)
[21:07:50] <alex_joni> then spits out a queue with small motion chunks
[21:08:19] <alex_joni> say one motion chunk is to keep velocity constant, and for how long
[21:08:27] <alex_joni> or accel
[21:08:31] <alex_joni> or whatever
[21:08:43] <alex_joni> adn motion (RT) takes a chunk and runs it
[21:08:58] <paul_c> skip "funky" "filters" and replace "blending" with "crude algorithm"
[21:09:53] <alex_joni> well.. was thinking about the overall concept
[21:10:23] <paul_c> well, yes....
[21:10:37] <paul_c> TP takes a series of lines & arcs
[21:10:55] <paul_c> does some (limited) blending
[21:11:18] <paul_c> and spits out a queue of way points for the servo loop to hit
[21:12:06] <alex_joni> based on change in direction?
[21:12:07] <paul_c> (way point - current position) * constant = velocity command
[21:12:15] <alex_joni> or also change in speed?
[21:12:35] <alex_joni> I mean figuring out the waypoints
[21:14:11] <paul_c> A typical line (or segment) as it is passed to TP -
[21:14:34] <paul_c> end_x, end_y, end_z, velocty
[21:15:09] <paul_c> the last end points are the start points for the current segment
[21:15:54] <paul_c> TP looks at the velocity and the distance of the segment.
[21:16:53] <paul_c> based on the max velocity & max accel
[21:17:13] <paul_c> the calculated time of the move may be increased...
[21:17:47] <paul_c> Once TP knows the length of time the current segment will take
[21:18:06] <paul_c> it slices it up in to way points at the servo rate.
[21:19:40] <alex_joni> so not based on interp read velocity?
[21:19:58] <alex_joni> say you have F200 in the g-code
[21:20:12] <alex_joni> multiply that by the max override and use that as max_vel
[21:20:32] <alex_joni> that way you might get less waipoints, when not running at full speed
[21:21:26] <A-L-P-H-A> What's the SFM for cold rolled mild steel?
[21:21:39] <paul_c> so now the servo loop has to take in to account an ever increasing error....
[21:22:10] <alex_joni_laptop> what error is that?
[21:22:44] <paul_c> IF the servo loop was running in single shot mode, it might work....
[21:23:15] <paul_c> although it would probably go tits up when you try to run two or more axis.
[21:23:32] <alex_joni_laptop> how so?
[21:23:53] <paul_c> think about it - Three axis...
[21:23:59] <paul_c> three servo loops
[21:24:03] <alex_joni_laptop> actually 6
[21:24:08] <paul_c> all running at different speeds
[21:24:27] <alex_joni_laptop> yup.. but you have one waypoint
[21:24:32] <alex_joni_laptop> for all of the axes
[21:24:38] <alex_joni_laptop> X,Y,Z,A,B,C
[21:25:32] <paul_c> OK.... Now say Y is subject to an unusal loading that increases the following error
[21:26:00] <alex_joni_laptop> ok...
[21:26:13] <paul_c> way point[n+1] now needs the ferr added on
[21:26:35] <alex_joni_laptop> why?
[21:26:47] <paul_c> now the actual way point is not the same as the planned way point.
[21:26:59] <alex_joni_laptop> it still needs to go to the waypoint
[21:27:03] <alex_joni_laptop> to the planned one
[21:27:17] <alex_joni_laptop> or it should imho
[21:28:06] <paul_c> in which case, you can not use a single shot timer for the servo loop.
[21:28:19] <paul_c> so you are back to periodic timings
[21:28:36] <Phydbleep> ROFLMAO!
[21:29:03] <alex_joni_laptop> * alex_joni_laptop finds it conforting that at least somebody gets his laughs
[21:29:18] <Phydbleep> http://www.sky.com/skynews/article/0,,91059-13355259,00.html
[21:30:59] <Phydbleep> Sorry, This was just so awfully utterly ridiculous. :)
[21:31:34] <Phydbleep> I hope paul doesn't think I was laughing at him. :)
[21:31:49] <alex_joni_laptop> don't think so..
[21:47:08] <alex_joni_laptop> we can always code up some clothoids
[21:57:41] <anonimasu> iab
[21:57:45] <anonimasu> finally off work.
[21:58:06] <alex_joni_laptop> wb
[21:58:11] <anonimasu> thanks
[21:58:15] <anonimasu> 17 hours..
[21:58:21] <anonimasu> brb, eating dinner..
[21:58:40] <alex_joni_laptop> getting clear the deadline is near for an0n ;)
[21:58:56] <alex_joni_laptop> when he's at 25 h / day .. it's only a few days far away :D
[21:59:16] <anonimasu> alex_joni_laptop: oh, I was working on somthing else..
[21:59:43] <anonimasu> alex_joni_laptop: the racecar project..
[21:59:43] <alex_joni_laptop> heh
[21:59:53] <anonimasu> although I am going to take half of tomorrow off..
[22:00:04] <anonimasu> I am going to tig some stainless..
[22:01:00] <anonimasu> and lack of sleep isnt too good when welding thin stuff :)
[22:01:21] <anonimasu> alex_joni_laptop: lend me a robot ;)
[22:01:40] <Phydbleep> anonimasu: I saw a Fanuc for <$4k
[22:01:48] <anonimasu> I
[22:01:51] <anonimasu> I've seen it..
[22:02:18] <anonimasu> did you get anywhere with the discussion about TP?
[22:03:57] <alex_joni_laptop> not very far
[22:04:04] <Phydbleep> anonimasu: I think i saw something about pre-crunching the #'s (non-RT).
[22:04:05] <alex_joni_laptop> but we might start some coding
[22:05:33] <anonimasu> ok..
[22:07:12] <Phydbleep> Whee! The accelerometer samples are here.
[22:07:24] <Phydbleep> * Phydbleep gets out a magnifying glass.
[22:07:26] <alex_joni_laptop> heh
[22:07:41] <alex_joni_laptop> now.. stick a few in your pockets, then jump out the window
[22:07:47] <alex_joni_laptop> and tell us how it went
[22:07:51] <Phydbleep> 4mm X 4mm X <2mm
[22:08:20] <Phydbleep> +/- 18g, 100mV/g when VCC = 5V..
[22:08:44] <alex_joni_laptop> hmm.. not sure you'll survive 18g
[22:08:51] <alex_joni_laptop> -4g is tricky
[22:08:57] <alex_joni_laptop> +9 is doable
[22:09:58] <Phydbleep> I figure they should survive life as spin balancer parts. :)
[22:14:41] <alex_joni_laptop> * alex_joni_laptop goes to bed
[22:14:45] <alex_joni_laptop> too long day ;)
[22:15:21] <Phydbleep> G'night AJ. :)
[22:15:54] <alex_joni_laptop> night FIdo
[22:15:58] <alex_joni_laptop> et all
[22:17:45] <Phydbleep> * Phydbleep looks to see how many of the 16 tiny (0.5mm square) pads on the back of this really need to be connected.
[22:32:04] <les> well was away a bit longer than I thought
[22:32:12] <les> oh I read back
[22:32:23] <SWPadnos> heh - are we making any sense?
[22:32:36] <les> a comment about dac velocity or torque....
[22:32:49] <anonimasu> iab
[22:32:57] <les> either one works fine...it's the nature of PID
[22:33:09] <les> most machines send torque commands
[22:33:28] <SWPadnos> it's probably more the discontinuous nature of the control that has me going
[22:33:57] <SWPadnos> ie, it's a discrete time control, operating on a continuous-time machine
[22:34:03] <les> it is discontinuous but not due to using torque or velocity
[22:34:23] <les> it is discontinuous because it is a trapeziodal planner
[22:34:31] <SWPadnos> but as Paul pointed out, filtering and servo rate adjustments can fix that problem
[22:34:58] <SWPadnos> no - it's discontinuous because the calculations are applied every n seconds, rather than continuously
[22:35:12] <SWPadnos> it's fft vs. fourier
[22:35:29] <SWPadnos> (more precisely, DFT vs. real fourier series)
[22:35:31] <les> Well imagine a velocity vs time trapezoid...ok?
[22:35:46] <SWPadnos> sure - that's discontinuous also :)
[22:36:02] <les> now differentiate that
[22:36:09] <les> and it looks like?
[22:36:13] <SWPadnos> yes - you have impulses
[22:36:18] <les> right
[22:36:20] <SWPadnos> or step functions
[22:36:23] <SWPadnos> and that's bad
[22:36:37] <les> heaviside functions yeah
[22:36:42] <les> it is bad
[22:37:04] <SWPadnos> my point is that any curve following is effectively like a trapezoid, because the continuous curve is split into smaller line segments that are (obviously) non-collinear
[22:37:28] <les> a polygon yes
[22:37:41] <les> but that should be at the servo rate...very high
[22:37:49] <SWPadnos> right - that gives the same problem as a trapezoid, but on a smaller scale
[22:37:57] <les> perhaps a couple kilohertz
[22:38:11] <les> the motor is an integrator
[22:38:24] <SWPadnos> yep - that's where Paul's filtering comes in
[22:38:39] <les> so it's smooth
[22:39:13] <SWPadnos> roght - or at least withing the limits of "non-jerkiness"
[22:39:48] <SWPadnos> (sans typing errors)
[22:40:19] <SWPadnos> that's why I wanted to start at the machine performance specs, and work backwards into the planner requirements
[22:41:01] <les> yup
[22:41:20] <SWPadnos> but you (and Paul) may have already done that, at least in your heads
[22:42:40] <les> well that needs to be a consensus i guess
[22:43:07] <SWPadnos> yep - that's where I was leading yesterday with the question about max machine feedrate
[22:43:39] <SWPadnos> perhaps a wiki page "NewTrajectoryPlanner" with thoughts and performance goals would be in order
[22:44:01] <les> sure
[22:44:18] <les> i know what i need
[22:45:32] <les> I think it should be good enough for a light industrial router
[22:46:04] <les> It should be on a par with any modern control
[22:46:11] <les> providing...
[22:46:31] <les> the RT.user comms don't limit it too much
[22:46:48] <les> according to Paul that may be a real brick wall
[22:46:49] <SWPadnos> well - that's what we need "real" specs for
[22:46:56] <les> yeah
[22:47:26] <SWPadnos> if we can agree on a performance spec, and we can show that it's impossible with the current user<->RT comm method, then the conclusion is obvious for all of us
[22:48:00] <les> And I figure if one strives for a very good control....it will also be fine for hobby stuff.
[22:48:10] <les> but not the other way round...
[22:48:17] <SWPadnos> it shouldn't be any worse than a crappy control :)
[22:48:29] <SWPadnos> but possibly harder to configure
[22:48:53] <les> 200 microsecond and better I would consider very good at this point
[22:49:22] <SWPadnos> servo rate?
[22:49:27] <les> yeah
[22:49:54] <les> galil's cards are about 250
[22:49:59] <SWPadnos> there will probably be a fair amount of phase jitter at that rate
[22:50:24] <les> the kmotion card that I am getting in is 90.
[22:50:29] <SWPadnos> a DSP or FPGA would certainly make the jitter much lower, and probably can do a higher rate as well
[22:50:39] <SWPadnos> 90 uS?
[22:50:47] <les> 90 seems pretty good.
[22:50:52] <les> yeah!
[22:50:56] <SWPadnos> how many axes
[22:51:00] <les> 4
[22:51:03] <SWPadnos> not bad
[22:51:14] <les> yeah
[22:51:22] <les> it's a kilobuck
[22:51:24] <SWPadnos> I made a PID controller for a power supply that ran at a phase rate of 50 KHz
[22:51:37] <les> I am getting a freebie to eveluate
[22:51:44] <SWPadnos> 20 uS * 5 phases gave a 10 KHz update rate
[22:51:52] <SWPadnos> free = good ;)
[22:51:59] <les> it uses emc interpreter
[22:52:10] <les> but they wrote a new TP
[22:52:23] <SWPadnos> does it do the interpretation on the card?
[22:52:29] <les> it is not quite there I suspect...and they want some help
[22:52:35] <les> hence free boards.
[22:53:04] <SWPadnos> cool
[22:53:20] <les> They are doing non RT TP on the host and usb 2.0 flashing the dsp
[22:53:22] <SWPadnos> what is the company name? (I just searched for KMotion, but google came up with irrelevant stuff)
[22:53:33] <les> that could be problematic of course
[22:53:33] <SWPadnos> ah
[22:53:41] <les> hang on
[22:54:10] <SWPadnos> micromech?
[22:54:44] <SWPadnos> nope
[22:55:09] <les> http://www.dynomotion.com/Help/
[22:55:46] <les> check out the iir filter stuff in the pid
[22:56:18] <SWPadnos> filters are oh-so-pfast on a DSP - it's calculating the coefficients that's a bear
[22:56:34] <SWPadnos> fast, not pfast
[22:57:02] <SWPadnos> they generally take one cycle per element (so an 8-element filter takes 8 cycles, or 0.08 uS on this DSP)
[22:57:22] <les> See I really have a couple separate business problems...I have production jobs with my big router that run way too slow and...
[22:57:40] <SWPadnos> you want to make an affordable, yet good, router to sell :0
[22:57:43] <les> I have a router product that needs a good low cost control
[22:58:20] <les> $699 quan ten for software, card, amps, and all ain't bad
[22:58:37] <SWPadnos> well - having some embedded control is probably a good thing
[22:58:48] <les> but i'll bet it is not quite ready for prime time yet
[22:58:57] <SWPadnos> but it's not the greatest if the user has to re-flash the unit every time they make a program change
[22:59:13] <SWPadnos> (G-code program change that is)
[22:59:19] <les> I don't know...but will find out
[23:00:02] <les> the stuff on that page looks pretty neat
[23:00:21] <SWPadnos> yep
[23:00:22] <les> that's all I know at this point other that a long talk on the phone
[23:01:19] <les> They seemed reassured when I said the 274 interpreter part of emc was very good
[23:01:36] <SWPadnos> heh
[23:01:43] <les> They used that...and tossed the rest
[23:01:54] <les> said they could not figure it out
[23:02:15] <les> They wrote an SQ type planner
[23:02:58] <les> the three biquad iir filters in the pidff are very good
[23:03:14] <les> can put zeros on machine resonance poles
[23:03:38] <SWPadnos> yeah - good on a DSP, but nearly impossible on a (30x faster) x86 CPU
[23:03:49] <les> I think so
[23:04:36] <les> emc has one low pass
[23:04:50] <les> called SMOOTH_D or something
[23:04:56] <SWPadnos> is that a low pass filter, or slew rate limiting?
[23:05:12] <les> it is a fir filter
[23:05:16] <SWPadnos> the 4-point smoother in cubic.c?
[23:05:23] <les> no
[23:05:52] <les> I forgot where it is though...or even if it is being used
[23:06:24] <les> It is just a realization that differentiators blow up at high freq
[23:07:04] <les> difference equations might not...but they still can get big.
[23:07:49] <SWPadnos> yeah - integrators need to be clamped
[23:09:15] <les> itemc has anti windup
[23:09:19] <les> oops
[23:09:24] <les> has to
[23:11:36] <les> anyway I am wondering how my work time will be going...
[23:11:48] <SWPadnos> hmmm - too bad their software only seems to work on Windows
[23:12:20] <les> I want a couple or so days a week of engineering....and some production...and some extra time
[23:12:33] <SWPadnos> extra time is good
[23:13:21] <les> But Devilbiss is sending a bunch of competitor's electrostatic guns next day air...
[23:13:36] <les> I have to design a better spray gun system
[23:13:58] <SWPadnos> that sounds - um - fun. yeah - that's it, fun :)
[23:14:01] <les> Think they'll let me work on it two days a week?
[23:14:15] <SWPadnos> all customers are patient, caring individuals.
[23:14:21] <SWPadnos> they really want you to be happy
[23:14:21] <les> hahahaha
[23:14:29] <les> bftt
[23:14:30] <Phydbleep> ROFLMAO!
[23:14:34] <les> heh
[23:14:57] <Phydbleep> * Phydbleep wonders what SWPadnos has been smoking.
[23:15:04] <les> I am going to shock some people with these 100 kV guns
[23:15:07] <SWPadnos> customers
[23:16:19] <les> I don't even know what I will do yet
[23:17:26] <les> anyway I'll see how much extra time I get
[23:17:46] <les> if I switch from one job to another too fast I get confused
[23:18:28] <les> how about one week spray gun.....next week cnc?
[23:18:42] <les> back and forth
[23:18:53] <SWPadnos> OK by me - but you mnay need a full board vote to get off the hook so easily :)
[23:19:05] <les> haha
[23:19:24] <SWPadnos> hey - this is *volunteer* - the most demanding type of work there is
[23:19:29] <Phydbleep> * Phydbleep is too bored to vote and would rather watch les wriggle. :)
[23:20:16] <les> I have a fellowship with the parent company.....but...they still want inovation on que
[23:21:02] <les> Aw they are prob doing gant charts right now
[23:21:05] <les> bluh
[23:21:33] <Phydbleep> les: What about 10:00-12:00 sprayer, 12:00-13:00 Lunch, 13:00-15:00 CNC, 15:00-10:00 relax/chase women? :)
[23:21:52] <les> heh
[23:22:01] <les> sounds like a plan
[23:22:21] <les> pity I am out in the woods
[23:22:29] <les> oh there are women...
[23:22:36] <les> but they have no teeth.
[23:23:18] <SWPadnos> 1500-15:45 - travel to town, 1545-09:15 relax/chase women , 0915-10:00 travel back to work
[23:23:27] <Phydbleep> So.. "Hey baby watch it with the teeth!" is out of the evenings conversation. :)
[23:23:36] <les> 10 per square mile avg pop density in this county
[23:23:51] <les> no...pickup line is:
[23:24:03] <les> Hi. Nice tooth!
[23:24:13] <SWPadnos> "Hey Y'all - ever seen this?"
[23:24:19] <les> heh
[23:24:41] <Phydbleep> SWPadnos: Yeah, On tape on ebay last week. :)
[23:24:59] <les> I am not quite accurate really...many have a full set of teeth.
[23:25:09] <les> But they come out at night.
[23:25:15] <Phydbleep> les: Sitting in a glas of water?
[23:25:19] <les> haha
[23:25:46] <les> They ALL like Paul though
[23:25:48] <les> hmm
[23:25:55] <SWPadnos> heh - it's the accent :)
[23:26:05] <les> clever brit
[23:26:09] <Phydbleep> Bloody Ell. :)
[23:26:13] <les> haha
[23:26:38] <SWPadnos> that's haitch - ell
[23:28:22] <SWPadnos> Howdy Ray
[23:28:48] <rayh> Hey Steve. How you doing this evening.
[23:29:07] <SWPadnos> OK
[23:29:29] <SWPadnos> still trying to probe a camera with microscopic contacts
[23:30:17] <rayh> Using EMC to guide the probes I presume.
[23:30:24] <SWPadnos> if only :)
[23:30:35] <Phydbleep> SWPadnos: What are you trying to do? Trip the shutter or read the action?
[23:31:04] <SWPadnos> cause 60 cameras to capture at the same time (within +-50 uS or so)
[23:31:12] <rayh> You need some of jeff's nanotech.
[23:31:27] <SWPadnos> jepler?
[23:31:40] <A-L-P-H-A> roar!
[23:31:47] <SWPadnos> slap
[23:31:50] <rayh> Josh Hall from devFest
[23:31:51] <Phydbleep> SWPadnos: Matched length fiber lines and tuned circuits?
[23:31:51] <A-L-P-H-A> :(
[23:31:52] <SWPadnos> down boy
[23:31:59] <A-L-P-H-A> that's child abuse!
[23:32:03] <SWPadnos> ah - indeed. too bad it isn't ready yet :)
[23:32:07] <rayh> Nanorex -- sorry.
[23:34:49] <anonimasu> I hope the qt book lands tomorrow :)
[23:35:09] <rayh> Don't each of these cameras have a free running pic.
[23:35:33] <SWPadnos> yes, but that would be too low resolution, and too coarse timing
[23:35:42] <SWPadnos> the free run is usually at 15-30 fps
[23:35:57] <SWPadnos> (or about 1000 times too variable)
[23:36:02] <rayh> So how do you get round that?
[23:36:28] <SWPadnos> well - on a camera with a mechanical shutter, you take over the operation of the shutter, and release it a programmed time after trigger
[23:36:39] <Phydbleep> SWPadnos:
[23:36:40] <rayh> I was thinking of the processor that reads the button to take the picture.
[23:36:50] <SWPadnos> that also gives you shutter speed control, because you can release the second curtain a programmed time later
[23:37:09] <Phydbleep> SWPadnos: What kind of cameras are thesse?
[23:37:17] <SWPadnos> Fuji FinePix E550
[23:37:39] <SWPadnos> that microcontroller runs its own interrupt cycle, then does some stuff before triggering the capture
[23:37:51] <Phydbleep> SWPadnos: Standard remote release with a solenoid?
[23:37:55] <SWPadnos> it's variable by around 50 mS at the moment
[23:37:56] <rayh> Good luck.
[23:38:01] <SWPadnos> nope
[23:38:04] <SWPadnos> thanks
[23:38:53] <anonimasu> night guys
[23:39:08] <Phydbleep> G'night anonimasu :)
[23:39:12] <rayh> see you.
[23:39:24] <SWPadnos> see ya
[23:39:29] <Phydbleep> SWPadnos: What about a rack of film cameras?
[23:39:34] <SWPadnos> we already have that
[23:40:03] <SWPadnos> http://www.bigfreeze.com or
http://www.8perfpictures.com
[23:40:04] <Phydbleep> BOING!
[23:40:19] <Phydbleep> SWPadnos: Flying spot camera! :)
[23:40:32] <SWPadnos> um - yeah
[23:41:30] <Phydbleep> SWPadnos: Are you familiar with the concept?
[23:41:50] <SWPadnos> the ones that hang on 4 wires?
[23:42:22] <Phydbleep> No, The high-speed scanned light dot with 1 detector.
[23:42:36] <SWPadnos> ah - like the good film scanners
[23:42:55] <SWPadnos> they use a CRT with a spot of varying size to get good variable resolution scans
[23:43:50] <SWPadnos> I haven't seen any with a single detector, but I have seen the multi-detector IR scopes on the M1 tank
[23:44:14] <Phydbleep> The system I'm thinking of uses a laser, piezo mirrors and a spread set of detectors to generate a semi-holographic image.
[23:44:57] <SWPadnos> Hi Paul
[23:45:06] <Phydbleep> Hi Paul. :)
[23:45:33] <paul_c> Hey, quit jumping on me as soon as I appear
[23:45:42] <SWPadnos> fine - be that way
[23:46:12] <paul_c> No more tea for SWPadnos ;O
[23:46:27] <SWPadnos> fine - be that way
[23:47:01] <paul_c> So.... Where did we get to ?
[23:47:45] <SWPadnos> I think Les and I agreed that a wiki page with expected performance specs would be a good thing
[23:48:04] <SWPadnos> then we can work backwards into what implementations can work
[23:48:24] <SWPadnos> (assuming you're talking about TP)
[23:48:58] <rayh> Say Paul. I don't see a config-2.6.10 will 2.6.9 work?
[23:49:06] <SWPadnos> deja-vu
[23:49:35] <paul_c> rayh: Sure - Just replace 10 with 9 and you'll be OK
[23:50:05] <rayh> k
[23:51:11] <rayh> no rule to make target.
[23:52:07] <paul_c> did you follow all the instructions on the wiki page ?
[23:52:24] <rayh> Yes I tried.
[23:53:01] <rayh> all the installs worked. Said what was there was the latest.
[23:53:34] <paul_c> can you tell me what "uname -a" returns ?
[23:55:12] <rayh> 2.6.9-adeos fri jan28 20:06:40 GMT
[23:55:36] <rayh> Something is borked. This is the box I ran at devFest.
[23:55:45] <rayh> Will reinstall it all.
[23:56:03] <paul_c> OK... Now "ls /usr/src/kernel-sources-2.6.9-adeos/.config"
[23:57:12] <rayh> no such file or dir
[23:57:39] <paul_c> OK... Now "ls /usr/src/kernel-source-2.6.9-adeos/.config"
[23:57:44] <rayh> I did change /boot/config* from 9 to 10
[23:57:46] <paul_c> my fault...
