Back
[00:13:10] <jepler> Dmess: op-amp board? I sent some links for servo amp boards earlier today, is that what you mean?
http://pico-systems.com/pwmservo.html and
http://mesanet.com/ -> click "motion control", scroll down to "7i29"
[00:13:18] <jepler> don't think I've had op-amps on my mind lately
[00:16:22] <Dmess> it was to feed my VFD controller
[00:21:32] <Dmess> http://www.cnc4pc.com/Store/osc/product_info.php?products_id=58 would this work??
[00:27:25] <jepler> oh, you must be thinking of someone else
[00:28:41] <stustev> jepler: what did you think of the video of the cinci?
[00:29:36] <jepler> stustev: the youtube video was still long enough that I found myself skipping forward, but it makes me shiver to see emc2 doing that
[00:29:48] <jepler> one of these days we'll actually be comparable to the big boys like mach3 and turbocnc
[00:29:57] <stustev> alright!
[00:30:24] <stustev> you don't want to download the whole thing and watch that for 52 minutes?
[00:30:27] <jepler> but, seriously, it's great seeing emc do that
[00:31:02] <stustev> it IS sweet to see
[00:31:19] <stustev> you gentlemen have done a great job on it
[00:32:40] <Dmess> you are carving some nice stuff and seem to have it tuned correctly
[00:33:27] <jepler> now we just need to finish up 2.3 so that everyone can have that code easily...
[00:33:40] <stustev> yes
[00:34:51] <stustev> Dmess: the tuning could be better - the servo amp are SCR amp with their own tuning - emc must superimpose tuning on them and cannot get much if any better than the tuning of the SCR amps
[00:35:51] <stustev> I want some 'dumb' amps. So emc2 is in full control
[00:36:35] <jepler> stustev: how many V and A?
[00:36:58] <stustev> 90V 25A - I think
[00:38:25] <stustev> we have discussed this here before - there are a few possibilities that have been identified
[00:38:44] <jepler> can't you get jon elson to sell you some 25A-rated boards?
[00:39:01] <jepler> looks like both his DC and brushless boards are 160V/20A
[00:39:35] <stustev> he and I have visited about that - he was very busy on another project at the time - he has since finished the project - I will hit him up again - thanks
[00:40:24] <stustev> after thinking about this for a minute the numbers are 90V 33A
[00:40:45] <jepler> DC or brushless?
[00:40:54] <stustev> brushed DC
[00:41:24] <stustev> I asked him if I could parallel two of his drives - he said it would be difficult
[00:41:35] <jepler> yeah that was the next question I had as well
[00:41:47] <stustev> something about load balance
[00:42:22] <stustev> it would be easier for him to develop a larger capacity unit
[00:43:52] <stustev> Randy, the outside service tech, brought in a dumb amp he put together. That was about the time I fried the spindle on the cinci.
[00:44:16] <stustev> I stopped all other projects to concentrate on one at a time
[00:44:17] <jepler> yeah what happened to that amp?
[00:44:32] <stustev> it is still on my desk
[00:45:17] <jepler> oh!
[00:45:34] <jepler> oh look, a the thread on checking squareness of a machine
[00:45:41] <jepler> * jepler should do that on his machine
[00:46:01] <stustev> we will get back on it shortly - now that the cinci is up - I will get the G&L up and then (crossed fingers) I will have some time to do something else
[00:46:12] <stustev> a thread on the users list?
[00:46:21] <toastydeath> stustev: your machine is incredible, how much did you get the iron for
[00:47:41] <stustev> I have had this machine since late 1996. It had the cinci control on it for year. I put MDSI's OpenCNC on it. Earlier this year I started the EMC2 install.
[00:49:25] <jmkasunich> stustev: when you run out of projects, you need to get the big gantry going with EMC ;-)
[00:49:40] <stustev> that is a project on the list
[00:49:43] <jmkasunich> might need a new building first
[00:49:55] <stustev> I have been looking
[00:50:17] <stustev> I need to get the retrofit projects in a room by themselves.
[00:51:15] <stustev> alzheimers is making it's presence known
[00:51:50] <stustev> I need to restrict myself to one project (like this) at a time
[01:08:32] <stustev> jepler: all the software I am using is available in TRUNK except the kinematics with the geometric compensation of the rotary axes. (I think)
[01:12:05] <stustev> jmk: I have been looking a the hgr website. I told my wife I need to make a trip to Euclid Ohio
[01:12:26] <jmkasunich> heh
[01:12:36] <jmkasunich> let me know when you are coming
[01:12:48] <jmkasunich> I don't need any excuse to go there, but if I have one that makes it even better
[01:12:54] <jepler> stustev: swing by lincoln and pick me up on the way
[01:13:00] <jepler> (I bet chris will want to come too)
[01:13:23] <jmkasunich> next EMC workshop can be in cleveland
[01:13:24] <stustev> I am sure chris will go - we can make a trip of it :)
[01:13:32] <stustev> I will be there
[01:15:36] <jmkasunich> its a very long drive from NE or KS, and if you fly you are seriously limited in what you can bring home
[01:15:55] <stustev> that's why a drive would be necessary
[01:16:11] <stustev> 12 hours from Lincoln?
[01:16:24] <jmkasunich> its about 530 miles, 9 hours, from the CNC workshop to here
[01:16:35] <jmkasunich> I bet its closer to 16 from Lincoln
[01:16:41] <stustev> it would be
[01:16:47] <stustev> same from Wichita
[01:17:08] <stustev> just a short day jaunt
[01:17:12] <jmkasunich> heh
[01:17:17] <jmkasunich> did you drive to IMTS?
[01:17:20] <stustev> yes
[01:17:27] <stustev> through lincoln
[01:17:50] <jmkasunich> its probably 5 hours from chicago to here
[01:17:59] <jmkasunich> all of indiana and most of ohio
[01:18:22] <stustev> that would put is about 12 hours - maybe 13
[01:18:36] <stustev> no step for a stepper
[01:19:10] <stustev> the only problem would be driving something big enough to carry the purchases
[01:19:14] <jmkasunich> if you come, there are other places to visit
[01:19:24] <stustev> HGR2
[01:19:32] <stustev> ? :)
[01:19:35] <jmkasunich> net measurement pyvcp.measurement => motion.analog-in-00
[01:19:38] <jmkasunich> oops
[01:19:47] <jmkasunich> http://www.mckeanmachinery.com/
[01:19:59] <jmkasunich> less then 5 miles from HGR
[01:20:37] <jmkasunich> they used to be less than 1 mile away, and I'd often visit both
[01:20:45] <jmkasunich> then they moved to a more out-of-the way spot
[01:20:53] <jmkasunich> they also don't have saturday hours
[01:21:22] <stustev> is Mohawk Machinery and Great American close to you?
[01:21:31] <jmkasunich> those don't ring a bell
[01:22:14] <jmkasunich> cincinatti - diagonally opposite end of the state
[01:22:18] <jmkasunich> probably 5-6 hours
[01:23:08] <stustev> maybe worth a visit on the way home
[01:23:48] <skunkworks> stustev: I find myself running the progress bar of the 5 axis video back and forth.. very hypnotic.
[01:24:04] <jmkasunich> this one is close by
[01:24:05] <jmkasunich> http://www.clevelandmachinery.com/
[01:24:20] <stustev> skunkworks: it is fun to watch
[01:24:48] <jmkasunich> they are "machines" only, unlike HGR and McKean that have both complete machines and tons of misc stuff
[01:25:24] <jmkasunich> also this place:
http://www.smalltools.com/
[01:25:29] <stustev> could be a few day visit - with emc stuff and all
[01:26:06] <jmkasunich> its hard to justify two 12 hour drives to visit one place, but four......
[01:26:44] <stustev> hgr looks almost worth it by itself
[01:26:56] <jmkasunich> hgr is pretty amazing
[01:27:24] <stustev> I find myself wondering what I am missing by just looking at the pictures
[01:27:45] <jmkasunich> HGR is a former fisher body plant from back in the day
[01:27:54] <jmkasunich> big old wood-framed industrial building
[01:27:56] <stustev> big building
[01:28:42] <stustev> skunkworks: any questions? comments?
[01:29:56] <jmkasunich> oh, McKean moved again- they're on the west side now
[01:32:10] <stustev> skunkworks: if you find yourself wanting to torture yourself there is a file www.mpm1.com:8080/cinci/Machine long.avi - it is the whole thing
[01:32:43] <stustev> McKean has moved twice in how many years?
[01:32:58] <jmkasunich> less than 10
[01:33:04] <jmkasunich> maybe less then 7?
[01:33:09] <stustev> are they growing or getting smaller?
[01:33:14] <jmkasunich> I bet smaller
[01:33:19] <jmkasunich> I think HGR is kicking their rear
[01:33:41] <jmkasunich> ISTR that either HGR was founded by former McKean folks, or the other way around
[01:33:41] <stustev> must be - maybe the next move will be to west virginia
[01:34:26] <jmkasunich> I think it HGR is newer - they say "celebrating 10 years" on their site
[01:34:34] <jmkasunich> so they were founded by former McKean folks
[01:34:56] <jmkasunich> HGR is better organized, has a better website, and probably does a lot more volume
[01:35:46] <jmkasunich> I've even seen HGR ads on TV here - that isn't the kind of place that normally advertises on TV
[01:36:03] <stustev> the good guys at mckean left to mange their own company better - happens all the time
[01:42:46] <stustev> jepler: where has cradek been this weekend? he seems to have just dropped off the face of the world (or turned off his computer)
[01:42:59] <stustev> same thing :)
[01:43:15] <jmkasunich> he was in the -dev channel for a little bit not to long ago, then off again
[01:43:19] <jmkasunich> probably working on something
[01:44:23] <stustev> ok
[02:31:29] <whatswithhumans> hello
[02:32:14] <fenn> a windows user, get him!
[02:32:25] <toastydeath> * toastydeath mug
[02:32:45] <stustev> traitor
[02:32:57] <whatswithhumans> ... i am actually using a computer at my svhools lab
[02:33:07] <stustev> spy
[02:33:27] <jmkasunich> what is the unix command to copy files?
[02:33:38] <whatswithhumans> cp
[02:33:39] <stustev> might be cp
[02:33:45] <jmkasunich> password accepted, welcome!
[02:34:20] <stustev> rats
[02:35:02] <whatswithhumans> anyways, my friends and i are trying to figure out ecm2 mainly what is required for the stepper motor controlers. think you can give us any help?
[02:35:14] <jmkasunich> just ask your question
[02:35:59] <whatswithhumans> does emc2 do all of the work? do the stepper controllers just need to be power amps?
[02:36:22] <jmkasunich> emc normally outputs step/dir, for the traditional step/dir drives
[02:36:30] <whatswithhumans> awesome, thanks
[02:36:37] <jmkasunich> it can also output various patterns that can be used to directly drive transistors
[02:36:54] <jmkasunich> but that kind of system is usually rather low performance compared to a modern chopper driver with step/dir input
[02:37:15] <whatswithhumans> well. we'd make the controller ourselves
[02:37:22] <whatswithhumans> so the transistor method will probably be better
[02:37:45] <jmkasunich> unipolar or bipolar?
[02:37:45] <whatswithhumans> unless you can point me to really nice controller shcematics
[02:37:53] <whatswithhumans> we have unipolar right now
[02:38:12] <jmkasunich> 4 transistors, center taps of the windings hooked to the supply voltage?
[02:38:59] <jmkasunich> http://www.linuxcnc.org/docview/html//hal_rtcomps.html#sub:Stepgen-Step-Types
[02:40:08] <jmkasunich> type 5 is full step one-winding on, type 6 is full step two windings on (more torque), type 9 is half-step
[02:42:10] <stustev> did you scare them off?
[02:42:38] <whatswithhumans> ....
[02:42:54] <stustev> oh - just thinking
[02:42:58] <stustev> :)
[02:43:43] <stustev> you guys blew by me with the first question - I know < nothing about steppers
[02:44:04] <whatswithhumans> hehe
[02:44:24] <stustev> I can only lurk and make smart aleck comments
[02:44:41] <whatswithhumans> how fast does the computer need to be to get decent sofware pwm?
[02:46:35] <jmkasunich> its not so much computer speed (GHz) as it is latency
[02:46:46] <jmkasunich> sometimes a slower computer actually has better latency
[02:46:58] <jmkasunich> "decent" is hard to define
[02:47:17] <jmkasunich> but in general, you aren't going to get high quality many KHz PWM out of software
[02:47:38] <jmkasunich> you can usually get single-digit KHz at reasonable resolution
[02:48:02] <stustev> whatswithhumans: what is your definition of 'decent' - what is your project
[02:49:32] <whatswithhumans> circuit boards first, then maybe small alum pieces. Nothing really presision intensive
[02:49:47] <whatswithhumans> perhaps we will make a larger mill later to build engine parts
[02:55:15] <stustev> bbl
[02:58:40] <JymmmEMC> If you're hiking in the snow/ice, do you build a fire ON the snow/ice? Like eskimos in igloos do (I think)
[02:59:20] <JymmmEMC> I would think the grounds would be froxen, so you couldn't dig up rocks to build the fire on
[03:07:57] <cradek> stustev: I haven't disappeared, just working on stuff all weekend
[03:08:12] <stustev> good to see you
[03:08:39] <stustev> honey do's?
[03:08:48] <cradek> end of weekend approaching...
[03:08:59] <stustev> time to rest
[03:09:00] <cradek> I never get done as much as I want.
[03:09:19] <stustev> readjust your goals
[03:09:35] <stustev> if you have very low goals it is easy to attain them :)
[03:09:39] <cradek> then my goals are to take a nap :-)
[03:09:51] <stustev> dagwood bumstead
[03:10:47] <stustev> did you see the cinci run?
[03:10:53] <cradek> yes! very nice.
[03:10:57] <stustev> good
[03:12:44] <cradek> is it a production machine now?
[03:13:06] <cradek> be careful, if so you won't be able to play with it anymore
[03:13:17] <stustev> not yet - I don't have the inspection report - I am interested to see what it looks like
[03:13:26] <cradek> ah
[03:13:57] <stustev> I know - I ordered some (dumb) amps from Jon. He said he could modify them pretty easily.
[03:14:21] <cradek> like he will put bigger transistors on some for you?
[03:14:34] <stustev> If it doesn't look good I will disable my geocomp and run another part
[03:14:59] <stustev> he said something about inductors and screw clamps instead of the plug
[03:15:23] <stustev> he said the base amp will do 56 amp continuous
[03:15:35] <cradek> wow
[03:16:26] <stustev> I will still play with this to try the amps (and other stuff)
[03:16:42] <cradek> do you expect better performance with an amp replacement
[03:16:43] <cradek> ?
[03:17:11] <stustev> yes - I can only superimpose the emc2 tuning on the SCR amps (with their tuning)
[03:17:45] <stustev> I won't push it but I think it will be smoother, crisper, quieter
[03:18:07] <cradek> does it have fairly high resolution encoders?
[03:18:39] <stustev> yes - 1000 count - 10000 per inch
[03:19:07] <stustev> I think - I will look
[03:19:39] <cradek> I think that's not very high for position loop only
[03:19:48] <stustev> 20000 per inch
[03:20:22] <stustev> 2000 per degree
[03:20:46] <stustev> the cinci.ini file is on my website
[03:20:56] <cradek> well if you replace one and don't like how it tunes up, you could use them on the next project
[03:21:07] <stustev> it may be a little old but will be very close
[03:21:23] <stustev> yes - that will probably be the Mori Jr
[03:24:33] <cradek> lots of stuff on your site...
[03:25:06] <stustev> all kinds of stuff - it is accessible to me from anywhere that way
[03:25:27] <stustev> I have very few secrets or patents :)
[03:25:36] <cradek> me too.
[03:25:46] <cradek> so you have it change gears by itself according to the S word?
[03:26:01] <stustev> I would make it a pretty site but I have more important things to do
[03:26:15] <stustev> yes - I noticed a problem I am fixing.
[03:26:37] <stustev> when I move the spindle override it will shift gears when I reach the change speed
[03:26:52] <cradek> oooh that's not good
[03:26:53] <stustev> I will change it to not change gears
[03:27:15] <stustev> not good at all - it stops feeding while changing but still not good
[03:27:50] <cradek> on my lathe I program the gear with M code
[03:28:09] <stustev> that keeps it in gear
[03:28:52] <cradek> I think you can't tell at the HAL level whether speed=100 is S100+100% or S1000+10%
[03:29:21] <stustev> I can in my gear4.comp
[03:29:22] <cradek> I guess you could inhibit shifting if the spindle is commanded on
[03:29:43] <cradek> how?
[03:30:37] <stustev> I will multiply the change speed by the over ride per cent in my decision
[03:30:59] <stustev> that way I will get the correct gear no matter what the over ride is
[03:31:04] <cradek> oh is spindle override % available from halui?
[03:31:23] <cradek> that's the piece I was missing (how would you know)
[03:31:39] <stustev> I don't know - I sure thought it was there
[03:31:53] <stustev> I just started on this yesterday
[03:31:56] <cradek> 13429 float OUT 1 halui.spindle-override.value
[03:32:10] <cradek> you are right
[03:32:24] <stustev> very very good - you had me scared
[03:32:36] <cradek> we would have just added it...
[03:32:44] <stustev> thanks
[03:33:37] <stustev> the inspector said his preliminary view of the part was that it is within .005 of matching the model - if that is the case I am stoked to the max
[03:34:00] <cradek> wow
[03:34:13] <cradek> sounds like that would be great for that machine
[03:34:16] <stustev> the CMM doesn't have a 'best fit' routine
[03:34:23] <stustev> killer for that beast
[03:34:35] <stustev> beyond perfect
[03:35:39] <stustev> we will see - he is kind of new at this - he is pretty sharp - I hope he is correct
[03:36:53] <stustev> when do you expect the ball screw balls to get there?
[03:37:03] <cradek> early this week I hope
[03:37:13] <cradek> sent ups ground wednesday or thursday
[03:37:17] <cradek> maybe even tomorrow
[03:37:23] <stustev> I am very interested in how this turns out
[03:37:34] <cradek> me too
[03:37:50] <cradek> I expect to have to order a third size of ball to get it 'perfect'
[03:37:54] <stustev> that is the only part of the machine I have tried and failed - miserably
[03:38:00] <stustev> probably
[03:38:21] <stustev> oh well - next time you will be able to get it the first time
[03:38:41] <cradek> yeah sure
[03:40:18] <cradek> I ordered the size I calculated as right, and also .001 smaller
[03:40:24] <cradek> I hope one of them fits in the nut
[03:40:32] <stustev> you will need the .001 over :)
[03:40:41] <cradek> if so, I can measure backlash again and get a very good estimate of the correct size
[03:40:49] <stustev> murphy's law
[03:41:21] <stustev> shoot for a little preload
[03:41:25] <cradek> it's ok if it's not perfect. I just hope one size goes in
[03:41:41] <cradek> yeah I don't have a feel for how much would be right
[03:41:56] <stustev> how much bigger did you go? unless you went very radical they will fit
[03:42:42] <cradek> the size that would take up all the play, considering the backlash I measured carefully in tenths and the apparent contact angle
[03:43:08] <stustev> did you order in tenths or thou
[03:43:11] <cradek> tenths
[03:43:29] <stustev> wow that's close
[03:43:30] <cradek> both sizes are .XXX9
[03:44:11] <stustev> it will be fun to find out
[03:44:19] <cradek> yeah I am excited about it.
[03:44:37] <stustev> if you would let me 'work'
[03:44:53] <stustev> on the B/P I would come up to help
[03:45:18] <cradek> cool, I'll keep that in mind
[03:45:31] <cradek> the real problem with that is it's still working
[03:45:39] <stustev> I can fix that
[03:45:46] <cradek> haha
[03:45:48] <stustev> not a problem at all
[03:45:50] <cradek> yeah I could too
[03:46:13] <cradek> it almost fixed itself - an important button on the keypad was not working - but I threatened it and beat on it and it's been fine since
[03:46:33] <stustev> you have it scared - the master cometh
[03:47:21] <stustev> you have the same problem I face when a machine is running - don't mess with it it may not run again for a while
[03:47:30] <cradek> right
[03:47:52] <cradek> it would be easier than the lathe though.
[03:48:08] <stustev> yes - very straight forward
[03:48:11] <cradek> it has encoders, it has enough cabinet room for everything
[03:48:33] <cradek> the amps even connect with screw terminals!
[03:48:36] <stustev> take a day or two max
[03:48:51] <cradek> realistically it would take a few weeks like the lathe
[03:48:55] <stustev> then you could run your shop from work
[03:49:20] <stustev> just a little optimistic :)
[03:49:55] <stustev> get a webcam, a robot and you would be set
[03:50:14] <cradek> and some production parts...
[03:50:36] <stustev> from anywhere - the beach on Aruba - production bushings?
[03:52:03] <stustev> I would bet we could do it in one day - if everything was there and ready
[03:52:10] <cradek> hey do you have a suggestion of cutting oil? I read about Mobil Omicron but it's $21/gal and I need 9 gal!
[03:52:59] <stustev> never heard of it - I will check it out - you want oil not coolant right
[03:53:19] <cradek> stustev: you are optimistic - maybe 2.
[03:53:23] <cradek> yes has to be oil
[03:53:37] <stustev> 2 max max
[03:53:50] <stustev> is the Omicron a high sulfur oil?
[03:54:18] <cradek> I might try putting a big rock in the sump to get the volume down
[03:54:49] <cradek> 'nonstaining cutting fluid' sulfur 0.5%
[03:54:56] <stustev> omicron has been discontinued
[03:55:14] <stustev> does someone have some stock they want to get rid of?
[03:55:16] <cradek> oh maybe that's why it's expensive
[03:55:21] <cradek> http://www.drillspot.com/products/272134/Mobil_MOBILMET_OMICRON_Nonstaining_Cutting_Fluid
[03:55:44] <stustev> http://www.mobil.com/USA-English/Lubes/PDS/GLXXENINDMOMobilmet_Upsilon_Omicron_Nu.asp
[03:57:24] <cradek> This makes it especially suitable for high surface speed machining of screw stocks, aluminum, and brass.
[03:58:03] <stustev> the replacement may be more expensive
[03:58:10] <cradek> In machines where the cutting oil leaks into the lubricant reservoir, the Mobilmet oils are ideal because they perform satisfactorily as lubricants.
[03:58:28] <cradek> I bet this is important because it runs everywhere
[03:58:36] <stustev> that is nice - no negative contamination
[03:58:58] <stustev> you will track ALL over the house
[03:59:26] <stustev> there will be an oil sheen to all things in your shop(house)
[03:59:43] <stustev> you MAY get a little backlash
[04:00:16] <stustev> not in the ballscrew but from the other inhabitants of the house
[04:00:25] <cradek> ha
[04:00:33] <cradek> I can handle them.
[04:00:39] <stustev> slide into bed will take on a whole nother meaning
[04:02:20] <cradek> http://www.use-enco.com/CGI/INSRIT?PMAKA=505-2052&PMPXNO=950175&PARTPG=INLMK32
[04:02:36] <cradek> $75 for 5 gal...
[04:02:58] <cradek> this is 1.2% sulphur though - I wonder what the "stink" threshold is
[04:03:24] <stustev> almost nothing - I am sure - ha ha :)
[04:03:39] <cradek> oops I mean 2.2%
[04:03:39] <stustev> especially under a cutting load
[04:04:39] <stustev> you need to get a shop built not connected to the house :)
[04:05:13] <stustev> the whole house will smell like the cutting oil or coolant you use - the whole house
[04:05:51] <cradek> smell is a consideration
[04:06:08] <cradek> the flood coolant on the mill has very little smell and it is not unpleasant
[04:06:27] <cradek> mobilmet 404 says "relatively low-odor"
[04:07:07] <stustev> :) :) - this is a BIG smile
[04:08:01] <cradek> yeah "relatively"
[04:08:03] <stustev> dog poop usually has a 'relatively' low odor compared to cat poop
[04:09:14] <stustev> just be prepared :) - got to go - must have my beauty sleep - thanks - have fun
[04:09:18] <cradek> goodnight
[04:09:22] <stustev> goodnight
[04:41:03] <tomp2> machine squareness
http://findarticles.com/p/articles/mi_m3101/is_/ai_17450800
[04:48:54] <jmkasunich> cradek: mcmaster has omicron at $79.53 for 5 gallons, and non-staining, non-sulfer stuff for $69.27 for 5 gals
[04:49:35] <jmkasunich> see page 2123 in the catalog
[10:01:18] <archivist_ub> good Monday morning viewing, Stuarts cinci!
[10:06:32] <alex_joni> heh
[10:07:40] <archivist_ub> and a DMG brochure to steal ideas from
[10:13:22] <alex_joni> for me it's a good morning to travel :)
[10:13:30] <alex_joni> * alex_joni is currently in stuttgart
[10:17:52] <archivist_ub> my weekend was Model Engineer Exhibition on Friday and an open day at a local "garden" railway about a mile of track anf a nice workshop
[10:19:51] <alex_joni> sounds good
[14:36:57] <stuste1> good morning world
[14:38:09] <skunkworks_> stuste1: what is on the agenda today?
[14:38:57] <stuste1> waiting for the inspection report on the test part
[14:39:33] <stuste1> it is on the cmm right now
[14:39:39] <skunkworks_> neat
[14:40:19] <skunkworks_> what kind of tollerance are you looking for?
[14:40:22] <skunkworks_> tolerance
[14:40:32] <skunkworks_> *hoping
[14:40:45] <stuste1> I will be happy with +/- .005
[14:41:12] <stuste1> then I can cut +/- .010 parts reliably
[14:42:21] <skunkworks_> coolbeans
[15:19:53] <skunkworks_> http://www.youtube.com/watch?v=feM0vp0_ciA
[15:34:15] <dushantch> nice
[15:35:08] <dushantch> do you know why did they use servo positioning for translation axis? plain pneum cyl would suffice?
[15:39:15] <skunkworks_> I don't know..
[15:39:31] <skunkworks_> http://www.cnczone.com/forums/showthread.php?t=56451
[15:40:18] <dushantch> it's a little flexible on vertical axis :)
[16:50:43] <jepler> interesting stuff here:
http://www.fsf.org/resources/hw
[16:51:44] <anonimasu> dushantch: yeah, I'm wondering about the same
[16:51:44] <jepler> (lists of hardware that work without proprietary drivers)
[16:53:36] <cradek> nice. I had looked for that before (on the fsf site) but found only fluff instead
[16:54:24] <jepler> maybe next time I buy a desktop machine I'll look for one that I can run coreboot on
[16:55:34] <dushantch> jepler: then you'll maybe buy used old machine? :)
http://www.coreboot.org/Supported_Chipsets_and_Devices
[16:57:13] <dushantch> btw. anyone had any experience with laser scanners like
http://www.david-laserscanner.com/ and are there any oss solutions?
[16:59:08] <anonimasu> yes
[16:59:50] <anonimasu> I looked at them for a while back
[16:59:54] <anonimasu> there are OSS solutions to it
[17:00:18] <anonimasu> I cant point you to one but I found stuff about it..
[17:02:01] <jepler> this seems to be one:
http://www.splinescan.co.uk/
[17:02:12] <jepler> "splinescan is licenced under the terms of the gpl"
[17:02:47] <jepler> (I don't know anything about this project except that google found it for me)
[17:03:12] <jepler> more stuff to be found a click or two away from
http://blog.makezine.com/archive/2006/10/how_to_build_yo_4.html
[17:06:35] <dushantch> thanks
[17:07:37] <dushantch> we're stil a little low in cad/cam/cae in oss, but it's getting better :)
[17:07:47] <archivist_ub> jepler just watched your 5 axis gantry mill simulation vid was that a python driven by axis or in axis
[17:17:20] <skunkworks_> archivist_ub:
http://jmkasunich.dyndns.org/cgi-bin/blosxom/software/simulated-machine-02-04-07.html
[17:18:16] <archivist_ub> Ive seen that one
[17:18:41] <archivist_ub> this
http://nl.youtube.com/watch?v=fWKYQUj5AOs&NR=1
[17:19:58] <archivist_ub> seems so right and the way to go
[17:21:39] <BigJohnT> * BigJohnT want's one
[17:24:04] <archivist_ub> although I still like the idea of rotary tables as well
[17:29:03] <dushantch> It would be nice if we could input the workpiece dimensions too and to show removed material but that would be more for some CAM package :)
[17:31:32] <fragalot> I've been wondering.. Do you guys think it's possible to capture and convert the partport signal to USB, and then via some "custom" hardware convert that back to a "bitbang" signal?
[17:31:43] <archivist_ub> well the software that came with a dos for Boxford VMC cnc miller does do that but does not have the machine
[17:32:01] <fragalot> like EMC2->app->USB->PIC18F4550->CNC controller board
[17:35:08] <fragalot> if that somehow worked, I could even add more "pins" to the port without needing 2 parallel ports,.. as atm i have.. none, and no way to add them without using USB, (or SATA... lol)
[17:36:25] <archivist_ub> some claim usb is not fast enough for realtime
[17:36:57] <archivist_ub> but having read most of the USB2 spec I think its doable
[17:37:31] <archivist_ub> but will be somewhat hard to implement
[17:38:41] <fragalot> I see...
[17:39:16] <fragalot> brb, i'll look into it later,.. I've seen some in here claim that it's possible, and that they use it, with a normal USB->parallel adapter, (mine doesn't work.. lol typical)
[17:39:19] <fragalot> bbl
[17:52:22] <jepler> fragalot: for signals without timing requirements (spindle forward/reverse/stop being one that comes to mind) you can write HAL userspace drivers that can talk to any linux-supported hardware. for signals with timing requrements (such as position control including step&direction signals, software pwm generation, etc) you have to use hal realtime hardware drivers like hal_parport.
[17:52:47] <jepler> for the former, USB works today. for the latter, it doesn't work today and IMO it would take an heroic programming effort to make it work (if indeed it's possible at all)
[17:56:29] <jepler> (when I say "USB works today", I mean that you can write a driver using things like libusb with a minimum of fuss, not that there are HAL userspace drivers for specific USB devices bundled with emc today)
[17:58:25] <jepler> imo you're better off buying devices like mesa's fpga cards (pci or parport) or jon elson's boards (parport) when you outgrow a single parport. compared to other parts of "real mills" (like amplifiers) they are not that expensive and they are simply excellent hardware
[18:01:56] <jepler> afternoon maddash
[18:02:10] <maddash> jepler: howdy, partner
[18:16:01] <Lerman> jepler: are you still here?
[18:16:58] <fragalot> I'm back.
[18:17:44] <fragalot> jepler: I don't even have PCI available on my pc........
[18:18:13] <fragalot> jepler: all it has is USB - VGA - audio in/out - 12VDC in
[18:18:20] <fragalot> and an 80GB hd
[18:19:26] <fragalot> jepler: I also have a lot of microcontrollers, and a few FPGA boards, so making the stepper logic isn't the issue, it's just GETTING THE SIGNAL THERE :p
[18:19:54] <cradek> getting an appropriate pc would be cheaper, easier, and will work better in the end
[18:20:45] <Lerman> cradek: Did you see my note about pausing for tool change?
[18:20:57] <fragalot> cradek: how is it cheaper, lol.
[18:21:12] <Lerman> (email subject: Axis question on Emc-users list)
[18:21:23] <fragalot> cradek: all i'd have to do is use an existing USB->whatever board i have, and some epic programming.
[18:22:56] <cradek> Lerman: ugh, yes
[18:23:02] <Lerman> fragalot: I'll trade you a suitable PC for a suitably programmed FPGA for my laser interferometer project.
[18:23:07] <cradek> I also "vote" that someone should do something about it
[18:23:13] <Lerman> ugh, yes. But would it work.
[18:23:13] <skunkworks_> fragalot: honestly - you should go with mach then... it already has usb hardware. (moves motion off to it - like smooth stepper). I really don't see emc doing anything like that in the near future.
[18:23:57] <Lerman> Everyone agrees that someone should do it. But no one is the some one.
[18:24:08] <cradek> Lerman: I think my new-run-from-line is the basis of fixing those problems
[18:24:12] <fragalot> skunkworks_: already have the L297+298 boards, :p
[18:24:45] <Lerman> I never did figure out how you are doing run from line without running thru all the code (if that is what you are doing).
[18:24:52] <cradek> yes
[18:25:05] <cradek> I do it by just doing it
[18:25:14] <fragalot> lol.
[18:25:19] <cradek> also I made mode switches not turn everything off
[18:25:53] <cradek> so you can set up the machine in manual or MDI mode and then start the program
[18:25:53] <Lerman> But how do you get the proper context set. I believe that all #vars must be properly restored to the values they would have if you had executed the code.
[18:26:09] <jepler> in cradek's scheme, variables aren't restored
[18:26:26] <cradek> I don't think it's possible to run-from-line all code.
[18:26:47] <cradek> if you use loops, and you want to enter a loop on a certain iteration, you'd set the var in mdi, then run from the beginning of the loop.
[18:26:58] <cradek> it does exactly what you tell it
[18:27:02] <Lerman> Then the code after the restart can't use vars that have been preset.
[18:27:03] <cradek> I think that's the only sane design
[18:27:14] <cradek> yes that's right, unless you set them in MDI before starting
[18:27:42] <cradek> the next part of the solution is to not nuke the interpreter state by default. then you could abort, do something, and continue
[18:27:46] <Lerman> Well, that's one sane design. Why wouldn't it work to silently go thru all of the code (without doing any motion).
[18:28:17] <Lerman> It should be pretty easy to not nuke the state.
[18:28:19] <cradek> Lerman: that's pretty much what it does now. it cannot fix the problem with starting in a loop or subroutine - IMO there is no benefit, but there is less flexibility
[18:28:20] <jepler> that's what it does now, but everyone hates it.
[18:28:50] <jepler> for some reason cradek thinks they'll hate his suggestion less
[18:29:03] <jepler> sorry, I shouldn't talk today, I seem to be in a bad mood
[18:29:08] <Lerman> Right now, it nukes the state.
[18:29:50] <fragalot> lol.
[18:30:06] <cradek> jepler: I value your input and I'm immune to your bad mood, so don't sweat it
[18:30:25] <fragalot> * fragalot pretends he got upset to grasp some attention.
[18:30:34] <Lerman> I've added a LAZY_CLOSE switch that doesn't close the file. I'm not sure if it also disables nuking the state. But it could easily do that.
[18:30:35] <cradek> if there is an alternate coherent design, I'd love to hear it
[18:30:42] <cradek> Lerman: interesting
[18:31:44] <Lerman> You said "abort". That's different than "pause". Pausing would continue from the current point. Aborting might run from a line that was previously (already) executed.
[18:31:53] <cradek> the only other alternative I see is to try to fix each problem with what we have now - spindle, tool load, tool length, coolant, ...
[18:32:02] <Lerman> The state might have been changed between lines.
[18:32:14] <cradek> in the end we would have to make guesses about what the user wants and I don't like that.
[18:32:29] <Lerman> What's wrong with rerunning the program from the beginning (at high speed with motion disabled).
[18:32:30] <Lerman> ?
[18:33:00] <cradek> Lerman: currently: it doesn't load the tool. it doesn't turn on mist or flood. it doesn't start the spindle. it doesn't invoke length offsets.
[18:33:05] <cradek> (there might be more problems)
[18:33:39] <cradek> if the program depends on analog or digital inputs or probing, it will run differently
[18:33:44] <Lerman> But couldn't it simulate doing all of those things as it skipped along until it got to the proper line.
[18:34:07] <cradek> and then it would guess what order to do a bunch of queued up stuff in?
[18:34:13] <Lerman> Inputs and probing are clearly problems that could be ignored because there is no way to really fix them.
[18:34:35] <cradek> heh, that's where I started, ignoring the things that I thought were impossible to get right, and figuring out what is actually possible
[18:34:37] <Lerman> No. It would do them in the order that they were queued.
[18:34:52] <cradek> so you would load each of 10 tools, and turn the coolant on and off a bunch of times?
[18:35:32] <cradek> and the spindle too?
[18:35:35] <Lerman> Simulate doing that. Do the last tool before you execute.
[18:35:44] <cradek> sorry, I'm not trying to be an ass, it comes naturally
[18:36:07] <Lerman> Sure, simulate turning it on and off. Before starting to execute again, set it to the last known state.
[18:36:37] <cradek> so it would go load the last tool that was loaded before the line you want to run?
[18:36:46] <Lerman> (If lerman wanted someone to agree with him, he would be talking to himself -- only).
[18:37:00] <Lerman> Sure. That seems to work.
[18:37:23] <cradek> then set TLO if there was one after that tool load, then turn on coolant if there was one, then turn the spindle on if there was one (since when?), then start running from that line?
[18:37:49] <cradek> but between the last tool change and the run-from line, there are safe moves to approach the work from the tool change position -- but you just skipped them
[18:38:00] <Lerman> Yes. Spindle on if the last spindle command was on.
[18:38:02] <fragalot> sod it i'll buy a small intel Atom based PC....
[18:38:28] <fragalot> for some reason, those are cheaper than a used PC is here.... lol
[18:38:35] <Lerman> The user must place the tool in a safe place before running from line. That's not unreasonable.
[18:38:56] <jepler> fragalot: I just saw someone on the user list saying that the rtai kernel doesn't like the NIC on his atom motherboard
[18:38:58] <cradek> well it was - he did that instinctively - but you gave him a tool change (and motion to the tool change position) he didn't want
[18:39:08] <cradek> you know he didn't want it, because he selected r-f-l AFTER it
[18:39:33] <fragalot> jepler: it doesn't like the a) NIC b) video card c) USB->parallel adapter of any of my current hardware, so that's the least of my worries
[18:39:33] <cradek> IMO, you are guessing what the user wants, and that messes him up
[18:39:40] <BigJohnT> That's how I handle tool changes on my BP move to safe place, change tool, continue program
[18:39:52] <fragalot> jepler: if the machine works, i'm happy.
[18:40:13] <fragalot> jepler: if it's slow, so be it, lol. I just want something small that WORKS :p
[18:40:23] <fragalot> without paying a lot.
[18:40:27] <jepler> fragalot: you really should move to our side of the world. it seems we're drowning in surplus PentiumIII-class machines with working everything
[18:40:35] <Lerman> cradek: Sounds like that's a problem.
[18:40:59] <fragalot> jepler: one of those machines, 2nd hand would cost rougly 80 euro here.
[18:41:37] <Lerman> Is there a safe way to always move to the tool change position? Save the current position and move back along the inverse path.
[18:41:46] <cradek> nope
[18:42:01] <fragalot> Lerman: by manually programming that in? :p
[18:42:02] <cradek> there is no safe way to get to the tool change position
[18:42:15] <Lerman> Then we could crash on the way to loading the tool.
[18:42:18] <cradek> yes
[18:42:43] <fragalot> cradek: you mean there is no 100% guaranteed always safe way,.. I've never had issues by just moving up, :p
[18:42:49] <Lerman> What do other systems do?
[18:43:33] <cradek> Lerman: I understand that fanuc does exactly what the user tells it to do - like my scheme. you set modal codes in MDI, you load the right tool, you move to a safe place, you turn on flood, then you run and it starts at the specified line
[18:43:33] <BigJohnT> I do a Z0 T0 (anilam) to z up then g0 x-4 y0 to my favorite tool change spot then a Tn to stop and wait for me to change the tool
[18:43:36] <Lerman> If my keyway cutter is cutting a horizontal slot in something the tool gets crashed when moving straight up.
[18:43:47] <LawrenceG> this may sound nuts, but how about a gcode parser that breaks a program up into sections (reformats gcode) that are tool related? most of the request seem to stem from tool change of tool breakage restarts
[18:43:55] <BigJohnT> then you program a move in a safe manner
[18:43:56] <cradek> and clearly on my lathe moving Z+ first is not always safe
[18:44:23] <cradek> neither is moving X+ first
[18:44:29] <cradek> there IS no safe move
[18:44:33] <BigJohnT> it's up to the programmer to select the correct path :)
[18:44:39] <cradek> exactly!
[18:44:40] <Lerman> Up on a mill == out on a lathe -- unless you have tools front and back :-)
[18:44:48] <cradek> Lerman: or a boring bar?
[18:44:54] <cradek> there IS no safe move
[18:44:56] <Lerman> The guy who is running the machine is NOT a programmer.
[18:45:19] <stuste1> but he thinks he is
[18:45:20] <BigJohnT> the programmer should understand the path to a safe place
[18:45:22] <cradek> my understanding is the guy who is running the machine DOES know gcode or else he's ill-equipped to deal with these things
[18:45:38] <fragalot> OR he only presses "start"
[18:45:51] <Lerman> He wants to fix the broken insert, jog to someplace, and continue where he left off.
[18:46:01] <dushantch> he only presses start and holds hand on esotp or coffe jar
[18:46:09] <cradek> well he's not where he left off - so he can't.
[18:46:15] <Lerman> My suggestion of enabling jogging while paused would let him do that.
[18:46:17] <BigJohnT> exactly
[18:46:26] <cradek> how do you re-enter the work after jogging?
[18:46:26] <dushantch> well then they usually yell and call someone :)
[18:46:33] <cradek> safely re-enter
[18:46:41] <fragalot> cradek: he wants it to remember what you did before, and then do that again, in reverse
[18:46:53] <dushantch> programmer makes that not emc
[18:46:54] <BigJohnT> which might need some on the spot coding
[18:46:55] <Lerman> You jog back to where you were. Manually if necessary.
[18:47:08] <dushantch> nah it's dangerous
[18:47:43] <dushantch> just start the program from the begining
[18:47:47] <cradek> Lerman: IMO you pick a safe place to start in the program. it's probably an entry move of some kind.
[18:48:07] <tomp> heidenhain remembers jogs in a history during these times, and has a button "return to path" that runs thru the remembered list
[18:48:31] <Lerman> That would be straightforward to do.
[18:48:33] <cradek> that's an interesting idea
[18:48:35] <dushantch> tomp: that could be nice
[18:48:35] <cradek> Lerman: haha
[18:48:43] <fragalot> wow it's been years since i've used one of those, lol
[18:48:44] <BigJohnT> so the jog is assumed to be a safe reentry path?
[18:48:56] <Lerman> It could all be done in HAL.
[18:48:59] <fragalot> only had heidenhains in school,.. I remember hating their emulators on the PC... lol
[18:49:06] <dushantch> if you got out you can get back in :)
[18:49:18] <dushantch> but it can make problems
[18:49:22] <tomp> there are assumptions, that fixtures didnt fall apart etc
[18:49:24] <cradek> Lerman: you lost me now
[18:49:48] <dushantch> like if following circular shape and come back on one side and gcode tels you to go straight to other side
[18:49:58] <fragalot> dushantch: assuming that the spindle didn't turn (in case of a powered drill :p)
[18:50:15] <dushantch> :)
[18:50:39] <Lerman> Have some blocks in hal that add an offset to the current position. The offset comes from pyVCP. That let's you pause the machine AND still jog.
[18:50:51] <Lerman> You are still in auto mode.
[18:51:11] <jepler> that breaks soft limits
[18:51:22] <cradek> I'm not interested in heroicly hacking around stuff, I'm interested in fixing the software
[18:51:33] <jepler> if you jog Z up 1" with that method, then you can go an inch outside the soft limits at the top, and can't get within an inch at the bottom
[18:51:57] <dushantch> that way of coming back the way you left is a good idea
[18:52:00] <Lerman> HAL could know about soft limits.
[18:52:19] <tomp> and there's the Fanuc 'skip' command. G31 in their dialect moves to the destination IF a small potential diff from tool to wkpc is maintained ( lack of contact ). it's the Helen Keller mode. if contact is made, the tool moves to the beginning of that motion and cries.
[18:52:21] <cradek> there are 100 problems with that. would you rewrite jogwheel handling? what about nontrivkins?
[18:53:19] <cradek> reimplementing jogging separate from the current jogging is surely a bad solution to these problems isn't it?
[18:53:20] <Lerman> I think we need to go back to fundamentals and ask what is the best way for it to work (from a user perspective). Then we can properly discuss how to do it.
[18:53:28] <dushantch> tomp: how do they know if contact is made?
[18:53:42] <tomp> dushantch: voltage drop
[18:53:52] <tomp> like 12 v battery , minmal current
[18:53:53] <Lerman> If it solves the problem, new jogging might not be bad.
[18:53:58] <stuste1> Lerman: that is a complete dissertation in itself
[18:53:59] <cradek> Lerman: the problem is you get a lot of "I want it to do what I want" and no coherent design
[18:54:06] <dushantch> tomp: but everyone doesn't have that :)
[18:54:13] <fragalot> cradek: gotta start somewhere :p
[18:54:14] <cradek> "just start again where I stopped it"
[18:54:50] <dushantch> cradek: but how to get there is the problem i believe?
[18:55:04] <fragalot> dushantch: how to get BACK there :p
[18:55:10] <dushantch> true
[18:55:26] <fragalot> you could always just.. not break your tools
[18:55:34] <Lerman> Can non-trivkin systems jog joints? I would think they should be able to, but my instincts have been (very) wrong before. :-)
[18:55:36] <cradek> IMO this isn't a question about jogging. it's bigger than that.
[18:55:43] <dushantch> yep, change them on time not when they fail :)
[18:55:48] <cradek> Lerman: yes you can jog either axes or joints
[18:56:14] <fragalot> dushantch: =) usually if they are that badly worn, the measurements of that piece will be wrong anyways, and it needs to be re-run from the top anyways.
[18:56:18] <stuste1> cradek: if a remembered one position move and then return after restart is easy then that would be the answer for 99% of all cases
[18:56:32] <fragalot> or atleast passing the contour once..
[18:56:47] <dushantch> how about this: go back the same way you got there, inverse last move command to come to its start, and then start from where you paused?
[18:56:51] <Lerman> Do we have a one sentence defn of the problem? (bigger than jogging).
[18:56:52] <stuste1> MDI all the other starting values and then move to auto and hit cycle start
[18:57:01] <dushantch> fragalot: I agree
[18:57:02] <cradek> dushantch: what if I changed the tool offset?
[18:57:21] <stuste1> the tool offset could be handled with MDI
[18:57:32] <cradek> stuste1: but I'm asking, what is the return path then
[18:57:47] <cradek> it's maybe not the inverse of that jog anymore
[18:57:53] <stuste1> from wherever you are
[18:58:43] <tomp> i think someone could look into 'break point return' 'stop point return' 'cycle interrupt' on several systems to get some ideas (these are all wire edm terms, but common in those industries where path interruption, re-approach is needed ).
[18:58:43] <cradek> or what if I changed g54 a bit while it was stopped?
[18:58:43] <cradek> Lerman: that's a good question.
[18:59:01] <dushantch> cradek: why can't it be compensated?
[18:59:16] <stuste1> MDI takes care of all that
[18:59:25] <dushantch> well we wouldn't use completly different tool
[18:59:50] <stuste1> why not
[19:00:23] <dushantch> well there's always a way to shoot yourself in the foot :)
[19:00:25] <cradek> I believe that the control should not ever guess what moves are safe
[19:00:46] <stuste1> cradek: I agree > 100%
[19:00:55] <dushantch> cradek: I agree, maybe some security mechanism?
[19:01:24] <dushantch> like ask: do you want to return the way you came, and the move with 10% feed?
[19:01:32] <stuste1> security - as in operator education
[19:01:43] <dushantch> nah, that's utopia
[19:01:56] <stuste1> I am optimistic :)
[19:02:09] <cradek> security, as in make the move yourself, and then choose a place to start in the program that will approach safely
[19:02:21] <stuste1> ok
[19:02:25] <stuste1> I like it
[19:02:32] <Lerman> stuste: You're the guy who stopped using probes because the operators kept crashing them :-)
[19:02:39] <stuste1> yes
[19:02:51] <stuste1> they don't work if they are broken
[19:02:59] <Lerman> (You probably need to get a bigger baseball bat for operator education :-)
[19:03:00] <dushantch> we learned that if you want a worker not to kill himself with machine you should make a 3meter iron fence around it, and that it'll stop them like in 50% :)
[19:03:04] <stuste1> the machines sit if the probe is broken
[19:03:38] <stuste1> if the machines have no probes the probe being broken is not in issue
[19:04:13] <dushantch> cradek: maybe offer the last line as the place to start?
[19:04:14] <stuste1> if I could remove the 'air breathers' from the equation - I would
[19:04:27] <fragalot> guys guys
[19:04:33] <cradek> dushantch: at least, I think you should be able to easily see what the last executed line was
[19:04:35] <dushantch> cradek: i meant the line where pause occured
[19:04:41] <fragalot> if the machine prevents you from breaking anything.. that won't stimulate the economy....
[19:04:48] <dushantch> true
[19:04:55] <stuste1> dushantch: why would you start at the last line of the program - that should be m30? :)
[19:04:59] <anonimasu> hehe
[19:05:20] <dushantch> stuste1: :) my english is bad :)
[19:05:39] <fragalot> stuste1: to increase the part count. :p
[19:05:42] <stuste1> no your english if fine
[19:05:53] <cradek> I bet you often want the line before the one that was running when you aborted
[19:06:01] <stuste1> fragalot: hadn't thought of that - I will not suggest it to the shop
[19:06:02] <cradek> because it will be a move to the beginning of the aborted move
[19:06:04] <dushantch> ok, translation of my thoughts to english is bad :)
[19:06:25] <cradek> it depends where you place the tool when you want to restart
[19:06:30] <stuste1> no you said it perfectly - I chose to read it incorrectly - on purpose
[19:06:41] <fragalot> stuste1: lol.
[19:06:42] <cradek> a good restart place might be a move in the rapid plane
[19:06:53] <anonimasu> * anonimasu nods
[19:06:54] <cradek> then as long as you are above the work when you restart, entry will be safe
[19:07:18] <fragalot> stuste1: somebody that worked for somebody I know did that a few times.. Lets just say that his bank "count" decreased quite a bit.
[19:07:20] <dushantch> cradek: what about drilling or 5 axis ?
[19:07:48] <cradek> dushantch: can you be more specific?
[19:07:51] <anonimasu> if you are at the rapid/clearance plane it should prepoition the work before
[19:07:57] <fragalot> dushantch: drilling or 5 axis should be the same, i'd say
[19:08:17] <cradek> dushantch: no matter what it is, you have to know enough about the gcode to pick a safe place to start
[19:08:17] <anonimasu> ie.. move to a safe plane rotate the work to the approach position then start the op..
[19:08:34] <dushantch> hrm I meant you came under the part, the part is between the rapid plane and tool
[19:08:53] <dushantch> you know funky g code
[19:08:54] <cradek> imagine you are doing g91 g81 l10. you better position right before you start at that line
[19:09:18] <fragalot> I can't help but say that i'm with cradek on this, but the suggestion would make things a bit easier,.. but it's not like your life depends on it. what is more urgent is getting me some supported hardware. LOL.
[19:10:35] <dushantch> dunno, I agree with cradek that the best thing is to make the user jog back to safe position to start again and then offer him a choice from which line to start, and maybe set the feed to 20%
[19:10:38] <cradek> I think we lost Lerman
[19:10:49] <dushantch> :)
[19:10:50] <cradek> dushantch: the operator could set FO to 20% before he hit run
[19:10:52] <Lerman> It might be useful if the programmer put "restart points" in the program. Lines with safe restart would have Nwords.
[19:11:00] <cradek> Lerman: yes!
[19:11:09] <dushantch> cradek: well they usually don't :)
[19:11:14] <cradek> Lerman: at a tool change is a very common place I want to restart, and I put all modal stuff there
[19:11:27] <Lerman> The GUI could enforce that.
[19:11:42] <cradek> Lerman: ?
[19:11:54] <Lerman> And if we wanted, the interp could save all the modal stuff at N words.
[19:12:09] <dushantch> what GUI?
[19:12:15] <cradek> dushantch: well they can if they want it.
[19:12:25] <Lerman> The GUI would only let you do a start at line if the line had an Nword.
[19:12:51] <cradek> I don't like that idea
[19:12:55] <Lerman> (I know some of the Axis programmers. Maybe they would be willing to help.)
[19:13:04] <dushantch> cradek: ok, it's not that important, what about the rest of idea?
[19:13:06] <cradek> (it would be neat if the gui would make it easy to start at a particular N)
[19:13:19] <dushantch> true
[19:13:21] <cradek> dushantch: sorry, you lost me
[19:13:30] <Lerman> Simply a matter of programming.
[19:13:37] <BigJohnT> if you put N in your g code...
[19:13:40] <dushantch> "dunno, I agree with cradek that the best thing is to make the user jog back to safe position to start again and then offer him a choice from which line to start"
[19:13:42] <cradek> Lerman: the BOSS lets you search for an N word and start there
[19:13:44] <stuste1> I would like to be able to start at ANY line - the one I want to start at
[19:13:53] <jepler> route
[19:13:58] <cradek> yes I agree with stuste1.
[19:13:59] <dushantch> I agree
[19:14:00] <jepler> argh there I go using eagle again
[19:14:07] <BigJohnT> my anilam lets you search for a line or a word
[19:14:12] <stuste1> fly fly away little eagle
[19:14:25] <cradek> dushantch: what about the rest of the idea (that I've been arguing?) needless to say, I like it
[19:14:26] <BigJohnT> that comes in handy
[19:14:27] <stuste1> :)
[19:14:36] <Lerman> Fine. But if the programmer told you which lines were safe, that would help.
[19:14:36] <fragalot> jepler: :( :p
[19:14:40] <dushantch> cradek: :)
[19:15:01] <cradek> almost every line is safe in some situation
[19:15:09] <stuste1> yes!
[19:15:13] <fragalot> jepler: i just wish that eagle improved their PCB designer a bit,.. like if you move a line arround, it pushes the others away, keeping the clearance in mind
[19:15:28] <dushantch> ok, maybe offer them if they exist but you can choose some other one of you want (line of code I mean)
[19:15:38] <cradek> no line is safe in every situation (I think)
[19:15:44] <stuste1> yes!
[19:15:45] <Lerman> Would it help if the interp saved the state information at each line as it executed?
[19:16:11] <cradek> Lerman: I don't know
[19:16:27] <stuste1> I would say yes! but I don't know whyt
[19:16:43] <cradek> a pedant might argue that the first line is safe in every situation, but he would still be wrong
[19:16:48] <dushantch> I dunno, but that state is not safe anyomre
[19:17:00] <dushantch> cradek: true
[19:17:02] <Lerman> That would let you restore the modes as they were at the last execution of the line.
[19:17:15] <dushantch> but that could be dangerous
[19:17:15] <fragalot> nomatter how you look at this, if the machinist wants to mess it up, he WILL mess it up, nomatter how safe you make it
[19:17:32] <dushantch> fragalot: gun, foot...
[19:17:56] <fragalot> dushantch: manually jogging the wrong way.. :p
[19:17:59] <anonimasu> hehe
[19:18:07] <anonimasu> been there done that.. :p
[19:18:17] <dushantch> everybody has :)
[19:18:22] <fragalot> not me! (yet)
[19:19:20] <BigJohnT> If I break a tool on my anilam I note the line number after I hit the oh-shit-switch then after fixing the tool and entering the auto mode I search for that line then back up as needed to have a safe restart
[19:19:37] <dushantch> btw. what about a dialog box in axis on resume from pause that allows you to choose from which line you want to continue on unpausing? that is robust enough
[19:19:41] <fragalot> last time i hit the "oh shit" switch, i broke the toolchanger.
[19:19:42] <cradek> BigJohnT: do you manually turn on the spindle, coolant, etc before restarting?
[19:20:04] <stuste1> cradek: run from the beginning without motion to the s.t.l. line. use a 1 level memory for the modes - the last mode read would be the start mode
[19:20:13] <BigJohnT> yes because they are manual :)
[19:20:43] <Lerman> BBL
[19:20:49] <stuste1> cu
[19:20:50] <cradek> stuste1: I think that is what Lerman has proposed (and almost what it does now)
[19:20:51] <BigJohnT> if they were automatic then I would add the needed lines at the restart point.
[19:21:05] <stuste1> except for spindle start?
[19:21:14] <cradek> (except for a lot of things)
[19:21:25] <dushantch> true
[19:21:26] <stuste1> ok
[19:21:28] <cradek> please read back to where we argued about that being a good idea :-)
[19:21:38] <anonimasu> hm..
[19:21:54] <dushantch> and about offering a dialog to start all those things that got paused?
[19:22:03] <BigJohnT> the more complex your g code the more complex the restart will be... did that make any sense?
[19:22:12] <cradek> BigJohnT: sure
[19:22:25] <fragalot> * fragalot smells a circular discussion :p
[19:22:46] <dushantch> fragalot: eggs came first
[19:22:47] <cradek> fragalot: so true.
[19:23:03] <fragalot> dushantch: lol. didn't see that one comming
[19:23:20] <dushantch> * dushantch bows
[19:23:42] <stuste1> tools, coolant, spindle, tlo :)
[19:23:53] <stuste1> a bunch of excepts
[19:24:19] <dushantch> could they be a bunch of dialogs, like yes, no, modify?
[19:24:27] <stuste1> I think the g54 etc and tlo should read every line - just to start another discussion :)
[19:24:34] <cradek> argh
[19:24:35] <fragalot> dushantch: I tend to call dialogs "hassles"
[19:24:42] <stuste1> just trying to help
[19:24:51] <dushantch> fragalot: this is just a special case
[19:25:02] <cradek> dushantch: IMO, the user already knows how to control all those things. you are proposing that he learn a second way that's peculiar to r-f-l
[19:25:23] <dushantch> fragalot: which requires a decision from the user, dunno if it could be done without user interaction
[19:26:13] <stuste1> the restart s/b simple - the line you choose - the dialog s/b - put hand on big red button before pushing cycle start
[19:26:14] <BigJohnT> cradek: how hard would it be to put a search button in AXIS to goto a line number or search for a word?
[19:26:17] <dushantch> well I said to do plain r-f-l but you wanted more :)
[19:27:12] <cradek> BigJohnT: doubt it would be very hard to do that
[19:27:20] <fragalot> btw, does EMC have something like the "control panel" you find on commercial CNC machines? (eg. button to start/stop coolant,.. w/o M-functions)
[19:27:34] <cradek> fragalot: of course
[19:27:37] <fragalot> Couldn't find it when i was mucking arround in the livecd
[19:27:44] <BigJohnT> say you had 1k lines and you know you want to find T3 because you know that is a good restart point then do a start from line once you find it...
[19:27:57] <fragalot> and i couldn't get online either >.>
[19:28:11] <dushantch> cradek: and to offer the line to start again after restart with a way to go up/down to some other line?
[19:29:03] <BigJohnT> you can scroll now
[19:29:42] <cradek> brb
[19:29:47] <fragalot> btw, is it me, or does the livecd take half an hour to boot on everybodies system? (apprears to be an issue with all debian based systems on my boxes..)
[19:29:55] <dushantch> BigJohnT: couldn't remember the word :)
[19:30:03] <stuste1> you need more memory?
[19:30:14] <BigJohnT> I know the feeling :)
[19:30:21] <fragalot> stuste1: 2G doesn't suffice?
[19:30:36] <fragalot> stuste1: not to mention the 8G of swap it should detect..
[19:31:38] <dushantch> dunno, even my diskless machines boot under minute
[19:32:21] <fragalot> weird, it takes that long on 2 systems, (all up to date), and doesn't even boot on 1 other
[19:32:42] <fragalot> haven't tried my server ye...... hold on.... *checks if a sun Fire V60x has a parallel port*
[19:34:25] <fragalot> :'( nope
[19:35:19] <dushantch> and this is an amd k6-2 300mhz with 64MB ram
[19:36:05] <fragalot> no fair, lol, all these systems were "top of the line" under 2 years ago.
[19:36:22] <fragalot> which explains the utter lack of supported hardware on the EMC2 livecd...
[19:51:14] <stuste1> fragalot: that was a question - not a comment :)
[19:53:04] <fragalot> stuste1: ^_^ I replied,.. :p
[19:54:02] <K`zan> Just a silly question (after I hosed the EMC install): Why isn't the updating and upgrading blocked on the EMC install since, at least, the upgrade destroys EMC?
[20:04:24] <skunkworks_> K`zan: are you talking about the kernal update?
[20:04:41] <K`zan> That too, or at least that as a major destroyer...
[20:04:49] <K`zan> the major
[20:05:40] <K`zan> Was hoping the upgrade would fix some of the problems, with ubombu not EMC, but that sure was a rude surprise...
[20:05:51] <skunkworks_> what isn't working?
[20:06:58] <K`zan> EMC, which is the only real purpose of the box. After the upgrade EMC will not install due to, apparently, wanting older stuff and of course the kernel is no longer the RTC.
[20:07:54] <K`zan> It really would be simpler to go through the nightmare of running 100' of ethernet to the damn thing rather than trying to get the wireless to work.
[20:07:59] <K`zan> Sigh...
[20:08:14] <K`zan> Never a dull moment(TM) :-).
[20:08:29] <skunkworks_> hmm - maybe you need to explain exactly what happened..
[20:08:37] <K`zan> Upgrade really should be either blocked or with warnings of the result if you do.
[20:08:51] <K`zan> I selected the offered upgrade from the update manager...
[20:09:06] <K`zan> Just that and nothing more :).
[20:09:16] <skunkworks_> oh - you updated to the latest OS from dapper?
[20:09:26] <K`zan> Yes, 8.04.01 IIRC
[20:09:36] <K`zan> Or something like that...
[20:09:41] <jepler> When upgrading from 6.06 to 8.04 or 8.04.1 I am pretty sure that one step of the upgrade process shows you a list of packages to remove, and that emc2 would have been listed there.
[20:10:04] <jepler> We do not replace the upgrade manager package, and without doing that I am not aware of a way to configure it not to show the upgrade button
[20:10:04] <K`zan> Yep, IIRC it did, assumed (heh) that it could be reinstalled...
[20:10:24] <K`zan> Might be something for the FAQ then.
[20:10:49] <K`zan> In big red letters at the top :).
[20:11:03] <jepler> I don't know why it wouldn't be reinstallable at that step, though it's possible that it leaves it in a state that the emc2-install.sh script will not correct.
[20:11:29] <K`zan> Not sure why now, but it was looking for older versions of things IIRC.
[20:11:50] <K`zan> Got to take it all apart in there and drag it back in here where I have a net connection and rebuild it.
[20:11:52] <jepler> there are two main reasons we don't replace the update manager: first, we don't want to spend time doing what we don't absolutely have to do. second, we don't want to do it in a way that would prevent an ubuntu security update to the update manager itself from being installed
[20:12:20] <K`zan> jepler: I can appreciate the laziness but when it destroys the install it might be worth mentioning...
[20:12:55] <K`zan> I may be the only person in the world to run into it, but still thought it might be worth mentioning.
[20:13:07] <K`zan> Only thing i know that routinely destroyes work is m$ :).
[20:13:30] <jepler> the wiki can be edited by anyone after following the instructions on the page 'BasicSteps' (link at the bottom of the front wiki page)
[20:13:36] <jepler> contribute to emc and save someone the pain you experienced
[20:13:58] <K`zan> Sigh, yes, another loging and password to add to the 10,000 I already have, but yes.
[20:20:04] <skunkworks_> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Breezy_Upgrading
[20:20:13] <skunkworks_> just needs to be updated..
[20:20:46] <skunkworks_> However, when you press the "Upgrade" button in the update-manager, it fails to change the package repository for emc2, and as a result, an RT-patched version of the new kernel is never installed.
[20:21:05] <K`zan> That being the biggie, yes.
[20:21:33] <K`zan> Not sure now, but IIRC it also wanted an old version of ?Python? as a dependancy.
[21:13:53] <K`zan> This look OK:
[21:13:58] <K`zan> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EmcKnowledgeBase
[21:14:08] <K`zan> Hopefully enough info...
[21:16:05] <fenn> K`zan: i remember the "dont press the upgrade button" being on the front page of the wiki for a long time
[21:16:37] <K`zan> May be relevant since the EMC distro doesn't warrant locking it out as more work than necesary.
[21:17:02] <K`zan> Dunno, if it becomes irrelevant then it can be removed.
[21:17:53] <fenn> i guess the warning was removed when we deprecated breezy
[21:17:58] <K`zan> But it will hopefully keep anyone else circumspect in creating the mess I have here :-/.
[21:18:33] <fenn> unfortunately usemod doesn't keep a full history of wiki revisions
[21:21:08] <fenn> * fenn nominates skunkworks to write a "Dapper_Upgrading" page
[21:23:34] <skunkworks_> http://web.archive.org/web/20070112205918rn_1/wiki.linuxcnc.org/cgi-bin/emcinfo.pl
[21:24:05] <skunkworks_> http://web.archive.org/web/*/wiki.linuxcnc.org
[21:30:42] <skunkworks_> cradek:
http://web.archive.org/web/20010331093625/http://www.timeguy.com/
[21:30:54] <skunkworks_> cradek:
http://web.archive.org/web/*/timeguy.com
[21:31:56] <skunkworks_> wow - you had that same page until 2005 ;)
[21:33:06] <skunkworks_> * skunkworks_ shouldn't talk..
[21:34:15] <skunkworks_> http://web.archive.org/web/20060613021104/axis.unpythonic.net/
[21:34:31] <skunkworks_> * skunkworks_ got sucked into that site again..
[21:34:32] <skunkworks_> bbl
[22:39:34] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/tqfpboard.jpg http://emergent.unpy.net/index.cgi-files/sandbox/tqfpboard-eagle.png
[22:42:04] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/tqfpboard-composite.jpg
[22:43:27] <\malex\> jepler: is there any info on the machine you used to do that?
[22:44:28] <jepler> \malex\: random posts on my blog such as
http://axis.unpy.net/01221947885 http://axis.unpy.net/01219715210
[22:44:39] <\malex\> ah thanks
[22:46:48] <jepler> unfortunately the current "zenbot" machines built by the same guy have a much lower resolution than the model I have; I'm concerned that it might be too low for these tiny features (only 1350 steps per inch in 1/8-stepping mode)
[22:47:58] <jepler> and as you can see on my blog I've had to make a bunch of changes anyway
[22:48:05] <jepler> but now I'm really excited about this machine of mine
[22:49:49] <fenn> now try the QFN package
[22:50:09] <jepler> fenn: not today
[22:53:48] <fenn> these things look so much smaller in reality
[22:54:34] <jepler> that's a 600DPI scan, so 6x magnification if you're looking at it on a typical monitor at around 100dpi
[22:54:49] <jepler> bbl
[22:54:59] <jepler> someone point skunkworks at the scrollback when he gets back
[22:55:01] <fenn> yeah, what i meant was it's hard to get a sense for how big it really is just looking at pictures
[22:55:32] <jepler> agreed
[22:56:01] <jepler> I work obsessively to make the board smaller in eagle; every time I'm done the board is about 1/2 as big as I expected
[22:56:43] <jepler> that's sure a weird defect in the cutout in the lower left hand corner
[22:56:50] <JymmmEMC> jepler: if you keep playing with it, you'll go blind =)
[22:57:01] <jepler> that's where it started, with the left hand side going clockwise, doing that arc last..
[22:57:47] <fenn> lost a step maybe
[22:58:07] <fenn> or the board shifted
[22:58:17] <JymmmEMC> Newsflash.... "Blind man invents worlds smallest PCB"
[22:59:19] <dareposte> are those standard .100" headers at the bottom?
[23:02:01] <Dmess> i wish i knew enuf to make 1 of them that would work... i can cut anything even micro
[23:03:40] <fenn> dmess get a breadboard, an arduino, and some LED's
[23:04:02] <fenn> make sure you get the socketed chip of course
[23:04:57] <fenn> then it's just fighting with crappy software
[23:06:08] <dareposte> or an atmega168, those are my personal preference
[23:06:40] <dareposte> small, dip, gcc makes code for it
[23:08:10] <fenn> me too, but arduino has lots of projects and such
[23:49:12] <Dmess> http://www.cnc4pc.com/Store/osc/product_info.php?cPath=25&products_id=58
[23:49:12] <Dmess> ... could i accomplish the same as that with my extra x-axis drive already ON my card???
[23:49:40] <Dmess> sorry y-axis
[23:52:17] <cradek> jepler: that looks very successful - neat.
[23:52:55] <cradek> the upper left trace looks very small
[23:53:21] <cradek> I wonder if you did lose X position
[23:59:06] <dareposte> Dmess: you could do that, but it would take more than just an arduino
