Back
[02:05:58] <fenn> hi jmk
[02:06:05] <jmkasunich> hi
[02:07:11] <fenn> jon e says feedrate compensation must be turned off for rigid threading (tapping?) but i dont see why that is
[02:07:42] <fenn> i can understand for cutting work-hardening materials, or for welding
[02:07:43] <jmkasunich> given that we don't even have feedrate compensation, its almost irrelevant
[02:08:04] <jmkasunich> and its also dependent on what definition you use for feedrate comp
[02:08:04] <fenn> emc just throws a following error right?
[02:08:16] <jmkasunich> see, not even the same definitions
[02:08:32] <fenn> i'm trying to write definitions for the glossary right now
[02:08:41] <jmkasunich> I think Jon's definition works like this:
[02:09:16] <jmkasunich> you sense spindle motor load current, or maybe spindle speed, and if the spindle starts to bog down, you reduce your feed
[02:09:31] <jmkasunich> which works in some situations, on some materials
[02:09:42] <jmkasunich> on others it may just make things worse
[02:09:55] <fenn> if you treat the spindle as an axis then it's the same definition
[02:10:07] <jmkasunich> but it has nothing at all to do with the following arror on the axis themselves
[02:10:21] <jmkasunich> spindles is not an axis, except on a very few machines
[02:10:41] <fenn> even if you're doing rigid tapping?
[02:10:58] <fenn> (those are the few machines right?)
[02:11:13] <jmkasunich> one way to do rigid tapping is to treat the spindle as an axis, IF you have suitable amps, motors, encoders, etc
[02:11:20] <jmkasunich> most spindles can't do that
[02:11:46] <jmkasunich> the mazak for instance has too much backlash in the spindle gearbox to do any kind of precise positioning
[02:12:34] <jmkasunich> my lathe has a single phase constant speed induction motor and vee belt drive... never gonna treat that as an axis
[02:13:08] <jmkasunich> two ways to do rigid tapping:
[02:13:20] <jmkasunich> 1) send commands to both the spindle and the Z axis
[02:13:35] <jmkasunich> (ie, treat the spindle as an axis)
[02:13:46] <jmkasunich> 2) run the spindle open-loop and slave the Z axis to it
[02:14:12] <jmkasunich> 1 can be done, even with todays emc, but the machine has to be suitable for it (motors, gearbox, encoders, and such)
[02:14:33] <jmkasunich> the other is var more versatile, but emc doesn't have the code for that yet
[02:15:14] <jmkasunich> * jmkasunich needs to get coding
[02:15:34] <fenn> what ya coding?
[02:15:51] <jmkasunich> its a surprise ;-)
[02:15:56] <fenn> figure out how to fix the stepgen bug?
[02:16:02] <jmkasunich> no
[02:16:14] <fenn> heh dont want to bog you down with more problems
[02:16:27] <jmkasunich> which one? ;-/
[02:16:46] <fenn> n/m
[02:16:50] <fenn> have fun
[02:17:12] <jmkasunich> the stepgen headroom bug is trivial to "fix" if you are willing to edit HAL files, just explicitly give your stepgen a few percent of headroom
[02:17:30] <jmkasunich> the problem is trying to do that while reading the data from the ini file
[02:41:38] <fenn> what is the difference between "world coordinates" and "machine coordinates"?
[02:43:25] <fenn> is machine coordinates necessarily a cartesian system?
[02:43:45] <jmkasunich> I don't think so
[02:44:08] <jmkasunich> but both those terms are used at the GUI and interp level, and I'm not an authority there
[02:44:19] <fenn> so machine coords is like world coords but in joint space?
[02:44:31] <fenn> where home is always 0,0,0
[02:44:57] <jmkasunich> if you want to know about coords in the low level code, go to emc2/src/emc/motion/control.c line 1739
[02:45:05] <jmkasunich> everything I know is right there
[02:45:33] <jmkasunich> machine coords may or may not be cartesean, world always is
[02:46:01] <fenn> ok
[02:46:15] <jmkasunich> I don't know if there is any system where home is always 0,0,0, with all the offsets and stuff in the interp
[02:46:24] <fenn> well, yeah, but you get the point
[02:46:49] <fenn> actually i dont think offsets should affect the value of home
[03:11:54] <skunkworks> does anyone know if lermans interp got merged with emc2 - I saw he was trying to do it the other day
[03:12:15] <SWPadnos> not yet - ther ewould have been a bunch of commit messages if it had
[03:16:52] <jmkasunich> gonna be a few days I think
[03:18:28] <skunkworks> I actually got it installe a few days ago- exactly what I needed.
[03:23:27] <jmkasunich> I'm talking about the merge with emc2 HEAD
[03:23:36] <jmkasunich> the lerman-interp branch is working now
[03:26:42] <skunkworks> I installed the lerman interp using the cvs up -dP lerman-interp <- something like that. I was just wondering if he had merged it with the emc2 head (as you say - I may not know the terms)
[03:26:59] <jmkasunich> no, not merged to head yet
[03:27:48] <skunkworks> Thanks - had a chance to think about the following error stepper problem? - again no rush just inquiring
[03:28:01] <jmkasunich> there are several issues
[03:28:13] <jmkasunich> one is with feedrate override
[03:28:45] <fenn> pesky feature
[03:28:51] <jmkasunich> there seems to be an issue with the trajectory planner that lets it command greater than expected velocity when the feedrate override is greater than 100%
[03:29:36] <cradek> jmkasunich: only if some of your axes have different maxvels (lower than TRAJ maxvel)
[03:29:46] <jmkasunich> right
[03:30:05] <jmkasunich> anyway, that is one issue
[03:30:14] <jmkasunich> the other is headroom in the step generators
[03:30:31] <jmkasunich> emc can command motion up to the velocity and accel limits in the ini file
[03:30:50] <jmkasunich> those same limits are passed to the step generator, and it applies them too
[03:31:40] <jmkasunich> if roundoff errors, or anything else, results in either emc asking for a tiny bit more than the limit, or in the step generator limiting at a tiny bit less than the limit, stepgen falls behind and you can get a following error
[03:32:02] <jmkasunich> the answer is to provide some headroom - set stepgen's limits a few percent higher than the ini file limits
[03:32:21] <cradek> you could put this slop in the C instead of the hal file...?
[03:32:28] <SWPadnos> skunkworks, you can add a variable to each AXIS_n section, called STEPGEN_MAX_OUTPUT, set it to something a little higher than the axis MAX_VELOCITY, then change the core_stepper.hal file so that it sets the limits from that var (instead of [TRAJ]_MAX_VELOCITY or [AXIS_n]MAX_VELOCITY
[03:33:15] <jmkasunich> what SWP is suggesting is probably the best short term fix
[03:33:35] <jmkasunich> just have to remember that if you change MAX_VELOCITY, you need to change STEPGEN_MAX_OUTPUT too
[03:33:47] <SWPadnos> rigjt
[03:33:49] <SWPadnos> right
[03:33:51] <skunkworks> I will definatly try that - thanks
[03:34:50] <SWPadnos> just add a few percent to hte max_velocity value for each axis - between 3% and (maybe as high as) 10% should do it
[03:35:07] <SWPadnos> add a few percent to get the stepgen max, that is
[03:35:44] <SWPadnos> you have a little headroom anyway, right? (Z is 20K steps/inch, but you can do 25K)
[03:36:01] <skunkworks> what about my accelleration issue? where I want the x-y to be able to accellerate at a different rate than z
[03:36:04] <skunkworks> right
[03:36:19] <skunkworks> It definatly gives me something to play with
[03:36:20] <jmkasunich> there are potential accel headroom issues too
[03:36:36] <jmkasunich> again, a couple percent extra to stepgen will probably make this problem go away
[03:37:05] <SWPadnos> the basic idea is that (for now, at any rate) you can set up any ini file vars you want, and put them anywhere into the HAL - you just have to manually calculate them
[03:37:07] <jmkasunich> long term, we may change stepgen so it doesn't enfore limits at all, justs trusts EMC to do the right thing
[03:38:13] <fenn> "never trust EMC"
[03:38:32] <jmkasunich> thats why I put the limits in stepgen in the first place
[03:38:39] <jmkasunich> because I don't trust emc
[03:38:42] <SWPadnos> I don't use EMC - they're way too expensive (and I don't have that much data)
[03:38:51] <jmkasunich> but it went and bit me in the ass anyway
[03:39:00] <skunkworks> Thanks - I am sure I will have more questions when I get in front of the machine.
[03:39:01] <jmkasunich> damned if you do, damned if you don't
[03:39:19] <fenn> jmk why not set a fudge-factor in the ini file?
[03:39:37] <fenn> and multiply max_vel by fudge-factor to get the stepgen max
[03:39:48] <jmkasunich> where do you do the multiply?
[03:39:50] <skunkworks> going to have to print out the irc history tomorrow. ;)
[03:39:54] <fenn> in the stepgen code
[03:40:12] <jmkasunich> I'm definitely not gonna put a fudge factor in my nice generic stepgen module
[03:40:24] <fenn> why not?
[03:40:33] <jmkasunich> because its an abomination
[03:40:51] <cradek> fudging for emc bugs is an abomination
[03:41:00] <cradek> fudging for FP limitations isn't (IMO)
[03:41:04] <cradek> which is this?
[03:41:17] <jmkasunich> yes
[03:41:18] <fenn> but you will always have some kind of error since there will always be timeslice rounding of t
[03:41:19] <SWPadnos> the fudge factor would need to be different, depending on the amchine
[03:41:23] <jmkasunich> (a little of both)
[03:41:29] <fenn> swp that's why it's in the .ini file
[03:41:50] <SWPadnos> well - the fudge factor exists - just ad it to the ini file like I said
[03:42:09] <jmkasunich> there are several limits: TRAJ, AXIS, and stepgen
[03:42:14] <SWPadnos> with expressions in halcmd, it'll be even easier
[03:42:20] <jmkasunich> shh
[03:42:43] <SWPadnos> sorry
[03:42:55] <SWPadnos> well - it *would* be easier
[03:43:01] <jmkasunich> the problem is that two of them, AXIS and stepgen, are the same right now (and that is only because of a desire to get them from the ini file)
[03:43:05] <petev> I got that expression code ready anytime
[03:43:49] <jmkasunich> when I first started with HAL, I assumed you'd just set the stepgen limits in the hal file, applying whatever headroom your system needs
[03:44:16] <jmkasunich> of course I'm an engineer, and so I want to do a detailed engineering design of my machine.
[03:44:28] <jmkasunich> normal people aren't as obsessive, and just want to edit the ini and go
[03:44:33] <jmkasunich> a reasonable request....
[03:44:42] <jmkasunich> so we added the ability to get hal params from the ini
[03:44:49] <jmkasunich> and in the process, headroom vanished
[03:45:22] <petev> with the HAL setup now, it's easy to just add another INI var, not that big a deal
[03:45:27] <fenn> ok how about getting MAX_VEL_FUDGED from the ini file instead?
[03:45:59] <skunkworks> and max_acc_fudged
[03:46:00] <fenn> bah nevermind
[03:46:12] <jmkasunich> fenn: while its easy to add a new param, and you can call it whatever you want, you will still have two in the ini file
[03:46:23] <cradek> STEPGEN_FUDGE_PERCENTAGE=3
[03:46:25] <jmkasunich> when you change one, if you forget to change the other you will have trouble
[03:46:36] <fenn> yes
[03:46:42] <cradek> (not serious)
[03:47:09] <jmkasunich> if we had someplace to do the multiply, you could have a FUDGE percentage, or whatever the heck else you wanted to call it
[03:47:14] <SWPadnos> ore even MAX_VELOCITY_ALLOWED_FROM_STEPGEN_INCLUDING_FUDGE_FACTOR
[03:47:24] <jmkasunich> lol
[03:47:30] <SWPadnos> per axis, of course
[03:47:40] <skunkworks> :) well now that I got you all arguing - I am going to bed as my battery is going dead. I never knew I was an instigator. sorry. Thanks for the help
[03:47:41] <cradek> if the FUDGE is separate, you just have to change the numbers in one place again, which I think should be an important goal
[03:47:50] <jmkasunich> right
[03:47:57] <SWPadnos> night skunkworks
[03:48:02] <cradek> but the whole thing smells bad, doesn't it
[03:48:03] <jmkasunich> night skunkworks
[03:48:13] <SWPadnos> bad fudge - eeeewwww
[03:48:19] <jmkasunich> fudge in computers usually does
[03:48:35] <skunkworks> thanks again - you guys are great.
[03:48:37] <fenn> i dont see the need for a fudge factor as an emc bug, rather a limitation of the fact that you're using a computer and it can only do one thing at a time
[03:49:22] <SWPadnos> it's true that a simple change to emc.ini and core_stepper.hal, with a comment in emc.ini, would solve 99% of the problem for a long time
[03:49:49] <jmkasunich> yes
[03:50:02] <SWPadnos> heck - why don't I just go do that?
[03:50:02] <jmkasunich> do it, and I'll buy you a beer the next time we meet
[03:50:19] <SWPadnos> kewl
[03:50:44] <SWPadnos> maybe even for core_servo, so PID has a little headroom as well
[03:51:03] <SWPadnos> incidentally, MAX_OUTPUT is unused in emc2, I believe
[03:51:04] <jmkasunich> that one is most likely controlled by MAX_OUTPUT
[03:51:08] <jmkasunich> which is already in the INI
[03:51:09] <SWPadnos> great
[03:51:11] <SWPadnos> minds
[03:51:17] <jmkasunich> perhaps stepgen should also use it
[03:51:33] <SWPadnos> OK by me
[03:51:52] <SWPadnos> (but the beer may have to be a Bailey's)
[03:51:57] <jmkasunich> ok
[03:52:19] <jmkasunich> thats irish isn't it? I'll raise a Guiness at the same time
[03:52:36] <SWPadnos_> yep - Irish cream vs Irish ale
[03:52:46] <jmkasunich> irish stout
[03:52:52] <SWPadnos_> then there's the Whiskey, for Ray or someone
[03:52:55] <jmkasunich> you can see thru ale
[03:53:00] <SWPadnos_> yes - it is a bit stout,isn;t it
[03:53:15] <SWPadnos_> (I don't like beer, but if I have to have it, I have Guiness)
[03:53:54] <fenn> i'm not following.. i see setp pid.0.maxoutput [AXIS_0]MAX_VELOCITY, where's MAX_OUTPUT supposed to be?
[03:54:13] <SWPadnos_> right there, instead of MAX_OUTPUT
[03:54:19] <jmkasunich> in the [AXIS_0] section of the ini file
[03:54:23] <SWPadnos_> right there, instead of MAX_VELOCITY (oops)
[03:54:48] <jmkasunich> maybe its been deleted from the emc2 ini... easy enough to put back in if so
[03:55:36] <SWPadnos_> do you have to use dP when you update -A? (ssuming you want to prune and add dirs)
[03:55:49] <jmkasunich> not sure
[03:55:55] <jmkasunich> I just use -dP all the time
[03:56:17] <SWPadnos_> well - I just did - we'll see what happens
[03:56:20] <jmkasunich> and I never use -A
[03:56:37] <jmkasunich> if I need to checkout a branch or tag, I do it to another directory
[03:56:40] <SWPadnos_> I wanted to be sure I got the CVS version of all these files, to eliminate spurious changes
[03:56:50] <jmkasunich> when I'm done, I rm -rf * the whole tree
[03:57:06] <SWPadnos_> incidentally, the gtk_entry signal for the enter key is "activate"
[03:57:25] <SWPadnos_> I never got around to making the new signal or connecting it, but I did discover that
[03:58:05] <jmkasunich> probably one line...
[03:58:07] <jmkasunich> * jmkasunich tries
[03:58:57] <SWPadnos_> shall I clean up the ini file a bit as well - I think there are a few other settings that aren't used any more
[03:59:12] <jmkasunich> go ahead
[03:59:24] <jmkasunich> consider it part of the prep for an emc2 file release
[03:59:28] <SWPadnos_> ok
[03:59:47] <SWPadnos_> hm - I think I wanted -C, not -A
[04:01:12] <jmkasunich> nope, enter still doesnt work
[04:01:19] <SWPadnos_> ok
[04:01:41] <jmkasunich> I'm probably missing something simple about that widget
[04:02:01] <jmkasunich> when you click on the button that opens the dialog, you get a dialog with the entry widget, ok, and cancel buttons
[04:02:05] <SWPadnos_> did you create a new signal and connect it, or try to use an existing signal?
[04:02:33] <jmkasunich> the entry doesn't have focus when the dialog pops up, you need to click in it before you can type, and you need to click OK to accept
[04:02:39] <SWPadnos_> (I foolishly connected it to the genericbutton1 signal, which segfaulted)
[04:02:57] <jmkasunich> you don't create the signal (I don't think)
[04:03:08] <jmkasunich> scope_vert.c line 710
[04:03:39] <SWPadnos_> yep - leave that one - it gets called every time the text changes
[04:03:46] <jmkasunich> I think that connects to the "changed" signal, I added another line under it connected to the activate signal
[04:04:08] <SWPadnos_> but it's the dialog_generic_button1 signal that kills the dialog
[04:04:11] <jmkasunich> ok, that handler function just copies the content
[04:04:15] <SWPadnos_> right
[04:04:16] <jmkasunich> right
[04:04:22] <SWPadnos_> (and should validate as well)
[04:05:17] <jmkasunich> the dialog_generic thing might be complicatiing the issue
[04:05:32] <jmkasunich> that isnt a GTK widget, its a convenience one I created
[04:05:54] <SWPadnos_> right - I found the array of 4 generic button handlers
[04:06:03] <SWPadnos_> (which all just kill the parent)
[04:07:54] <jmkasunich> waitaminnit... I didn't use my generic dialog anyway
[04:08:20] <jmkasunich> I just used the predefined callbacks
[04:08:22] <SWPadnos_> no - it's a new one
[04:08:25] <SWPadnos_> ritht
[04:08:27] <jmkasunich> but I explicitly created the buttons
[04:08:27] <SWPadnos_> right
[04:08:42] <jmkasunich> I'm relearning what I did
[04:08:50] <SWPadnos_> the dialog, buttons, and text entry are all explicitly created
[04:09:46] <SWPadnos_> one thinkg to note - the cancel button doesn't work - since the value is updated at every change, it's already done when the dialog goes away
[04:09:59] <SWPadnos_> (though there may be a save and restore that I missed)
[04:10:34] <jmkasunich> it works, you missed the strtod at line 738
[04:10:49] <jmkasunich> the "changed" handler just copies the string to a buffer
[04:11:03] <jmkasunich> only when you exit the dialog is it converted to a number and stored
[04:11:21] <SWPadnos_> ah - OK
[04:11:48] <petev> what's up with posemath? It only seems to be used in some user interface coede
[04:12:12] <jmkasunich> I think its also used for non-trivial kinematics
[04:12:20] <jmkasunich> lots of transform matrices and such
[04:12:28] <petev> I ran the emc tree and didn't see it
[04:13:08] <jmkasunich> no non-trivial kins in emc2 yet
[04:13:13] <petev> oh
[04:13:30] <petev> there are similar structs declared in canon.hh
[04:13:37] <SWPadnos_> that would be agood place for a well-defined class (which is pretty much what it is)
[04:13:39] <petev> I think it should be the same everywhere
[04:13:58] <petev> swp: which is a good place?
[04:14:37] <SWPadnos_> posemath / kins
[04:14:48] <petev> ahh
[04:15:04] <petev> I'm thinking the interp and canon should be using the pose structs too
[04:16:13] <SWPadnos_> one thing that had been discussed was the idea of having the kins be pluggable
[04:16:31] <petev> so why are all the pose overloaded operators defined in the global name space?
[04:16:36] <SWPadnos_> so emc.ini specifies kins, planner, canon, and interp (and GUI and RT stuff)
[04:16:41] <petev> man, I gotta stop looking at code
[04:16:42] <SWPadnos_> damfino
[04:16:54] <petev> every time I see more, it needs fixin
[04:17:32] <SWPadnos_> heh - you need to repeat the following mantra: "if it more or less works, I don't have to fix it immediately"
[04:17:53] <petev> yeah, but if I want to use it, it will make more code that needs fixin later
[04:18:09] <cradek> petev: if you're itching to do something, you could fix the varfile bug for me...
[04:18:21] <petev> cradek, I got enough to do
[04:18:25] <cradek> darn
[04:18:28] <cradek> me too
[04:18:28] <petev> I'm trying to keep it contained
[04:18:29] <SWPadnos_> heh
[04:19:06] <SWPadnos_> ok - the help.txt document looks more or less accurate, but incomplete - should I just move it over from emc1 to emc2?
[05:16:48] <Jymmm> Anyone know how to get 1.5VDC from 120VAC w/o a xfmr?
[05:17:27] <SWPadnos_> stand near the 120VAC?
[05:17:35] <SWPadnos_> with a diode
[05:17:39] <Jymmm> Yeah, that's what I was thinking.
[05:17:54] <fenn> use a battery
[05:18:01] <rayh> and one big voltage divider
[05:19:38] <Jymmm> Eh, maybe I can find a switching PS
[05:19:46] <Jymmm> wall cube
[05:20:51] <Jymmm> Found a $30 MP3 player today 128MB, I should have picked it up.
[05:22:24] <Jymmm> But at least I found a xmas gift for my gf =)
[05:23:18] <Jymmm> http://truly.net/html/prod/proddetail.php?id=81
[05:24:16] <fenn> ah but does it have a cellphone built in?
[05:24:24] <Jymmm> hell no =)
[05:26:06] <jmkasunich> jymmm: depends on how many amps (mA) you need at 1.5V
[05:27:37] <Jymmm> jmkasunich doens't say -->
http://www.creative.com/products/product.asp?category=213&subcategory=215&product=10919&nav=2
[05:28:29] <jmkasunich> says it runs on a battery...
[05:28:38] <jmkasunich> you talking about an ac adapter for one?
[05:28:53] <Jymmm> jmkasunich: dummy battery
[05:28:58] <Jymmm> to ac adapter
[05:29:43] <jmkasunich> and you don't want a xfmr in the adapter? I wouldn't go there
[05:30:13] <Jymmm> jmkasunich: it would be too big, only have about .5" thickness to play with.
[05:30:21] <Jymmm> maybe .75"
[05:30:43] <jmkasunich> I can think of ways, but mostly very low current, and no simple ones are isolated
[05:30:50] <jmkasunich> I would not skip isolation for that
[05:31:13] <jmkasunich> the product was designed for a battery, probably not save with an unisolated source
[05:33:09] <Jymmm> I'mm thinking of making some christmas thingy, then use a mp3 players as the sound/music source for it. Still need to come up with amp and speakers (mono is fine).
[05:33:52] <jmkasunich> can you steal power from the amp?
[05:34:22] <Jymmm> I wish... still need to provide power to that too. Thinking some simple lil $1.99 thing
[05:34:36] <jmkasunich> wallwart
[05:35:38] <Jymmm> DUH.............. (been a long day)........ I can use a walwart as I still nee to power the lights.... DUH........ extension cables/cord. *sigh*
[05:36:35] <Jymmm> I'd LOVE to use stereo, but I dont think I'll get enough seperation or quality speakers being so small and no enclosures
[05:37:37] <CIA-8> 03paul_c * 10emc2-auto/wiki/ (20 files in 13 dirs): "Auto update wiki from a cron job. Wed Dec 7 05:30:01 GMT 2005 "
[05:42:23] <SWPadnos__> SWPadnos__ is now known as SWPadnos
[05:49:58] <SWPadnos__> SWPadnos__ is now known as SWPadnos
[08:47:18] <anonimasu> hello
[09:00:11] <ValarQ> hiya
[09:06:47] <CIA-8> 03fenn * 10documents/images/ (chips2.svg chips2.png): fun pic of a slightly fatter chips with an endmill
[09:11:01] <anonimasu> jymm: why dont you want a xformr
[09:11:11] <anonimasu> hey valarq
[09:13:17] <anonimasu> hello alex_joni
[09:22:52] <anonimasu> hm
[09:22:59] <anonimasu> I need a cfd analysis of some stuff :(
[09:28:22] <alex_joni> hey anders
[09:30:38] <fenn> alex have you been able to get mediawiki set up on a local system?
[09:30:52] <alex_joni> nope
[09:30:56] <alex_joni> never tried :)
[09:31:04] <fenn> i got stuck on mysql
[09:31:09] <alex_joni> :(
[09:31:27] <alex_joni> not sure mysql is available on SF
[09:31:44] <fenn> php is tho right?
[09:31:51] <alex_joni> I think so..
[09:32:06] <fenn> was the idea to host wiki v2 on sf?
[09:32:43] <alex_joni> could be..
[09:32:48] <alex_joni> but not necessarely
[09:32:57] <alex_joni> the place was best, because it's neutral
[09:33:05] <alex_joni> not depending on anyones hosting
[09:36:51] <anonimasu> hmm
[13:35:54] <les_w> morning
[13:36:00] <anonimasu> morening
[13:36:16] <les_w> I see another post from josh
[13:36:48] <anonimasu> I havent checked my mail today
[13:36:59] <anonimasu> hmm, what's it about?
[13:37:17] <les_w> He is going through the same thought process that others have about the emc tp
[13:37:26] <anonimasu> hehe
[13:37:28] <anonimasu> :)
[13:37:28] <les_w> specifically that:
[13:37:48] <les_w> 1) emc has some serious problems with HSM
[13:38:05] <les_w> 2) the math for a good planner is not that hard
[13:38:17] <anonimasu> hm is it only the planner that's the problem?
[13:38:33] <anonimasu> if it were like that it'd be easier to fix :/
[13:39:02] <les_w> right now I wiuld say yes since wb9 demonstrated 125 microsecond servo updates
[13:39:32] <les_w> Well, that's the big issue. No one can integrate a new planner.
[13:39:42] <les_w> Not even the authors of emc
[13:40:01] <anonimasu> heh
[13:40:22] <les_w> It was just not written in a way where you could plug in a new planner or something.
[13:40:27] <les_w> Now....
[13:40:30] <les_w> emc2....
[13:40:32] <anonimasu> yeah
[13:40:35] <les_w> perhaps?
[13:40:46] <anonimasu> I still have that doumentation project in mind
[13:41:02] <anonimasu> but my life's being in the way
[13:41:07] <les_w> haha
[13:41:22] <anonimasu> ^_^
[13:41:25] <les_w> yeah, me too
[13:41:27] <anonimasu> in a good way
[13:41:45] <skunkworks> les - when you said you where having problems at 800 ipm with tool path - was that with emc1?
[13:42:00] <les_w> same here. I seem to have gotten into this making money thing. For a change.
[13:42:38] <les_w> I can only go 600 with my current ballscrews skunk
[13:42:48] <les_w> but even 200 is a problem
[13:43:05] <skunkworks> ah - emc1?
[13:43:19] <les_w> to be fair, that is due to the math error we can't find...not the general nature of the current planner
[13:43:26] <les_w> emc1 yes
[13:44:10] <skunkworks> was the planner rewritten for emc2? or is it pretty much the same? Have you tried emc2 on your machine?
[13:44:46] <les_w> it's the same. I have to use emc 1 right now, because I am a commercial operation.
[13:45:12] <skunkworks> :) I forget people actually use there machines for production.
[13:45:20] <skunkworks> someday
[13:45:30] <les_w> yeah. If it poops out, workers get laid off.
[13:45:52] <les_w> EMC1 is stable enough
[13:46:00] <les_w> it never crashes
[13:46:16] <anonimasu> hm I found emc2 stable also
[13:46:19] <anonimasu> when I ran it..
[13:46:23] <skunkworks> I am really excited about emc - It does some really powerful things. - more than I will need.
[13:46:26] <anonimasu> I cant wait to skip emc1 and run it..
[13:46:47] <les_w> When emc 2 is released hopefully it will be similarly stable
[13:46:58] <skunkworks> anonimasu - are you running servos?
[13:47:00] <anonimasu> * anonimasu is really anxious about he's machine
[13:47:04] <anonimasu> step servos..
[13:47:10] <anonimasu> geckos and a usc..
[13:47:18] <anonimasu> with one of thoose feedback boards..
[13:47:29] <skunkworks> usc? its own clock generator?
[13:47:30] <anonimasu> yeah
[13:47:38] <skunkworks> that would be nice
[13:47:54] <alex_joni> and it works on emc2 ;)
[13:48:04] <anonimasu> I had trouble with one axis being slower then the other and the bug where emc dosent obey the vel/accel limits
[13:48:37] <skunkworks> I got some good help last night on how to solve my problems - may try it today. (adding vel - acc limmits to both the ini and hal files)
[13:48:46] <anonimasu> but, I've got a servo for my last axis now ;)
[13:49:01] <skunkworks> yes that is my problem
[13:49:05] <anonimasu> so I can run x,y,z at the same speed..
[13:49:09] <skunkworks> partly
[13:49:17] <anonimasu> alex_joni: I am going to try it someday soon
[13:49:33] <anonimasu> I just need a ballscrew for the Z axis and like 25 hours at the lathje
[13:49:34] <anonimasu> lathe ;)
[13:49:43] <les_w> heh
[13:49:56] <anonimasu> making parts
[13:50:02] <skunkworks> my z scale right now is 20000 vs x and y which is 2540
[13:50:03] <anonimasu> it's kind of tricky spinning the nut..
[13:50:05] <anonimasu> :)
[13:50:14] <les_w> well, I will answer jush's post while I wait for the shop to warm up
[13:50:34] <les_w> btw where is the segmentqueue paper on sf?
[13:53:41] <les_w> nm found it
[14:19:44] <anonimasu> hm
[14:19:45] <anonimasu> ok
[14:21:15] <les_w> ok post sent
[14:25:33] <les_w> dammit....cold this morning (-5c) and I have zero dry wood for the stoves.
[14:25:48] <les_w> will have to use $$$ gas.
[14:30:21] <anonimasu> hmm ok
[15:00:47] <rayh> les_w: IMO "modern machining" is another one of those loaded terms that is designed to confuse and encourage FUD. Modern as compared to what, primitive machining.
[15:01:44] <rayh> Many of today's machine tools still operate at rates where the emc is comfortable.
[15:02:04] <rayh> I'd think a less loaded term might be high speed machining.
[15:03:02] <les_w> sounds fine
[15:05:33] <les_w> I used that term I think because some modern machining is not fast, but requires extreme path precision
[15:06:04] <les_w> like creep grinding
[15:07:16] <les_w> I guess the bottom line in my post is yes we need a better TP, but it won't be in emc1.
[15:07:48] <les_w> And the current tp would be a heck of a lot better if we could find the rest of that error
[15:10:51] <anonimasu> hm yeah
[15:10:53] <anonimasu> that's true
[15:13:24] <les_w> However as a commercial type (with a different aganda) I have to ask myself " would I market a new cnc with emc1 as the control?"
[15:13:31] <les_w> and the answer is no way.
[15:16:00] <les_w> not in it's current state
[15:17:11] <anonimasu> yep
[15:19:28] <CIA-8> 03lerman * 10emc2/src/emc/rs274ngc/ (9 files):
[15:19:28] <CIA-8> Merged lerman-interp branch. This adds subroutines, looping, and
[15:19:28] <CIA-8> conditional operations to the interpreter.
[15:20:23] <cradek> lerman: yay
[15:20:53] <anonimasu> whee
[15:25:35] <lerman> Well, I was waiting for the Board to tell me to do it, and decided that it was time. Please test this ASAP. And thanks for your support.
[15:41:25] <cradek> lerman: I know jmk was worried that others might have local changes to that directory, and he wanted to give them time to deal with a possibly-big merge problem
[15:44:42] <lerman> I think they had plenty of time. Also, it is unlikely that their merges would be as big as mine. But, if anyone has problems, I assume we could just back it out. The only one I'm really concerned about is the Rumley changes. I'd like to get some of them in ASAP -- particularly the ones like the semicolon comments and the changes to read tolerances and other settings from the .ini file....
[15:44:44] <lerman> ...Does anyone know if Keith is working on that?
[15:45:07] <cradek> I'm sure there is no problem and will be no need to back out.
[15:45:29] <lerman> AFAIK, Rumley and I are the only ones making changes to the interpreter.
[15:45:44] <cradek> that's my understanding too.
[15:45:54] <cradek> although, I'm probably about to start looking for a bug
[15:46:05] <cradek> so I might have small changes
[15:46:40] <lerman> Well, in that case, it is better that my changes get in before you fix the bug. That avoids overlapping merges.
[15:47:00] <cradek> right
[15:47:21] <lerman> Whoops -- I'm out of here. Gotta go babysit the grandchildren for a day. I'll try to connect from my daughter's house.
[16:11:20] <les_w> ah...the energychain spindle cable was just delivered...drop shipped from igus
[16:11:28] <les_w> seriously fat wire...
[16:12:51] <les_w> shielded 4x12 hiflex
[16:54:24] <les_w> hey jymmm...just takin a break
[16:54:34] <Jymmm> howdy les_w
[16:55:21] <Jymmm> Just got an inquiry from someone that wants to buy one of my domains.
[16:55:47] <les_w> oh really
[16:56:10] <les_w> christmas domain sale?
[16:57:08] <Jymmm> It have to be a serious price for me to sell it. 5-20k doesn't go that far today.
[16:57:31] <les_w> yeah. the money ain't worth nuthin
[16:58:05] <Jymmm> If they offered like 50-100K, I'd have to think about it.
[16:58:16] <les_w> soon we'll all be poverty level millionaires.
[16:58:33] <les_w> 50-100k? I wouldn't think long.
[16:58:34] <Jymmm> just the taxes alone would wipe out most of it.
[16:58:52] <les_w> income averaging my boy
[16:59:09] <Jymmm> I would... now $250K is another story.
[16:59:33] <les_w> i'll sell mine for 10 bucks
[16:59:54] <Jymmm> les_w that wouldn't even pay for the transfer fees =)
[17:00:03] <les_w> haha
[17:00:52] <les_w> Today I am just doing a conventional machining job in between arguing with law dogs still over NDA
[17:01:18] <Jymmm> whats to argue about?
[17:01:34] <les_w> intellectual property.
[17:02:25] <les_w> I don't want their intellectual property....I just want to buy their stuff.
[17:02:28] <Jymmm> what are they wanting you to give up the rights to your pencil and post-it notes or something?
[17:02:36] <les_w> But I want a second source too.
[17:03:23] <les_w> No, I must admit our law dogs are being borg -like.
[17:03:26] <Jymmm> what are you wanting to buy?
[17:03:52] <les_w> So I just called em with the good cop bad cop thing...
[17:03:58] <les_w> seemingly didn't work
[17:04:21] <Jymmm> les_w: what are you wanting to buy?
[17:04:31] <les_w> insider...can't say
[17:04:44] <Jymmm> les_w: tangible or rights?
[17:04:45] <les_w> just frustrated
[17:04:56] <les_w> yes.
[17:05:28] <Jymmm> les_w: oh, you want a vested interest in it?
[17:06:13] <les_w> Jymm, haha I want a vested interest in almost everything
[17:06:18] <Jymmm> lol
[17:07:13] <les_w> Admittedly I am a bit money grubbing...starving a couple years will do that to you
[17:07:22] <les_w> Ain't starving now!
[17:07:22] <Jymmm> always will
[17:08:19] <les_w> I'm not an electrical engineer or mechanical engineer or aero engineer....
[17:08:29] <les_w> I'm a money engineer.
[17:08:48] <les_w> I engineer creative ways for people to give me money.
[17:09:00] <Jymmm> lol
[17:09:58] <les_w> well, back to the pickle works.
[17:10:10] <Jymmm> c-ya
[17:48:43] <CIA-8> 03swpadnos * 10emc2/src/hal/utils/halcmd.c: Added script mode to "show" outputs, prompt in interactive mode, and forced mutex release. Script mode is less human-readable, but makes parsing easier.
[18:56:17] <skunkworks_emc2> Hello
[18:57:34] <skunkworks_emc2> I am playing around with adding the STEPGEN_MAX_OUTPUT to each axis in the ini and then setting the setp stepgen.0.maxvel in the hal file
[18:58:30] <skunkworks_emc2> I added this to the ini file -> STEPGEN_MAX_OUTPUT 5.5
[18:58:40] <skunkworks_emc2> for each axis and then
[18:59:06] <skunkworks_emc2> changed the hal file to setp stepgen.0.maxvel [AXIS_0]STEPGEN_MAX_OUTPUT
[18:59:07] <skunkworks_emc2> setp stepgen.1.maxvel [AXIS_1]STEPGEN_MAX_OUTPUT
[18:59:07] <skunkworks_emc2> setp stepgen.2.maxvel [AXIS_2]STEPGEN_MAX_OUTPUT
[18:59:46] <skunkworks_emc2> I get an error on the startup of emc - HAL:66: ERROR: ini file variable '[AXIS_0]STEPGEN_MAX_OUTPUT
[19:00:10] <skunkworks_emc2> Do I some how have to initialize this variable somewhere?
[19:01:25] <skunkworks_emc2> HAL:66: ERROR: ini file variable '[AXIS_0]STEPGEN_MAX_OUTPUT' not found
[19:05:43] <SWPadnos> skunkworks - that shuold work, as long as you spelled the variable the same in both places, the setting is in the correct sections, and the correct .ini file is passed to halcmd ;)
[19:05:47] <SWPadnos> should
[19:06:03] <skunkworks> odd - I coppied and pasted as to not make a mistake
[19:07:42] <SWPadnos> can you paste in the relevant portions of the .hal and .ini files?
[19:09:45] <skunkworks_emc2> hal file
[19:09:46] <skunkworks_emc2> # set stepgen module accel limits - get values from ini file
[19:09:46] <skunkworks_emc2> setp stepgen.0.maxaccel [AXIS_0]MAX_ACCELERATION
[19:09:47] <skunkworks_emc2> setp stepgen.1.maxaccel [AXIS_1]MAX_ACCELERATION
[19:09:47] <skunkworks_emc2> setp stepgen.2.maxaccel [AXIS_2]MAX_ACCELERATION
[19:09:56] <skunkworks_emc2> oops
[19:09:59] <skunkworks_emc2> try that again
[19:10:00] <SWPadnos> heh
[19:10:18] <skunkworks_emc2> hal file
[19:10:19] <skunkworks_emc2> # set stepgen module velocity limits - get values from ini file
[19:10:19] <skunkworks_emc2> setp stepgen.0.maxvel [AXIS_0]STEPGEN_MAX_OUTPUT
[19:10:20] <skunkworks_emc2> setp stepgen.1.maxvel [AXIS_1]STEPGEN_MAX_OUTPUT
[19:10:20] <skunkworks_emc2> setp stepgen.2.maxvel [AXIS_2]STEPGEN_MAX_OUTPUT
[19:11:11] <skunkworks_emc2> emc.ini
[19:11:14] <skunkworks_emc2> # First axis
[19:11:14] <skunkworks_emc2> [AXIS_0]
[19:11:15] <skunkworks_emc2> TYPE = LINEAR
[19:11:15] <skunkworks_emc2> UNITS = 0.03937007874016
[19:11:16] <skunkworks_emc2> HOME = 0.000
[19:11:16] <skunkworks_emc2> STEPGEN_MAX_OUTPUT 5.5
[19:11:17] <skunkworks_emc2> MAX_VELOCITY = 5.0
[19:11:19] <skunkworks_emc2> MAX_ACCELERATION = 10.0
[19:11:21] <skunkworks_emc2> BACKLASH = 0.000
[19:11:23] <skunkworks_emc2> CYCLE_TIME = 0.001000
[19:11:26] <skunkworks_emc2> INPUT_SCALE = 2540 0
[19:11:27] <SWPadnos> you need an equals sign
[19:11:27] <skunkworks_emc2> OUTPUT_SCALE = 1.000 0.000
[19:11:29] <skunkworks_emc2> MIN_LIMIT = -100.0
[19:11:31] <skunkworks_emc2> MAX_LIMIT = 100.0
[19:11:33] <skunkworks_emc2> FERROR = 0.050
[19:11:35] <skunkworks_emc2> MIN_FERROR = 0.010
[19:11:37] <skunkworks_emc2> HOME_OFFSET = 0.0
[19:11:41] <skunkworks_emc2> HOME_SEARCH_VEL = 0.0
[19:11:41] <skunkworks_emc2> HOME_LATCH_VEL = 0.0
[19:11:43] <skunkworks_emc2> HOME_USE_INDEX = NO
[19:11:45] <skunkworks_emc2> HOME_IGNORE_LIMITS = NO
[19:11:49] <skunkworks_emc2> crap
[19:11:51] <skunkworks_emc2> thank you
[19:11:54] <SWPadnos> np
[19:12:40] <skunkworks_emc2> It started - now time to play - thank again
[19:12:47] <SWPadnos> sure - have fun
[19:13:18] <LawrenceG> I love those quick fixes }
[19:13:20] <skunkworks_emc2> I should be able to do the same thing with the max accellerataion for each axis - if need be
[19:13:28] <SWPadnos> yep
[19:13:32] <skunkworks_emc2> ok
[19:13:34] <skunkworks_emc2> thanks
[19:14:07] <SWPadnos> keep coming back with easy ones ;)
[19:14:07] <skunkworks_emc2> make up a new veriable (stepgen_maxacc) or something like that
[19:14:12] <SWPadnos> yep
[19:14:40] <SWPadnos> incidentally, the emc1 variable that controlled output was called MAX_OUTPUT
[19:14:48] <SWPadnos> you could use that instead of STEPGEN_MAX_OUTPUT
[20:12:45] <cradek> good evening alex
[20:18:16] <alex_joni> evening chris
[20:19:07] <cradek> I've been having a friendly argument with petev about that bug I put in the tracker...
[20:20:26] <alex_joni> you put a bug in the tracker? that's not nice ;)
[20:20:38] <cradek> yep, I did, and I'm not ashamed of it either
[20:20:41] <cradek> how are you feeling?
[20:20:44] <alex_joni> poor bug ;)
[20:20:53] <alex_joni> great actually, thanks for asking
[20:21:22] <cradek> great, it's about time
[20:21:54] <alex_joni> it was...
[20:22:00] <SWPadnos_> I should read that follow-up
[20:52:42] <skunkworks_emc2> did you know if you change the ouput scale in the ini file - it changes back to 1. (default emc ini steppers.)
[20:55:12] <SWPadnos_> yes
[21:01:32] <CIA-12> 03swpadnos * 10emc2/docs/man/man1/halcmd.1: Added description of -s option description to manpage. Left out -R, so it's somewhat secret.
[21:18:56] <robin_sz> meep?
[21:19:14] <cradek> hi robin!
[21:19:22] <robin_sz> evening
[21:19:36] <cradek> we don't see you around here much anymore
[21:20:11] <robin_sz> mmmm ... I got fed up with being kicked off ...
[21:20:40] <cradek> guess I wasn't in on that
[21:20:58] <robin_sz> anyway ... time passes
[21:21:10] <cradek> welcome back then
[21:21:13] <robin_sz> heh :)
[21:21:30] <robin_sz> so ... whats new in emc? I hear the motenc board is looking promising
[21:21:41] <cradek> emc2 can run lots of machines now
[21:23:53] <robin_sz> good. its getting mopre mainstream then ..
[21:24:14] <robin_sz> johns HAL stuff is starting to flex its muscles now too
[21:26:43] <robin_sz> and from what I see, there are several GUI threads going on too ...
[21:27:14] <robin_sz> looks like we are making some progress on that front ... all in all, quite promising
[21:27:48] <cradek> yeah
[21:27:58] <cradek> have you seen a recent AXIS release?
[21:28:04] <robin_sz> nope
[21:28:27] <robin_sz> I did try compiling an early one . but my laptop refused
[21:28:37] <robin_sz> ancient linux :(
[21:29:01] <robin_sz> dedrat 7.<mumble>
[21:29:14] <cradek> it's much easier now
[21:29:19] <cradek> you need only a working python and tkinter
[21:29:24] <cradek> no other dependencies
[21:29:43] <cradek> and it works on python 2.2
[21:30:58] <jepler> redhat 7 may not have a python as new as 2.2
[21:31:12] <jepler> and it's sometimes a bit of a puzzle to build your own python with tkinter support
[21:31:22] <robin_sz> 1.5
[21:31:24] <cradek> hmm
[21:31:41] <cradek> maybe try the python.org src rpm?
[21:31:57] <cradek> or the redhat-9 update CD (seriously)
[21:31:59] <robin_sz> maybe burn the laptop and install Debian over christmas?
[21:32:02] <cradek> I've updated from 7.2 to 9
[21:32:12] <robin_sz> nah
[21:32:17] <robin_sz> debian is the way to go]
[21:32:40] <cradek> well, not IMO
[21:32:49] <cradek> but whatever you're used to is best
[21:33:54] <robin_sz> ive gone debian on all the other baoxes now
[21:34:06] <robin_sz> just this deadbeef laptop to do ...
[21:34:18] <jepler> you could try this package too:
http://download.fedoralegacy.org/apt/redhat/7.3/i386/RPMS.os/python2-2.2-16.i386.rpm
[21:34:27] <jepler> and
http://download.fedoralegacy.org/apt/redhat/7.3/i386/RPMS.os/tkinter2-2.2-16.i386.rpm
[21:34:41] <jepler> those are specifically built for 7.3; they seemed to have some 7.2 packages too
[21:35:06] <robin_sz> saving ....
[21:35:13] <cradek> aha, I bet that will work
[21:35:26] <jepler> I can't test it for myself, but those python packages are probably built right
[21:35:35] <jepler> you'll have to use "python2.2 setup.py ..." to build/install axis though
[21:35:44] <jepler> because /usr/bin/python is still 1.5.2 after you install those RPMs
[21:36:02] <alex_joni> meep?
[21:36:06] <jepler> hi alex
[21:36:11] <alex_joni> hey jeff :)
[21:36:32] <robin_sz> hmm ... need libdb-3.3
[21:36:42] <cradek> jepler: alex finally found a photo of you - he still hasn't found one of me
[21:36:54] <robin_sz> * robin_sz stares at the entrance to dependancy hell
[21:37:00] <alex_joni> cradek: but I'm silently searching still
[21:37:29] <jepler> robin_sz: you might get away with --force'ing it. start by looking in the same directory for the libdb package, though
[21:37:43] <alex_joni> cradek: I'll bait jepler to take a pic of you with a candid cam ;)
[21:37:47] <alex_joni> and sell it to me :P
[21:37:59] <cradek> ha
[21:38:04] <cradek> you'll get more for your money elsewhere
[21:38:10] <alex_joni> where?
[21:38:16] <cradek> pretty much anywhere
[21:38:32] <alex_joni> lol, what's wrong with jeff & money?
[21:38:38] <robin_sz> * robin_sz look
[21:38:39] <robin_sz> s
[21:38:59] <robin_sz> nope ... no libdb rpm
[21:39:24] <robin_sz> it will have to wait until I install debian
[21:39:39] <jepler> robin_sz: --force it --force it! <chants>
[21:39:55] <alex_joni> robin_sz: the --force shall be with you
[21:40:31] <robin_sz> itr still refuses .. weird
[21:40:58] <alex_joni> try --force-goddammit
[21:41:22] <cradek> --force --nodeps
[21:41:25] <robin_sz> ever tried the reformat option in mkraid?
[21:41:34] <robin_sz> first it refuses ...
[21:41:41] <robin_sz> so you use --force
[21:41:50] <robin_sz> which is "interesting" ...
[21:42:22] <skunkworks_emc2> adding the fugde factor into the ini and core_stepper hal seemed to fix the jogging following error - happy happy joy joy ;)
[21:43:02] <skunkworks_emc2> I am still fuzzy on accelleration though.
[21:43:20] <alex_joni> fuzzy logic controller
[21:43:25] <robin_sz> I never got the hang of the ini .. I thought I did once ...
[21:44:48] <skunkworks> I am sure I just don't understand it.
[21:45:19] <robin_sz> it was always the PID values I never understood
[21:46:18] <alex_joni> those are gone in emc2
[21:46:21] <alex_joni> at least for steppers ;)
[21:46:27] <robin_sz> thank $deity
[21:46:43] <alex_joni> and classicladder is really great
[21:46:47] <alex_joni> works like a charm
[21:47:02] <robin_sz> I keep looking for IO board to use with it ...
[21:47:17] <alex_joni> hack an ISA with some 8255 on it ;)
[21:47:25] <robin_sz> ISA? dead and buried
[21:47:47] <alex_joni> btw, does anyone know the specs on a "81 210 W33" temperature sensor?
[21:47:56] <alex_joni> found one, and have no idea how to use it
[21:48:02] <skunkworks> it seems like the default_acceleration in the [traj] section is the max acceleration emc uses for all axises
[21:48:24] <alex_joni> back to cradek's bug :)
[21:48:26] <robin_sz> alex_joni: for temp sensing, try a Dallas DS1820
[21:48:33] <alex_joni> at least discovered by him
[21:48:40] <alex_joni> robin_sz: I have this one to use..
[21:48:58] <skunkworks> The only one I can change that makes a difference in accelleration anyways
[21:49:01] <robin_sz> gonna need some analogue stuff then
[21:49:18] <robin_sz> alex_joni: you can use the dallas ones straight froma serial port
[21:49:28] <alex_joni> yeah..
[21:49:48] <robin_sz> theres a pacage called "digitemp" that works with them
[21:50:00] <alex_joni> ok.. will look for it someday ;)
[21:50:15] <robin_sz> the day you find a DS1820?
[21:50:38] <alex_joni> probably :D
[21:50:47] <alex_joni> I have some I2C around somewhere too
[21:50:53] <robin_sz> ick
[21:51:17] <alex_joni> they are OK for micro's
[21:51:30] <alex_joni> some one wire kind too
[21:51:36] <robin_sz> thats them
[21:51:42] <alex_joni> right
[21:51:48] <robin_sz> the Dallas 1 wire series
[21:51:54] <alex_joni> not sure they're dallas.. but 1 wire
[21:52:00] <alex_joni> used them a while ago
[21:52:14] <robin_sz> very cute sensors ...
[21:52:29] <alex_joni> oh. btw, replaced some IGBT's today
[21:52:39] <robin_sz> did the old ones go ...
[21:52:44] <alex_joni> GT50J101, couldn't find them anymore
[21:52:46] <robin_sz> < B A N G >
[21:53:04] <alex_joni> 4 of 'em in an inverter
[21:53:21] <robin_sz> igbt technolgy has really moved on ...
[21:53:33] <alex_joni> yeah found some nice IRF's
[21:53:51] <robin_sz> Semikron are the big player
[21:54:52] <alex_joni> for brick type yes
[21:54:57] <robin_sz> yeah
[21:55:09] <robin_sz> full of elephant snot
[21:55:11] <alex_joni> these were TO-247 I think
[21:55:20] <robin_sz> oh, baby ones :)
[21:56:00] <alex_joni> small ones, yet 1200V 50Amps
[21:56:10] <alex_joni> no idea how they handle that :)
[21:56:13] <robin_sz> neat
[21:56:17] <alex_joni> in their dreams probably
[21:56:24] <robin_sz> shrug
[21:56:47] <robin_sz> wasnt someonme building a servo amp on here?
[21:56:52] <alex_joni> anyways.. it seems to run, gotta test some more
[21:56:56] <alex_joni> yeah.. lots of em ;)
[21:57:01] <alex_joni> etla was I think
[21:57:06] <robin_sz> di they get anywhere?
[21:57:25] <alex_joni> didn't hear a <bang> yet
[21:57:32] <alex_joni> probably too small FET's
[22:18:35] <alex_joni> night all
[22:20:22] <skunkworks> good night alex
[22:37:33] <robin_sz> and then there were three
[22:42:13] <fenn> and then there were 29
[23:02:28] <robin_sz> so .. what happened with those guys building a cheap motion board?
[23:02:39] <robin_sz> anaolgue out and encoders in?
[23:08:03] <jepler> I assume they're all electrocuted now
[23:11:36] <fenn> last i heard icee was working on the power supply, doing simulations and such
[23:12:02] <fenn> etla switched to a pre-programmed chip
[23:12:05] <fenn> http://www.cnczone.com/forums/showthread.php?t=14673&page=2&pp=15
[23:12:30] <robin_sz> oh cnczone ...
[23:12:37] <robin_sz> no thanks :)
[23:13:04] <fenn> this is the icee/lawrenceG project:
http://forums.donniebarnes.com/viewtopic.php?t=52
[23:13:19] <fenn> i hate cnczone too
[23:13:41] <robin_sz> I only have a 1mb connection
[23:13:56] <fenn> so?
[23:14:16] <robin_sz> I only have an hour or so to spare, so not enough time to load all the animate dadverts really
[23:16:23] <robin_sz> what happened to achiestdragon? did he get his machine to work?
[23:17:41] <fenn> uh, you could go ask him.. he's usually on #brlcad
[23:18:14] <robin_sz> ah
[23:19:01] <robin_sz> what I could use ...
[23:19:08] <robin_sz> is two bits of software ...
[23:19:29] <robin_sz> 1) somthing that will take a dxf of several profiles
[23:19:41] <robin_sz> and split it up into several dxfs of 1 profile each
[23:19:50] <robin_sz> and 2)
[23:20:13] <robin_sz> something that can make my more useless customers learn to send drawings in DXF not on bits pf paper
[23:28:19] <jepler> 2) is not a matter of software
[23:46:01] <cradek> robin_sz: 1) autocad 2) clue stick
[23:55:09] <SWPadnos_> sadly, many customers seem to have developed clue stick repellent