Back
[00:04:13] <Rugludallur> Anyone want a plasma welder sans torch and psu ?
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=1&item=260136777656&ssPageName=STRK:MEWA:IT&ih=016
[00:04:50] <Rugludallur> I'd buy it but shipping is to much
[00:11:26] <a-l-p-h-a2> a-l-p-h-a2 is now known as a-l-p-h-a
[00:35:58] <tomp> JymmmmEMC: nice to see there's new stuff from hektor. maybe 3 emc fests ago, i wrote an svg/ecmascript hektor simulator ( it followed the mouse, displaying the angle/radius... it's really just polar coordinates, and the 2nd motor/cable is complimentary )
[00:37:56] <robin_sz> has anyone seen my camel?
[00:43:56] <robin_sz> Rugludallur, its got a torch with it .. see pic 2 of 5
[00:45:23] <Rugludallur> robin_sz: right, hmm just plug into CC psu and a water cooler
[00:45:40] <robin_sz> yeah
[00:45:43] <robin_sz> tig set?
[00:45:57] <Rugludallur> robin_sz: yeah, should work well
[00:46:29] <Rugludallur> robin_sz: or just a stick DC welder and a simple pump/radiator setup
[00:46:48] <robin_sz> define "DC welder"
[00:47:03] <toastydeath> non-ac
[00:47:03] <Rugludallur> robin_sz: anything with Constant Current psu
[00:47:13] <robin_sz> TIG set, not MIG
[00:47:14] <toastydeath> you can weld with either AC current or DC current
[00:47:19] <toastydeath> uh, any welder
[00:47:19] <Rugludallur> robin_sz: opposed to MIG which is constant voltage
[00:47:28] <robin_sz> Rugludallur, exactly
[00:47:30] <Rugludallur> and AC stick welders :)
[00:47:40] <toastydeath> guys, many mig rigs have constant current
[00:47:49] <toastydeath> we have 8 of them at school
[00:47:49] <robin_sz> toastydeath, bollocks
[00:47:55] <toastydeath> not bollocs
[00:48:18] <robin_sz> you have MIG sets with contant current?
[00:48:21] <toastydeath> we do
[00:48:26] <robin_sz> make, model
[00:48:27] <Rugludallur> toastydeath: constant current with wire feeder is possible but you have to keep the distance to the work piece exactly the same
[00:48:31] <toastydeath> they're multifunction units
[00:48:40] <Rugludallur> toastydeath: then they are CV/CC
[00:48:41] <toastydeath> miller something?
[00:48:46] <robin_sz> mig and tig?
[00:48:51] <robin_sz> mig and stick?
[00:48:52] <toastydeath> mig/tig/stick
[00:48:55] <robin_sz> right
[00:49:22] <robin_sz> mig is CV
[00:49:29] <robin_sz> tig and stick are CC
[00:50:03] <toastydeath> interesting
[00:50:14] <toastydeath> I WILL BELIEVE YOU FOR NOW
[00:50:24] <robin_sz> well, I might be worng of course
[00:50:33] <toastydeath> i don't see why it can't be CC
[00:50:52] <robin_sz> toastydeath, how many welders do you employ?
[00:51:04] <toastydeath> i don't own my own business?
[00:51:23] <toastydeath> like i said, i will believe you
[00:51:32] <toastydeath> and look it up later
[00:51:44] <robin_sz> well, take it from me, since I employ 5 welders, all coded to BS287 pt1,
[00:51:56] <robin_sz> tig and stick are CC,
[00:52:00] <robin_sz> mig is CV
[00:52:34] <ds2> doesn't CC generate more RFI and arcs then CV?
[00:52:37] <toastydeath> 20:51 < toastydeath> like i said, i will believe you
[00:52:36] <toastydeath> 20:51 < toastydeath> and look it up later
[00:52:50] <robin_sz> toastydeath> I WILL BELIEVE YOU FOR NOW
[00:53:15] <robin_sz> ds2, not compared to the HF start on a tig rig
[00:53:39] <ds2> but TIG Is CC =)
[00:53:42] <robin_sz> ive got some 500A millers that produce more RFI than a russiona jamming station :)
[00:53:47] <toastydeath> the only reason i say that is because i've spoken with veteran welders who swear up and down XYZ
[00:53:54] <toastydeath> and they turn out to be completely wrong
[00:53:59] <robin_sz> welders often are
[00:54:06] <toastydeath> so i've taken it to looking that kind of thing up myself
[00:54:12] <ds2> robin_sz: what's to prevent someone from drawing really really long sparks when they lift off during a CC weld?
[00:54:23] <robin_sz> ds2, nothing
[00:54:30] <ds2> oh
[00:54:35] <robin_sz> yes, it does happen
[00:54:50] <ds2> sounds dangerous
[00:55:04] <toastydeath> you can get pretty far away and still have an arc with cc tig
[00:55:12] <robin_sz> well, the maximum voltage is limited
[00:55:22] <ds2> ah so there is a cap
[00:55:24] <robin_sz> 70 or 80V max on most tig sets
[00:55:46] <Rugludallur> compared to 8k-20k volts on the HF
[00:55:53] <robin_sz> exactly
[00:56:07] <tomp> sparks depend on voltage, not current, so stop the voltage = stop the spark ( the spec for dielectric breakdown is volts per distance, current is not in the equation )
[00:56:08] <ds2> so with a CC system the thing gets hotter as you remove the electrode?
[00:56:15] <robin_sz> always turn of the HF before trying to stick weld :)
[00:56:19] <robin_sz> ds2, yep
[00:56:27] <ds2> tomp: yes, but to maintain CC, V must go up
[00:56:35] <ds2> interesting
[00:56:56] <robin_sz> in other words, you move the electrode closer to lower the heat
[00:57:02] <robin_sz> oppposite of MIG and gas
[00:57:04] <ds2> so it also means it is safe to keep the electrode stuck to the part w/o risk of burning out (other then via duty cycle limitations)?
[00:57:08] <robin_sz> correct
[00:57:30] <ds2> it is so nice when common physics works ;)
[00:57:53] <robin_sz> the thinner and sharper the lectrode, the tighter the weld
[00:58:16] <robin_sz> we do some gorgeous, tiny, clean welds on 1.2mm
[00:58:47] <Rugludallur> just remember not to do that with AC TIG :)
[00:58:52] <ds2> in tig, the electrode does not get consumed; but what happens with ARC?
[00:59:03] <robin_sz> arc as in stick?
[00:59:05] <ds2> Rugludallur: why?
[00:59:10] <toastydeath> the electrode is the filler metal
[00:59:13] <toastydeath> in stick
[00:59:14] <Rugludallur> ds2: you would melt the end of the electrode
[00:59:16] <robin_sz> electrode is the filler
[00:59:17] <ds2> arc as in the other CC process you mentioned
[00:59:33] <Rugludallur> ds2: with ac you ball up the end of the electrode
[00:59:44] <ds2> Rugludallur: oh? isn't the electrode W and melts a lot hotter then the steel?
[00:59:50] <robin_sz> Rugludallur, easier said than done :)
[01:00:06] <Rugludallur> ds2: not when you are using AC and 400A :)
[01:00:15] <Rugludallur> err robin_sz :)
[01:00:20] <ds2> Rugludallur: why does AC matter?
[01:00:27] <Rugludallur> ds2 electron transfer
[01:00:30] <robin_sz> ds2, DC and sharp, thoriated electrode for steel, ac and round ceriated electrode for aluminoium
[01:00:41] <toastydeath> or zirconia
[01:00:46] <toastydeath> on aluminum
[01:00:54] <ds2> hmmm
[01:00:57] <Rugludallur> pure tungsten also works good on aluminium
[01:01:06] <tomp> W? as in wolfram? tungsten?
[01:01:06] <Rugludallur> found it to work better than zirconated in most cases
[01:01:32] <ds2> I need to find a welding class with an instructor that speaks physics instead of like an automechanic who can't explain things with basic scientific principles
[01:01:38] <ds2> tomp: W as in Tungsten
[01:01:40] <toastydeath> ds2: the point behind AC is it provides a mix of electrode posive and electrode negative characteristics
[01:01:42] <robin_sz> I was trying to ball up a 1/8" electrode on ally yesterday
[01:01:53] <toastydeath> electrode negative, which has a deeper penetration on the workpeice
[01:01:53] <robin_sz> needs a lot of current
[01:01:58] <Rugludallur> ds2: the negative side of the path gives off electrons , if you weld with ac you electrode gets the same amount of heat as your work piece, assuming you don't have square/unbalanced wave
[01:02:07] <ds2> so WC would be something you machine with, not piss into ;)
[01:02:18] <toastydeath> and electrode positive, which heats the electrode up more, but cleans the weld area
[01:02:32] <Rugludallur> robin_sz: I switch to dc + and ball up on a piece of stainless stock
[01:02:35] <robin_sz> we have sq wave variable balance on AC
[01:02:42] <toastydeath> it has to do which direction the plasma sheath is travelling
[01:02:52] <robin_sz> Rugludallur, rightm, I ll try that
[01:02:51] <ds2> Rugludallur: does that mean I can control the temperature by varying the duty polarity duty cycle?
[01:03:01] <toastydeath> yes
[01:03:03] <ds2> (at constant distance)
[01:03:07] <toastydeath> ds2: yes
[01:03:13] <toastydeath> that's called wave balance control
[01:03:15] <Rugludallur> robin_sz: just lower the juice, otherwise you might melt off more than you want :)
[01:03:32] <robin_sz> wave balance is usally a penetration/clenaing trade off
[01:03:46] <robin_sz> we use the pulse settigns to control heat
[01:03:52] <robin_sz> and the go-go pedal
[01:03:57] <toastydeath> it is, because the more negative you go, the deeper the penetration - the hot plasma is heating the weld, in addition to the electron flow
[01:04:18] <Rugludallur> robin_sz: wish I had a pulse tig, so much easier for alu
[01:04:20] <ds2> just thinking of how they would vary temperature in an automatic "CNC" welding setup
[01:04:34] <toastydeath> the more positive, the better the cleaning - the plasma is pulling the impurities off the surface of the work as it is formed
[01:04:38] <robin_sz> ds2, easy, theyd use MIG :)
[01:04:43] <toastydeath> but that means the plasma is heating the electrode.
[01:04:53] <ds2> robin_sz: MIG is no good for Al, right?
[01:05:01] <toastydeath> you can weld AL with mig
[01:05:05] <robin_sz> ds2, no, mig is good on ally
[01:05:11] <robin_sz> especially with pulse transfer
[01:05:12] <Rugludallur> but the results are usually not as good as with tig
[01:05:20] <robin_sz> wellm true
[01:05:28] <toastydeath> nothing's going to beat a tig weld except machine welding or plasma
[01:05:29] <robin_sz> wut for robotic welding ...
[01:05:46] <robin_sz> hot wire tig robot maybe ...
[01:06:01] <robin_sz> but robotic mig, pulse welder
[01:06:06] <toastydeath> SAW
[01:06:20] <robin_sz> ok bedtime
[01:06:38] <Rugludallur> nite
[01:06:50] <toastydeath> cya
[01:07:39] <toastydeath> we get things electron beam welded all the time
[01:07:45] <toastydeath> that makes a pretty darn good joint too
[01:08:10] <Rugludallur> toastydeath: only thing that beats electron beam would be stir friction
[01:08:33] <toastydeath> how does that wind up superior?
[01:08:41] <toastydeath> won't the tool wear into the weld?
[01:08:47] <Rugludallur> toastydeath: less heat affected zone
[01:08:51] <toastydeath> ahh
[01:09:00] <Rugludallur> toastydeath: it's what nasa is using on critical stuff today
[01:09:16] <toastydeath> is there a dedicated machine for it
[01:09:24] <toastydeath> i see videos of people using milling machines
[01:09:33] <Rugludallur> toastydeath: yeah it's huge
[01:09:51] <Rugludallur> toastydeath: at least the one I have seen
[01:09:54] <toastydeath> but is it necessary? like, could one purchase the tool and stick it in a mill
[01:10:11] <toastydeath> i don't know enough about the process parameters to know
[01:10:56] <Rugludallur> toastydeath: you can friction weld with normal equipment but you can't get the same quality as the nasa stuff
[01:11:03] <toastydeath> ahh
[01:11:08] <tomp> http://www.azom.com/details.asp?ArticleID=1170
[01:11:11] <ds2> isn't friction welding hard on equipment?
[01:11:17] <tomp> friction welding
[01:11:34] <toastydeath> ds2: that's entirely a function of if your equipment can handle friction welding
[01:11:51] <toastydeath> i'm not saying try it on a bridgeport, for example
[01:12:09] <ds2> toastydeath: but I'd think if I friction welded with a lathe, it would not last as long as one that is used purely to machine 12L14
[01:12:19] <toastydeath> I've seen videos of people using a K&T 30 hp vertical to do it, but i'm not sure how the select parameters
[01:12:19] <ds2> regardless of what equipment it is
[01:12:32] <toastydeath> ds2: not really
[01:12:51] <toastydeath> it depends on the size of the lathe and what it's normal load is
[01:13:01] <toastydeath> like, a Jet import may have problems
[01:13:21] <toastydeath> but an American Pacemaker is not, if you could get it to spin fast enough to get the weld started
[01:13:29] <tomp> friction welding vid
http://www.msm.cam.ac.uk/phase%2Dtrans/2002/papers/LINEAR.MPG
[01:13:39] <tomp> oscillating not spinning
[01:13:50] <toastydeath> tomp: ty
[01:14:14] <tomp> nasa = hi tech = rub 2 sticks together :)
[01:14:18] <toastydeath> yeah, the ones i've seen are most definately stirring
[01:14:42] <toastydeath> the secret is revealed!
[01:24:25] <tomp> mel brooks: friction welding as the 10,000 year old man " we had 5 guys, each had a point, they'd run together at a great speed, and WHAM , a star of David.. great seller, then along came this guy, 'Paul' I think, and he had this idea, he called it a 'cross', i laughed and said it'd never catch on, what did i know! I coulda laid off 3 guys "
[01:32:08] <Rugludallur> nite ppl
[01:40:57] <maddash> are there any docs on using teleop?
[01:51:51] <maddash> :( teleop wasn't what I thought it was.
[02:05:24] <tomp> what factors would be assets to a servo system that had to respond to say, a 1mV and a 2mV command voltages?
[02:05:29] <tomp> this system has to have good low speed response and be able to differentiate between a single voltage step ( like respond to near the LSB of a DAC )
[02:13:51] <tomp> just caught that jepler's daisy.ngc was a song played by emc via frequencies of steppers ( thats why the path view looked like a scribble, it doesnt matter what it looks like, its what it sounds like :)
[02:16:25] <maddash> holy crap, microstepping
[02:17:02] <tomp> btw its af-ford, & how about want tts to accompany it ( new M code ) ? hal would sound 'right' with Hawkins voice.
[02:33:56] <maddash> can anyone recommend a kick-ass stepper driver w/quadrature (gray) coding and microstepping?
[02:36:14] <tomp> jepler: if you have festival installed, run the shell & this command...
[02:36:14] <tomp> festival> (tts "/usr/share/doc/festival/examples/songs/daisy.xml" 'singing) to accompany daisy.ngc :)
[03:11:40] <skunkworks> So - the big servos we have - 50v = 400rpm 100v = 600rpm and 150v = 1200rpm.. (yes I know it is linear)
[03:12:01] <skunkworks> That will give us 200ipm rapids with a 2:1 and 3tpi
[03:12:22] <skunkworks> 150v is very good also. not too scary.
[03:15:48] <skunkworks> that was strait rectified 120v single phase. (thru a isolation transformer and variac - bridge and caps)
[03:16:11] <skunkworks> we will be rectifying aprox 120v 3 phase.
[03:17:05] <skunkworks> oops - 100v = 800 rpm (that was linear) ;)
[03:19:58] <skunkworks> which will give us a bit higher peak.
[08:23:49] <xemet> hello
[08:23:55] <sebjames> Hello there
[08:24:21] <xemet> I don't remember a thing, how can I use halcmd command line with EMC2 installed Run In Place?
[08:38:57] <sebjames> You need to specify the path to the halcmd program.
[08:39:04] <sebjames> NOw, let me see where it is...
[08:39:41] <sebjames> If you're in the directory that you compiled emc2 in , you type ./bin/halcmd
[08:40:43] <sebjames> [cnc@cnc-desktop 09:40:29 emc2-trunk]$ pwd
[08:40:43] <sebjames> /home/cnc/emc2/emc2-trunk
[08:40:43] <sebjames> [cnc@cnc-desktop 09:40:31 emc2-trunk]$ ./bin/halcmd show sig TEST
[08:40:44] <sebjames> RTAPI: ERROR: could not open shared memory (errno=2)
[08:40:44] <sebjames> HAL: ERROR: rtapi init failed
[08:40:43] <sebjames> halcmd: hal_init() failed: -9
[08:40:45] <sebjames> NOTE: 'rtapi' kernel module must be loaded
[08:40:51] <sebjames> [cnc@cnc-desktop 09:40:32 emc2-trunk]$
[08:41:21] <xemet> ok, found it
[08:41:33] <sebjames> Great
[08:41:31] <xemet> just launch the script emc-environment
[09:00:47] <Jymmm> lerneaen_hydra: you again, I thought you wen tto sleep!
[09:29:49] <The_Ball> is there any free tools to convert 2d dxf files to toolpaths?
[09:30:34] <The_Ball> there are lot's of free dxf patterns on cnczone but all in dxf format. I don't have a fancy cam program
[09:31:32] <Jymmm> dxf2gcode
[09:31:37] <Jymmm> ace converter iirc
[09:32:07] <Jymmm> http://www.dakeng.com/ace.html
[09:33:53] <The_Ball> thanks :)
[09:33:59] <Jymmm> np =)
[09:34:12] <The_Ball> what programs do you use?
[11:36:02] <cradek_> cradek_ is now known as cradek
[12:10:17] <sebjames> I'm working with halui right now.
[12:11:33] <sebjames> I have a hal component to do a homing sequence. If the axis thinks it is homed, how can I set it so that it isn't homed? That is, can I clear halui.joint.o.is_homed
[12:12:31] <sebjames> And is there any way other than sending data to halui.joint.0.is_homed? Because the user interface seems to use this pin, so is blocking me from writing to it...
[12:12:47] <cradek> halui.is_homed is an output, you can't write to it
[12:13:20] <cradek> but, you don't have to be unhomed to home
[12:13:34] <sebjames> Hmm. That's true.
[12:14:08] <sebjames> It's just my component which checks the halui.joint.0.is-homed pin.. I'll rethink it.
[12:19:32] <sebjames> Now, I keep seeing this: emcSystemCmd: abandoning process 20326
[12:19:53] <sebjames> Which comes from emctaskmain.cc
[12:20:03] <cradek> I think that means a custom mcode's program isn't exiting, so emc eventually gives up waiting for it
[12:20:54] <sebjames> Yes. If this flag isn't set, then the program gets abandoned.EMC_TASK_EXEC_WAITING_FOR_SYSTEM_CMD
[12:21:15] <cradek> bbl
[12:21:15] <alex_joni> sebjames: the custom M-code needs to end after a certain time
[12:21:17] <sebjames> Ok. I put a couple of sleep commands in my script... I'm sure they're the problem
[12:21:30] <alex_joni> sebjames: probably you sleep too much
[12:21:33] <sebjames> alex_joni: Yep, that'll be it.
[12:21:52] <sebjames> :) Not enough, as it happens; two small children :)
[12:21:54] <alex_joni> what are you waiting for?
[12:22:04] <alex_joni> (with the sleep I mean..)
[12:22:06] <sebjames> A clamp to come down
[12:22:11] <alex_joni> I see
[12:22:25] <sebjames> Clamp comes down, once it is down, the material is clamped up against the X encoder
[12:22:43] <sebjames> _then_ I can start my homing procedure with halui.joint.0.home
[12:22:53] <alex_joni> sebjames: do this in ladder
[12:23:19] <alex_joni> sounds a lot easier to me..
[12:23:38] <alex_joni> you can have an output from ladder to inhibit motion while the sequence is not complete for example
[12:24:09] <sebjames> Right. I didn't want to get into ladder; I've avoided it this far... :)
[12:24:56] <sebjames> I'll make a component which when clamp is asserted, waits a couple of loops then says "clamp is down"
[12:25:11] <sebjames> I can also then have an output which says if any clamps are down.
[12:26:24] <jepler> // something's already running, and we can only handle one
[12:26:28] <jepler> if (EMC_DEBUG & EMC_DEBUG_TASK_ISSUE) {
[12:26:28] <jepler> rcs_print
[12:26:28] <jepler> ("emcSystemCmd: abandoning process %d, running ``%s''\n",
[12:26:54] <alex_joni> sebjames: see.. you could extend that :P
[12:27:12] <alex_joni> so probably your previous scripts didn't die properly
[12:27:26] <jepler> oh wait, there's another location
[12:27:39] <jepler> // first check for an abandoned system command and abort it
[12:27:41] <jepler> if (emcSystemCmdPid != 0 &&
[12:27:41] <jepler> emcStatus->task.execState !=
[12:27:41] <jepler> EMC_TASK_EXEC_WAITING_FOR_SYSTEM_CMD) {
[12:27:41] <jepler> if (EMC_DEBUG & EMC_DEBUG_TASK_ISSUE) {
[12:27:42] <jepler> rcs_print("emcSystemCmd: abandoning process %d\n",
[12:27:48] <jepler> execStat must have changed away from EMC_TASK_EXEC_WAITING_FOR_SYSTEM_CMD
[12:27:52] <sebjames> Yes jepler - that's the place
[12:27:59] <jepler> not sure what would make it change
[12:28:02] <sebjames> No
[12:28:41] <jepler> switching to mdi mode would cause that
[12:28:44] <sebjames> If you run a script, then the next time we come to this point ni emctaskmain.cc if the script is still running, it gets abandoned
[12:28:50] <sebjames> Ahhhhh
[12:29:12] <jepler> // leaving auto or mdi mode for manual
[12:29:17] <jepler> emcStatus->task.execState = EMC_TASK_EXEC_DONE;
[12:29:22] <jepler> around line 1822
[12:29:23] <sebjames> I have been switching modes in my component - because I have to be ni manual mode to home. Really, it would be better to be able to home when in auto or mdi mode
[12:29:41] <sebjames> SO the solution is to make it possible to home in mdi or auto mode
[12:29:48] <sebjames> For me at any rate.
[12:39:23] <sebjames> Have updated my emctaskmain.cc to suit this.
[12:42:51] <jepler> I am surprised it was easy
[12:48:56] <sebjames> :) It wasn't
[12:49:37] <sebjames> I added case EMC_AXIS_HOME_TYPE: to the list of "immediate commands" for the states ON, Auto and ON, MDI and the homing command is issued, but to no effect.
[12:49:55] <sebjames> Issuing EMC_AXIS_HOME -- (+123,+16, +9, +0,)
[12:50:03] <sebjames> Then no motion or attempt to home
[12:50:46] <sebjames> I'm trying first to get to a position where I can switch to MDI mode, then press the "home" button, and the machine will home.
[12:50:58] <sebjames> ... in the tkemc frontend, btw.
[12:56:03] <Guest525> alex_joni: 150v = 1200rpm :)
[12:56:53] <Guest525> oops
[12:57:00] <Guest525> Guest525 is now known as skunkworks_
[13:00:13] <sebjames> Can someone explain, before I have ploughed through const char *NML::msg2str(NMLmsg * nml_msg), what the (+123,+16,+9,+0,) means in the debug message "Issuing EMC_AXIS_HOME -- (+123,+16, +9, +0,)"??
[13:03:16] <jepler> #define EMC_AXIS_HOME_TYPE ((NMLTYPE) 123)
[13:03:18] <jepler> I don't know what the others mean
[13:05:14] <sebjames> Yes, there seems to be only two bits of information in an NMLmsg
[13:05:20] <sebjames> type and size.
[13:06:06] <jepler> I think in this case the 4 fields are: type, size, serial number, axis number
[13:06:27] <sebjames> That's +123 and +16. Then +9 is I think the message number (giving its order) and yes - an argument
[13:06:33] <sebjames> In this case axis number
[13:07:12] <sebjames> Well, there seems to be nothing out of order with the message I am sending to achieve a homing sequence in MDI mode...
[13:10:08] <jepler> static void do_homing(void)
[13:10:11] <jepler> if (emcmotStatus->motion_state != EMCMOT_MOTION_FREE) {
[13:10:11] <jepler> /* can't home unless in free mode */
[13:10:11] <jepler> return;
[13:16:39] <sebjames> Ah jepler - thanks
[13:36:27] <sebjames> It's tough to debug stuff in the servo thread - thinking particularly of this do_homing function and friends.
[13:37:45] <sebjames> rtapi_print_msg() didn't seem to have an effect...
[13:58:32] <sebjames> Oh, rtapi_print() works, and rtapi_print_msg prob. works too; they send data to logs.
[13:58:45] <sebjames> Still, haven't worked out why I can't home in MDI mode yet.
[13:59:01] <sebjames> And have to get off shortly.
[13:59:13] <sebjames> sebjames has changed the topic to: Welcome! EMC (Enhanced Machine Controller) is a linux-based opensourc e CNC control. | Latest release: EMC 2.1.6 |
http://www.linuxcnc.org |
http://wiki.linuxcnc.org
[13:59:11] <ChanServ> ChanServ has changed the topic to: Welcome! EMC (Enhanced Machine Controller) is a linux-based opensource CNC control. | Latest release: EMC 2.1.6 |
http://www.linuxcnc.org |
http://wiki.linuxcnc.org
[13:59:29] <sebjames> Whops
[13:59:31] <sebjames> Whoops
[13:59:44] <awallin> can't you just home in jog-mode?
[13:59:55] <sebjames> awallin: No.
[14:00:26] <sebjames> awalling: I have to home the _material_ before each run, so it needs to be a command in a program
[14:01:15] <awallin> are there G/M codes for homing?
[14:01:24] <awallin> what you want to do might be called probing??
[14:01:54] <sebjames> So, I really need to home via a user M command. I can do this with halui, but that requires that I change mode from MDI to Manaul. Much better if homing will work in MDI/Auto modes
[14:02:09] <sebjames> There's no existing G/M code for homing.
[14:02:28] <sebjames> Anyway, I'll have to come back to this.
[14:02:34] <awallin> could you do a probe of where your part is, then set a working coordinate system?
[14:03:02] <awallin> in the work coordinate system the probed point of the part would be at (0,0)
[14:03:03] <sebjames> How to probe?
[14:03:15] <awallin> that should be in the wiki and there is G-code for that
[14:03:18] <jepler> G38.2
[14:03:21] <sebjames> Ok
[14:03:29] <jepler> it moves towards the specified point until a HAL input becomes true
[14:03:33] <awallin> the result can probably be stored in a variable
[14:03:38] <jepler> at that point it stops and puts the coordinate values in some variable
[14:03:40] <jepler> #5xxx
[14:03:45] <sebjames> Ok, that might work.
[14:03:52] <awallin> and loaded into an offset register with G10 or something?
[14:04:59] <sebjames> I sort of prefer the idea of homing the axis. Nice and simple
[14:05:16] <sebjames> No artificial offsets and so on.
[14:05:33] <sebjames> But if "probing" is easier...
[14:06:57] <sebjames> Also, homing is quite sophisticated with the motion. Does probing also work as well?
[14:07:05] <awallin> you could set the machine coordinates to 0,0 with G92 but that is uglier than using the G54 etc offset
[14:07:21] <awallin> I think probing is just slow feed until a switch flips
[14:07:22] <sebjames> you know -wtih a fast speed to find the homing sensor, then slow traverse to carefully find the home postion
[14:07:30] <sebjames> Right.
[14:07:52] <cradek> you can probe several times at different speeds if that's what you want
[14:07:59] <sebjames> I'll think about it.
[14:08:07] <sebjames> Thanks for the help.
[14:09:30] <cradek> it would be an awful lot of task hacking to allow homing during a program run
[14:09:46] <jepler> I have a feeling you're right
[14:11:24] <cradek> I'd tackle it by controlling a 'gui' programatically, whether that gui is halui or something like jdi
[15:01:25] <sebjames> sebjames is now known as sebjames_
[15:02:19] <sebjames_> sebjames_ is now known as sebjames
[15:43:47] <awallin> jepler: did you ever save animations in gif or avi format from your z-map cut-sim tests?
[15:44:13] <awallin> or does anyone else know how to make an animation(avi or similar) from a g-code file?
[15:44:32] <jepler> awallin: no, I haven't done that
[15:44:40] <awallin> ok
[15:45:44] <jepler> minigl would require a few additions to allow the contents of the window to be written as an image, if you want a 3d view during the cut
[15:46:06] <jepler> you'd also have to arrange for actually writing the images at the appropriate times during the run
[15:46:40] <jepler> mumble glReadPixels
[15:47:45] <awallin> my drop cutter stuff seems to finally be working after squashing a few bugs today:
http://imagebin.org/9317 would be nice to illustrate it with a cutting simulation, but maybe I will have to settle for back-plot (I could do that in matlab)
[15:49:01] <awallin> I will have to do chippy next!
[16:28:10] <awallin> matlab is kind of slow with 22k triangles in one figure :)
[16:30:00] <ler_hydra> 'lo
[16:30:04] <ler_hydra> anbyone here?
[16:30:12] <christel> [Global Notice] Hi all, we're experiencing some routing issues at present causing some minor splittage, affected users approx. 4500. We're working to magic them back as we speak! Thank you for using freenode and have a great day!
[16:30:31] <awallin> hi
[16:31:40] <ler_hydra> if I find that the interpreter/traj planner needs more cpu time (because of a file that has say many small movements) would the traj period be what I need to increase?
[16:32:59] <awallin> that will increase the number of trajectory points calculated
[16:33:10] <awallin> so a lower traj_period means more work for the cpu
[16:33:27] <ler_hydra> oh I see
[16:33:35] <jepler> if your segements are so short that emc cannot reach cruise velocity during a single segment, adjusting parameters like trajectory period will not really change anything
[16:33:52] <cradek> best bet is to use tolerance mode
[16:33:55] <jepler> you might try specifying a G64 P- tolerance so that the trajectory planner gets longer segments
[16:34:09] <ler_hydra> the segments are very short, however there isn't a large delta-omega between them
[16:34:31] <cradek> ler_hydra: exactly what is the problem you're having
[16:35:03] <ler_hydra> cradek, the mill "jerks" forward somewhat instead of being a somewhat smooth movement
[16:35:19] <cradek> ok, that's probably starvation
[16:35:23] <ler_hydra> or rather, it jerks forwards sometimes, maybe 3-4 times per second
[16:35:34] <cradek> which means *task* needs more cpu time
[16:35:35] <ler_hydra> depending on how many line segments per second
[16:35:44] <cradek> on a slow machine I moticed that task and AXIS fight
[16:35:52] <ler_hydra> it's about 10-20 lines per second
[16:35:54] <ler_hydra> oh ok
[16:36:53] <cradek> in the emc script you could try niceing AXIS - that will fix it, but it's not a great solution
[16:37:30] <ler_hydra> I can't seem to see any correlation between axis updats and slowdown though
[16:37:42] <ler_hydra> would increaseing base period do anything?
[16:37:58] <ler_hydra> this is on a 1.8 ghz celeron, so it's not that slow
[16:38:08] <ler_hydra> base period of 25k or so
[16:38:12] <cradek> I'm surprised you're having this problem
[16:38:26] <cradek> if you can have a larger base period that might help
[16:38:42] <cradek> or, try a different gui (xemc?) and see if it's better
[16:38:54] <cradek> if so, we know it's the problem I saw on my PII
[16:40:27] <ler_hydra> I was just running the part, while in IRC, and it was about as responsive as an over internet ssh session
[16:40:42] <ler_hydra> (irc was about as responsive)
[16:40:49] <ler_hydra> s/irc/xchat
[16:41:26] <cradek> # this nice here makes a huge difference in segment throughput on my very
[16:41:26] <cradek> # slow machine, by letting milltask run.
[16:41:26] <cradek> nice $EMC2_BIN_DIR/$EMCDISPLAY -ini $INIFILE $EMCDISPLAYARGS $EXTRA_ARGS
[16:41:39] <cradek> I guess this is still in 2.1. I assume you are using trunk which doesn't have it?
[16:42:21] <ler_hydra> yeah this is 2.1.x
[16:42:31] <cradek> x=?
[16:42:32] <ler_hydra> 6
[16:42:38] <jepler> consider this ngc file:
http://emergent.unpy.net/files/sandbox/stutter.ngc
[16:42:50] <jepler> it has some shortish moves and some absolutely teeny moves
[16:43:07] <jepler> here's a halscope of it:
http://emergent.unpy.net/files/sandbox/stutter.png
[16:43:10] <ler_hydra> my file was about 800mm/min and 0.5mm moves
[16:43:23] <jepler> you can see that when it hits an absolutely teeny move, the speed goes way down
[16:43:37] <ler_hydra> that just about what I'm seeing except it's irregular
[16:43:49] <cradek> maybe jepler is right and it's not starvation
[16:43:52] <ler_hydra> at first I thought it was RT overrruns but the RT test was safe down to 18k
[16:43:55] <awallin> jepler: if you reduce the number of moves in the loop to 2, is the velocity graph smoother?
[16:44:24] <cradek> g64p will fix jepler's program
[16:44:59] <awallin> but the moves are all in one direction - so this is still a bit embarrasing from a tp point of view...
[16:45:17] <jepler> it's embarassing gcode
[16:45:26] <cradek> haha, PGA awallin
[16:45:46] <jepler> PGA?
[16:45:51] <cradek> patches ...
[16:47:08] <awallin> for better lookahead I think feed-override needs to be restricted. commercial controls restrict fo to 200% in 'HSM' mode when the lookahead buffer is deep
[16:47:15] <ler_hydra> it's very common for cam apps to export that kind of gcode
[16:47:20] <awallin> at least that would make the problem a bit easier
[16:47:26] <ler_hydra> not in a straight line maybe :)
[16:47:28] <cradek> ler_hydra: we made tolerance mode for that reason
[16:47:40] <cradek> (bad cam output I mean)
[16:47:44] <ler_hydra> yeah :)
[16:48:26] <awallin> so we should all works towards a good open-source cam app then ? ;)
[16:51:16] <bill2or3> please.
[16:52:44] <renesis_> renesis_ is now known as renesis
[16:58:19] <awallin> here's a second demo of the drop-cutter algorithm:
http://imagebin.org/9318 still no animations...
[16:59:04] <ler_hydra> awallin, a paralell lace cycle?
[16:59:31] <awallin> yes, raster finish or whatever you want to call it
[16:59:53] <awallin> every cam company seems to have their own name for the toolpaths
[17:00:07] <ler_hydra> heh yeah
[17:03:52] <awallin> anonimasu seemd keen on working on a GUI for cad/cam so we shall see how far I get with these cam-algorithms...
[17:05:15] <ler_hydra> sweet :)
[17:08:34] <awallin> gotta go, maybe back later.
[17:29:37] <skunkworks_> ler_hydra: what is the machine that your using?
[17:29:44] <skunkworks_> you're
[17:56:06] <awalli1> -
[17:57:01] <skunkworks_> --
[18:01:08] <a-l-p-h-a2> a-l-p-h-a2 is now known as a-l-p-h-a
[18:05:25] <Dallur> ---
[18:15:56] <|Bo^Dick|> thanks for all help
[18:16:21] <|Bo^Dick|> particularly you SpeedEvil
[18:31:08] <steve_stallings> steve_stallings is now known as steves_logging
[18:31:25] <awalli1> Dallur: did you make any progress with your python program for cad/cam ?
[18:38:42] <lerneaen_hydra> skunkworks_: this machine
http://www.lerneaenhydra.net/index.php?option=com_rsgallery2&Itemid=32&catid=8
[18:41:25] <awalli1> lerneaen_hydra: there are much too many stock parts on that machine ;)
[18:41:32] <Dallur> awallin: I have not worked on it in ages
[18:41:41] <lerneaen_hydra> awalli1: ah, very true ;)
[18:41:53] <Dallur> awallin: dxf2cnc kinda does most of what I was doing so ...
[18:41:51] <lerneaen_hydra> at least compared to your machine
[18:42:17] <awalli1> Dallur: ok. I'm dabbling with various cam ideas and looking for collaborators
[18:42:47] <awalli1> lerneaen_hydra: yeah, re-build is perhaps more appropriate than 'conversion' in our case!
[18:43:17] <Dallur> awawllin: I would really like to help with whatever needs to be done in regards to CAM work
[18:43:25] <lerneaen_hydra> heh, what have you got left of the original machine? the cast iron base and the cast iron motor housing?
[18:43:44] <skunkworks_> lerneaen_hydra: very nice. I want a small machine similar to that for my house ;)
[18:44:06] <lerneaen_hydra> skunkworks_: nice, it's quite a good machine for the price
[18:44:06] <awalli1> lerneaen_hydra: no, just the base and the column. the new spindle box is diy
[18:44:12] <lerneaen_hydra> awalli1: oh ok
[18:44:21] <lerneaen_hydra> awalli1: stock motor or 3phase?
[18:44:33] <awalli1> Dallur: ok, I will let you know how it goes. anonimasu suggested mono/c# for gui stuff
[18:44:46] <Dallur> awallin: at the end of my project I kinda came to the conclusion that what I really wanted to do was to make new datatypes for every type of geometric object with hierarchical relationships between them
[18:44:59] <awalli1> lerneaen_hydra: we now use a 1.5kW 3-phase motor with a vector vfd
[18:45:05] <lerneaen_hydra> sweet
[18:45:32] <Dallur> awallin: and use those as a basic object object model/ file format which any other cad/cam format can be imported to without losing any info
[18:45:34] <lerneaen_hydra> awalli1: you don't feel limited by the stability of the cast iron base? (N/µm deflection)
[18:46:07] <awalli1> Dallur: I found Aerohydro's patent:
http://www.patentstorm.us/patents/5627949-fulltext.html but maybe we shouldn't be scared of software patents
[18:46:48] <Dallur> awallin: I have not tried C# but I hear good things about mono and it would be portable + faster than python
[18:47:04] <awalli1> lerneaen_hydra: I think still the spindle motor is limiting when it comes to how big cuts are possible when roughing. No idea about accuracy of finishing wrt. base bending
[18:47:27] <lerneaen_hydra> awalli1: have you got an auto tool changer?
[18:47:29] <Dallur> awallin: A software patent is pretty worthless unless it's been defended in courts at least once so unless we know they are enforcing it I would suggest to ignore it
[18:47:47] <lerneaen_hydra> as it is now I just run a small mill for all tasks and let it take its time
[18:47:54] <awalli1> lerneaen_hydra: no atc. and I don't think we are going to build one
[18:48:03] <lerneaen_hydra> why not?
[18:48:09] <lerneaen_hydra> difficult/not worth the work?
[18:48:38] <awalli1> I think it's quite difficult. would require pneumatic drawbar or something like that.
[18:48:53] <lerneaen_hydra> oh, I saw some relatively simple designs
[18:49:12] <lerneaen_hydra> I don't recall offhand, but they were simple enough to implement
[18:49:21] <awalli1> Dallur: agreed. I looked at c# and it seems interesting. performance is needed, my drop-cutter tests in matlab run plenty slow with 1-2k triangles
[18:49:51] <lerneaen_hydra> it needed that all tool shanks were the same diameter though
[18:50:01] <archivist> that patent is predated by Brlcad somwhat
[18:50:48] <awalli1> archivist: ah, good. anyway europe doesn't have software patents (yet?) :)
[18:51:01] <archivist> not yet no
[18:51:08] <Dallur> awallin: I think for something like this to be feasible in python the intensive sub-routines would need to be re-written in C/C++
[18:51:09] <archivist> brlcad is open source
[18:53:27] <awalli1> Dallur: yes. but if everything can be in c# and be quick enough then that works for me too.
[18:54:02] <awalli1> but with C or C++ you could end up spending time on writing your own iterators and containers and such which comes for free in both python and c# I think
[18:55:21] <awalli1> so we want the highest level language possible that still has decent performance
[18:56:57] <Dallur> awallin: yup, on the other hand python could easily be plugged into axis :)
[18:58:02] <skunkworks_> dim
[18:58:06] <skunkworks_> oops
[19:03:07] <JymmmmEMC> * JymmmmEMC taught himself EVERYTHING about Eagle, as long as all you want to know is how to zoom in and out =)
[19:03:58] <skunkworks_> it has a learning curve - doesn't it? ;)
[19:05:11] <JymmmmEMC> Well, at least the tutorial isn't too shabby =)
[19:08:02] <skunkworks_> cradek/jepler are a good resource ;)
[19:08:44] <JymmmmEMC> good to know
[19:09:00] <JymmmmEMC> everythign I have in mind is pretty simple though.
[19:10:00] <JymmmmEMC> I went looking for a PS board/kit, never could find one. So I'll create one.
[19:12:02] <skunkworks_> power supply?
[19:12:38] <JymmmmEMC> linear 5/12v
[19:13:33] <JymmmmEMC> I ended up just buying a couple switching PS instead.
[19:20:33] <jepler> I haven't tried them, but there are some interesting, small and not too expensive ($8-$15) isolated 1W DC-DC converters
http://www.mouser.com/catalog/630/1650.pdf
[19:20:49] <jepler> e.g., 5V in, +-12V out
[19:21:33] <JymmmmEMC> jepler: Thanks, I still would have needed a PCB though =)
[19:22:20] <JymmmmEMC> $4/ea switching PS isn't too shabby.
[19:22:56] <awalli1> with the switchis psus you need to ground the - wire. they will usually float up to between 0 and the AC mains otherwise
[19:23:01] <JymmmmEMC> [email protected], 12V@1A, though I wish the ratings were reversed =)
[19:24:17] <JymmmmEMC> awalli1: 12v ground is common with earth ground and chassis
[19:25:25] <awalli1> ok.
[19:26:10] <JymmmmEMC> unfortunantly
[19:28:57] <JymmmmEMC> This whole isolation and "grounds" just throws me for a curve sometimes
[19:30:12] <JymmmmEMC> jepler: you do any smt pcv's yet?
[19:30:17] <JymmmmEMC> pcb's
[19:32:02] <jepler> JymmmmEMC: it's no trouble to mill them but I find it hard to keep the components in place to solder them
[19:32:18] <jepler> (using a soldering iron, I haven't tried any of the toaster oven type methods)
[19:33:33] <JymmmmEMC> jepler: Ah. I had to replace a smt -sstyle ribbon cable one time on my HT, Yaesu told me to solder like crazy, then solder wick up the excess =) It worked.
[19:34:05] <jepler> I'm sure that in time I'd get better
[19:35:07] <JymmmmEMC> Oh, speaking of which... I found some component pick and place machines yesterday.
[19:35:33] <JymmmmEMC> look REALLY old, or REALLY used.
[19:36:21] <JymmmmEMC> I wonder if they're worth anything scrapping out.
[19:36:31] <JymmmmEMC> 7 of them in a surplus store
[19:39:08] <jepler> sure could be
[20:04:03] <lerneaen_hydra> anyone here have a schematic for a variable voltage adjustable current limit psu, 0-20-ish volts >2A?
[20:06:07] <archivist> discretes or modern chip type
[20:07:25] <lerneaen_hydra> doesn't really matter as long as it's relatively cheap
[20:07:49] <archivist> I have manuals for commercial psus
[20:08:06] <lerneaen_hydra> oh with schematics?
[20:08:52] <jepler> http://www.uoguelph.ca/~antoon/circ/ps3010/ps3010a.html "
[20:08:52] <jepler> http://www.uoguelph.ca/~antoon/circ/ps3010/ps3010a.html ""This 30 volt Bench Top Power Supply is rated at 10 amp, and it is so versatile and powerful that it will slowly turn your regular 115VAC power drill. It was designed to work under the most extreme circumstances and fully short-circuit protected, even in the 10-Amp setting. The optional Cooling fan(s) keep the semiconductors and the large cooling rib cool automatically."
[20:09:03] <jepler> (no experience with it, just found while searching the web .. excuse the bad paste)
[20:09:29] <archivist> http://www.archivist.info/collection/searchv8.php?srcdata=title&searchv4page=1&errlev=0&searchstr=Farnell yes but need to scan
[20:10:47] <archivist> possibly this one IS 569 PSU'S L series L30/2, LT30/2
[20:12:28] <archivist> it was a pretty bomb proof bench psu
[20:12:56] <lerneaen_hydra> archivist: I don't see how to get info about it...
[20:13:13] <archivist> I need to scan it (its at home)
[20:13:19] <lerneaen_hydra> oh, I see
[20:13:36] <archivist> 10 miles away
[20:13:41] <lerneaen_hydra> if it's not too difficult and you
[20:13:52] <lerneaen_hydra> 're at home sometime then I would be very obliged :)
[20:14:56] <archivist> will dig out BX118 wheres its in later and scan in next few days
[20:16:10] <lerneaen_hydra> http://www.national.com/ds.cgi/LM/LM117.pdf <-- page 17 seems to be very simple
[20:17:24] <jepler> lerneaen_hydra: not adjustable down to 0V; I'm not sure if that's important to you
[20:17:33] <lerneaen_hydra> oh that doesn't matter to me
[20:17:37] <archivist> and no current limit
[20:17:42] <lerneaen_hydra> there was a current limit there though
[20:17:55] <jepler> LM117 itself doesn't have current limit, but the page 17 circuit does
[20:18:07] <lerneaen_hydra> yeah
[20:18:18] <lerneaen_hydra> probably via the 0.2 ohm sensing resistor
[20:18:44] <lerneaen_hydra> and the pot to adjust
[20:20:03] <jepler> needs a -6V supply too?
[20:20:16] <lerneaen_hydra> wtf. oh
[20:20:19] <lerneaen_hydra> for the op-amp
[20:20:25] <lerneaen_hydra> that's not so nice
[20:21:56] <archivist> could be a crude -6
[20:26:47] <lerneaen_hydra> crude -6?
[20:27:21] <archivist> diode cap
[20:27:41] <skunkworks_> zener
[20:28:08] <lerneaen_hydra> ?
[20:42:08] <skunkworks_> is keystick a text only front end?
[20:42:32] <skunkworks_> Like it would run without x
[20:42:36] <skunkworks_> ?
[20:43:13] <jepler> skunkworks_: yes and no
[20:43:23] <jepler> right now the
[20:43:29] <jepler> "emc" script runs keystick in a terminal
[20:43:34] <jepler> you'd have to modify it not to do that
[20:43:46] <skunkworks_> ah - ok
[20:43:49] <jepler> and make sure that nothing else prints anything, because that disturbs the keystick display
[20:44:59] <skunkworks_> Just wondering.. I don't plan on using it. Someone was wondering about machine control using dos
[20:45:40] <skunkworks_> http://www.cnczone.com/forums/showpost.php?p=318883&postcount=19
[20:45:50] <skunkworks_> that thread is a bit interesting.
[20:46:32] <skunkworks_> I think he has missed the point that linux/emc is free.
[20:46:56] <cradek> just because windows is a bad choice for a machine control platform doesn't make dos a good choice
[20:47:22] <archivist> he thinks a dos window in 98 would be ok wtf
[20:47:41] <cradek> it's true that there is a Free dos, but I doubt that's what he means about dos being "essentially" free
[20:47:59] <skunkworks_> He is a very smart guy - but has wierd ideas about machine controls.
[20:48:27] <archivist> perhaps he also missunderstands the multitasking in 98se
[20:48:58] <cradek> this is very much the kind of thread I know to stay out of
[20:49:22] <archivist> hehe
[20:50:19] <cradek> you simultaneously say you don't want to support microsoft's practices, and waste time arguing about which exclusively microsoft product to use?
[20:50:21] <archivist> I had my fill of Riscos "multitasking" when writing a printer driver
[20:51:10] <skunkworks_> :) I am suprised there hasn't been more 'use mach' in the thread.
[20:58:18] <lerneaen_hydra> what type of interface do those linear slides used for digital measurement systems on manual mills/lathes use?
[20:58:27] <lerneaen_hydra> analog quadrature-esque?
[20:59:29] <cradek> you mean regular DRO scales?
[20:59:44] <cradek> pretty sure they are all just quadrature
[20:59:59] <lerneaen_hydra> proabably, if DRO is what you find on any standard lathe/mill
[21:00:09] <lerneaen_hydra> so it would be simple to interface with EMC?
[21:00:19] <cradek> sure
[21:00:31] <cradek> what you want to do with it next is a harder question
[21:00:37] <cradek> but reading it is trivial
[21:01:04] <lerneaen_hydra> could be nice, afaik they're not much more expensive than encoders and you get real backlash comp, both in the screw and if you have timing belts
[21:01:29] <lerneaen_hydra> could get some nasty oscilation maybe
[21:01:31] <cradek> you can't tune a position pid very well if there's backlash
[21:01:34] <cradek> exactly
[21:01:43] <cradek> it hasn't moved yet? GO FASTER
[21:01:50] <cradek> oh crap too far
[21:01:50] <lerneaen_hydra> well it depends on how much backlash there is
[21:01:58] <lerneaen_hydra> exactly, jittering back and forth
[21:02:22] <lerneaen_hydra> you'll get rid of screw irregularity too
[21:02:29] <skunkworks_> ball screws.. or spring loaded nuts
[21:02:59] <cradek> I'd be tempted to use it only to set up compensation tables
[21:03:47] <lerneaen_hydra> not for a running machine?
[21:04:02] <skunkworks_> then you would only need one
[21:04:06] <cradek> it's not clear to me how to use it for any benefit
[21:04:15] <cradek> you could watch it for FE of course
[21:04:24] <lerneaen_hydra> how's the price level?
[21:04:24] <skunkworks_> now that screw comp is working... ;)
[21:04:36] <lerneaen_hydra> aren't they very similar in cost? (DRO slides and encoders)
[21:04:47] <cradek> I don't know
[21:04:51] <alex_joni> slides are usually way more expensive
[21:05:03] <alex_joni> if you're talking about glass scales
[21:05:08] <lerneaen_hydra> how much is an encoder? sub $50?
[21:05:09] <anonimasu> hm, well the commercial machines with linear encoders works very well.
[21:05:11] <anonimasu> :)
[21:05:21] <alex_joni> lerneaen_hydra: 100-200$
[21:05:37] <alex_joni> and glass scales are usually 200+/m
[21:05:47] <lerneaen_hydra> hmm, funny
[21:06:08] <anonimasu> I wonder how they do it..
[21:06:12] <skunkworks_> anonimasu: they have no back lash most likely and controls that can handle it if there is a little.
[21:06:17] <skunkworks_> emc cannot as I understand it
[21:06:20] <lerneaen_hydra> the DRO scales I've seen in sweden are about $150, whuch means they should be available for <100 in the usa
[21:06:48] <anonimasu> lerneaen_hydra: they still ship them from .tw/china
[21:06:48] <cradek> anonimasu: velocity loops in the amps I bet
[21:07:17] <anonimasu> cradek: yeah.. now that you mention it..
[21:08:13] <anonimasu> cradek: I like the idea of using glass scales to compensate for pitch errors..
[21:08:14] <anonimasu> :)
[21:16:25] <alex_joni> plus you get micron-accuracy\
[21:16:50] <lerneaen_hydra> that's what I was thinking
[21:16:57] <alex_joni> you can't get worse accuracy in scales these days
[21:17:16] <lerneaen_hydra> you loose all the innacuracies between the motor and the table movement
[21:17:29] <lerneaen_hydra> there's still tool/machine deflection though
[21:17:31] <alex_joni> lerneaen_hydra: obviously it's a problem with longer joints
[21:17:42] <lerneaen_hydra> how so?
[21:17:42] <alex_joni> > 5m travel
[21:17:45] <lerneaen_hydra> oh
[21:17:48] <lerneaen_hydra> really big
[21:17:50] <alex_joni> hard to make the scales
[21:17:52] <lerneaen_hydra> yeah
[21:18:01] <lerneaen_hydra> I'm still thinking sub bridgeport sized
[21:18:13] <alex_joni> * alex_joni thinks he should get some sleep
[21:18:23] <alex_joni> good night all
[21:18:25] <lerneaen_hydra> 'night
[21:18:32] <alex_joni> lerneaen_hydra: saw the message from you
[21:18:35] <skunkworks_> Night alex
[21:18:34] <alex_joni> earlier..
[21:19:00] <alex_joni> but I'm not at home (with my beloved internet connection), so I'll fix it when I get back
[21:19:09] <alex_joni> lerneaen_hydra: btw, greetings from athens ;)
[21:19:20] <lerneaen_hydra> alex_joni: cool :)
[21:19:34] <lerneaen_hydra> alex_joni: ah ok, no hurry
[21:19:45] <alex_joni> skunkworks_: no, it's not true .. I don't go to bed earlier now (after I got married :P)
[21:19:46] <lerneaen_hydra> I'll still have the old domain for a while
[21:20:17] <alex_joni> lerneaen_hydra: maybe remind me in 1-2 weeks if I haven't done it already
[21:20:23] <lerneaen_hydra> sure
[21:27:27] <skunkworks_> alex_joni: :)
