Back
[00:00:04] <morficmobile> found a minimum thread engagement chart, for 8.8 and 10.9 bolts at least, but not the formula that easily let you calculate this based on pitch and diameter, to show why the formula works, still better than nothing
[00:03:58] <theorb> theorb is now known as theorbtwo
[00:21:14] <cradek> seems like you need to compare tension failure of the bolt with thread pullout in your material
[00:21:53] <cradek> i.e. there's no set answer for a certain bolt - it sounds like you want to tell your customer the bolt will fail before the threads do, if it's X deep, so 3X is just a waste
[00:22:48] <cradek> I don't even have a gut feel for it though, sorry. maybe some answers in MH.
[00:23:48] <morficmobile> correct, it involves knowing the part material, and bolt class (8.8, 10.9, 12.9 are yields, failure range and elastic range in % of failure yield)
[00:24:45] <morficmobile> cradek: i have one in my german "MH", but it's a established number, not the more detailed formula (and none of them go past 1.5xD with 8.8 and 10.9 mentioned)
[00:25:22] <cradek> I guess at some point the bolt's threads themselves will fail - I didn't consider that
[00:25:29] <cradek> so there are three problems?
[00:25:41] <morficmobile> cradek: and most those parts i hate are in house designs, old and done so noone gets the depth wrong "well, i told them tap through, so it's not my problem"
[00:27:11] <morficmobile> cradek: the formula i have in mind calculates it based on the thread profile, and you end up with a number of threads more than a quick and clean 1.4xD the book lists
[00:27:34] <morficmobile> the formula would tell you how many threads will hold the same as the solid section of the bolt
[00:28:06] <morficmobile> and you can check it for both bolt and material, BUT "Einschraubtiefen" did not lead me to the formula i wanted
[00:29:07] <morficmobile> you pick the length where the threads in both part and bolt hold more than the solid cross section of the bolt
[00:36:05] <morficmobile> that i don't see it in the books makes me wonder if the teacher just took it just one step further and had us proof the table in the book
[00:39:58] <Valen> what category should I file my "touch off uses commanded position not actual position" bug?
[00:40:05] <Jymmm> Does anyone use solid works ?
[00:42:10] <Valen> morficmobile: sounds like the kind of thing Machinery's Handbook would have in it?
[00:43:11] <cradek> Valen: that doesn't sound like a bug. can you elaborate?
[00:43:21] <Valen> Basically when you press touch off, it is setting the co-ordinate system based on the commanded position rather than the actual position, given a servo system may well have some ferror at the time the end user is touching off it seems it would be more accurate to use the actual position than the commanded position for this process.
[00:44:26] <cradek> but the ferror when stationary will be the same no matter what you set commanded to
[00:44:40] <ds2> does avoiding solidworks like the plague count as "Using it"? :D
[00:45:16] <cradek> if you're at command 1 actual 1.1, and you touch off .5, you'll be at command .5 actual .6
[00:45:24] <cradek> I don't see how else it could work
[00:45:47] <Valen> thing is if your trying to touch off something so you jog up to it, and say have .1 ferror then touch off, your touching off .1 wrong
[00:46:13] <cradek> do my example. at command .1 actual 1.1, and you touch off .5 -- what are you proposing the two values become?
[00:46:23] <cradek> err
[00:46:27] <cradek> do my example. at command 1 actual 1.1, and you touch off .5 -- what are you proposing the two values become?
[00:46:29] <Valen> you dont change the commanded or actual positions
[00:46:40] <Valen> well ok I spose you do
[00:46:41] <cradek> what
[00:46:45] <Valen> let me rephrase
[00:47:13] <Valen> you are zeroing the co-ordinate system, the goal being 0 of the part = 0 in the co-ordinate system yes?
[00:47:40] <cradek> no you are setting the commanded value to a new number, without moving the machine
[00:48:02] <Valen> I understand the machine isnt moving
[00:48:23] <Valen> but the goal is to set the co-ordinate system to match the real world
[00:48:39] <Valen> disregarding commanded and actual positions for the moment, that is what the purpose of touch off is
[00:48:49] <cradek> the real goal is to set the coordinate system so when you later command the given value, the machine comes *here* - ie where it is now
[00:49:15] <cradek> if you touch off .5, and move around and then come back to command .5, you want the machine to be in the same place as now
[00:49:22] <cradek> that is the current behavior
[00:49:40] <cradek> I think your proposed change would make the machine LATER be wrong by the CURRENT error
[00:49:52] <cradek> I think you're thinking about it backwards
[00:49:58] <Valen> your assuming the ferror is constant
[00:50:42] <cradek> well even if it's random, you can't do better than later commanding the given value again
[00:51:22] <cradek> (ferror does tend to be constant, not random)
[00:51:28] <Valen> to my mind it would be best for the cordinate system to match the part, that way errors are in both directions rather than a fixed offset
[00:51:29] <cradek> for example, amp input offset
[00:51:51] <cradek> I'm pretty sure what you are proposing makes the situation worse
[00:51:54] <Valen> ours seems to be a Gaussian distribution around the central point
[00:52:05] <cradek> please answer my question with the example
[00:53:16] <Valen> if you are commanded 1 actual 1.1 and touch off with 0 actual should go to 0 and commanded to -.1
[00:54:02] <cradek> so if you touch off 0, and then immediately issue G0 Z0 it will move by .1
[00:54:40] <morficmobile> just as listener, it seems to make sense to not compensate for the error, as it's going to be off by that again, and that's where i want it to be later again
[00:54:48] <skunkworks> the error after - touch off, touch off, touch off, touch off, touch off would be large after a while. You want to always change commanded for that reason. if I understand it. say you touch off by going to 1 inch and say - that is 0 inches. (not actually touching anything) Now you move to 7 and say that is 0. and so on. if you are constantly changing the actual position instead of the...
[00:54:50] <skunkworks> ...commanded - you could start shifting your whole work area.
[00:55:15] <Valen> morficmobile: what happens however if your error is not fixed?
[00:56:16] <cradek> if you want to come back to this location later, the BEST thing you can hope to do, no matter what your errors, is to command the same value you're commanding now
[00:56:34] <cradek> that must be what we disagree about
[00:56:41] <Valen> thing is if your trying to touch off something so you jog up to it, and say you always are running .1 behind
[00:56:47] <morficmobile> Valen: then i call maintenance and tell my boss the parts won't ship as i don't know where my tools will be at at any given time, if errors vary so much i can't trust the machine
[00:56:52] <Valen> sorry got my stuff mixed up
[00:56:56] <Valen> try again
[00:57:27] <cradek> bbl
[00:57:51] <Valen> say you have a machine that lags by .1 the whole time, then where the tool is at when you tell it to go to 0 is going to be different depending on which direction you approach it from
[00:58:17] <Valen> and you would be best off having the actual position be at 0 when it is actually at zero ;->
[00:58:24] <morficmobile> sounds like you did not set up/fix backlash then?
[00:58:32] <Valen> i was giving it as an example
[00:58:37] <cradek> morficmobile: that's a tangent
[00:59:10] <cradek> Valen: if you later approach it the same way from the same direction, with your suggested setup, you'd be in a different place. if you approach the other way, your error would be doubled
[00:59:11] <Valen> our machine travels at an average of 0 ferror, with the ferror oscilating above and below that 0
[00:59:48] <Valen> cradek: thats what I'm saying, with my method the error is spread evenly over both directions rather than being in one direction
[01:00:02] <cradek> skunkworks has an interesting point. if you'd touch off the same number three times in a row, the position you'd later have to command to get to this spot is 3 errors away from the given number
[01:00:26] <Valen> thats a good point
[01:00:30] <cradek> I insist you're suggesting something that would make it worse
[01:01:07] <Valen> explain it to me on our machine
[01:01:18] <cradek> I can't explain it any better than I've already tried
[01:01:48] <Valen> I can see the multiple touchoffs without moving causing an issue
[01:01:59] <morficmobile> wouldn't it be easier to look at why your machine oscillates to a point it troubles you and fix that if that is what made you think about touch offs?
[01:02:13] <cradek> if your error is evenly distributed around zero, and you're commanding 1 now, what value should you command later to make it most likely that the machine is in this very position?
[01:02:13] <Valen> it doesn't trouble me
[01:03:39] <cradek> bbl
[01:03:44] <Valen> cya
[01:04:24] <Valen> morficmobile: i noticed the behaviour when using EMC as a glorified DRO ;->
[01:05:58] <Valen> cradek: thing is I have the machine at commanded 1.1 and actual 1, to return to 1 I would set commanded to 1, as if I go to commanded 1.1 next time I could wind up at actual 1.2
[01:06:23] <Valen> If i set commanded to 1 then i am going to wind up at .9 to 1.1
[01:07:57] <Valen> regarding multiple touch offs skunkworks, if you touchoff once and set actual to 0, then next time you touch off, your actual is already going to be 0 so commanded wouldn't change
[01:12:15] <mike__> i've run into that *problem as well
[01:13:04] <Valen> mike__: which?
[01:13:12] <mike__> touch
[01:13:20] <mike__> not sure what to think...
[01:14:05] <mike__> I think by using the commanded position, the touch is off by whatever the FE was when the touch occured
[01:14:13] <mike__> ..right?
[01:14:40] <Valen> yeah
[01:15:50] <Valen> I spose it comes down to the distribution of ferror on a given machine what the best strategy is
[01:17:19] <mike__> feedback resolution could be an issue too...
[01:17:19] <Valen> to me I'd rather my part be +-.1 rather than +.2
[01:17:36] <mike__> yeah
[02:31:27] <morficmobile> so awesome, 3" facemill is set up as 3" diameter tool, but with a .25" x 45deg. chamfer, it's a 3.5" tool as far as shoulders are concerned (yes, a little mispurposed, still setup wrong by whoever made the tool), manually calculating X/Y positions instead of trusting "proven tools" == \o/
[02:34:46] <L84Supper> Jymmm: we use Solidworks
[02:58:27] <cradek> Valen: I changed your report to a feature request and added a link to the discussion here. since it is working as designed, I feel it is not a bug.
[03:42:37] <Valen> cradek: fairynuff
[03:43:05] <Valen> did you see this bit? " cradek: thing is I have the machine at commanded 1.1 and actual 1, to return to 1 I would set commanded to 1, as if I go to commanded 1.1 next time I could wind up at actual 1.2"
[03:56:24] <morficmobile> i'm trying hard to see the problem other than a machine i wouldn't trust in its current state, from what i understand, cradek goes by "if it's systematic error, tell it what it should be "commanded", while you go by "but next time it could be off another amount, so i want to compensate for it while setting the tool" (which seems like a battle you never win)
[04:18:16] <Valen> i'm not compensating for the error, i'm assuming the error centers on zero where cradec assumes the error will repeat exactly
[04:26:39] <morficmobile> Valen: what do you get if you put a 1" block somewhere, touch off the tool at 1", tell it it's 1", then write a program to take the tool to 1", does it drag under the tool, is it too high or is it too low?
[04:27:41] <Valen> 50% of the time it will be within the ferror too high and 50% of the time it will be within the ferror too low
[04:28:14] <morficmobile> so the process works perfect as is, correct?
[04:28:21] <Valen> yes
[04:28:29] <morficmobile> so what needs fixing?
[04:28:36] <Valen> it could be better
[04:29:18] <Valen> its not a big deal
[04:29:38] <Valen> but if it can improve things why not?
[04:29:59] <morficmobile> sure, that's not in question
[04:31:03] <morficmobile> i mean are we even looking at the right problem to find a improvement for?
[04:31:09] <morficmobile> an*
[04:31:48] <Valen> what does the ferror look like on your machines?
[04:33:45] <morficmobile> we have no emc machines yet. i'm just looking at it from a "if one of our machines did that" point of view
[04:33:56] <Valen> how do you know they dont?
[04:34:10] <Valen> well, they will, servo systems respond to error ;->
[04:36:30] <morficmobile> i'm not saying they have no error, what i am saying is that we don't have much issues with them being at the right place aside from backlash
[04:37:27] <morficmobile> and when you said "now if i approach it from the other side, i will be off in the other direction", that's where the red lights started flashing and to me, you were talking about backlash
[04:40:20] <Valen> i was giving an example
[04:40:28] <Valen> but it is a decent one
[04:40:33] <Valen> if your machine has backlash
[04:40:58] <Valen> our backlash is really rather minimal but we can actually measure it ;->
[04:41:39] <morficmobile> easy with enough decimals around
[04:42:03] <Valen> we use glass scales for our feedback loop
[04:42:10] <Valen> so we measure the actual position of the table
[04:44:31] <Valen> but lets just look at what happens to a machine with backlash
[04:45:04] <Valen> if you approach a point from one side until you touch, you wind up with commanded at 1.1 and actual at 1
[04:45:29] <Valen> if you come at it from the other side you have comanded .9 and actual 1
[04:46:35] <Valen> in either case touching off setting the actual position will result in a net shift of any part you make after there
[04:47:48] <morficmobile> backlash is something you fix before you think any further, and when you touch something off, you do this in one direction, out of good practice/habit :)
[04:55:27] <morficmobile> Valen: i would want to know how to deal with the difference between commanded and actual (glass scale), if it's not consistent
[04:56:20] <morficmobile> (i would want the machine/config fixed, not the process of setting tools on a functioning machine)
[04:57:29] <morficmobile> Valen: if you command the same tool to the same position 10 times, you get 10 different actual positions?
[05:27:28] <Valen> by very small amounts
[05:28:13] <Valen> morficmobile: you saying you have 0 backlash or just "very small"?
[05:29:37] <morficmobile> Valen: we have minimal backlash after compensation, depends on what we do, if i have less than .0005" i often do nothing, as adjusting it is so much fun, i save it for when i need it better than that
[05:32:07] <morficmobile> Valen: but if i tell it to go to Z2.0 , it will go to 2" each and every time where backlash comes into play is if i interpolate a hole or turn a ball, you lose the shape (and a ball very likely is one part where .0005" wouldn't fly)
[05:33:05] <Valen> thing is when you are touching off on a part you are setting the co-ordinate space to zero
[05:33:16] <Valen> do you want that zero to be where the tool is
[05:33:23] <Valen> or where the tool is commanded to be
[05:33:44] <morficmobile> Valen: you can even program to not have to worry about backlash, just don't feed from X5. to X4.810 and next time feed from X4.7 to X4.800 and wonder why the part is off even though youy had hit the 4.810 diameter in previous op, with the same tool
[05:34:00] <Valen> assuming you have your .005" backlash it will wind up shifting the part
[05:34:04] <morficmobile> Valen: no
[05:34:06] <morficmobile> never
[05:34:13] <morficmobile> i always move Z-
[05:34:22] <morficmobile> so there is NEVER backlash while touching anything
[05:34:31] <Valen> so you never ever make a cut in a direction opposite to the direction you touch from
[05:36:51] <morficmobile> when we are surfacing core boxes, the tool cuts in all directions, there you would have backlash, but that's a machine problem, not a touchoff problem, say the tool cuts down to Z-1. all points at Z-1. will be at Z-1. cutting upward, the tool may lag behind or jump ahead (if overcompensated)
[05:37:30] <morficmobile> and luckily the tolerances there wouldn't be killed by .0005" here or there
[05:42:56] <morficmobile> <Valen> do you want that zero to be where the tool is <Valen> or where the tool is commanded to be <--- "yes" (because i want it to be the same, if i say 1" and i have a 1" block and later program 1" over Z0., where it is commanded to go 1" is where i want it to be 1")
[05:43:40] <morficmobile> "where the tool is" will be on a 1" block and then telling it 1" will make that 1" :)
[05:50:28] <Valen> on one side
[05:53:42] <Valen> because when you tell it to cut the other side it will have the backlash at full whack
[06:09:27] <morficmobile> Valen: right, you understand backlash, not sure why we talk backlash as it affects tool touchoff, when really it does not, that's what i go on and on and on about :)
[06:10:14] <Valen> because EMC doesn't know about the backlash, its telling the tool to be somewhere and it isnt
[06:11:01] <Valen> to me I would rather my co-ordinate system be centered on the part so the errors introduced into my part due to backlash is +-1 rather than +2
[06:11:09] <Valen> assuming a backlash of 2 units
[06:18:44] <morficmobile> tell emc about the backlash then
[06:19:10] <morficmobile> Valen: ^
[06:19:11] <Valen> it already thinks it knows
[06:20:28] <Valen> my contention is that if your error in production is going to be on either side of the commanded position your better off making your touchoff be in the middle of your error not on the edge
[06:20:33] <morficmobile> then give it some more correction, if it is off different amounts in different areas of the table, drop simple backlash and using your scales do a full geometric mapping, should be even simpler than the stuff explained for machines without scales
[06:22:36] <morficmobile> Valen: the map files seem to be pretty easy to deal with, to me: fix the real problem, don't come up with a bandaid for a unfixed problem
[06:22:51] <Valen> you are completley not getting the actual problem
[06:23:05] <Valen> there is a difference between commanded and actual positions
[06:23:20] <Valen> EMC knows about this
[06:23:37] <Valen> called the following error
[06:25:34] <Valen> if your following error varies around your set point then setting your co-ordinate system to have an offset to your part, results in making the part with that same offset
[06:26:12] <Valen> its all within the error, but you are shifting the error from being on center to having a fixed offset
[06:27:23] <Jymmm> L84Supper: ping?
[06:27:41] <Valen> the objective isn't to hit the same point on a repeated move away and back to the same point, its to minimise the overall error when making a part
[06:28:03] <Valen> the repeatability will be the same within the error bounds anyway
[06:29:02] <morficmobile> you are the one who started talking about the error when coming from an opposite direction :)
[06:29:26] <Jymmm> STOP THE MADNESS
[06:29:35] <morficmobile> if you can't repeat consistently, then how do you tell emc2 by what amount you vary to properly center your offset within the variation
[06:29:35] <Jymmm> Won't someone think of the children!!!
[06:30:08] <Valen> morficmobile: because you have actually moved the tool into the right position it is a "true fact"
[06:30:28] <Valen> it has 0 error by definition them actual position is correct
[06:32:07] <Valen> I was trying to break it down and give an example
[06:34:21] <morficmobile> you are right, i no longer see a common ground to explain how tool touch off changes to fix this variation is wrong, once you establish the variation of your process, you adjust your workoffset Z0, so all the errors causing you to cut at different levels still produce a correct part, if you have more variation than you have tolerance, you improve the process or fix the machine
[06:36:18] <Valen> basically I'm talking about handeling of error
[06:36:46] <Valen> the current way to me offsets the error in the rest of your part by any error at the start
[06:47:07] <morficmobile> Valen: it works for consistent error, if your error is not consistent, you make the adjustment needed to stay in tolerance on say 1000pc. by shifting your workshift so the minimum and maximum actual position are all within tolerance. this works with the tool touch of as it is now, this works on any control, this works for any job
[06:47:57] <morficmobile> Valen: whoever runs the machine has to recognize when to stop trying, when he can not hold tolerance and check what can be done to introduce less variation
[06:48:43] <Valen> what do you mean by consistent?
[06:52:06] <morficmobile> Valen: that if you program it to move to a point and you set an indicator at the tip to read zero, then rerun the program 5 times, if each time the indicator moves back to zero at the end of the move, that's consistent, even if each move had the same error amount in it
[06:52:35] <Valen> I'm talking about the error in that repeat
[06:56:21] <morficmobile> right, i would rather want to know why is there variation and see if this can be improved rather than trying to find a way to make the tool touch off somehow centered within the bounds of your error
[06:57:03] <Jymmm> solidworks?
[06:57:54] <Jymmm> what do you mena by touch off?
[06:58:37] <morficmobile> Valen: what i get at is that you have a problem in the way the machine operates, how you think about it and not how tool touch off works
[06:58:59] <morficmobile> Jymmm: hey, you told us to quit it, and now you want to hit it?
[06:59:26] <Valen> so your saying that a machine with .01mm following error that averages out to 0 has a problem
[06:59:38] <Jymmm> Ah hell no, I was just quoting the Simpsons, carry on!
[07:01:04] <Jymmm> avg out per job? multiple job? multiple parts?
[07:01:45] <Valen> averages over a second or so
[07:02:02] <Valen> actually more like .1 of a second
[07:02:02] <Jymmm> 1s is a long time
[07:02:22] <Jymmm> is the ferr consistant? repeatable?
[07:02:30] <morficmobile> it is not
[07:02:50] <Valen> its noise as it moves along
[07:03:02] <Jymmm> emi?
[07:03:03] <Valen> i can see the ballscrew rotating in it
[07:03:10] <Valen> mechanical noise
[07:03:44] <Jymmm> .1mm over 100ms ? seem minor infraction
[07:04:01] <Jymmm> I could be wrong, depends on how it adds up
[07:04:21] <Jymmm> usually there is ALWAYS "some" pattern
[07:04:50] <Valen> it is minor
[07:04:54] <Valen> its nothing at all
[07:05:07] <Valen> the machine itself has nothing to do with it
[07:05:09] <Jymmm> well 100ms is long too imo
[07:05:50] <Valen> I am not trying to fix my machine, correct a problem with a part or anything like that
[07:06:23] <Jymmm> I dont even know what you guys are debating about.
[07:06:42] <Valen> I am suggesting that the way touchoff is handled at the moment introduces an offset into the part on any servo based machine
[07:06:59] <morficmobile> Valen: just link him to the feature request you filed
[07:07:08] <Jymmm> please dont =)
[07:07:21] <Valen> i filed it as a bug
[07:07:23] <Jymmm> what do you mean by touch off?
[07:07:31] <Valen> press the touch off button in axis
[07:07:46] <Jymmm> like touch the tool to a surface and zero out?
[07:07:51] <Valen> it resets the co-ordinate system based on commanded position, not on actual position
[07:07:52] <Valen> yes
[07:08:13] <morficmobile> Jymmm: he thinks this varying following error should be considered during tool touch off
[07:08:37] <Valen> I'm saying when you touch off, the actual position of the tool is at 0
[07:08:46] <Valen> and the commanded position is whats wrong
[07:09:03] <morficmobile> Jymmm: what we "argue" about is me basically not letting go that i don't think you should try to fix a tool touch off process if the following error is "floating"
[07:09:33] <Valen> its not fixing a problem in the machine
[07:09:39] <Jymmm> Valen: did you mean to reverse those two statements?
[07:09:48] <Valen> no,
[07:09:54] <Jymmm> touchoff and the relative postion should be 0
[07:10:02] <Jymmm> yes or no?
[07:10:10] <Valen> Jymmm: they should be but they wont be
[07:10:16] <Jymmm> why not?
[07:10:21] <Valen> ferror exists
[07:10:33] <Jymmm> in software or mechanical?
[07:10:43] <Valen> mechanical
[07:11:18] <Jymmm> so you have backlash in your machine, have entered that in the ini and touchoff doens't take that into consideration?
[07:11:29] <Valen> nothing whatsoever to do with an actual machine
[07:11:58] <Valen> all that crap is taken into account, and it will still be wrong
[07:12:29] <Jymmm> Wait, there is no machien, yet there is a mechanical ferr that isn't being takiing into consideration?
[07:13:01] <Valen> the point i am making is about managing error
[07:13:07] <Jymmm> do you have sample/examples of this occuring?
[07:13:15] <Jymmm> halscope?
[07:13:16] <Valen> if I let you talk about a paticular machine you will go off on the wrong tangent
[07:14:42] <Jymmm> do you have sample/examples of this occuring?
[07:14:55] <Valen> to my mind when you move the tool to what is actually 0, then you should set "actual position" to zero, and your machine should then try its best to be close to that zero, currently EMC is compensating for the error
[07:14:59] <Valen> or trying to
[07:15:10] <Valen> but to my mind it will cause an offset
[07:15:30] <Jymmm> where is this error? is it repeatable?
[07:15:49] <Valen> yes, all servo machines will always have ferror
[07:16:08] <Jymmm> why is that?
[07:16:28] <Valen> because a servo system acts to correct errors
[07:16:55] <Valen> unless you demand that all servo machines operate with 0 error the point is moot
[07:17:04] <Jymmm> ok, so whats the repeatability tolerance for this or any servi system?
[07:17:12] <Valen> irrelevant
[07:17:20] <Jymmm> no
[07:17:23] <Valen> yes
[07:17:28] <Valen> 589.334833
[07:17:34] <Valen> is that a number your happy with?
[07:17:35] <Jymmm> Then expect that
[07:17:41] <Valen> great
[07:17:51] <Valen> now talk about the problem
[07:18:14] <Jymmm> if the tolerance is 1 inch, that's going to be reflected in everything else.
[07:18:20] <Valen> sure
[07:18:31] <Jymmm> so it IS relevant.
[07:18:45] <Valen> but do you want that 1 inch to be +- .5 of an inch or do you want it to only be +1 inch
[07:19:01] <Jymmm> say +-.0
[07:19:04] <Jymmm> .5
[07:20:12] <Jymmm> If the repeatability tolerance is +/- 0.5", you can't do any better down the road.
[07:20:28] <Valen> if you have a 1 inch error bar do you set the zero co-ordinate to be somewhere inside that error (potentially half an inch off, meaning anything you do from that point on will be offset by half an inch +- 1 inch), or do you set it to exactly 0 and then be +- 1 inch
[07:20:49] <Valen> sorry those +-'s should be +- .5 inch
[07:21:34] <Jymmm> 0
[07:21:45] <Jymmm> or touch the machine =)
[07:21:48] <Jymmm> torch
[07:22:12] <Valen> right, now when you touch the part to the job the machine is actually at 0, but the commanded position can be up to half an inch off right?
[07:22:41] <Valen> touch the tool to the job
[07:23:15] <Jymmm> zero is zero, if you know that you can be off as much as .5 so be it.
[07:23:24] <Valen> its not off
[07:23:37] <Valen> there are 2 things, actual and commanded position
[07:24:01] <Jymmm> lets use the terms relative and absolute position if you wouldn't mind.
[07:24:11] <Jymmm> relative being touchoff
[07:24:23] <Valen> they don't actually fit, EMC uses actual and comanded
[07:24:39] <Valen> actual being that which is measured by the servo system
[07:24:45] <Jymmm> ok absolute == actual, and relative == commanded
[07:24:49] <Valen> commanded being where EMC wants the system to be
[07:25:15] <Valen> relative just sounds hinkey to me but anyway
[07:25:16] <Jymmm> ok and the difference being?
[07:25:38] <Valen> actual being what is measured, commanded being where it should be
[07:25:58] <Jymmm> and the difference between them is?
[07:26:04] <Valen> the error
[07:26:12] <Valen> or following error
[07:26:14] <Jymmm> ok
[07:26:19] <Valen> ferror for short
[07:26:49] <Valen> so with our really poorly tuned servo system that has +- half an inch of ferror in it
[07:26:52] <Jymmm> and isn't that really a "catch up" process?
[07:27:05] <Valen> you use FF terms to null it out
[07:27:21] <Valen> and it gets corrected by the PID as well
[07:27:48] <Valen> I in paticular will return it to 0 error, but small upsets along the way cause errors to pop up
[07:27:48] <Jymmm> If the encoder says it's at 0 point (absolute), why wouldn't it match commanded?
[07:28:19] <Valen> it works the other way
[07:28:31] <Jymmm> either way
[07:28:45] <Valen> commanded is say set to 0 then EMC drives motors to try and make the encoder read 0
[07:29:18] <Valen> then mechanical things get in the way like stiction and such things meaning that you may well not actually meet the 0
[07:29:39] <Jymmm> so if commanded says zero, why doens't the encoder?
[07:29:49] <Valen> because the encoder is in the real world
[07:30:03] <Jymmm> ok,
[07:31:03] <Jymmm> again, zero is zero, it may drift back and fourth from 0.005 to -0.005 continously trying to "maintain" 0
[07:31:27] <Valen> yes, but for the sake of simplicity lets assume its .5 of an inch
[07:31:47] <Jymmm> sure why not
[07:32:44] <Valen> so now we want to make a part
[07:32:53] <Valen> so we jog our machine up to the part
[07:33:14] <Valen> when we touch it what should we zero
[07:33:22] <Valen> the actual position, or the commanded position
[07:33:45] <Valen> theres an idea though, why not zero both?
[07:34:09] <Jymmm> Well, if they differ already, that should be resolved.
[07:34:30] <Valen> thats the whole point they must and will differ
[07:34:47] <Valen> actual position never equals commanded position except in passing
[07:35:12] <Valen> morficmobile: what if touch off zeroed both actual and commanded position?
[07:35:15] <Jymmm> I dont know enough on the that to comment specifically.
[07:38:03] <morficmobile> let me catch up on what was said up to here and i answer when i am home, time to split now, bbiab
[07:38:17] <Valen> no worries
[07:45:55] <elmo42> morficmobile: if the base material is Al or softer you need 5 threads minimum to be as strong as a grade-5 bolt. Steel or stronger 4 is all you need. It doesn't sound like much but this is what ARP says. I will try to find their literature on it.
[07:48:42] <Jymmm> whos using heekscad?
[07:50:18] <Connor> Okay, Got my CNC router up and working .. at least all axis moving that is..
[07:50:27] <Connor> What exactly is "Touch Off" ?
[07:50:51] <Jymmm> It's setting the tool at "zero" in relation to the material.
[07:51:38] <Connor> okay. I have to enter a value in.. no way to move the tool via Jog then "Touch Off" >
[07:51:38] <Connor> ?
[07:55:00] <WalterN> heh
[08:11:40] <cpresser> Connor: type in nothing, 0.0 is correct if the tool is at its designated start-position
[08:12:05] <cpresser> jog to the desired position, then "touch off" (Each axis!)
[08:15:38] <Connor> okay.. I'm looking right now to see how to wire up my limit and home switches.. well.. not switches.. they're opto interupts.. but.. I want to put the limits in series..
[08:21:50] <Valen> it may be best as i vuagley recall to have your home switches seperate
[08:22:01] <Valen> not impossible the other way just harder
[08:22:26] <Connor> Idea, limit in series, homes 1 input each. But, they're all opto interupt.
[08:22:47] <cpresser> sounds reasonable, Connor
[08:23:02] <Connor> just need to find out how to wire opto interups in series.
[08:23:38] <Valen> got a datasheet on them?
[08:24:08] <Connor> http://www.components.omron.com/components/web/pdflib.nsf/0/B92B9C12E226363185257201007DD5D7/$file/D21EESV3SERIES0305.pdf
[08:26:17] <Valen> i think you can just wire it up in parallell with one pullup resistor
[08:27:25] <Valen> or pulldown as the case may be
[08:28:46] <morfic> so, where were we?
[08:29:11] <Valen> I think this sums it up fairly well
[08:29:13] <Valen> if you have a 1 inch error bar do you set the zero co-ordinate to be somewhere inside that error (potentially half an inch off, meaning anything you do from that point on will be offset by half an inch +- 1 inch), or do you set it to exactly 0 and then be +- 1 inch
[08:30:22] <morfic> elmo42: i found a table with fine/coarse pitch, 8.8 and 10.9 grades of bolds and various materials, more a "established/somplified" version of what i wanted
[08:30:54] <morfic> Valen: you do talk about the varying error during *MOTION* a servo loop has, correct?
[08:31:22] <morfic> this is the error you want to be in the middle of, correct?
[08:31:25] <Valen> yes
[08:34:33] <morfic> then hold on, so i can get this answer straight and make you happy ;)
[08:34:59] <Valen> i think i know what your going to say but go ahead anyway
[08:35:01] <Valen> ;-P
[08:41:58] <morfic> Valen: basically i am trying to find it written what is supposed to "be" at the end of the motion
[08:43:33] <morfic> since i am now up 21hrs, i rather find a link or a line in a log than to rely on memory right now
[08:44:08] <Valen> the naive assumption is it should be at the commmanded position
[08:44:27] <Valen> then machine errors will take you somewhere near that
[08:50:10] <morfic> machine errors, but not whatever following errors you see while the servo loop plays catch up during motion, can we agree on that?
[08:50:31] <Valen> to some degree
[08:52:37] <morfic> ok, so link me to your proposal of how a change in tool touchoff fixes these machine errors
[08:52:54] <Valen> it wont
[08:53:22] <Valen> it would however fix any random ferror at touch off
[08:53:50] <morfic> ok, not "fix" fix, but "make workable" fix
[08:54:04] <Valen> and if your machine errors aren't fixed across the job at hand you will be introducing an offset
[08:54:16] <Valen> (and if they are fixed, you should compensate them out ;-P)
[08:54:36] <Valen> the point isnt to "fix" a machine error
[08:54:51] <Valen> its to tollerate the machine error better
[08:55:16] <Valen> I'm assuming that your machine is as good as it can be, nothing you do will change the size of the error
[08:55:57] <Valen> you can however ensure that your error is centered on 0 rather than offset
[08:57:13] <morfic> i think we just invested a whole lot of time talking about something that would have no real trustable agreebale use caused by me understanding you see a difference in end position on an anctual machine, not a hypothetical varying end position that was related to a servo loop playing catchup during motion
[08:58:31] <Valen> i did try to keep saying "the machine doesn't matter" and "this is just an example"
[08:59:13] <morfic> yes, but it started out with "we can see it, we have glass scales" :)
[09:00:13] <morfic> that's where my brain locked target, "real machine" it was, past that it sounded like you tried to find abstractions to explain the problem you are seeing
[09:00:39] <Valen> no, the glass scales is because we were using EMC in a way that was not intended
[09:00:49] <Valen> and it showed up the behaviour
[09:01:16] <Valen> IE you move the lathe around, press touch off and instead of going to 0 it goes to 23.5 or whatever
[09:01:25] <Valen> (which is what the commanded position happened to be)
[09:01:53] <morfic> i would go back to the naive "at the end of the motion it caught up to where actual position is commanded position"
[09:01:58] <Valen> which lead me to think, what happens when you use EMC as intended, if when you touch off, commanded and actual positions are different
[09:03:06] <Valen> and the answer to me is that it will cause the whole job to be offset by the error
[09:03:48] <morfic> if you move to say X1. and set a 1" travel indicator to 0, then tell it to move to X2. the indicator should show you a full inch, even if while it travels the indicator may lag behind the commanded position, ferror
[09:03:59] <Valen> it should,
[09:04:16] <Valen> but if you presume that for whatever mechanical reasons it doesnt
[09:05:20] <morfic> the problem is, when you touch off a tool, you basically tell a control "this position on the glass scale is going to be 1" when i command 1" in the program"
[09:07:34] <morfic> Valen: you are saying it can not reach the actual commanded position, correct?
[09:09:56] <Valen> i have to go pick the missus up
[09:10:02] <Valen> back in about an hour
[09:10:12] <morfic> i better be asleep then
[09:10:41] <morfic> although i'm not feeling it yet, i should, up 22hours in ~30 minutes
[09:13:26] <WalterN> I've done 26 hours before
[09:13:49] <WalterN> donno if I could push any longer than that without external help
[09:16:26] <morfic> i've done stupid stuff when i was young, my body does not like doing things now it did just fine 20 yrs ago
[09:18:43] <morfic> i wonder how many people are/were actually sitting back while Valen and i go/went back and forth
[09:19:37] <alex_joni> usually ferror is the max error that doesn't bother you
[09:21:08] <morfic> during motion, or is it still there after the motion is complete
[09:21:25] <alex_joni> min_ferror after the move
[09:21:29] <alex_joni> ferror at max speed
[09:21:42] <morfic> i read the ferror for rapid and min_ferror for slower moves, and the ramping between the both
[09:22:00] <alex_joni> right
[09:22:29] <morfic> then there is nothing to change on tool touch off, since i already accepted this error to be "ok"
[09:22:29] <alex_joni> so after a move you should be at max. min_ferror away from commanded pos
[09:22:40] <alex_joni> morfic: right
[09:22:53] <alex_joni> the only thing that's still debateable is that it's accumulative
[09:22:57] <alex_joni> say you do 100 touch-offs
[09:23:12] <alex_joni> at each touch-off you have the worst case of +(min_ferror)
[09:23:24] <alex_joni> so you get overall 100*+(min_ferror)
[09:26:22] <morfic> you say any move can be off by that much, and each consecutive motion will be off by that amount again (moving away from touch off, say during milling or turning feed motion)
[09:26:38] <morfic> and it all adds up to one grand total
[09:33:12] <morfic> alex_joni: what i get at is, say you mill a block, and you mill a cavity to say use as a mold to do some vaccuum molding of a RC Car top out of Lexan, you rough with larger endmills and then you end up on your finish tool, and all the rest machining is thousands of short little moves in X, Y, Z, with short i mean some really small segments, so i have thousands of them in a small area, with the accumulative concept i would quickly be off a whole inch, eve
[09:33:12] <morfic> n if min_ferror is .0001"
[09:33:35] <alex_joni> but then again you do touch off based on the tooltip position not repetively based on commanded pos.
[09:34:03] <alex_joni> morfic: you're not supposed to touch off more than once on the same part
[09:34:37] <alex_joni> a consecutive motion _won't_ be off by that amount again
[09:34:49] <alex_joni> the maximum error on _any_ move is max that amount
[09:36:01] <morfic> alex_joni: the way i see it/expect it you tell the machine, "the position you know right now, think of it as 1" from now on", and when i do program Z1. later on, i am at 1" over the surface the 1" block was on, within min_Ferror
[09:37:14] <morfic> alex_joni: the max error is absolute from reference, not accumulative, that's just how that sounded: <alex_joni> so you get overall 100*+(min_ferror)
[09:37:25] <alex_joni> morfic: only if you do 100 touch-off's
[09:37:50] <alex_joni> say touch-off, then g0x1 - touch-off again, g0x1 - touch-off again, etc
[09:38:03] <alex_joni> which you probably would never do in praxis
[09:38:30] <morfic> oh, that's crazy, but i get the example now :)
[09:40:49] <morfic> alex_joni: so a few dozen lines later, nothing has changed, if you could live with min_ferror/ferror before, you can live with it now, so still a none issue
[09:41:40] <alex_joni> right
[09:42:23] <alex_joni> come to thinking of it you really want to do touch-off based on the where the machine is
[09:42:36] <alex_joni> say you want to touch-off on the top of material
[09:42:46] <alex_joni> so you use a dowel pin or whatever to find the top edge
[09:43:06] <alex_joni> you actually care about where the tool _is_ not where you told it to be
[09:43:16] <alex_joni> even if the difference is minute
[09:43:33] <morfic> alex_joni: if your 100x example is truly and positively possible on a EMC2 equipped machine, then emc2 is broken, or the example is, because any position should be an absolute distance to work x, y, z 0 from one reference point
[09:43:49] <morfic> alex_joni: right
[09:44:47] <morfic> you do "train it/teach it" and you should be within the set error each time
[09:49:47] <morfic> alex_joni: i need to type faster, because what you said is what i meant, when you do tool touch off, you should be a certain amount of encoder pulses from where the machine started counting, and if you touch that tool off a million times, that number of impulses should always result in the same tool table entry
[09:50:20] <morfic> of course we use machine units for convenience, not ballscrew turns or encoder pulses :)
[09:53:57] <morfic> alex_joni, Valen: 'night and thanks
[10:07:07] <alex_joni> 'night
[10:53:33] <Valen> alex_joni: the point i was making with touch off is that by using commanded position rather than actual position, you are going to offset your part by the error
[10:56:08] <alex_joni> Valen: yeah, probably.. but the error is negligable
[10:57:36] <Valen> well one would hope, but why leave it wrong?
[11:22:53] <elmo42> Jymmm: I use heeks... from time to time. what's up?
[12:10:39] <Valen> one of these would be nice
http://www.youtube.com/watch?v=wIElFAibxTU&feature=related
[12:22:17] <alex_joni> Valen: heh, dream on :P
[12:36:56] <cpresser> 25kW spindle sounds nice :D
[12:37:37] <cpresser> its almost milling as fast as my machine does rapid-feed moves :)
[12:57:07] <elmo42> are VIA processors well supported?
[13:02:37] <elmo42> this a simple way to get a solid state drive?
http://qurl.org/h41
[13:24:05] <Valen> yeah, you do want to watch the write life of the CF card though
[13:24:19] <Valen> also you want to make sure you get one that supports DMA
[13:27:14] <alex_joni> CF != SSD
[13:30:08] <alex_joni> "A real SSD will include proper wear-levelling, because it is designed for the use-case of a standard HDD. CF cards are not."
[13:31:56] <Valen> still they are good enough if you know the limitations
[13:32:13] <Valen> though you can get 32Gb SSD's for ~$100 Australian
[13:32:16] <Valen> anyway night
[13:46:34] <alex_joni> is there a way to check the currently loaded tool's diameter?
[13:47:27] <_AR_> use a micrometer
[13:47:40] <alex_joni> I meant from the g-code program :)
[13:47:44] <_AR_> lol
[13:47:59] <_AR_> well if you know what tool you have and loaded it in
[13:47:59] <alex_joni> (msg, use a micrometer dumbass)
[13:48:07] <skunkworks> heh
[13:48:09] <skunkworks> Hi alex
[13:48:17] <alex_joni> _AR_: I want to write a subroutine
[13:48:28] <cradek> I think it's not in 2.4, but yes there's a diameter variable now
[13:48:29] <alex_joni> a generic one, that doesn't know before what tool is loaded
[13:48:33] <alex_joni> hi skunkworks
[13:48:35] <cradek> if only I knew what it was...
[13:48:36] <_AR_> lol
[13:48:40] <_AR_> well then you need sensors
[13:48:41] <_AR_> or something
[13:48:43] <alex_joni> 5xxx
[13:49:10] <cradek> #5410
[13:49:39] <alex_joni> whee.. thanks
[13:49:55] <skunkworks> alex_joni: whatcha workin on?
[13:49:57] <alex_joni> maybe jthornton can add it some day to the docs
[13:50:09] <alex_joni> skunkworks: nothing really, got a quesiton asked from a user
[13:50:14] <skunkworks> ah
[14:54:16] <steverob> Anybody home?
[14:54:54] <steverob> Just installed EMC on a desktop computer and it hangs whenever I start EMC2.
[14:55:15] <steverob> I get a splash screen then it just hangs. Any ideas?
[14:56:49] <cradek> what version of EMC, what OS, what configuration are you trying to start?
[14:57:48] <steverob> The computer is at a friends shop so, I don't have it in front of me. It's a 2 GHZ processor, 80 GB disk, 512MB memory.
[14:58:22] <steverob> I only had 8.? with me so, that's what I installed. Later this evening I'll try a newer version.
[14:58:51] <cradek> ok so you're talking about the linuxcnc cd version of ubuntu 8?
[14:59:06] <steverob> I've installed on several computers at home and never had a problem.
[14:59:08] <steverob> Yes
[14:59:33] <cradek> ok, what emc configuration were you trying to run?
[15:00:03] <steverob> I tried several IE sherline-inch and a couple others.
[15:00:19] <cradek> ok, so parport/stepper configs. did you try sim/axis?
[15:00:54] <steverob> No... I'm not familair with sim/axis
[15:02:41] <cradek> brb
[15:04:52] <steverob> Sorry... Gotta go. The wife just got home.
[15:07:12] <jthornton> Dave911: if your around I've learned a bit more about the mill today
[15:09:06] <Dave911> Hi John.. what did you find
[15:09:57] <jthornton> after reading a bit the material you sent me the drive is not giving an alarm but only showing the operating status (I think)
[15:10:46] <jthornton> I wrote a short program that has a 1/2 dwell between increments of 100 and can start at 1000 and ramp all the way up to 6000 with no problems
[15:11:08] <jthornton> 1/2 second
[15:12:43] <jthornton> I do however have (last time I looked) some error leds on the first section (power section) on (bottom 4 if I recall correctly) after the fault
[15:31:36] <Dave911> That drive is pretty old... it would not surprise me at all if the capacitors in the power section are getting weak ... might want to search for new caps.. 17 years is a long time for big power caps..
[15:32:17] <Dave911> I'm having problems with a similar vintage big spindle drive and I suspect the caps are going now also..
[15:32:58] <jthornton> that is the first section right?
[15:33:02] <jthornton> on the left
[15:33:05] <Dave911> From what I have been told by repair centers for similar drives.. when they get drives that old in for repair they first replace the caps and then test and start looking for other problems
[15:33:16] <Dave911> Yes .. that is the DC bus power supply
[15:33:53] <jthornton> ok, thanks for all the help
[15:34:35] <Dave911> Sure .. you are welcome... I'm glad I could help..
[15:35:15] <jthornton> and thanks for the manuals
[15:35:32] <jthornton> * jthornton is on dialup so I gotta hang up now :/
[15:35:36] <Dave911> Make sure you allow those caps to discharge before you try and remove them! They can store a lot of energy ...
[15:35:43] <Dave911> Np ... bye
[15:35:54] <jthornton> and they bite you if you don't lol
[15:36:07] <Dave911> Oh yes ...
[15:49:40] <cradek> seb_kuzminsky: did your town survive?
[15:50:21] <seb_kuzminsky> most of it
[15:50:50] <seb_kuzminsky> something like 170 houses burned, all up in the mountains where it's hard to get firetrucks
[15:53:46] <skunkworks> yeck
[15:54:08] <skunkworks> we got 4 inches of rain last night - too bad we couldn't email that.
[15:54:17] <seb_kuzminsky> pastebin it
[15:54:51] <cradek> seb_kuzminsky: yikes.
[15:55:02] <cradek> did you evacuate?
[15:55:12] <seb_kuzminsky> we didnt have to
[15:55:30] <seb_kuzminsky> we were on evac notice, so i had the bags packed and the cars fuelled and all that
[15:55:34] <cradek> I wasn't too worried - highlab.com was still pinging.
[15:55:54] <seb_kuzminsky> it was scary standing outside at night with the sky all red and the wind blowing smoke in my face
[15:56:28] <cradek> and, being stupid monkeys, we build our houses out of tree parts...
[15:56:38] <seb_kuzminsky> yeah - pretty ridiculous
[15:56:38] <cradek> frightening
[15:57:51] <seb_kuzminsky> highlab is on the evac packing list ;-)
[15:59:13] <cradek> packing list: 1) cats 2) tapes 3) other
[15:59:53] <seb_kuzminsky> a bus full of scared cats
[16:00:08] <cradek> actually, 3 is probably my laptop
[16:00:35] <cradek> 4) 80 gallons of diesel
[16:00:38] <cradek> haha
[16:00:49] <seb_kuzminsky> dont forget that box of buerocratic papers
[16:01:08] <cradek> file drawer - yep
[16:01:53] <seb_kuzminsky> turn off residential gas & electricity, & put a note on the front door saying you're all out
[16:02:18] <cradek> the note is smart - was that instruction in your evac announcements?
[16:02:27] <seb_kuzminsky> yeah
[16:02:51] <cradek> well, guess it depends whether you expect to have rescuers or looters visit
[16:03:20] <cradek> with a note though, a looter would be pretty sure that easy to carry valuables are quite gone
[16:03:25] <seb_kuzminsky> ugh
[16:03:44] <seb_kuzminsky> "residents have left, robotic defenders are still here"
[16:04:38] <seb_kuzminsky> my old CS teacher's house burned down to the foundation
[16:04:50] <cradek> jeez
[16:25:07] <tom3p> IMTS: a nice 5 axis gantry , i always preferred this 'above your head' style ( drop the machine onto 2 walls )
http://imagebin.ca/view/NkbETQn4.html
[16:26:10] <tom3p> and an interesting nutating spindle design at NUM
http://imagebin.ca/view/1Bc98Nr.html
[16:26:51] <tom3p> moving the 2 motors controls A&B angle, spindle is thru the tube
[16:28:06] <tom3p> you'll have to imagine it.. and think about when the lengths are the same, and when they differ ( to see how A&B are controlled )
[16:32:39] <skunkworks> sort of one section of a hexapod.
[16:32:50] <skunkworks> (2 joints)
[16:34:08] <awallin> did anyone go to imts?
[16:34:21] <cradek> I went last year...
[16:36:04] <awallin> there's something here in finland next week... but I'm not sure if I should just go to look (not buying anything anyway)
[16:36:37] <cradek> I thought it was fun to go once
[16:36:53] <cradek> there's some big stuff, some fast stuff, some small precise stuff, etc
[16:38:27] <cradek> although the coolness of seeing stuff was offset by the salespeople who wanted to chat
[16:39:24] <awallin> chat == sell ?
[16:40:19] <tom3p> thats what they're there for, but you can get some real info if you find the right guy and he's not busy
[16:41:58] <tom3p> turned out NUM is local to me and they offered to let me try their gap controller
[16:45:22] <tom3p> oh and Rolls had a new turbine demo, a head tracking device and 3D shutter lenses that trained maintainence people. you could duck under a wing, reach in and pull out a bit, them examine it.
[16:47:09] <tom3p> trent 700
[16:49:58] <Dave911> seb: I hope you don't have any large gas lines near your house ... ;-)
[17:20:40] <nullie> anyone uses lumenlab micro?
[17:22:56] <andypugh> I have just noticed that I am now a "Gold Boarder" on the EMC2 forums. I am disappointed, being a "Goldmember" would have been so much more Austin Powers.
[17:36:30] <skunkworks> heh
[17:54:02] <tom3p> that nutating head from NUM, found an animation goto
http://www.num.com/ drill down to Total Solutions/ NUMcut
[17:56:24] <skunkworks> tom3p: neat
[17:56:26] <andypugh> I have seen that before, and I am not entirely sure what it does better than designs with far simpler kinematics
[17:56:49] <skunkworks> 2 rotating axis? :)
[17:57:53] <tom3p> 1 linear
[17:57:53] <tom3p> err 2 linear
[17:58:08] <tom3p> mass moved is small
[17:59:32] <andypugh> I would be surprised if a plasma or waterjet head ever moved fast enough for mass to be a problem.
[18:00:25] <tom3p> in edm ( notoriously slow ) you need to run away really fast
[18:00:26] <Connor> Question, my X and Y motors run really Cool, but, my Z axis motor is blazing hot.. it's a smaller motor... why would it be so dang hot? (it's also a 6 wire vs a 4 wire)
[18:00:45] <skunkworks> run away! run away!
[18:00:51] <tom3p> :)
[18:01:05] <andypugh> Connor: Are you perhaps running it way above rated current?
[18:01:24] <Connor> I'm running it at 75%
[18:01:39] <andypugh> That is the current set by the drive?
[18:01:39] <Connor> It's mostly when it's standing still
[18:01:59] <Connor> yea.. I can switch 25,50,75 and 100% on the driver board.
[18:02:00] <andypugh> It might be rated at that current unipolar, and you might be driving it bipolar?
[18:02:01] <skunkworks> andypugh: positioning speeds would be a lot faster with that system.
[18:02:06] <tom3p> hot often means working harder , try moving similar axis by hand and feel the difference ( standing still can be work )
[18:02:51] <andypugh> 75% of the driver board max current is what? And what is the motor rated current?
[18:02:52] <Connor> It's on a 5mm pitch vs the others which are 10mm.. and it's mostly just sitting.. when I was running test on it back and forth.. it was cool to touch.
[18:03:03] <Connor> let me look
[18:04:13] <andypugh> Standing still you are only driving one phase, when moving the current is a) lower and b shared out between the phases.
[18:04:56] <Connor> it's rated at 1amp at 8.6v ??
[18:05:14] <andypugh> You can ignore the voltage rating.
[18:05:29] <andypugh> But what current does your drive supply at 75%
[18:06:35] <Connor> It's the Toshiba 6560A
[18:06:41] <Connor> looking for spec sheet now.
[18:06:51] <Connor> It's rated for 3amps.
[18:07:21] <andypugh> So 75% is 2.2A through a 1A rated motor?
[18:07:48] <Connor> so, I guess I need to drop it to 25%
[18:08:04] <andypugh> Try 50% first, it hasn't burnt out yet.
[18:08:11] <Connor> k
[18:08:19] <andypugh> You could attach a heatsink.
[18:08:20] <andypugh> ]
[18:08:44] <andypugh> Allowable temperature rise for motors is actually pretty high.
[18:09:43] <andypugh> Google suggests a max of 80 degrees C case temp (176F) which is enough to burn you.
[18:50:30] <tom3p> when did the mesa 'group buy' occur ? ( mesa asked me for date when i asked to change ide to terminal strip )
[18:55:24] <andypugh> People _buy_ Mesa kit? I seem to have built up quite a collection with vague promises of drivers :-)
[18:56:42] <alex_joni> tom3p: 2006? or 2007
[18:57:52] <alex_joni> http://jmkasunich.com/cgi-bin/blosxom/shoptask/m5i20-group-buy.html
[19:00:35] <skunkworks> heh - I have had the hardware since early 07. I am not even using the 7i37's I bought
[19:02:21] <skunkworks> some one want to trade a few 7i37's for a 7i33 or 7I48? :)
[19:03:36] <tom3p> alex_joni, thx very much
[19:05:58] <andypugh> Only got 7i39s
[19:23:31] <cradek> alex_joni: funny - I gave away 2/3 of the boards I got in that buy
[19:36:56] <skunkworks> you still have a pluto ;)
[19:56:23] <Jymmm> skunkworks: I thought the pluto was kinda dead ?
[19:56:28] <L84Supper> anyone ever try a 1-1/4" end mill holder in R8?
http://cgi.ebay.com/1-1-4-END-MILL-HOLDER-R8-ADAPTOR-TOOL-MILLING-NEW-/330452277638?pt=BI_Tool_Work_Holding&hash=item4cf07d9986
[19:57:13] <L84Supper> is it steady enough for rough cuts in aluminum?
[19:57:28] <Jymmm> L84Supper: PM?
[19:57:37] <skunkworks> Jymmm: it works... but you can get a mesa for a few dollars more that is just built better ;)
[19:58:07] <Jymmm> skunkworks: Oh, I thought there was some wall that was hit with it
[20:01:43] <andypugh> L84Supper: I don't see why not, I use a 50mm dia face mill on a No3 Morse. The spindle is rigid enough, just a pity about the rest.
[20:08:39] <cradek> L84Supper: I recommend a 3/4 roughing end mill instead
[20:09:05] <cradek> I think 1-1/4 is way too big for an R8 machine
[20:09:38] <cradek> if you have flood coolant you can pretty much cut aluminum as fast and deep as you want with a 3/4 rougher
[20:18:46] <andypugh> How do you reset a 7i43? Mine seems convinced that it has a 200k FPGA, after trying to use it with a duff bitfile.
[20:19:29] <pjm> andypugh i had that problem too, power cycle i seem to recall fixed it
[20:19:40] <pjm> but cradek also coded a fix which sent the reset bytes twice
[20:19:46] <pjm> which worked
[20:20:03] <andypugh> I have power-cycled the whole garage (i can do that from the house) and no luck so far. Maybe I need to wait longer?
[20:20:27] <pjm> ah just a few seconds was enough in my case
[20:21:06] <cradek> that was jepler - I've never touched a 7i43
[20:21:07] <pjm> but my issue was with the card when you stopped emc, closed it, then restarted it, the card was id'd incorrectly as it hadnt been reset
[20:21:13] <pjm> ah sorry yes u are right
[20:21:40] <andypugh> You devs all look the same from here.
[20:22:09] <cradek> you users too
[20:22:21] <cradek> little white letters
[20:22:32] <andypugh> White? How old-skool
[20:27:23] <L84Supper> cradek: that's what I had heard... I was just given a bunch of 1-1/4" cobalt end mills
[20:27:41] <L84Supper> they just look too big for R8
[20:28:27] <cradek> sounds like a nice gift, but those might be too big for anything other than 50 taper
[20:28:43] <cradek> I sometimes cut wood with a 1" - the big diameter helps get the surface speed up
[20:29:02] <L84Supper> andypugh: do you have cooling issues?
[20:29:04] <cradek> if you do any wood, maybe they'd be useful, but I doubt you'd be happy cutting metal with them
[20:29:14] <L84Supper> just aluminum
[20:30:41] <andypugh> L84Supper: I ignore cooling issues, as the machine has no coolant. I drip the odd sniff of cutting compound on it and hope for the best.
[20:33:45] <L84Supper> I have a set (8?) of 40 taper end mill holders ready for ebay unless somebody here is interested
[20:34:02] <elmo42> for the most part Al doesn't need cooling. Lubricant is a different issue. Air with a mist of cutting 'oil' is all we ever use. Far easier to clean up :)
[20:35:49] <andypugh> I have been working mainly in cast iron of late.
[20:38:47] <elmo42> grey iron? or nodular?
[20:39:13] <elmo42> grey is fine with only air or varsol. nodular is different.
[20:39:19] <elmo42> grey makes dust. I hate it
[20:39:45] <andypugh> Grey
[20:40:15] <andypugh> Servo motor mounts:
http://picasaweb.google.com/bodgesoc/Gibbs#5511282568768390018
[21:00:16] <PCW> andypugh: if you load the 7I43 with a bad bitfile, you will have to cycle the power (the 7I43 relies on the FPGA to reset itself if a config file is loaded)
[21:09:22] <andypugh> Yes, well.
[21:10:18] <andypugh> I patched with a "Suppress bad board" variant patch that I had lying about, and it still didn't work. So I reached down to cycle the power again, and noticed that the P-Port cable wasn't plugged in!
[21:10:36] <andypugh> It works fine now....
[21:11:21] <andypugh> It just happened that the dmesg error is the same as you get when you use a bad bitfile, and I _had_ just used a bad bitfile....
[21:16:12] <JT-Hardinge> I hate when that happens
[21:17:49] <PCW> The 7I43 ID stuff is pretty primitive, Just figured out how to save bout 11 cells in the CPLD so I could improve it now
[21:17:52] <andypugh> With a 4-joint 3-axis machine, what is the correct way to configure [TRAJ] AXES and [TRAJ] COORDINATES?
[21:21:42] <elmo42> andypugh: did you cast them yourself? they look beefy!
[21:23:05] <andypugh> I wanted to cast them myself, but project overload meant that i made more sense to have them made for me. £100 all-in seemed reasonable compared to the cost of suitable lumps of steel or ali.
[21:24:04] <PCW> Andy, just sent your bitfile
[21:26:12] <andypugh> Great, just as I have got sorted out with the 7i43 version on my 7i43 :-)
[21:26:49] <andypugh> Not having to walk out to the workshop to see what it is doing should be a big help
[21:39:19] <JT-Hardinge> dang the BP308 drills a nice smooth hole... better than any other mill I have
[21:56:05] <alex_joni> http://funpics.classicfun.ws/index.php/Funpics/Grandad-remembering-the-good-old-days
[21:57:03] <PCW> andy: you can do most testing with only 48V bus power so it can be done safely
[22:01:48] <JT-Hardinge> Houston, the coolant containment vessel has been repaired and is now ready for service... except for what I spilled on the floor filling it up :)
[22:08:38] <skunkworks> we have an old linux machine that we want to hook to the network. I am failing (actually a centroid cnc) we have
http://pastebin.ca/1942425
[22:08:52] <skunkworks> I cannot ping anything but the nic
[22:09:38] <skinnypup> typr route and see what the gateway ip is for the default route
[22:09:52] <cradek> after it boots, what do ifconfig -a and netstat -nr say?
[22:10:39] <skunkworks> I will have to do it tomorrow. (it is at work)
[22:10:42] <skunkworks> thanks
[22:10:52] <cradek> how old is it? like what kernel?
[22:11:55] <skunkworks> I didn't look - I was following these directions -
http://www.centroidcnc.com/dealersupport/techbulletins/showtb.php?TBID=168
[22:12:54] <cradek> kind of feels like old redhat
[22:13:03] <cradek> in ifcfg-eth0 they have GATEWAY and you don't
[22:13:56] <skunkworks> the section For Software versions 2.60 & up
[22:14:16] <cradek> oh I see, different versions
[22:14:54] <skunkworks> right
[22:15:31] <cradek> what kind of network card? does it have more than one port? (bnc, aui, tp)?
[22:15:41] <skunkworks> now that I think about it - maybe the ip address was already used. (I didn't double check what a coworker came up with)
[22:15:58] <skunkworks> onboard network
[22:16:21] <skunkworks> pretty new - less than a year old
[22:16:22] <cradek> oh it must not be as old as I thought :-)
[22:16:33] <skunkworks> just old software ;)
[22:16:37] <skunkworks> I guess
[22:16:49] <cradek> eth0 is detected sanely in dmesg?
[22:17:06] <skunkworks> wow - I have a lot of things to check :)
[22:17:19] <cradek> heh
[22:21:28] <JT-Hardinge> * JT-Hardinge is sure glad loc-line nozzles are not made from steel :/
[22:32:44] <alex_joni> skunkworks: you asked for it :P
[22:48:48] <Valen> skunkworks: try dhcp first time around
[22:49:05] <Valen> dhclient eth0
[22:50:02] <Valen> theory is dhcp should give you enough right settings, and if you get no replies you know its a lower level issue than IP
[22:52:31] <Valen> PCW how high a voltage would one be comfortable running a 7i40 at? got a switchmode supply but I cant turn it down below around 42 volts
[22:52:57] <PCW> LV model?
[22:53:06] <Valen> yah
[22:53:37] <Valen> I should have gone the H version it seems ;->
[22:53:58] <PCW> Its got 55V MOSFETS so if its really 42V you should be OK
[22:54:19] <Valen> any other limitations on it, components that are voltage sensitive?
[22:54:27] <PCW> I think its HV clamp is set for 50V
[22:55:23] <Valen> I'll add some beefy low ESR caps to the supply
[22:55:36] <skunkworks> Valen: no dhcp server
[22:55:46] <Valen> skunkworks: :-<
[22:55:53] <skunkworks> all static
[22:56:11] <Valen> I normally set everything with static DHCP leases ;-.
[23:36:38] <morficmobile> 'evening
[23:39:31] <Valen> zup
[23:42:01] <morficmobile> not much, ready for another fun filled night of programming parts
[23:43:08] <Valen> isnt that dayjob stuff?
[23:43:33] <morficmobile> my day job does shifts, so based on need, i program day and night in the same week
[23:44:03] <Valen> lots of $$$?
[23:45:12] <JT-Hardinge> morficmobile: what cam program do you use?
[23:45:48] <morficmobile> Esprit
[23:47:39] <morficmobile> if you wonder if i like it? i can get the parts done, but i don't think it's "how it should be" (but it seems i have a memory of how the old gibbs was that may no longer be true for the current gibbs versions :/)
[23:50:48] <morficmobile> JT-Hardinge: the "feature recognition" of Esprit is coming along nicely, it can spit out frontside/backside programs of simpler bushings and rings just by being fed a solid model
[23:55:16] <JT-Hardinge> I'm using Solidworks with OneCNC
[23:55:34] <JT-Hardinge> SW is fantastic but OneCNC cuts a lot of air
[23:56:05] <Valen> air cutting is daft
[23:56:38] <Valen> if tool is not cutting then delete track
[23:56:49] <JT-Hardinge> ain't that simple
[23:57:02] <Valen> feels like it should be lol
[23:57:11] <JT-Hardinge> I know what you mean
[23:57:18] <Valen> if tool is cutting when outside of stock area then stop being so stupid
[23:57:23] <Valen> freekin rhinocam
[23:58:08] <JT-Hardinge> high speed pockets don't start in the center so lots of wasted time with OneCNC for some reason I've yet to understand