#emc | Logs for 2007-06-22

Back
[01:12:23] <jmkasunich_> SWPadnos: did I see you paying $200+ for a NEMA 12 box earlier?
[01:12:47] <jmkasunich_> you really should have stopped at HGR when you went driving by, I paid $50 for mine
[01:13:20] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[01:21:16] <jmkasunich_> jmkasunich_ is now known as jmk2
[01:23:49] <cradek> welcome, all you jmkasuniches
[01:25:52] <jmk2> heh
[01:25:59] <jmk2> clones
[01:26:13] <jmk2> I'm trying to convince one of me to go to work so the other one can sleep in
[01:26:16] <jmk2> no luck so far
[01:26:22] <cradek> if only
[01:28:32] <jmk2> * jmk2 RTFMs to try to hook an encoder to the mesa board
[01:28:59] <jmk2> step 1: find an encoder (that works)
[01:32:15] <cradek> mesa index?
[01:32:27] <jmk2> yeah
[01:32:35] <tomp2> the m5i20 has DAC's in the std FPGA cfg, has anyone written ADC's for it?
[01:32:49] <cradek> my sympathies
[01:32:55] <jmk2> tomp2: they would be damned slow
[01:33:04] <jmk2> the "DAC" is PWM into a filter
[01:33:22] <tomp2> wish i had a pci stg ;)
[01:33:26] <jmk2> so doing an SAR with it would probably take a mS per bit
[01:33:44] <jmk2> I'm planning to support serial A/D and D/A chips eventually
[01:37:26] <jmk2> wow, this encoder is ancient
[01:37:41] <skunkworks> hmm - would a flywheel act similar to a table/leadscrew combination - load on a servo?
[01:37:59] <jmk2> ceramic dips, and curvy traces on the PCB (the kind that come from skinny black tape on mylar layout)
[01:38:14] <cradek> skunkworks: yes
[01:38:32] <skunkworks> well - that might be an easy way for me to add mass to the system
[01:38:46] <skunkworks> for playing
[01:39:18] <skunkworks> question is - do I have any here :)
[01:41:44] <Ziegle1> Ziegle1 is now known as Ziegler
[01:46:35] <The_Ball> jmk2, can I ask you if there is some magic to driving FET's in a P & N channel H-bridge? Please have a look at http://wigen.net/pwm.png (the left side) if you have time
[01:46:58] <jmk2> it depends on the supply voltage
[01:47:18] <The_Ball> 36V, that's why the gate-source have 18V zeners
[01:47:55] <feoc2> jmkasunich ya about ?
[01:48:05] <jmk2> the high side devices have the zeners in the wrong place (their sources are on top)
[01:48:21] <jmk2> no. jmkasunich isn't here
[01:48:28] <The_Ball> oh yes
[01:48:45] <feoc2> jmk2 course ya not :)
[01:49:26] <jmk2> the top right one has an issue - its gate needs to swing from +36 (off) to +36-10 = +26 (on), but you're driving it from a logic gate (which I assume uses gnd as its negative supply)
[01:49:53] <The_Ball> yes, i did not update the right side, it will be a mirror of the left side
[01:49:55] <feoc2> hows it going with the mesa to stepper driver ?
[01:49:56] <jmk2> ok
[01:50:13] <The_Ball> jmk2, thanks for the input
[01:50:22] <feoc2> not that im utterly despertatly in need of it working or anything :)
[01:50:25] <jmk2> feoc2: right now I'm trying to find a problem with the old mesa driver
[01:50:33] <feoc2> but anything i can help with ?
[01:50:47] <jmk2> not really
[01:50:56] <feoc2> np
[01:51:08] <jmk2> The_Ball: the top side left driver has issues too
[01:51:08] <feoc2> as soon as you want sombody to test it gimmie a shout
[01:51:16] <jmk2> feoc2: will do
[01:51:52] <jmk2> The_Ball: when Q5 turns on, it will be pulling that gate toward 0V, but the zener (once moved) won't want it to go below 26V
[01:52:34] <jmk2> to be honest, I'm a great fan of IR2110 and similar chips, and all-N-channel bridges, once the supply voltage gets over about 12V
[01:52:43] <feoc2> think ill have to run geckos from par port til i can get the mesa going
[01:52:57] <feoc2> use the mesa for the other io
[01:53:05] <The_Ball> jmk2, it's a 18V zener so it will limit at 18V, but max source gate voltage is 20V so that should be fine right?
[01:53:05] <jmk2> feoc2: I'm trying ;-)
[01:53:14] <feoc2> cant get my analog servo driver to behave right
[01:53:19] <jmk2> my machine will use the mesa step/dir. so I'm motivated
[01:53:27] <The_Ball> jmk2, yes i would like to have the IR chips, but I can't get them quickly
[01:53:47] <feoc2> jmk2 theres a crate of beer in it for when you sort it ;)
[01:54:00] <jmk2> The_Ball: 10V is normally more than enough to fully turn on the FETs, 18V will just slow down turn off
[01:54:15] <jmk2> especially if the R5 pullup isn't very strong
[01:54:17] <The_Ball> oh i see, good hint, i will get 10V zeners instead then
[01:54:42] <jmk2> driving the mosfet gate capacitance is the biggest issue, passive pull-ups are limited there
[01:55:22] <The_Ball> jmk2, would driving these FET's with a IR2111 be fine?
[01:55:23] <jmk2> I have a circuit around here somewhere that works pretty well for a P/N totem pole, but it is somewhat sensitive to the supply voltage, and has a fairly high parts count
[01:55:37] <jmk2> 2111 and friends are designed for N/N totem poles
[01:55:43] <The_Ball> oh, only IRF540N's if going with 2111
[01:55:52] <jmk2> it bootstraps the high side fet above the supply
[01:56:10] <jmk2> only hitch is that it can't do 100% high duty cycle, the bootstrap will eventually discharge
[01:56:23] <jmk2> set your max duty cycle to 98% or so and it works fine
[01:56:37] <feoc2> jmk2 what are you using as steppers from a mesa ?
[01:56:45] <The_Ball> i see, i thought when open the FET's draw very little current?
[01:56:57] <feoc2> why dont you just use a par port or some other device everyone else is
[01:57:00] <jmk2> gecko 202s and 900oz-in NEMA 34's from Kelinginc
[01:57:17] <feoc2> ah ic
[01:57:22] <feoc2> i wanna use gecko 340's
[01:57:31] <jmk2> feoc: I want higher step rates, and I have other stuff I want to run
[01:57:37] <feoc2> k
[01:58:00] <feoc2> my options is gecko's or pico pwms
[01:58:13] <feoc2> but iv been told the pwms would be more work
[01:58:30] <jmk2> if you haven't spend the money yet, PWMs would give you true closed loop, not pseudo-CL
[01:58:44] <feoc2> not spent the money yet
[01:58:50] <cradek> step-servos are silly if you have emc
[01:59:05] <feoc2> i just want somthing thats gonna work now
[01:59:21] <feoc2> spent so much time trying to get my servo setup to work to find my servo driver is just fucked
[01:59:31] <jmk2> The_Ball: FETs draw zero DC gate current, but they have non-trivial gate-source and gate-drain capacitance
[01:59:39] <jmk2> that C needs to be charged/discharged when switching
[01:59:55] <feoc2> so dont want to waste any more money
[01:59:56] <jmk2> see your fet data sheet for the values
[02:00:22] <feoc2> if pico pwm's will work with mesa and emc then ill be happy
[02:00:37] <jmk2> pico PWMs work with the pico UPC board
[02:00:44] <feoc2> if they wont they geckos might be an option
[02:01:03] <feoc2> guess my mesa was a waste of cash then
[02:01:11] <jmk2> pico PWMs might work with PWM out of the mesa
[02:01:26] <jmk2> I thought you said you hadn't spent the money yet?
[02:01:37] <feoc2> only on mesas
[02:01:57] <feoc2> all was going well
[02:02:03] <feoc2> but it just wont hold tune
[02:02:05] <jmk2> so you have a 5i20, and you have some servo amps, but the amps don't work?
[02:02:10] <feoc2> the servo driver just seems to do its own thing
[02:02:18] <feoc2> yah
[02:02:35] <jmk2> old analog ones, with pots for tuning, or what?
[02:02:38] <feoc2> yes
[02:02:51] <feoc2> a burny servomate
[02:03:02] <jmk2> unfortunately that doesn't mean anything to me
[02:03:09] <feoc2> k np
[02:03:18] <feoc2> ya basicly i get it setup and running spot on
[02:03:31] <feoc2> next day i power up again and its doing somthing else
[02:03:46] <jmk2> how electronically inclined are you?
[02:03:59] <feoc2> 2
[02:04:23] <jmk2> older amps are more likely to be servicable than new ones - maybe you can replace some old leaky caps or something and bring them back
[02:04:38] <feoc2> i figured it be somthing like the caps
[02:04:51] <feoc2> what caps are likley to have lost it ?
[02:04:53] <jmk2> new ones with ASICs and surface mount crap are basically "no user servicable parts inside"
[02:05:00] <jmk2> electrolytics
[02:05:12] <jmk2> could also be dirty pots
[02:05:12] <feoc2> all of em ?
[02:05:28] <feoc2> hmm
[02:05:30] <jmk2> again, I know nothing about the amps, so this is total speculation
[02:05:35] <feoc2> tbh i might just donate em
[02:05:53] <feoc2> cant be fucked with it just want my mill working now
[02:06:45] <jmk2> how much I/O do you need (besides the motors)?
[02:06:54] <feoc2> a fair bit
[02:06:57] <jmk2> spindle stuff? limits? homes? toolchanger?
[02:07:04] <feoc2> all the above
[02:07:11] <jmk2> if its a lot, then the mesa is a better bet than the UPC
[02:07:16] <feoc2> yah
[02:07:23] <feoc2> well i know ill need the ios
[02:07:55] <jmk2> I think Jon Elson has tried the PWM from the Mesa on his PWM amps, but I can't speak for him - for all I know he only supports it if you use his PWM generator
[02:08:14] <jmk2> but if he supports his amps with the mesa, that beats the heck out of step/dir
[02:08:22] <feoc2> ok
[02:08:26] <feoc2> ill give him an email
[02:08:53] <feoc2> if im able to run the motors via the pwm gen of his and all the tool changer stuff via the mesa
[02:09:00] <feoc2> its not a total loss
[02:10:45] <feoc2> right gone past 3am
[02:10:50] <feoc2> best go sleep
[02:10:56] <feoc2> thanks as always
[02:10:57] <feoc2> gnight
[02:11:16] <jmk2> night
[02:22:59] <jmk2> woot! the encoder works
[02:23:35] <jmk2> strange one - in addition to A, B, and index, it has three outputs that toggle four times per rev (high twice low twice)
[02:23:40] <jmk2> bet they're for AC servo commutation
[02:24:39] <tomp2> this usb dac/adc/dio/ctr/timer says it works with kernel2.6 and has drivers. could it work with hal? its cheap but i havent read about speed yet. http://www.labjack.com/labjack_u3.php?prodId=25
[02:24:55] <tomp2> oh, it's usb too
[02:25:23] <jmk2> no usb device will give realtime performance untill someone writes a realtime USB driver
[02:27:45] <tomp2> right, not realtime, i dont need realtime, like btn presses are not realtime, i need to know a voltage a bti faster than i can use a voltmeter, i need to set a voltage no faster than i can turn a knob.
[02:28:45] <jmk2> if you can access the board from a user space program, you can make it accessible to HAL
[02:29:01] <tomp2> great thanks
[02:29:13] <tomp2> for 99$ i can try
[02:29:24] <jmk2> you'll have to write some C to do that, but userspace HAL comps aren't hard
[02:29:39] <jmk2> if you can printf the ADC reading, you can make it appear on a HAL pin
[02:30:02] <tomp2> any suggested source code to look at?
[02:30:23] <jmk2> hmm, there aren't any simple user space HAL comps I don't think
[02:30:40] <jmk2> iocontrol and halui are complex user space hal comps
[02:31:21] <jmk2> they both speak NML, for example, and there are huge chunks of grotty stuff related to that which you;d need to chop out
[02:31:33] <jmk2> it only takes a few lines to invoke hal_init and export a few hal pins
[02:33:00] <tomp2> ok, i look at the basics onside iocontrol/halui.c maybe you can point me to some explanation of user space/whateveritscompliment is? ( is it user space/realtime ?)
[02:33:14] <jmk2> user space vs realtime
[02:33:23] <jmk2> most hal comps are realtime
[02:33:23] <tomp2> good guess :)
[02:33:53] <tomp2> ok, thanks
[02:34:53] <jepler> it's not in "C" but 'pydoc hal' shows an example in Python .. it gives the general idea of what a userspace component must do: create pins, then from time to time drive or read the pins
[02:35:33] <jmk2> duh, I forgot all about several user space comps
[02:35:41] <jmk2> pyvcp, and the original halvcp
[02:36:56] <tomp2> oh, cool
[02:36:57] <jepler> hal_joystic, hal_input ..
[02:37:08] <jmk2> yeah
[02:38:29] <jmk2> oh, nice - I asserted m5i20.0.enc-01-reset-count, and it didn't reset, but it does refuse to count anymore
[02:38:36] <jmk2> even after I deasserted it
[02:38:45] <jepler> yuck
[02:38:58] <jepler> and I was just telling somebody the 5i20 was essentially bugfree
[02:39:26] <jmk2> I just announced on the list that its not
[02:39:45] <jmk2> normal counting works fine, but reset and index are broked
[02:39:47] <jepler> sigh
[02:40:25] <jmk2> I'm looking at the 2.1.6 version right now, which doesn't even come close to the canonical interface
[02:40:30] <jmk2> it has the petev interface
[02:41:03] <jepler> so maybe the same problem as motenc?
[02:41:20] <jepler> though a reset problem doesn't sound familiar...
[02:41:23] <jmk2> that would be quite a coincidecne I think
[02:44:08] <jmk2> msgfmt: po/fr_axis.po: warning: Charset "" is not a portable encoding name.
[02:44:09] <jmk2> Message conversion to user's charset might not work.
[02:44:23] <jmk2> minor problem with the new french translation?
[02:45:05] <jepler> beats me -- I just check in the files the translators send me :-P
[02:45:33] <jmk2> beat you?
[02:45:38] <jmk2> * jmk2 reaches for the trout
[02:45:42] <jepler> to be a bit more serious I know the fix and should go fix it
[02:45:53] <jmk2> * jmk2 puts away the trout
[02:46:00] <jepler> except I first have to figure out what charset the translator e-mailed the file to me in :-P
[02:46:16] <jmk2> here, let me lend you a trout for the translator
[02:46:16] <jepler> you were building TRUNK?
[02:46:22] <jmk2> 2.1
[02:46:23] <jepler> OK
[02:46:34] <jmk2> I bet trunk has the same thing tho
[02:47:54] <CIA-8> 03jepler 07v2_1_branch * 10emc2/src/po/fr_axis.po: specify character encoding
[02:48:14] <CIA-8> 03jepler 07TRUNK * 10emc2/src/po/fr_axis.po: specify character encoding
[02:49:07] <cradek> jepler: did you put the motenc index fix we gave to jack on the branch?
[02:50:10] <jepler> cradek: yes I think so
[02:50:12] <jepler> let me check
[02:50:30] <jepler> Working file: hal_motenc.c
[02:50:36] <jepler> revision 1.19.4.1
[02:50:36] <jepler> date: 2006/12/14 19:31:48; author: jepler; state: Exp; lines: +62 -48
[02:50:36] <jepler> merge rev 1.20: including the index-enable HAL pin
[02:52:27] <tomp2> ah, hal_joystick's #define MAX_AXIS = 6 is why my 8 axis usb joypad shows as 6... no further debugging required ( its not really an axis, just an analog input )
[02:59:00] <tomp2> thanks, g'nite
[03:02:17] <jmk2> /home/jmkasunich/emcdev/emc2head/src/objects/hal/components/updown.c:116:1: warning: "max" redefined
[03:03:34] <jmk2> seems that include/linux/kernel.h defines "max"
[03:03:44] <jmk2> not very nice of them
[03:13:37] <skunkworks> Night guys.
[03:13:52] <skunkworks> good luck on the index issue
[03:41:55] <toastydeath> so
[03:42:02] <toastydeath> should i buy a toolbox
[03:42:04] <toastydeath> for 500
[03:42:08] <toastydeath> or 500 in dial indicators
[03:42:15] <toastydeath> i need both, i just don't know which one i need more
[03:53:18] <ds2> why not $250 in indicators and $250 in toolbox? ;)
[03:54:38] <toastydeath> because it's for my job, and the toolchests are 800-900 bucks
[03:54:41] <toastydeath> work pays for half
[03:57:04] <toastydeath> it's all stuff i need and will be buying, i just don't know in what order to buy it
[03:58:38] <JymmmmEMC> yo ho ho
[04:17:23] <Unit41> http://en.wikipedia.org/wiki/Gyroscope
[04:19:00] <toastydeath> do you have commentary
[04:19:08] <toastydeath> or just a wikilink you'd like to share
[04:35:45] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[04:55:01] <Usman> Hi there..
[04:55:31] <Usman> I want some guidance regarding rtai.
[05:01:59] <jmkasunich> what do you want to know
[05:03:41] <toastydeath> unladen flight, swallow, etc etc
[05:04:07] <ds2> american or european?
[05:05:40] <Usman> I am installing rtai on fedora core 5, I have compiled the kernel and rtai with no errors but when I try to check whether it is installed well using "./run" command it gives error message "insmod: error inserting /usr/realtime/modules/rtai_hal.ko' : -1 Operation not permitted
[05:05:57] <toastydeath> isn't that a root issue
[05:06:04] <jmkasunich> did you try using sudo or su?
[05:06:41] <jmkasunich> note that we are NOT rtai experts here, most of us use precompiled and prepatched kernels
[05:07:29] <Usman> from where i can get the rtai installation help?
[05:07:47] <jmkasunich> rtai mailing list?
[05:08:55] <jmkasunich> but before you do that, try your ./run as root: "sudo ./run" or "su -c ./run"
[05:22:21] <CIA-8> 03jmkasunich 07TRUNK * 10emc2/src/hal/drivers/hal_m5i20.c: fix encoder index
[06:24:24] <JymmmmEMC> anyone still alive?
[06:30:32] <toastydeath> ya
[06:30:41] <toastydeath> i am probably not who you are looking for though
[06:31:56] <JymmmmEMC> just seeing if anyoen was still up.
[06:32:07] <toastydeath> oh
[06:32:10] <toastydeath> then yes!
[06:32:12] <toastydeath> yes i am.
[06:32:19] <JymmmmEMC> heh
[07:01:21] <JymmmmEMC> no your not, quit lying
[07:17:50] <alex_joni> hey JymmmmEMC
[07:21:28] <JymmmmEMC> yo
[07:21:48] <alex_joni> was out of town yesterday
[07:21:53] <alex_joni> saw you were looking for me?
[07:22:19] <JymmmmEMC> Oh nah... I found what I was looking for.... spray can cnc videos
[07:23:55] <alex_joni> right
[07:24:02] <alex_joni> some .ch site iirc
[07:24:27] <JymmmmEMC> kejtor.ch
[07:24:30] <JymmmmEMC> hektor.ch
[07:24:50] <alex_joni> that's it
[07:26:11] <JymmmmEMC> !!!!! #4 IS ALIVE !!!!!
[07:26:18] <alex_joni> #4?
[07:26:33] <JymmmmEMC> stepper drive #4
[07:27:01] <JymmmmEMC> I'm bench testing them
[07:27:47] <JymmmmEMC> alex_joni: in self-test mode that is
[07:28:18] <alex_joni> them?
[07:28:33] <alex_joni> ahhh.. what kind of drivers?
[07:28:49] <JymmmmEMC> Parker OEM750 and OEM650
[07:29:00] <alex_joni> any good?
[07:29:44] <JymmmmEMC> So far the 3 OEM750's are all good. this oneOEM650 just tested good.
[07:31:19] <JymmmmEMC> alex_joni: did you mean good functioanlly, or quality?
[07:31:44] <alex_joni> both
[07:32:28] <JymmmmEMC> on failures in the self-test so far. As far as quality goes.... OEM750's have mid-band compensation, the OEM650's don't.
[07:32:35] <JymmmmEMC> s/on/no/
[07:34:13] <JymmmmEMC> alex_joni: other than that, they're feature rich. Can go up to 50,000 microstepping
[07:34:42] <alex_joni> nice
[07:35:52] <JymmmmEMC> alex_joni: http://www.parkermotion.com/products/Stepper_Drives_and_Motors__4003__30_32_80_567_29.html
[07:38:29] <JymmmmEMC> !!!!! #5 IS ALIVE !!!!!
[07:41:28] <alex_joni> how many did you get?
[07:43:06] <JymmmmEMC> 8
[07:50:14] <JymmmmEMC> !!!!! #6 IS ALIVE !!!!!
[08:00:35] <JymmmmEMC> !!!!! #7 IS ALIVE !!!!!
[08:02:31] <JymmmmEMC> alex_joni: you know anything about signal harnoics?
[08:02:37] <JymmmmEMC> harmonics
[08:03:57] <JymmmmEMC> Err waveform harmonics
[08:05:47] <alex_joni> JymmmmEMC: only a tiny bit.. most I forgot already
[08:06:28] <JymmmmEMC> alex_joni: Hmmm, yeah there are settings on these drives that set that. But I'm not sure what they are/represent.
[08:07:03] <alex_joni> I read on their site that you have different profiles on the current waveform
[08:07:23] <alex_joni> guess it's a trial & error to find the best one depending on the motor
[08:07:54] <alex_joni> * alex_joni is looking for a colour laser printer
[08:08:35] <JymmmmEMC> alex_joni: yeah, there's that setting too =)
[08:09:09] <alex_joni> JymmmmEMC: any idea about colour laser printers?
[08:09:11] <JymmmmEMC> well, there is a "default" setting too, but just was wondering what it really meant. I can call them tomorrow I suppose.
[08:09:25] <JymmmmEMC> alex_joni: which ones are you looking at?
[08:10:10] <alex_joni> lexmark C530dn
[08:10:27] <JymmmmEMC> avoif lexmark
[08:10:29] <alex_joni> HP LJ2700N
[08:10:30] <JymmmmEMC> avoid
[08:10:34] <alex_joni> how come?
[08:10:37] <JymmmmEMC> POS
[08:10:45] <alex_joni> ;-)
[08:10:50] <JymmmmEMC> and cartridges are $$$$$$$$$$$$$$$$$$$$$$
[08:11:24] <alex_joni> how about HP?
[08:11:33] <alex_joni> I had a couple (b/w) which work great
[08:13:42] <alex_joni> hmm.. think I like the LJ2605DN (duplex & network)
[08:14:23] <JymmmmEMC> Ok, HPLJ printers have a mode chip that you can install. What they do is will only print so many copies per cartridge. Getting the chip bypasses this
[08:14:51] <alex_joni> hmm.. I don't get that on my LJ1200
[08:15:05] <alex_joni> I usually print till it starts to screw the output..
[08:15:27] <alex_joni> how about Samsung?
[08:15:37] <JymmmmEMC> http://cgi.ebay.com/HP-Color-LaserJet-3700-Printer-Toners-Drum-Chips-lot_W0QQitemZ160128173925QQihZ006QQcategoryZ51282QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
[08:15:42] <alex_joni> I've never seen/used samsung printers before
[08:15:50] <JymmmmEMC> neither have I.
[08:16:00] <JymmmmEMC> mostly HP or textronics
[08:16:29] <alex_joni> http://reviews.cnet.com/laser-printers/samsung-clp-510n-color/4507-3159_7-31273285.html
[08:20:08] <JymmmmEMC> features look goods, BE SURE to check the cost and copies of cartidges.
[08:20:34] <JymmmmEMC> no matter what you get, because printers are cheap, it's the consumables that get expensive.
[08:21:06] <alex_joni> "The larger-size toner cartridge prices out affordably, especially for color: about 2 cents per page of black text and about 11 cents per page of color, including the belt and drum."
[08:21:16] <alex_joni> sounds good to me
[08:24:25] <JymmmmEMC> how much though $$$ ???
[08:28:11] <alex_joni> ~400$ for all toners
[08:28:22] <alex_joni> 5000 pages ofr CMY, and 7000 pages for K
[08:28:52] <alex_joni> http://www.supermediastore.com/samsung-clp510d7k-clp510d5c-clp510d5m-clp510d5y-toner-combo-oem.html
[08:31:46] <JymmmmEMC> seems a bit expensive, but I haven't looked in a while
[10:11:54] <hcseb> Hello all.
[10:11:59] <hcseb> hcseb is now known as sebjames
[10:13:03] <sebjames> I was wondering about shutdown procedures. When I shut down emc, I'd like to make sure that certain logic lines go into safe states
[10:13:19] <sebjames> Is there some hook that I can hang my shutdown stuff on?
[10:20:47] <alex_joni> sebjames: yeah, there is a thingie ;)
[10:20:50] <alex_joni> looking it up now
[10:21:08] <alex_joni> sebjames: basicly it's a shutdown hal file that can get executed
[10:23:07] <sebjames> That's what I need. I have a line into my machine called "controller on". If emc exits unexpectedly, this needs to go low, so that the machine shutdown down its electrical systems
[10:24:43] <alex_joni> [HAL] SHUTDOWN = foo.hal
[10:25:15] <sebjames> Thanks! That's not in the Integrators manual, I don't think
[10:25:28] <alex_joni> sebjames: I'm checking now to see if this is part of 2.1.6
[10:25:43] <sebjames> *nod*
[10:25:50] <sebjames> I'm on 2.1.5
[10:26:11] <sebjames> Got my machine moving really well now
[10:26:30] <alex_joni> nope, not yet
[10:26:36] <alex_joni> it will be part of 2.2.0
[10:26:58] <sebjames> Ok. I need to backport the change to my code then,#
[10:27:10] <alex_joni> sebjames: if you're confident with changing a single file, it's pretty easy
[10:27:15] <sebjames> Ok.
[10:27:24] <sebjames> I can manage that :)
[10:27:43] <alex_joni> http://cvs.linuxcnc.org/cvs/emc2/scripts/emc.in.diff?r1=1.75;r2=1.76
[10:27:49] <sebjames> Cheers!
[10:28:02] <alex_joni> 5 lines :P
[10:28:09] <alex_joni> but you need to find the script emc
[10:28:18] <alex_joni> I think it's installed in /usr/bin ?
[10:28:56] <alex_joni> yup, seems like it.. it's been too long since I worked on this stuff :(
[10:32:03] <sebjames> Yes, that'w where it was. Done that.
[10:32:40] <alex_joni> sebjames: you're a quickie :P
[10:32:55] <alex_joni> * alex_joni loves users like this
[10:33:07] <alex_joni> not having to explain why you need to use sudo to edit the file :P
[10:36:30] <sebjames> I've been using Linux exclusively since 1997
[10:37:01] <sebjames> Starting with data analysis and latex for my PhD
[10:37:22] <sebjames> Then on to embedded Linux for various projects
[10:37:40] <sebjames> See www.wmltd.co.uk for current products
[10:40:41] <alex_joni> cool, what platform for your thin clients?
[10:40:53] <alex_joni> nm.. found out
[10:41:07] <alex_joni> any parport on that?
[10:41:25] <alex_joni> or maybe DIO?
[10:41:40] <alex_joni> it would be a great emc2 machine.. preinstalled & all
[10:45:04] <sebjames> You can have a version with 2 serial and 1 parallel in a slightly larger box. Yes, It would be a neat box.
[10:45:27] <sebjames> Esp. as no moving parts, so great for industrial environments
[10:45:29] <alex_joni> $$ ?
[10:46:35] <sebjames> 179 ukp for GX thin client. 230 to 250 ish (can't quite remember exactly) for the LX box with serial and parallel. Those are 1 off prices
[10:47:08] <alex_joni> so about 4-500$ for a preinstalled emc2 machine?
[10:47:13] <sebjames> *nod*
[10:47:25] <alex_joni> that might be attractive to people ;)
[10:47:30] <sebjames> You're right
[10:48:18] <sebjames> I might do an EMC build of FoundryLinux for those boxes. Does parallel port and serials give enough I/O to run a 4 axis mill?
[10:48:39] <alex_joni> if you're doing steppers, yes
[10:48:48] <sebjames> Or perhaps there is an off the shelf component to do the axis driving (with steppers)
[10:49:05] <alex_joni> there would be the USC from JonE
[10:49:29] <alex_joni> http://jelinux.pico-systems.com/univstep.html
[10:50:10] <alex_joni> 250$ though.. but works great (I heard)
[10:52:06] <alex_joni> probably a bit less for resellers..
[10:52:17] <sebjames> *nod*
[10:52:23] <sebjames> Could be a nice bundle
[10:58:27] <The-Ball> when using manualtoolchange.hal, how can I touch off Z in the middle of a program?
[10:59:21] <alex_joni> The-Ball: you need to stop the program, and then touch-off, then select the line where you stopped and select run from line, then run the program again
[11:01:46] <The-Ball> is "run from line" in the axis gui?
[11:01:56] <alex_joni> yeah, in the menu somewhere
[11:02:09] <alex_joni> set run line, or something like that
[11:02:14] <alex_joni> * alex_joni forgets the exact name
[11:02:52] <The-Ball> ah, set next line, cheers for that
[11:03:31] <alex_joni> np
[11:07:36] <anonimasu> morning
[11:08:22] <sebjames> Hi anonimasu
[11:08:41] <sebjames> Now, can I set a hal parameter inside a hal component, which I'm creating using "comp"
[11:09:25] <alex_joni> sebjames: don't think so
[11:09:40] <alex_joni> is the param in the same component?
[11:09:53] <sebjames> No, it's a parameter in another component
[11:10:00] <alex_joni> nope, you can't
[11:10:13] <sebjames> I need to set the input_scale parameter while the program is in progress
[11:10:36] <alex_joni> input_scale ?
[11:10:42] <sebjames> This is because I need to switch encoders from an input-feed X position encoder to an output-feed X position encoder.
[11:10:58] <sebjames> And the encoders generate different numbers of counts per mm travel :(
[11:10:59] <alex_joni> I think you need a NML message for that.. it goes through task, motion controller
[11:11:10] <sebjames> Ok.
[11:11:16] <alex_joni> why not scale the result?
[11:11:25] <alex_joni> have 2 encoder counters
[11:11:32] <alex_joni> how do you count this stuff?
[11:12:20] <sebjames> Two Heidenhain ROD encoders through two Heidenhain EXE600 boxes, into a PCB which switches between the outputs of the EXE, and feeds the count into a 7i33/5i20
[11:12:40] <alex_joni> can't you use 2 encoder counters in the 5i20 ?
[11:12:59] <sebjames> No, I already use all the I/O on the 5i20
[11:13:07] <alex_joni> I see..
[11:13:27] <sebjames> This machine is specifically designed to switch between the encoders.
[11:13:52] <sebjames> SO I really need to have a way to switch the input_scale parameter when I switch between in-feed and out-feed encoders.
[11:18:27] <sebjames> I just need to call the hal command 'setp m5i20.0.enc-00-scale X' from inside a HAL component.
[11:19:20] <alex_joni> how about connecting the output from the encoder counter to a scale block?
[11:19:36] <sebjames> Good idea
[11:19:57] <sebjames> That way my scale is a pin, which I can work with.
[11:20:06] <sebjames> I'll do that after some lunch.
[11:31:44] <The-Ball> I'm cutting my first circuit board, should i cut into the glass fiber? or just slightly through the copper?
[11:33:07] <cradek> I cut .004-.005 deep, which is barely through the copper
[11:33:19] <cradek> you can always make a second pass deeper if you need to
[11:33:26] <The-Ball> do you get any dust?
[11:33:38] <cradek> yes
[11:34:17] <The-Ball> enough to cover the board so you do not see the tracks after a while?
[11:35:15] <cradek> yeah, maybe that much
[11:35:39] <cradek> but if there's a ton of it, I might try less deep
[11:36:08] <The-Ball> ok, the first one i did did not generate noticible dust, but im going deeper this time. looks good
[11:38:03] <sebjames> can emc take gerber files as input?
[11:45:24] <cradek> not directly, but I heard gcam can translate them
[11:58:55] <alex_joni> sebjames: simply use 2 scaler blocks selected by a mux (which is controlled by a pin from your comp)
[12:03:18] <anonimasu> ^_^
[12:11:40] <maddash> well, i've finally finished debugging my debounce problem
[12:12:31] <maddash> here's my question: is debounce supposed to break down miserably (ie, the *.in and *.out pins do not changes state) ...
[12:13:10] <anonimasu> break down?
[12:13:24] <anonimasu> usually debouce is just a delay that waits for the pin to stabilize and then re-check the reading
[12:13:24] <sebjames> cradek: Neat. I like the idea of machining prototype boards
[12:13:37] <maddash> ... if you connect a parport pin - that has already been linked to a debounce filter - to a second signal and subsequently read from that second signal?
[12:14:10] <sebjames> alex_joni: Got my input scale switching fixed now.
[12:14:29] <anonimasu> Im not a hal expert.. but I guess the input pin should switch and the output should switch after the input has been debounced..
[12:14:30] <maddash> ^^ aheh concatenate the two messages into a single query
[12:14:48] <maddash> anonimasu: that's what I thought as well, which is my reason for calling this a "bug"
[12:15:48] <alex_joni> maddash: when you reconnect the pin to another signal it gets disconnected from the first
[12:15:57] <alex_joni> halcmd show sig
[12:16:10] <alex_joni> that will show you all signals and which one is connected where
[12:16:39] <alex_joni> basicly what you did, disconnected the pin from the debounce.. which obviously won't work anymore
[12:16:54] <maddash> alex_joni: i executed 'halcmd show pin' , and it showed that the parport pin was connected to both debounce and my signal...
[12:16:59] <sebjames> Opps, no that isn't it yet.
[12:17:29] <maddash> alex_joni: or maybe 'show pin' isn't a superset of 'show sig' as I thought?
[12:17:43] <alex_joni> it's not
[12:17:46] <alex_joni> halcmd show is a superset
[12:19:03] <maddash> so any time I link{sp/ps} after a linkpp, I disconnect the earlier command?
[12:19:30] <maddash> or does this also apply to previous link{sp/ps} as well (in addition to linkpp's)
[12:22:05] <maddash> alex_joni: ^^
[12:26:53] <sebjames> alex_joni: INPUT_SCALE is written to m5i20.0.enc-00-scale using the motenc driver
[12:27:16] <sebjames> So I can just update that pin. However, I think I still have position jumping to content with.
[12:28:38] <cradek> as everyone else has already said, you can't disconnect one encoder and connect another one without losing position
[12:29:00] <cradek> even if the original control did that, it's not a good design
[12:29:55] <skunkworks> The original controll probably did it because it could not count fast enough - high count for slow speed - low count for high speed. My though anyways
[12:31:28] <skunkworks> mornging
[12:31:31] <skunkworks> morning
[12:31:43] <cradek> hi skunks
[12:31:53] <sebjames> You can switch encoders on this thing, and you're right about losing position. I have to cope with that. The material is clamped at both encoder locations, so it doesn't move while you switch encoders
[12:32:35] <sebjames> Actually, m5i20.0.enc-00-scale is a parameter not a pin :( But I have my scaling block, which does the business.
[12:33:35] <skunkworks> cradek: I want to add mass to the servo and try tuning again.. I cannot get better than .0005 following error and I can't get rid of a oscolation at that error while moving. (would work though :))
[12:34:00] <jepler> skunkworks: "oscillation"
[12:34:16] <skunkworks> :) Thanks jepler.
[12:35:43] <cradek> skunkworks: not sure I understand - you added the mass already but now the tuning is bad?
[12:36:40] <cradek> bbl
[12:36:52] <skunkworks> no masss yet
[12:41:17] <alex_joni> masss might be too much for it?
[12:41:45] <skunkworks> mas?
[12:41:48] <skunkworks> ;)
[12:42:02] <SWPadnos> una mas mass, por favor
[12:43:12] <alex_joni> Did you mean: una mas mas, por favor
[12:43:23] <alex_joni> that's what google said
[12:45:32] <maddash> ahaha.
[12:45:52] <SWPadnos> no, I wanted another mass
[12:45:57] <SWPadnos> please
[12:46:19] <maddash> fpga4fun is making a fpga motmod board. :(
[12:47:25] <jepler> * jepler was playing with debounce: http://emergent.unpy.net/files/sandbox/debounce.png http://emergent.unpy.net/files/sandbox/debounce.hal
[12:47:58] <jepler> take a sine wave, feed it to pwmgen. You get a low time, followed by some rapid transitions, followed by some high time. debounce gives you a phase-shifted square wave.
[12:48:31] <maddash> haha.
[12:48:55] <SWPadnos> what was the debounce count set to?
[12:49:25] <jepler> maddash: the "link a pin to one signal and then another" is a behavior that has frequently bitten people on the ass. in emc 2.2 it will be signaled as an error, but we are reluctant to change it in 2.1 just in case someone has hal files with this mistake, but which manage to work anyway.
[12:49:58] <jepler> maddash: I am not opposed to revisiting that decision
[12:51:08] <jepler> in 2.2 the error you get will look something like this:
[12:51:08] <jepler> halcmd: linkps siggen.0.sine a
[12:51:08] <jepler> halcmd: linkps siggen.0.sine b
[12:51:08] <jepler> HAL: ERROR: pin 'siggen.0.sine' is linked to 'a', cannot link to 'b'
[12:51:08] <jepler> HAL:6: link failed
[12:51:24] <maddash> jepler: "manage to work anyway"? there's a possibility that the re-link{ps/sp} would not break the previous linkpp?
[12:51:40] <jepler> maddash: no, there's a possibility that the user didn't actually need that link anyway
[12:52:05] <jepler> some users operate by not understanding the full .hal file, but instead just adding lines at the bottom
[12:52:35] <jepler> e.g., to change the pinout write 'linkps Xstep => parport.0.mumble' at the end and do not delete any earlier lines about parport.0.mumble
[12:53:23] <maddash> why not modify hal to permit multiple linkages?
[12:55:43] <maddash> jepler: ^^
[12:57:32] <jepler> in hal, if you want pin A to drive a value onto pin B and pin C, you link A, B and C to one signal. That's simply the way it's implemented.
[12:57:43] <SWPadnos> what happens when you have two nets (each with its own writer), and you try to connect a single pin to both?
[12:58:01] <maddash> SWPadnos: the earlier net disconnects
[12:58:08] <SWPadnos> HAL can't know which writer you want to keep
[12:58:16] <SWPadnos> ah, well that's the present behavior
[12:58:21] <alex_joni> SWPadnos: using OC chips?
[12:58:29] <SWPadnos> alex_joni, shhh!
[12:58:33] <jepler> alex_joni: OC stands for "overclock" right?
[12:58:39] <maddash> orange county chips?
[12:58:40] <jepler> (joking)
[12:58:41] <alex_joni> jepler: close enough :D
[12:58:49] <alex_joni> * alex_joni shhh!'s
[12:59:02] <SWPadnos> currently, a link explicitly unlinks the pin then links it to the new signal
[12:59:10] <jepler> SWPadnos: I think you mean "implicitly"
[12:59:18] <maddash> huh? am I supposed to /part because of the classified info being tossed around?
[12:59:21] <SWPadnos> I explicitly mean implicitly
[12:59:25] <SWPadnos> or something :)
[12:59:47] <SWPadnos> I think we discussed adding a "relink" command that would have the current link behavior
[12:59:50] <alex_joni> maddash: no, we have another channel for that :)
[13:00:02] <SWPadnos> no, we'll kill you later
[13:00:12] <maddash> jepler: then what if I want to link parport.0.pin-10 to both axis.0.home-sw and axis.0.lim-neg?
[13:00:43] <jepler> maddash: "if you want pin A to drive a value onto pin B and pin C, you link A, B, and C to one signal".
[13:00:50] <maddash> jepler: technically, it wouldn't be right to call the signal "Xhome" or "Xneg"
[13:01:17] <SWPadnos> maddash, a pin can be connected to at most one signal, but a signal can connect to any number of pins (with some constraints)
[13:01:40] <maddash> jepler: I understand, but do you really want a signal called "Xhome" to link up with a pin named "axis.0.lim-neg"?
[13:01:49] <jepler> maddash: 'newsig name-which-makes-you-happy bit; linkps parport.0.pin-10 => name-which-makes-you-happy; linksp name-which-makes-you-happy => axis.0.home-sw; linksp name-which-makes-you-happy => axis.0.lim-neg'
[13:01:55] <SWPadnos> maddash, you should call that signal something like X_shared_neg_limit_and_home
[13:02:06] <maddash> isn't HAL supposed to be flexible?
[13:02:12] <SWPadnos> it is
[13:02:53] <SWPadnos> this has nothing to do with HALs flexibility, it's simply a change in default behavior of a command, due to apparent confusion caused for novice users
[13:02:54] <archivist> can it handle an external mux and latches for sgnals?
[13:03:34] <maddash> brb.
[13:03:46] <SWPadnos> you can still connect a pin to as many other pins as you like, the only difference is that it will no longer silently disconnect a pin from one signal when you connect it to another
[13:06:04] <maddash> w/e.
[13:08:27] <alex_joni> maddash: net name-which-makes-you-happy parport.0.pin-10 axis.0.home-sw axis.0.lim-neg
[13:08:54] <alex_joni> or like this to make it clearer: net name-which-makes-you-happy <= parport.0.pin-10 => axis.0.home-sw axis.0.lim-neg
[13:09:45] <maddash> alex_joni: "name-that-ends-up-too-fecking-long-in-order-to-become-appropriate" is a clear contradiction to describing HAL as "flexible"
[13:09:57] <SWPadnos> bullshit
[13:09:58] <alex_joni> then name it t1
[13:10:08] <alex_joni> * alex_joni will be back on monday
[13:10:14] <SWPadnos> you can have any name you want - *that's* flexibility
[13:10:14] <alex_joni> have a great weekend everyone
[13:10:22] <SWPadnos> see you Alex. have fun
[13:10:27] <maddash> it might be a small contradiction, but a contradiction nonetheless.
[13:10:41] <SWPadnos> you can have any name you want - how is that inflexible?
[13:10:55] <maddash> btw, i've written a "multishot" component. it does what oneshot does, except with variation of signal (as opposed to oneshot's singular "beep")
[13:11:16] <maddash> ^^ anyone interested?
[13:11:27] <SWPadnos> sure - is it a .comp or a .c file?
[13:11:32] <maddash> (anyone = {jepler, cradek, et al.})
[13:11:44] <maddash> C
[13:11:46] <SWPadnos> is it short enough to pastebin?
[13:11:56] <SWPadnos> oh, then it's probably a bit longer :)
[13:12:04] <maddash> pastebin has a cap?
[13:12:23] <SWPadnos> I don't think it'll hit their limit (if they have one)
[13:12:34] <SWPadnos> feel free to pastebin it
[13:12:42] <maddash> ok.
[13:15:01] <maddash> swpadnos: the code is in my home machine, and I can't ssh into it. i'll have to pastebin later on today.
[13:15:18] <SWPadnos> no problem, just let someone know the URL :)
[13:21:08] <sebjames> alex_joni: Bye, have a good weekend
[13:50:08] <cradek> jepler: I like your debounce test
[13:56:02] <jepler> cradek: thanks
[14:11:33] <sebjames> Does motion.feed-hold prevent any output to Axis motors?
[14:12:24] <jepler> that's the intent
[14:12:34] <cradek> I don't understand the question
[14:12:54] <jepler> while it is asserted, the motor-pos-cmd should not change
[14:12:56] <cradek> feed-hold causes the motion to stop
[14:13:13] <cradek> there is definitely output to the motors - whatever output is necessary to keep them in place
[14:13:51] <maddash> cradek: "output" probably denotes "step pulses"
[14:14:06] <cradek> maddash: yes, I agree that's one guess
[14:14:40] <cradek> actually the answer isn't right then either, since asserting feedhold causes a controlled deceleration to stop, so pulses go on for some time after it's asserted
[14:15:07] <anonimasu> that
[14:15:15] <anonimasu> that's actually a sane way :)
[14:15:24] <jepler> likewise, spindle-synchronized moves are not halted by motion.feed-hold
[14:17:01] <cradek> true
[14:17:56] <cradek> so I'm back to saying the question isn't specific enough to answer correctly :-)
[14:19:44] <maddash> jepler: so I read that you played with an altera fpga board. what kind of tool-chain did you use?
[14:21:33] <jepler> maddash: I used the free version of quartus ii running on a windows xp machine in vmware
[14:23:01] <jepler> "quartus ii web edition"
[14:23:26] <maddash> jepler: how's that working out? have you ever tried the licensed version?
[14:23:49] <SWPadnos> they're basically the same, except that the licensed version supports more chips
[14:24:04] <SWPadnos> also, I think you don't get all the NIOS stuff with the free version
[14:24:19] <jepler> maddash: it works OK
[14:25:14] <maddash> fpgas look fun, and i really want to get one to tinker with, but there doesn't seem to be any free linux toolchains
[14:25:35] <SWPadnos> the Xilinx free toolchain is available for Linux
[14:25:39] <jepler> maddash: I wish for a world where capital-F Free toolchains exist for FPGAs. There is a no-cost toolchain for xilinx that runs natively on linux, however.
[14:25:45] <maddash> not to mention that the knjn "Getting started with quartus" page is AWOL
[14:26:51] <jepler> this page loads for me: http://www.fpga4fun.com/QuartusQuickStart.html
[14:27:11] <maddash> eh? I read on fpga4fun that xilinx only hands out licensed linux tools http://www.fpga4fun.com/FPGAsoftware1.html
[14:27:59] <SWPadnos> that may have been the case at one point, but not any more
[14:29:42] <jepler> http://www.xilinx.com/ise/logic_design_prod/webpack.htm -- it says "Red Hat Enterprise Linux 3 and 4 WS (32-bit only)" but jmkasunich is running it on ubuntu 6.06.
[14:30:23] <jepler> "SE WebPACK is the industry?s only FREE, fully featured front-to-back FPGA design solution for both Windows and Linux." (well, maybe no-cost, but it's not Free)
[14:33:45] <maddash> are you hinting at its closed source?
[14:34:24] <cradek> * cradek grumbles under his breath at rms
[14:35:22] <skunkworks> roots means square?
[14:36:00] <skunkworks> root mean square
[14:36:07] <maddash> really mad scientist
[14:36:57] <sebjames> Thanks for the info on feed-hold guys
[14:37:15] <maddash> hm, the webpack only supports up to medium density fpgas
[14:40:50] <SWPadnos> I wouldn't worry about that. you probably don't want to spend enough to get a devkit with a high density FPGA
[14:44:49] <maddash> I should be able to link up multiple medium density fpgas to get one gigantic fpga, right?
[14:45:05] <SWPadnos> sort of, but the ISE tools won't help much there
[14:45:40] <SWPadnos> remember - "medium density" means things that are 2-3x the density of the Mesa card (which is 200k gates)
[14:45:52] <SWPadnos> high density these days is several million gates
[14:50:05] <jepler> building a PWM -> +-10V servo interface for use with emc, would you include a provision for offset in the converter (multi-turn pot or the like), or would you use the HAL offset instead?
[14:50:16] <sebjames> <-- Just bent his machine!
[14:50:26] <sebjames> <-- And managed to bend it back
[14:50:29] <jepler> ouch
[14:50:31] <cradek> wow
[14:50:36] <jepler> whatever you did, you probably shouldn't do it again
[14:50:36] <anonimasu> jepler: Yes
[14:50:54] <sebjames> Had the drill clamps down, and moved the material
[14:51:00] <SWPadnos> I'd put it in hardware, so the interface could be zeroed (such that HAL not running would result in no offset)
[14:51:01] <sebjames> One of the drill clamps bent
[14:51:23] <anonimasu> jepler: same reason as what swp said
[14:51:33] <sebjames> It's not that I wasn't going to put in a features to prevent that hapening, I just forgot the damn things were down
[14:51:41] <sebjames> While testing
[14:51:46] <jepler> SWPadnos: good point, though at that point the enables should be false
[14:51:54] <SWPadnos> should be ...
[14:52:06] <anonimasu> should and are is diff things :)
[14:52:14] <jepler> indeed
[14:52:28] <SWPadnos> also, you lose resolution and symmetry if there's an offset
[14:52:41] <SWPadnos> (or range, instead of resolution)
[14:52:46] <skunkworks> jepler: the circuit you posted yesterday was just for 0-5v?
[14:53:13] <maddash> sebjames: what part of your machine did you bend?
[14:53:42] <jepler> skunkworks: this? http://emergent.unpy.net/files/sandbox/pwm2analog.png no, the intent is up/down PWM to +-10V analog
[14:54:24] <skunkworks> I just saw single ended op amp. wondering how you where getting +/- 10v
[14:54:25] <jepler> of course it's completely untested and I'm hopeless at analog so it probably simply doesn't work
[14:54:46] <skunkworks> Jepler: never mind
[14:55:04] <jepler> the power isn't shown in that image -- it's assumed to be +-1xV, whatever is needed to get +-10V output depending on the exact op-amp chosen
[14:55:10] <skunkworks> I looked at it today and it makes more sense. :)
[14:55:31] <jepler> x3-1 and x3-3 are down and up
[14:56:53] <SWPadnos> you probably don't want that last stage to be inverting (unless you swap down and up)
[14:56:57] <skunkworks> jepler: thanks for doing this.. It was something I always thought I would be needing at some poing but never researched.
[14:57:10] <sebjames> maddash: There is a set of 3 drills, in a line. Inbetween the drills are 2 hydraulic clamps.
[14:57:19] <SWPadnos> (it looks inverting to me, but I'm mostly hopeless at analog, especially before sufficient caffeine)
[14:57:34] <sebjames> maddash: The clamps extend out and down and press against the steel plate material to hold it down while drilling.
[14:58:05] <jepler> SWPadnos: yes, I think it's in an inverting configuration. swap up and down at the inputs until your motors go the right way, then label x3-1 and x3-3 properly
[14:58:17] <SWPadnos> heh
[14:58:22] <sebjames> They're steel rods which extend out. About 7/8 inch diameter
[14:58:43] <jepler> so replace r3/r4 with a trimmer?
[14:58:50] <sebjames> If you move the material, the rods bend :(
[14:59:05] <SWPadnos> I'd add a trimmer to the R4 leg, I think
[14:59:19] <sebjames> If you then put another piece of material in with a lip welded on the end, you can tweak them back again ;)
[14:59:20] <anonimasu> will you release theese drives later?
[14:59:23] <SWPadnos> and you can get rid of the 1% spec at that point as well
[14:59:37] <anonimasu> im really interested in 0-10v drives
[14:59:43] <anonimasu> +/-10v
[15:00:01] <anonimasu> 1that dosent take a whole lot of skill to build :)
[15:00:09] <SWPadnos> use $some value for R3, and something like 0.9*$some_value for R4, plus a low value pot
[15:00:57] <SWPadnos> and if you do the same trick with R1, you can correct scaling and drop the 1% spec there
[15:02:13] <jepler> surely I only need one pot for the offset adjustment
[15:02:38] <a-l-p-h-a> SWPadnos, what's the word on the street about mesa + step/dir? :)
[15:02:48] <jepler> (without it, not even 1% would give decent performance -- unless I did the math wrong, assuming the difference in the input signals is 2V you end up with a 100mV offset in the +-10V output)
[15:03:22] <jepler> the operation becomes "trim pot until R1:R2 is the same as R3:(R4+pot)" and nothing is precision, right?
[15:03:52] <jepler> bbl, meeting
[15:04:18] <jepler> anonimasu: whatever I get I'll be putting online, but I don't actually have any +-10V drives to interface to which makes my interest largely academic
[15:04:39] <anonimasu> me neither yet
[15:05:13] <SWPadnos> a-l-p-h-a - jmk is still working on it. I think he has the FPGA part worked out, it's largely user config tools he's working on now
[15:05:19] <SWPadnos> but I'm not sure of all that
[15:06:37] <a-l-p-h-a> SWPadnos, thanks
[15:07:44] <archivist> jepler I would add an offset pot maybe to remove opamp offsets
[15:10:00] <The_Ball_> i can't seem to find support in pcb-gcode for milling the silk screen overlay. does anybody know if this would be possible?
[15:10:22] <The_Ball_> would be very handy for single sided board
[15:10:42] <cradek> you mean you'd mill it into the top side (the side without copper)?
[15:10:43] <skunkworks> ah - to mill the top side labels?
[15:10:57] <cradek> I agree that would be neat
[15:11:06] <The_Ball_> cradek, yeah, to show all the lables and component layout
[15:11:32] <The_Ball_> give the board a spray of black paint first ;)
[15:11:47] <cradek> neat idea
[15:11:58] <cradek> in eagle, you can get a vector font, so maybe it would be possible with that
[15:12:00] <SWPadnos> no - do the silk engraving first and do an ink inlay :)
[15:12:07] <skunkworks> The_Ball_: how is the pcb milling going?
[15:12:23] <SWPadnos> or just "engrave" it with a sharpie
[15:13:24] <The_Ball_> skunkworks, done now, went ok, next board will be a breeze, did a couple of stupid mistakes, but thrid time was the lucky one. only problem was that i had drilled the holes in the underlay for the previous tries so it was no longer flat... won't do that again
[15:15:45] <skunkworks> Pictures? ;)
[15:16:17] <The_Ball_> ok, hold on
[15:24:05] <The_Ball_> skunkworks, here ya go: http://wigen.net/workshop/cnc/IMG_0269.JPG http://wigen.net/workshop/cnc/IMG_0270.JPG
[15:25:47] <skunkworks> The_Ball_: very nice. what is the circuit?
[15:27:08] <skunkworks> looks like some sort of h-bridge.
[15:27:28] <The_Ball_> here's what yesterdays circuit ended as: http://wigen.net/pwm.png
[15:27:42] <The_Ball_> so the pluto will drive this
[15:28:16] <skunkworks> Nice. I saw a bit of the conversation you had with jmk.
[15:28:38] <The_Ball_> oh btw, the Q5[E,B,C] pads are so that I could play with the placement of the transistor feet to get a one layer board
[15:28:48] <feoc> ello
[15:29:22] <The_Ball_> skunkworks, q5,6,7,8 are all npn transistors sourcing to ground
[15:30:13] <skunkworks> understood
[15:31:00] <feoc> anyone know much about the gecko servo drives?
[15:31:02] <The_Ball_> i haven't looked at the pluto io lines yet, are they 3.3v out?
[15:31:28] <feoc> wondering if im going to need the step multiplier version
[15:31:49] <The_Ball_> feoc, depends on you encoders and the speed you want to obtain
[15:31:52] <skunkworks> The_Ball_: yes
[15:32:08] <skunkworks> I think everything is 3.3v
[15:32:37] <The_Ball_> skunkworks, i think that 3.3 is ok for the 74hc14 schmitt trigger but im not 100% sure
[15:33:11] <skunkworks> I don't know either... Although I would want some optical isolation in there... But that is just me :)
[15:34:45] <SWPadnos> feoc, if you're doing a 3-axis machine, then you should probably look into something like the mesa or pico systems cards instead of the gecko step multipliers
[15:35:04] <feoc> already have a mesa
[15:35:11] <SWPadnos> 3 axes of step multiplier is $100 or so, the FPGA-based step generator / encoder counter cards are $200
[15:35:21] <SWPadnos> ok, then you won't need a step multiplier
[15:35:38] <jepler> The_Ball_: I agree that would be a nice feature. I started adding it once but got bogged down -- you have to do a lot of "traversal" of the board structure to get to the strokes that make up the letters of each label of each package
[15:36:23] <jepler> The_Ball_: I also wasn't sure how I'd actually end up drawing the letters on -- for instance, sharpie rubs right off the fiberglass boards I usually use
[15:37:25] <anonimasu> ^_^
[15:37:35] <archivist> engrave writing and wipe a paint into the lines
[15:37:39] <anonimasu> yep
[15:39:34] <The_Ball_> jepler, why not use the same milling bit to engrave the letters?
[15:40:31] <anonimasu> why not?
[15:41:03] <jepler> I don't think the contrast would be good enough to see
[15:41:26] <cradek> maybe you could sharpie it afterward
[15:41:32] <cradek> once it's cut I bet it would soak up the ink
[15:41:55] <sebjames> Is there a variable for the realtime that I can access in a hal component?
[15:42:34] <sebjames> something like rtapi_get_realtime()?
[15:43:14] <jepler> sebjames: you mean to get "seconds since the unix epoch"? no, there is not
[15:44:52] <sebjames> jepler: No, I need nanoseconds from the real time counter. I need a delay between commanding my clamps down and starting to drill. Does rtapi_delay() block other components in a particular realtime thread?
[15:45:23] <sebjames> Oh - from rtapi.h: It is intended only for short
[15:45:23] <sebjames> delays, since it simply loops, wasting CPU cycles
[15:46:12] <SWPadnos> can you add a sensor to the clamps to see when they're engaged (air pressure switch maybe)?
[15:46:25] <anonimasu> sebjames: this is a classicladder thing
[15:46:27] <anonimasu> really
[15:46:31] <skunkworks> I would do that in ladder logic - but I am more comfortable with that. :)
[15:46:38] <anonimasu> it's what it's made for..
[15:46:51] <sebjames> I'm writing a drilling component. I have several inputs and outputs. When the component gets commanded to "drill" it needs to 1) clamp 2) wait a while 3) start to drill.
[15:47:00] <sebjames> I don't really want to learn about ladders
[15:47:27] <anonimasu> sebjames: well, it's easier to do it that way..
[15:47:49] <anonimasu> SWPadnos: yeah that'd work.. as you get a pressure increase when you've locked your piece down..
[15:47:54] <SWPadnos> you can probably use a timedelay block - the clamp command goes into the delay block, the output of the delay goes to a mux or something that keeps feedhold engaged
[15:48:11] <sebjames> anonimasu: I don't disagree with you, but it's quite neat having everything in components.
[15:48:30] <sebjames> SWPadnos: I can't retrofit a sensor to this machine. I have to work with what I have.
[15:48:31] <jepler> hum -- there's no manpage for timedelay
[15:48:37] <anonimasu> sebjames: well, imo you should use the right tool for a right work.
[15:48:38] <anonimasu> err job..
[15:48:44] <anonimasu> :)
[15:49:03] <SWPadnos> hmmm - I guess I should have written one :)
[15:49:07] <sebjames> let me look at timedelay.
[15:49:18] <sebjames> I'm going to need one of those to help with the torch component too.
[15:49:24] <SWPadnos> it may not work perfectly - I think it would delay the turn-off as well
[15:49:36] <anonimasu> sensors are always the safest bet..
[15:49:37] <anonimasu> :)
[15:49:50] <SWPadnos> you may need an AND block - if clamp and delayed_clamp, disable feedhold
[15:49:51] <anonimasu> timers/delays are the most insecure thing in the whole works..
[15:49:52] <anonimasu> world..
[15:50:10] <sebjames> anonimasu: Right about sensors, but Peddinghaus didn't see fit to put in a clamp down sensor.
[15:50:26] <anonimasu> but you arent paddinghaus.. if you want one fit one..
[15:50:27] <anonimasu> :)
[15:51:42] <anonimasu> should be a nice place close to the air valves.. to put them..
[15:51:55] <anonimasu> //end of rant
[15:51:59] <sebjames> Ok. when the clamps are going down, feehold will already have been set true, and a lock will have been placed on the Y axis. So.. to have a short delay before the clamps go down is acceptable. I though I might store the realtime counters in a data block, then when enough loops pass, I start the drills.
[15:52:28] <sebjames> I agree that delays are horrible, but I need one :(
[15:52:43] <sebjames> Back to rtapi.h...
[15:53:01] <anonimasu> depending on hardware to do stuff in a given time is pretty ugly at all times :)
[15:53:26] <anonimasu> * anonimasu chuckles
[15:54:05] <anonimasu> it's that damn real world that gets in the way ;)
[15:54:24] <anonimasu> gravity, and mass ;)
[15:55:17] <sebjames> And the fact that I bent these clamps already today, so they don't move quite as beautifully as they did this morning ;)
[15:55:38] <sebjames> rtapi_get_clocks() is my solution
[15:56:07] <sebjames> If it doesn't overflow too fast
[15:58:46] <SWPadnos> sebjames, you don't want to write a HAL component that busy-waits
[15:59:23] <SWPadnos> if all you want is a delay, then write one if there isn't one already (using comp, it would be ~3 lines of code)
[16:00:45] <jepler> in a realtime component, you know that 'period' nanoseconds pass between invocations
[16:01:31] <cradek> oneshot can be used as a delay
[16:01:34] <jepler> so you'd simply say 'time_left_ns -= period' and act if time_left_ns is <= 0
[16:05:29] <sebjames> I'm not writing a component that busy waits.
[16:05:53] <sebjames> jepler: Good suggestion
[16:06:06] <SWPadnos> ok. the rtapi_get_clocks() call isn't needed for the reason jepler pointed out. I made a bad assumption there :)
[16:11:27] <cradek> like oneshot, I think edge could be used as a delay
[16:11:31] <cradek> and maybe debounce
[16:15:03] <sebjames> Thanks for the help guys. Home time for me. Might get to actually make some plates on Monday!
[16:19:17] <jepler> added trimmer for offset: http://emergent.unpy.net/files/sandbox/pwm2analog2.png
[16:20:17] <jepler> ISTM that the offset trimmer R8 can correct for offsets due to variations in R as well as op-amp offsets, but perhaps my thinking is wrong
[16:21:44] <archivist> put back the R and a high val r to wiper of +- pot accross the rails with series r's
[16:22:08] <archivist> or use an opamp with offset pins
[16:25:26] <awallin> jepler: this is a PWM to analog converter?
[16:25:45] <jepler> awallin: yeah that's the idea
[16:26:39] <jepler> awallin: know of an existing design for this, so I can save my time?
[16:26:44] <awallin> you could probably have filtering on all three stages (unless you are using the interlaced pwm from the m5i20 which is very easy to filter)
[16:26:51] <awallin> jepler: nope, sorry.
[16:27:35] <awallin> dsPIC with a DAC ? ;)
[16:27:38] <jepler> awallin: the pluto also has an interlaced pwm option
[16:28:27] <awallin> ok, the interlaced pwm might look ok after only one RC stage.
[16:28:40] <awallin> it's a trade-off between ripple and bandwidth I guess
[16:30:19] <jepler> for interleaved PWM the time constant is probably a bit long -- it gives 4kHz bandwidth and was a value I saw in a circuit for 20kHz traditional PWM input
[16:32:25] <awallin> jepler: at work I've used an INA111 instrumentation amp when I need a differential amp. it has really high input impedance, so you could maybe get rid of the buffers you have there now ?
[16:32:59] <awallin> has anyone done a HAL spectrum analyzer and actually measured the whole system bandwidth for a typical mill/lathe ? 100Hz might be plenty?
[16:33:18] <jepler> FFT mode for halscope would be cool
[16:34:40] <jepler> awallin: I started with a quad op-amp in eagle so it was most natural to go ahead and use all of them
[16:34:47] <archivist> * archivist would cheat and use my HP
[16:35:12] <The_Ball_> jepler, shouldn't R8 be 2K to give you a null in center
[16:36:19] <jepler> The_Ball_: if everything's perfect then the null point would be about 400 ohms (4k3 + 400 = 4k7) wouldn't it? that's pretty close to the center of a 1k
[16:36:42] <The_Ball_> oh, didn't see it was a 4.3 not a 4.7
[16:38:02] <ds2> 9
[16:38:07] <The_Ball_> hehe, my reply did not make sense, you are right
[16:38:23] <archivist> thats a gain null but not dc offset null
[16:39:19] <archivist> is the gain important as its in a loop
[16:41:22] <The_Ball_> archivist, well you must reach 10V at 100% duty cycle or the motors will not be fully utilised
[16:42:16] <jepler> I guess I need to read horowitz and hill some more until it all sinks in
[16:42:43] <awallin> it looks ok, just test it. I bet it will work ok
[16:44:06] <archivist> probably loop would correct for opamp error
[16:44:43] <archivist> but gain error is not the same as opamp offset error
[16:46:11] <SWPadnos> jepler, I'd split R5 into either 2 or 3 resistors. using a single pot makes for very touchy adjustment
[16:46:30] <SWPadnos> (res - pot - res is ideal for adjustment precision)
[16:46:31] <jepler> my paper-scratching seemed to tell me that for perfect op-amps but imperfect R1..R4 I'd end up not getting 0V at pin 7 when the voltages on pins 1 and 14 were the same .. but by adding R8 I could adjust until R1:R2 == R3:(R4+R8)
[16:47:23] <jepler> so doesn't that make it a correction for opamp offset?
[16:48:15] <jepler> wow why do I have the feeling that I just said something so stupid it make the whole channel fall silent?
[16:48:20] <SWPadnos> heh
[16:48:54] <SWPadnos> I'm thinking - it takes me a while with this kind of circuit, or I get exact opposite results (vs. reality :) )
[16:50:42] <jepler> so about R5 -- I think that in practice I might want gain from 2 to 5 (output swings 10V but input swings might be as little as 2V or as high as 5V) .. so that should help me pick the ratio for the res-pot-res to replace R5
[16:51:49] <archivist> Im used to them a few years ago
[16:53:06] <archivist> off now see ya monday
[16:53:10] <jepler> see you archivist
[16:56:25] <SWPadnos> right (regarding R5) - it's hard to get the adjustment right, especially if you use a single-turn pot
[16:57:01] <SWPadnos> 2x to 5x range. hmmm
[16:57:23] <SWPadnos> I'd use different fixed resistors and keep the adjustment rage narrow
[16:58:48] <jepler> I don't know yet whether this is a board just for the pluto, or maybe for other systems with different output characteristics
[16:59:32] <jepler> if it's just for the pluto, the gain adjustment range could be much smalle
[16:59:33] <jepler> r
[16:59:50] <jepler> if it's for 5V logic too (e.g., somebody's AVR or PIC) then you end up wanting gain as low as 2x
[16:59:56] <jepler> bbl, lunchtime
[17:28:05] <skunkworks> Jymmm: did all the drives work?
[17:28:26] <Jymmm> skunkworks: In self-test mode.... yes
[17:29:44] <skunkworks> Cool
[17:30:17] <Jymmm> skunkworks: No, not yet...need to find heatsinks to be "cool" =)
[17:30:58] <Jymmm> skunkworks: what did you guys user for heatsinks?
[17:33:25] <Jymmm> skunkworks: what ya think? http://cgi.ebay.com/HEATSINK-ALUMINUM-EXTRUSION-12-BIG-AMP-MATERIAL_W0QQitemZ170122970910QQihZ007QQcategoryZ31489QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
[17:34:10] <skunkworks> That would work. We used whatever we had that was flat. I think some also came with the official ones.
[17:35:05] <Jymmm> skunkworks: I have some 1/4" al plate, think that might work good?
[17:35:46] <Jymmm> the auction isn't bad, he''ll even cut to size.
[17:35:52] <skunkworks> I would want fins on it..
[17:36:42] <Jymmm> I dont't know what "C/w" means though
[17:36:55] <skunkworks> :) http://www.electronicsam.com/images/KandT/servostart/mounting.JPG
[17:37:19] <skunkworks> probably Celcius per watt
[17:37:29] <Jymmm> Um, I think you're missing a few components =)
[17:37:35] <Jymmm> ah, gotcha
[17:37:36] <skunkworks> does it give a C/w rating?
[17:37:49] <Jymmm> in the desc
[17:37:55] <Jymmm> brb head
[17:38:06] <skunkworks> ah - I ment the oem750's
[17:47:35] <Jymmm> let me look
[17:47:57] <archivist> oo that job was easy back to play for a bit
[17:49:54] <skunkworks> they probably say you need their official heatsinks
[17:51:29] <Jymmm> actually, they say to measure heat at a specific location and that it should not exceed a certain temp
[17:51:45] <Jymmm> not exceed 55c
[17:52:36] <archivist> ambient temp + (watts dissipated * c per w)
[17:52:50] <Jymmm> skunkworks: In the manual... "Mounting without a heatsink"
[17:52:59] <archivist> should be less than max temp
[17:53:18] <skunkworks> do they give surface area then?
[17:53:26] <skunkworks> * skunkworks never really read the whole manual
[17:54:43] <Jymmm> they give minimal layouts if you are not using a heatsink, but also say to make sure temp doesn't go above 122F
[17:56:45] <Jymmm> skunkworks: on your heatsink, how are you goign to mount it?
[17:58:11] <anonimasu> hello
[17:58:49] <anonimasu> skunkworks: I like your drives
[17:59:05] <skunkworks> mount the actual heatsink?
[17:59:19] <skunkworks> anonimasu: the layout was jmkasunich
[17:59:33] <Jymmm> skunkworks: you just gonna toss it in a cabinet, or gonna bolt it to something?
[17:59:46] <skunkworks> Jymmm: have not gotten that far yet..
[17:59:51] <skunkworks> don't know
[18:00:11] <anonimasu> skunkworks: what input do they take?
[18:00:51] <archivist> you can dissipate 75 watts in 25 deg abient with 12" of that heatsink
[18:00:58] <skunkworks> The componants top at 200v right now. but I have not tested them that high. Hoping for somewhere between 100-150 or there abouts
[18:01:42] <archivist> or more with fan assistance
[18:04:38] <Jymmm> archivist: 75w per ???
[18:04:59] <archivist> continuous
[18:05:14] <archivist> no per anything
[18:05:52] <archivist> does the spec give a maximum dissipation
[18:05:57] <Jymmm> that doens't make sense to me.... what if you have 100W ?
[18:06:09] <archivist> then add a fan
[18:06:50] <archivist> or a longer heatsink
[18:06:59] <archivist> or deeper fins
[18:09:59] <archivist> any way whats the voltage and amps you will be running at and the quoted efficiency of the drive
[18:10:28] <Jymmm> Pg 38 http://www.parkermotion.com/manuals/OEM750/OEM750_Entire_Rev_B.pdf
[18:11:45] <Jymmm> their HS-1 has 1.5" fins, but not the 2/8" thick plate like the ebay one does, but I know that's for distribution, not disapation.
[18:11:51] <Jymmm> 3/8"
[18:13:06] <Jymmm> ebay has 3.9 fins per inch
[18:13:22] <Jymmm> at 1" tall
[18:13:49] <archivist> dont care about physical sises
[18:13:51] <Jymmm> parket hs-1 has 2.5 fins per inch @ 1.5" tall
[18:14:41] <ds2> you could try routing fins on the aluminum
[18:16:02] <Jymmm> archivist: If it wasn't clear thermodynamics is not my cup of tea.
[18:16:28] <ds2> it would help if you can make it black
[18:18:06] <skunkworks> anidizing maybe.. But painting it black is only going to add a nice layer of insulation.
[18:18:27] <Jymmm> archivist: I WILL have a nice fan in there, but if the heatsink could save the drive if the fan went out, that would be a good thing.
[18:18:54] <archivist> I hate pdfs they take so long to find info
[18:19:05] <Jymmm> skunkworks: Yeah, I would never use paint, shitloads of heatsink grease though =)
[18:19:27] <ds2> can you even get paint to stick to aluminum?
[18:21:12] <anonimasu> yes
[18:21:26] <anonimasu> ds2: with some prepwork..
[18:21:44] <maddash> why the feck does `make` output "make: Failed to remake makefile `Makefile'." ????? I'm so fucking pissed!
[18:21:57] <anonimasu> you make make break..
[18:22:03] <Jymmm> make clear; make; ?
[18:22:08] <ds2> I see.
[18:22:12] <cradek> maddash: instructions for troubleshooting that on the wiki
[18:22:20] <maddash> I cleaned the cache over 5 times! argh!
[18:22:35] <ds2> are you running as root?
[18:22:48] <maddash> only when I `make setuid`
[18:23:26] <ds2> wonder if you have somethings owned by root and it is failing to rewrite those
[18:23:52] <maddash> ds2: brb.
[18:23:54] <cradek> did you see what I said?
[18:24:08] <maddash> cradek: yes. which page is it? http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TroubleShooting has nothing
[18:24:41] <cradek> maddash: there is a search at the bottom: search for 'failed to remake'
[18:24:43] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?FailedToRemakeMakefile
[18:25:25] <Jymmm> heh
[18:26:04] <cradek> Jymmm: seriously, people often miss that there's a search box at the bottom
[18:26:19] <cradek> I think people expect to see it at the upper right
[18:26:31] <Jymmm> With heatsinks in general, is it better to have ONE LONG ONE or multiple shorter ones?
[18:26:55] <archivist> one long probably
[18:28:12] <Jymmm> cradek: Yeah, UI can be funky that way. Sun Microsystems did a study on UI once, They doubles the space between button on the top of the page and usage went up 500%. Originally Sun employees thought the button were just a decoration.
[18:29:35] <Jymmm> cradek: I've seen MANY websites when you are looking at multiple pages of products (as example), and their 'NEXT >' link is so small you miss it very easily.
[18:30:32] <Jymmm> Hell, the page footer is larger than the NEXT link much of the time.
[18:32:56] <Jymmm> cradek: Most photo gallery's bug the crap out of mr UI wise... Click on a thumbnail to see full size image, then you gotta click back, then NEXT to goto the next photo. So, I wrote a gallery where so there's not all that back and fourth navigation.
[18:33:34] <bill2or3> * bill2or3 too
[18:33:57] <bill2or3> I made the image a map, left side = prev, right side = next.
[18:34:29] <anonimasu> Jymmm: surface area is all that matters..
[18:34:35] <Jymmm> bill2or3: I found thatat doesn't work sometimes, as many don't realize that the img map is also navigation.
[18:34:46] <anonimasu> Jymmm: that's what contributes to heat disspassion
[18:34:45] <bill2or3> there are text links too.
[18:35:05] <Jymmm> bill2or3: ah, gotcha. That really helps.
[18:35:11] <bill2or3> scoot.net/gallery
[18:35:29] <bill2or3> complete with circa 1998 html styles
[18:35:41] <Jymmm> Though, I do like the JS variant that's out now, where the page is dimmed, and the full size iamge is overlayed on top.
[18:36:05] <archivist> Jymmm, fins vertical for best
[18:36:10] <Jymmm> I also made my gallery so clicking on full sized image take you back to the thumbnails.
[18:37:25] <Jymmm> archivist: Yeah, I don't think that's gotta happen though. If I use one full heatsink instead of multiple. Maybe I could mount vertically, but then the top-most drives would get the most heat build up.
[18:37:59] <archivist> side ways the air cant get in the fins
[18:38:14] <archivist> unless fan assisted
[18:38:24] <Jymmm> archivist: I was planning on mouting fans blowing directly down on the fins.
[18:38:46] <Jymmm> we'll see though. I need to sketch this out a bit.
[18:39:16] <Jymmm> The pricing on that ebay auction doesn't seem too shabby. especially with flat rate (whatever I can fit in the box" shipping.
[18:39:41] <Jymmm> and free cutting
[18:41:01] <anonimasu> yep
[18:42:09] <Jymmm> I just wish I had a spindle I could toss my tapping head and I'd machine a few.
[18:42:24] <archivist> seem ok stuff, pdf for the drive is sparse on max ratings
[18:42:26] <Jymmm> 8K rpm is a wee bit too fast
[18:43:12] <Jymmm> archivist: for heat disapation?
[18:43:19] <archivist> yes
[18:43:47] <Jymmm> I cna always call/email them. Or even drive in person they are on the other side of the bay.
[18:44:21] <archivist> all depends on how you use them
[18:46:52] <ds2> Jymmm: except for the contact area, more surface area is generally better
[19:12:18] <anonimasu> :)
[19:13:09] <anonimasu> how it's made on tv
[19:22:17] <archivist_livecd> * archivist_livecd starts exploring
[19:22:44] <skunkworks> archivist_livecd: Cool huh?
[19:22:46] <archivist> hello me
[19:23:08] <archivist> just playing
[19:23:52] <archivist_livecd> gotta find a pc for a permanent box and get a better kb map
[19:24:26] <archivist_livecd> cant stand the slowness of the cd
[19:27:28] <Jymmm> anonimasu: PING
[19:27:40] <anonimasu> Jymmm: PONG
[20:32:15] <skunkworks> http://www.cnczone.com/forums/showthread.php?t=6840&page=29
[20:32:21] <skunkworks> post 344 and on.
[20:49:35] <anonimasu> skunkworks: well, it's pretty good use on how to not do moldmaking
[20:50:06] <anonimasu> with a g64 P0.01 it'd be ripping ;)
[20:50:48] <lerneaen_hydra> why does it slow down when doing two axes at the same time?
[20:50:56] <anonimasu> it's in exact stop mode..
[20:51:01] <lerneaen_hydra> ah, ok
[20:51:09] <lerneaen_hydra> so it stops between each line?
[20:51:12] <anonimasu> yep
[20:51:43] <anonimasu> :D
[20:51:43] <lerneaen_hydra> ah, nasty
[20:51:45] <anonimasu> idiocy.
[20:51:55] <lerneaen_hydra> a g64 pxx would be much better indeed
[20:52:01] <anonimasu> that's like using 5% of your machine
[20:52:13] <lerneaen_hydra> well, Im sure there are uses for it, but this is *not* the correct place to use it
[20:52:14] <lerneaen_hydra> exactly
[20:52:55] <anonimasu> read that post at 8:10
[20:52:59] <anonimasu> Unread Today, 08:18 PM
[20:53:44] <lerneaen_hydra> err. which post is that?
[20:53:47] <lerneaen_hydra> which nr?
[20:53:51] <anonimasu> the one by mike f
[20:53:58] <anonimasu> Yes there is, well, sort of. In cv mode (constant velocity) you can set an angle at which, anything greater will be ignored and become exact stop.
[20:54:12] <lerneaen_hydra> you mean 10:18?
[20:54:18] <anonimasu> yeah
[20:54:29] <lerneaen_hydra> ah, oh, I see
[20:54:29] <anonimasu> * anonimasu chuckles
[20:54:45] <anonimasu> it'd be worth punching a 5-15 deg into it that feature
[20:55:00] <anonimasu> it's probably change between segments(atleast that's it on the heidenhain controls)
[20:55:11] <lerneaen_hydra> yeah
[20:55:11] <anonimasu> cant be much else
[20:55:15] <lerneaen_hydra> delta angle
[20:55:18] <anonimasu> yep
[20:56:14] <lerneaen_hydra> thats a rather sucky algorithm though
[20:56:24] <anonimasu> lerneaen_hydra: howcome?
[20:56:58] <lerneaen_hydra> what if delta angle is just above the set angle
[20:57:03] <lerneaen_hydra> its a binary threshold
[20:57:15] <lerneaen_hydra> whereas you want a smoothing-type algorithm
[20:57:23] <anonimasu> there's a contouring mode.. that does constant surface speed.. too
[20:58:07] <anonimasu> though not in mach ;)
[20:58:36] <anonimasu> lerneaen_hydra: I guess it's because if you are cutting a pocket you certainly dont want smoothing on the corners..
[20:59:32] <lerneaen_hydra> thats true
[20:59:38] <lerneaen_hydra> still, a Pxx would be better
[20:59:50] <anonimasu> hm, im not so sure.. that has downsides too
[21:00:05] <anonimasu> :)
[21:00:20] <anonimasu> still anything kills exact stop mode
[21:00:27] <lerneaen_hydra> heh, yeah
[21:01:27] <anonimasu> what have you been up to lately?
[21:01:55] <lerneaen_hydra> oh not so much, doing a retrofit on an opti bf20 at school
[21:02:05] <lerneaen_hydra> waiting for geckos at the moment
[21:02:19] <anonimasu> nice little mills
[21:02:23] <lerneaen_hydra> also making a cheap projector (lcd monitor + overhead display)
[21:02:33] <lerneaen_hydra> yeah, very cheap and good enough quality for me
[21:02:38] <lerneaen_hydra> got one yourself?
[21:02:43] <anonimasu> no
[21:02:55] <anonimasu> just from what I've heard :)
[21:03:19] <lerneaen_hydra> oh what have you heard?
[21:03:27] <anonimasu> heard/read
[21:03:30] <anonimasu> that they are nice
[21:04:02] <lerneaen_hydra> ah ok
[21:04:56] <anonimasu> I have a schaublin sv13 as a mill
[21:04:57] <anonimasu> :)
[21:05:05] <lerneaen_hydra> ah, size?
[21:05:13] <anonimasu> toolroom
[21:05:18] <anonimasu> actually I have 2
[21:05:25] <anonimasu> one cnc and one not
[21:05:43] <anonimasu> http://www.anglo-swiss-tools.co.uk/Resources/SV13.JPG
[21:06:13] <lerneaen_hydra> oh "standard" size
[21:06:23] <anonimasu> *hideyep
[21:06:25] <anonimasu> yep
[21:06:29] <anonimasu> it's small but heavy
[21:06:41] <lerneaen_hydra> 300-400kg?
[21:07:13] <anonimasu> 740kg..
[21:07:38] <anonimasu> :)
[21:08:02] <lerneaen_hydra> eek
[21:08:04] <lerneaen_hydra> nasty
[21:08:58] <anonimasu> perfect size ;)
[21:09:05] <anonimasu> though I'd like a bigger mill
[21:09:17] <anonimasu> much bigger then the mill at work.. ;)
[21:11:21] <anonimasu> * anonimasu is working on finding a nice lathe
[21:11:23] <anonimasu> err cnc lathe
[21:11:27] <anonimasu> for a good price
[21:12:01] <lerneaen_hydra> how big?
[21:12:09] <lerneaen_hydra> the same one you were talking about before?
[21:12:17] <anonimasu> the one on blocket?
[21:12:18] <anonimasu> yeah
[21:12:19] <lerneaen_hydra> 100mm dia parts?
[21:12:34] <anonimasu> yeah
[21:12:37] <anonimasu> or a bit bigger..
[21:14:23] <anonimasu> I saw some swedeturn on blocket
[21:14:39] <anonimasu> but it was just too big
[21:21:40] <lerneaen_hydra> jepler / cradek any of you there?
[21:21:49] <cradek> I am for a minute more
[21:22:19] <lerneaen_hydra> which way is the simplest to install emc sim on 6.06?
[21:22:36] <jepler> add to source list: deb http://www.linuxcnc.org/emc2/ dapper emc2.1-sim
[21:22:36] <jepler> deb-src http://www.linuxcnc.org/emc2/ dapper emc2.1-sim
[21:22:43] <jepler> enable universe
[21:22:46] <jepler> install emc2-sim package from synaptic
[21:22:57] <lerneaen_hydra> and the rest is automagic?
[21:22:58] <jepler> that is, add to /etc/sources.list
[21:23:12] <jepler> /etc/apt/sources.list
[21:23:20] <jepler> oh there's probably something I forgot :-P
[21:23:24] <lerneaen_hydra> sounds perfect
[21:23:31] <jepler> oh it'll warn you that you don't have the gpg key for our package manager
[21:23:41] <lerneaen_hydra> hopefully not too cryptic
[21:23:48] <lerneaen_hydra> oh unless I import it
[21:25:13] <jepler> gpg --keyserver pgpkeys.mit.edu --recv-key BC92B87F
[21:25:13] <jepler> gpg -a --export BC92B87F | sudo apt-key add -
[21:25:16] <jepler> ^^ this adds the necessary key
[21:27:41] <lerneaen_hydra> ah thanks
[21:31:37] <lerneaen_hydra> works perfectly :)
[21:35:10] <robin_sz> meep?
[21:53:56] <anonimasu> hey robin
[21:56:33] <robin_sz> dood
[22:22:29] <toastydeath> beeep
[22:22:52] <toastydeath> hey guys here is an important saftey reminder!
[22:23:05] <toastydeath> if you are drilling crap in a bridgeport, make sure it is safely fastened to the table in some way!
[22:23:19] <archivist> hehe
[22:23:20] <toastydeath> or you will rip the goddamn hell out of your hand when the part spins and a sharp corner buries itself in your thumb
[22:23:29] <cradek> did you make a spinning blade of death?
[22:23:40] <cradek> I've found that sheet metal and a drill press are very good for that
[22:23:42] <toastydeath> spinning blade of death right into my thumb, yes
[22:23:56] <toastydeath> except it was 3/4" plate
[22:24:00] <archivist> dont bleed on the bridgeport
[22:24:01] <cradek> yuck, hope you're ok
[22:24:02] <toastydeath> so not exactly quite so bladey
[22:24:10] <toastydeath> more "blunt object with spike"
[22:24:13] <toastydeath> "at 1000 rpm
[22:24:14] <toastydeath> "
[22:24:23] <toastydeath> i think i will be okay!
[22:24:28] <cradek> good
[22:24:37] <toastydeath> if it turns green, i will know the answer is: not okay!
[22:24:51] <lerneaen_hydra> random question: is it generally regarded as OK to drive geckos straight off the parport? or do they need too much power?
[22:25:09] <toastydeath> it probably needs stitches, but i insist my two band-aids are okay
[22:25:34] <cradek> lerneaen_hydra: geckos want 5v, and parports are often 3.3v
[22:26:05] <lerneaen_hydra> cradek: oh, so it's optocoupler + schmitt inverter after all
[22:26:07] <lerneaen_hydra> oh well
[22:26:08] <cradek> so sometimes, they don't work well, there are lots of boards to fix that, like the pmdx stuff
[22:26:34] <archivist> toastydeath, I had to use very tight sticky tape for a week once after a small slip with a knife
[22:27:01] <cradek> I sometimes use super glue (really)
[22:27:10] <toastydeath> i have a roll of medical tape around here somewhere
[22:27:16] <lerneaen_hydra> cradek: I take it some optocouplers and a schmitt inverter would do the trick?
[22:27:18] <toastydeath> i'm going to take it into work, as that's clearly where it will get the most use
[22:27:26] <toastydeath> i need that liquid suture crap
[22:27:27] <cradek> lerneaen_hydra: sure
[22:27:34] <toastydeath> TAKE THAT, INJURIES
[22:27:46] <toastydeath> i did clean the crap out of it
[22:27:50] <toastydeath> before i bandaged it up
[22:28:25] <archivist> I get more fun here from the boss milling his fingers etc
[22:28:31] <toastydeath> jesus christ
[22:29:09] <archivist> .8 module cycloidal index finger
[22:29:46] <toastydeath> what does that mean?
[22:29:47] <toastydeath> oh
[22:29:51] <anonimasu> toastydeath: hope you learnt that you always need to clamp stuff down
[22:29:53] <toastydeath> did he hob his hand?
[22:29:57] <anonimasu> and have your fingers left.
[22:30:03] <anonimasu> and still useable
[22:30:08] <toastydeath> well i thought it WAS clamped
[22:30:13] <toastydeath> or i would not have drilled into it
[22:30:17] <toastydeath> it was just not clamped well enough
[22:30:24] <anonimasu> lerneaen_hydra: it's ok
[22:30:26] <toastydeath> the vice apparently was less tight than i thought.
[22:30:30] <anonimasu> lerneaen_hydra: they are optocoupled
[22:30:37] <anonimasu> :/
[22:30:37] <archivist> toastydeath, no single slot cutter, a hob would have made a nice mess
[22:30:48] <toastydeath> epic gear maneuver
[22:30:55] <toastydeath> can you use his finger as a gauge now?
[22:31:00] <lerneaen_hydra> anonimasu: yes, I just have the optocouplers there so I can drive the invertets off the geckos power supply
[22:31:13] <anonimasu> lerneaen_hydra: no, the geckos have optocouplers already
[22:31:15] <anonimasu> internally
[22:31:49] <lerneaen_hydra> yes but I need to increase the voltage apparently, (and I don't really like pulling that much current off the parport)
[22:32:00] <anonimasu> you dont need that
[22:32:06] <anonimasu> for the geckos atleast..
[22:32:19] <lerneaen_hydra> anonimasu, cradek, fight! ;)
[22:32:37] <cradek> :-)
[22:32:46] <cradek> don't blame me, I only report the news
[22:33:38] <cradek> I think a pci card parport is more likely to be 5v
[22:33:46] <cradek> if it's 5v, hook it right up and don't worry
[22:34:16] <lerneaen_hydra> isn't the current draw around 15mA?
[22:34:34] <cradek> probably, since it's an opto
[22:35:05] <lerneaen_hydra> isn't that far more than the parport can source?
[22:35:23] <cradek> "These inputs are meant to be driven by standard TTL logic or other driver capable of sinking 16 mA of current."
[22:35:43] <cradek> lerneaen_hydra: I'm sure that depends on the parport
[22:35:49] <lerneaen_hydra> are parports regarded as being able to sink that much?
[22:35:49] <ds2> thought parallel ports are suppose to be TTL?
[22:35:49] <lerneaen_hydra> oh
[22:35:54] <cradek> often pins 2-9 have stronger drivers
[22:35:59] <ds2> in which case, 3.3V is prefectly fine TTL
[22:36:11] <lerneaen_hydra> pins 2-9 eh?
[22:36:16] <lerneaen_hydra> are they the data pins?
[22:37:06] <cradek> yes
[22:37:13] <lerneaen_hydra> ah ok
[22:37:27] <lerneaen_hydra> I guess it'll be best to test just directly to begin with
[22:40:15] <CIA-8> 03jepler 07TRUNK * 10emc2/src/po/ (fr_axis.po fr_rs274_err.po): updated translation from Francis TISSERANT
[22:42:01] <lerneaen_hydra> 'night
[22:50:38] <feoc> anyone have experience of the pico pwm amps and the mesa board?
[22:51:32] <feoc> guess i could just use the mesa ios for the toolchange stuff anyway
[22:51:38] <feoc> and get a pico pwm controller
[22:51:43] <feoc> keep things simple
[22:55:09] <toastydeath> can you have a second axis on top of another
[22:55:12] <toastydeath> in emc
[22:55:13] <toastydeath> ?
[22:55:17] <toastydeath> perhaps using the kinematics package?
[22:55:36] <toastydeath> like, two X axes on a lathe, stacked in the same spot?
[22:56:22] <jepler> toastydeath: sure, if you can define how it should work
[22:56:32] <ds2> like one X is the cross slide and the other X is the compound?
[22:56:49] <toastydeath> i'm thinking more fast tool servo
[22:56:53] <toastydeath> for eccentric turning machines
[22:56:55] <jepler> there's no reason you can't have 3 joints for 2 axes, but you have to write the software to understand how far to move each one when you issue "G0 X1"
[22:57:00] <toastydeath> where you have a traditional ballscrew X axis
[22:57:07] <toastydeath> but you have a fast tool servo sitting on top of that
[22:57:32] <toastydeath> so you can do C axis countouring at speed
[22:57:41] <jepler> for almost any position there is not just one solution
[22:57:50] <toastydeath> well it would be "use either or"
[22:57:52] <toastydeath> not both
[22:58:35] <toastydeath> the FTS usually has a limited stroke but can move lightning fast and handle the forces
[22:58:50] <toastydeath> and the ballscrew has a longer stroke/is more accurate
[22:59:40] <anonimasu> :)
[22:59:41] <toastydeath> so like, the lathe is set to whatever rpm, and the FTS just watches the encoder on the spindle, and follows a profile based on that
[22:59:47] <toastydeath> can you do that?
[22:59:58] <toastydeath> i don't actually want to build one of those, i'm just wondering
[23:00:07] <jepler> I'll have to change my earlier answer from "sure" to "I don't think I understand everything that is required"
[23:00:12] <anonimasu> toastydeath: yes, probably..
[23:00:23] <anonimasu> toastydeath: but, given the mass you need to move to do it it's not trivial.
[23:00:50] <toastydeath> well, that's not really the issue though
[23:01:00] <jepler> kinematics has the following knowledge: the last position of each joint and the desired new position of each axis. its output is the new position for each joint. This is done typically 100 times per second (the "traj cycle time")
[23:01:22] <jepler> so if the decision about which "X-like axis" to move involves looking at the gcode including into the future, kinematics is not built to do that
[23:01:30] <toastydeath> hmm
[23:01:30] <jepler> (or looking at whether it's a G0 or a G1 move, etc)
[23:02:05] <toastydeath> the FTL only moves two ways - a ramped linear move, and a constant linear move
[23:02:24] <anonimasu> toastydeath: Im not sure I get what you want and why you would want to do it..
[23:02:26] <toastydeath> trying to hit certain X coordinates at certain corresponding C coordinates
[23:02:36] <toastydeath> at 300-500 rpm
[23:02:55] <jepler> FTL and FTS are two different things?
[23:03:01] <toastydeath> er, fts
[23:03:01] <toastydeath> sorry
[23:03:10] <toastydeath> fast tool servo. my bad.
[23:03:19] <toastydeath> think of a cam
[23:03:27] <jepler> so FTS position is a function of the spindle rotation which you called C
[23:03:32] <toastydeath> correct
[23:03:42] <jepler> and some numbers that vary depending on the job
[23:03:47] <toastydeath> correct
[23:04:07] <jepler> OK I think I understand a bit better now
[23:04:53] <toastydeath> the classic example of what a fts needs to do is a cam - it has some base value, a ramp, a constant rise, a deramp, the top of the profile, and it reverses on the way back down
[23:04:59] <anonimasu> toastydeath: well, switch your spindle to a rotary axis.. and cut it..
[23:05:10] <toastydeath> you lose accuracy doing that
[23:05:16] <toastydeath> and it doesn't work for some applications
[23:05:20] <toastydeath> roll lathes, cams
[23:05:54] <toastydeath> in particular
[23:05:56] <anonimasu> toastydeath: there's a reson they grind camshafts.
[23:06:10] <toastydeath> many cams are ground on FTS-equipped grinders.
[23:06:20] <toastydeath> to achieve proper work speed
[23:06:41] <jepler> during a spindle-synched move, the spindle angle is what you hook to motion.spindle-revs -- 1.0 = 1 rev
[23:06:44] <ds2> hmmm
[23:07:34] <toastydeath> hmm
[23:08:14] <ds2> if i understand jepler correctly, another application would be for a bridgeport refit where there is a Z motor on the knee and another on the quill
[23:08:52] <toastydeath> i think the bridgeport application is a bit simpler - it's just another programmable axis, correct?
[23:09:04] <toastydeath> like a horizontal boring mill.
[23:09:09] <jepler> so you'd write your f(C) as a HAL component taking a float 'in' (spindle angle in revolutions) and a float 'out' (fts position)
[23:09:23] <toastydeath> hmm
[23:09:25] <ds2> for programming simplicity, I would think it is best to have EMC figure out which motor to move based on where it is at and the commanded Z move
[23:09:36] <jepler> then, ignoring stuff like enable and home position, you hook that to a position loop like PID or stepgen
[23:10:13] <toastydeath> hmm!
[23:10:57] <anonimasu> I think that's pretty bad.
[23:11:00] <jepler> the FPS position component might have various parameters, and they could be set by M1xx scripts
[23:11:09] <anonimasu> how do you keep track of ends of axes and stuff?
[23:11:18] <anonimasu> if one axis is faster then the other..
[23:11:24] <anonimasu> and you are at the end of it and you need to do a move..
[23:11:25] <toastydeath> one axis is locked
[23:11:40] <toastydeath> at least in the FTS situation, the real X axis clamps
[23:11:51] <anonimasu> but in the bridgeport like ds2 said..
[23:12:09] <toastydeath> i don't know how EMC handles it, but in commercial "two axis" controllers
[23:12:19] <toastydeath> there are limit switches on each individual axis and it trips
[23:12:23] <anonimasu> if you have them automatically switching you never know what axis that will move..
[23:12:29] <jepler> toastydeath: so during the FTS "cycle" are both X and Z stopped? or is X stopped and Z and the FTS move?
[23:12:30] <toastydeath> you don't have them switch
[23:12:35] <toastydeath> Z and the FTS run
[23:12:39] <anonimasu> 01:10 < ds2> for programming simplicity, I would think it is best to have EMC figure out which motor to move based on where it is at and the commanded Z move
[23:12:47] <ds2> anonimasu: limit switches or encoders?
[23:12:55] <anonimasu> ds2: limits dosent matter which..
[23:12:59] <toastydeath> the problem is it's not good to have EMC figure that out
[23:13:13] <toastydeath> perhaps if you wanted to have it figure that out, it would be difficult
[23:13:26] <toastydeath> if you had an application for it, i wouldn't know where to start - epsecially for obsticle avoidance
[23:13:44] <anonimasu> ds2: if you have no travel for your quill
[23:13:46] <toastydeath> but usually, the two axes are used for completely different tasks and are not interchangable
[23:13:49] <ds2> anonimasu: all the controller really needs to know is the maximum travel of each part and where it is at... should be able to optimize a move given that; prehaps it should limit itself to using one or the other
[23:14:13] <anonimasu> ds2: you need to smoke less of whatever.. :)
[23:14:18] <anonimasu> ds2: it's not really practical..
[23:14:25] <jepler> kinematics doesn't know about the past and has a limited knowledge of the future -- it's a terrible place to decide whether to move quill, knee, or both during a particular 10ms of time
[23:14:32] <anonimasu> jepler: yep
[23:14:32] <toastydeath> ds2: why do you want EMC figuring out which axis to move?
[23:14:41] <jepler> er, "doesn't know about the future and has limited knowledge of the past"
[23:14:43] <anonimasu> jepler: also if you are at the end of the quill and you have a rapid move..
[23:14:54] <ds2> anonimasu: isn't that exactly what a person is doing by hand if go with a 2.5 axis refit (motor only on quill)?
[23:15:09] <anonimasu> down, with the knee limited to a lower max speed due to weight..
[23:15:10] <ds2> toastydeath: so the same G Code can work on different machines
[23:15:46] <toastydeath> how are you going to write the obsticle avoidance for each axis?
[23:15:49] <ds2> granted, it gets sticky for stuff like a drilling canned cycle
[23:16:04] <anonimasu> it gets sticky for all kind of machining..
[23:16:08] <toastydeath> What if EMC moves the spindle down and leaves it in a place where it's going to get creamed?
[23:16:08] <ds2> Hmmmm
[23:16:24] <anonimasu> ds2: do you move both axes down.. before you need to do a rapid Z?.. while in cut?
[23:16:32] <ds2> toastydeath: how is that different from if the knee gets moved up where it gets creamed?
[23:16:34] <toastydeath> the spindle and knee are for pretty different tasks, and i would propose that it's entirely up to the programmer to make good judgement on which to use
[23:16:34] <anonimasu> so you have enough space for your quill to do it..
[23:16:50] <ds2> Hmmmm
[23:17:30] <anonimasu> toastydeath: yep, theres a good reason for knowing what axis will move and when..
[23:18:15] <jepler> bbl guys
[23:18:21] <toastydeath> like again, the horizontal boring machine, where you set the spindle axis to clear the part, and move the saddle to actually do the cut
[23:18:37] <toastydeath> Two Z axes, but for different parts and purposes.
[23:18:56] <anonimasu> the quill is a neat thing because you want fast Z rapids..
[23:19:14] <toastydeath> quill, to me, is light contouring, boring, and drilling
[23:19:18] <anonimasu> yep
[23:19:37] <toastydeath> i want the quill z at -0.0, and to use the knee if i want to do heavy roughing
[23:20:04] <toastydeath> i don't want EMC to decide it will use the 6" of quill travel to dig a huge face mill into my part
[23:20:44] <toastydeath> but, that's just my professional opinion.
[23:21:10] <toastydeath> the academic, non-practical side of me kind of wants to say "I am inteterested in how you would handle this and make it feasable!"
[23:21:27] <anonimasu> hehe
[23:21:28] <anonimasu> yeah
[23:21:46] <toastydeath> perhaps employing fuzzy logic
[23:21:59] <toastydeath> as the IPM trends in a certain direction, or spindle speed, or something
[23:22:05] <toastydeath> start to favor one axis over another.
[23:22:32] <toastydeath> If you try to move Z at 450 ipm, for example, try to use the quill
[23:22:37] <anonimasu> yep
[23:22:39] <toastydeath> if you try to move it at 2 ipm, use the saddle.
[23:22:47] <anonimasu> toastydeath: the fun part is when you end up clost to the limits..
[23:22:59] <anonimasu> ;)
[23:23:12] <toastydeath> PUSH IT TO THE LIMIT
[23:23:15] <toastydeath> WALK ALONG THE RAZOR'S EDGE
[23:23:17] <toastydeath> etc
[23:23:19] <anonimasu> move down the quill and the knee.. at the same time
[23:23:23] <toastydeath> yeah!
[23:23:30] <anonimasu> so you end up with enough space to do your move..
[23:23:30] <anonimasu> ;)
[23:23:43] <toastydeath> use the quill as a compensator, is what you're saying?
[23:23:54] <toastydeath> say the knee can only move 5 ipm, and you program 6?
[23:24:00] <anonimasu> yep
[23:24:05] <toastydeath> the knee goes full rapid, and the quill takes the other 1
[23:24:11] <toastydeath> that would be pretty neat.
[23:24:18] <toastydeath> i would support that from a practical standpoint.
[23:24:25] <anonimasu> hehe.. it's f-ugly );
[23:24:31] <toastydeath> you'd have to include an M-code of some sort to allow that kind of compensation
[23:24:47] <toastydeath> and another m or g code to turn it off and send the slow axis to the proper location
[23:24:55] <toastydeath> to cancel the travel compensation
[23:24:59] <anonimasu> toastydeath: my idea was to have that happen transparently ;)
[23:25:05] <toastydeath> i'd want to control it
[23:25:18] <toastydeath> i want the machine to say "hey, i can't move 6 ipm, dummy"
[23:25:37] <toastydeath> then go in and enable it, so that i had full control over what the machine was doing
[23:25:50] <anonimasu> actually I want one as Z and the other one as V or something
[23:25:55] <toastydeath> Z and W
[23:26:00] <anonimasu> hehe
[23:26:06] <toastydeath> no, seriously
[23:26:34] <toastydeath> those are the canoical names for the knee/saddle axis and the spindle
[23:27:15] <anonimasu> :)
[23:27:20] <anonimasu> I was really close
[23:28:41] <toastydeath> is there an MDI mode
[23:28:42] <toastydeath> in emc
[23:28:59] <toastydeath> i was using a conversational mill todayt
[23:29:01] <toastydeath> *today
[23:29:03] <toastydeath> and i wanted to die
[23:29:22] <toastydeath> "this machine makes everything harder than it needs to be, why hast thou forsaken me
[23:29:28] <anonimasu> hehe
[23:29:40] <anonimasu> have you tried the heidenhain conversational stuff?
[23:29:43] <toastydeath> no sir!
[23:29:44] <anonimasu> it's like g-code with a little twist..
[23:29:50] <toastydeath> this was, uh, accu-rite?
[23:29:54] <anonimasu> I like it better then g-code for contouring..
[23:29:59] <toastydeath> really?
[23:30:00] <anonimasu> ityeah
[23:30:28] <toastydeath> does it do the math for you or something
[23:30:34] <toastydeath> becuase that's the cool part of conversationals
[23:30:52] <toastydeath> at least, that's what this one kind of does
[23:30:59] <anonimasu> it can if you are a good programmer..
[23:30:59] <toastydeath> except you cant just tell it to "feed that way"
[23:31:18] <toastydeath> it needs start points and end points and all saftey keys must be in place
[23:31:24] <anonimasu> L X-100 Y10 Z-10 F100 is how it looks in heidenhain
[23:31:26] <toastydeath> please keep your arms and legs inside the vehicle at all times
[23:31:31] <toastydeath> L?
[23:31:32] <toastydeath> line?
[23:31:36] <anonimasu> that's like g1..
[23:31:39] <toastydeath> o
[23:31:54] <toastydeath> yeah this one is "HEY SKIPPER, I SEE YOU'RE TRYING TO WRITE A LETTER"
[23:32:05] <anonimasu> :)
[23:32:20] <feoc> L linear
[23:32:26] <anonimasu> ;) thanks feoc
[23:32:32] <toastydeath> i was contemplating going out into the shop floor and commandering the OKK horizontal we have
[23:32:47] <toastydeath> load up all my tools in one shot, i hate R8
[23:32:49] <anonimasu> it does tangential appriaces and stuff.. with very little code..
[23:32:57] <feoc> i use a heid at work
[23:33:03] <toastydeath> i use my ti-89
[23:33:04] <toastydeath> for that
[23:33:04] <anonimasu> feoc: what do you think of it?
[23:33:08] <feoc> nigh on every thing i write has a m92 at the end aswell
[23:33:12] <toastydeath> not as good as having the machine do it
[23:33:22] <anonimasu> what?
[23:33:34] <toastydeath> M92 - STOP; HAMMERTIME
[23:33:37] <anonimasu> 01:34 < feoc> nigh on every thing i write has a m92 at the end aswell
[23:33:44] <feoc> anonimasu its not bad
[23:33:49] <toastydeath> what is m92
[23:34:00] <anonimasu> user defined call?
[23:34:20] <feoc> its to use actual ref points instead of user defined datums on the axis
[23:34:24] <anonimasu> oh
[23:34:25] <anonimasu> yeah
[23:34:38] <anonimasu> I dont use datums at all yet..
[23:34:40] <toastydeath> that sounds like something i would use to crash the machine
[23:34:45] <anonimasu> I need to make/build a fixturing system
[23:34:49] <toastydeath> what's a user defined datum?
[23:34:50] <feoc> got annoyed with people moving datums about and causing crash's
[23:34:51] <toastydeath> is that a work coordinate?
[23:34:55] <anonimasu> yeah
[23:34:58] <toastydeath> oh
[23:35:16] <feoc> if i use an m92 it will go into the same place every time regardless of the user axis datums
[23:35:18] <toastydeath> oh man but i love work coordinates.
[23:35:52] <anonimasu> I just wish I had enough skill to re-burn the eeprom with some custom cycles I have..
[23:36:37] <toastydeath> no macro programming/etc?
[23:36:39] <feoc> trying to convince my work to get solidworks and solidcam
[23:37:11] <feoc> use some crappy french cam system at mo called lemoine it does my head in
[23:38:04] <anonimasu> :)
[23:38:10] <anonimasu> feoc: what kind of parts do you make?
[23:38:14] <anonimasu> and what control is it you have?
[23:38:55] <feoc> i make patterns for composite moulds
[23:39:04] <feoc> cant remember the model name
[23:39:22] <anonimasu> TNC-1xX=?
[23:39:26] <toastydeath> i bet it's one of those fancy moldmaking controls
[23:39:33] <anonimasu> is it new/old?
[23:39:41] <feoc> its about 5 yr old machine
[23:39:54] <anonimasu> Tnc-320?
[23:39:56] <feoc> toastydeath dont think so we make patterns more than molds
[23:40:26] <anonimasu> http://www.heidenhain.com/?/ca479_177,Controlling_Machine_Tools-583/ca2238_177,Products_and_Applications-479/ca583_177,Milling-584.html
[23:40:27] <toastydeath> oh
[23:40:41] <toastydeath> damn!
[23:40:44] <toastydeath> those are still fancy!
[23:40:49] <feoc> no its not a 320
[23:41:05] <anonimasu> ok
[23:41:15] <anonimasu> what does it look like?
[23:41:20] <anonimasu> like which one of thoose?
[23:41:23] <toastydeath> can't these goddamned machines incorporate two, easy to reach handwheels?
[23:41:29] <toastydeath> and maybe some buttons for pre-programmed macros?
[23:41:47] <toastydeath> i'm going to have to start a machine building company.
[23:42:08] <anonimasu> feoc: http://filebase.heidenhain.de/doku/tnc_guide/de/index/N161C0/N16320/N16792/N16792.html
[23:42:24] <anonimasu> feoc: sorry about being very curious :)
[23:43:51] <feoc> lemmie look
[23:44:28] <anonimasu> ok
[23:44:42] <toastydeath> LOOK FASTER
[23:44:49] <toastydeath> mister fancy controls
[23:45:11] <feoc> lol
[23:45:15] <anonimasu> lol
[23:45:16] <toastydeath> i need to work in a shop that uses controls born after 1980
[23:45:17] <feoc> its got a colour crt screen in it
[23:45:22] <toastydeath> yeah well, mine's color, too
[23:45:24] <toastydeath> one color
[23:45:25] <feoc> not an lcd like those apear too
[23:45:25] <toastydeath> green
[23:45:30] <feoc> lol
[23:45:41] <toastydeath> it's green, uphill, both ways
[23:45:45] <toastydeath> and we LIKE it
[23:46:17] <anonimasu> lol
[23:46:33] <anonimasu> feoc: find anything?
[23:47:42] <ds2> Hmmmm
[23:48:32] <feoc> cant find it
[23:48:41] <feoc> i looks like an older version of that 320 tho
[23:48:48] <anonimasu> 310?
[23:48:50] <feoc> with crt and a few other differences
[23:49:03] <anonimasu> err that's monochrome..
[23:50:01] <feoc> i dunno ill find out for ya when i see it
[23:50:05] <feoc> if ya still bothered
[23:50:06] <feoc> lol
[23:50:13] <anonimasu> :)
[23:50:13] <anonimasu> sure
[23:50:21] <anonimasu> I've got a tnc-310
[23:50:23] <anonimasu> at work
[23:51:08] <feoc> iv just had to send the motor from my lathe off for a service along with the drive
[23:51:18] <feoc> costing me 1850 pounds to repair
[23:51:28] <anonimasu> :/
[23:51:52] <toastydeath> i can't tell if blood is still seeping out of my bandages
[23:51:57] <toastydeath> or if it's all dry
[23:52:29] <feoc> toastydeath nice
[23:52:30] <toastydeath> maybe i should have gone to go get stiches
[23:52:34] <toastydeath> oh wel
[23:52:37] <toastydeath> l
[23:52:47] <toastydeath> LIVE BY THE DRILL DIE BY THE DRILL
[23:52:52] <feoc> next decision i gotta make is if i try the siemens 8t control system on it
[23:52:52] <toastydeath> or something more prophetic
[23:52:58] <toastydeath> link?
[23:53:00] <anonimasu> toastydeath: that's a good idea
[23:53:02] <feoc> or be done with it and go emc
[23:53:09] <anonimasu> feoc: try the stock one first ;)
[23:53:17] <anonimasu> if it works and are programable might aswell use it
[23:53:36] <feoc> maybe but emc will probably be more reliable in the long run
[23:53:45] <feoc> if emc breaks its cheap to fix
[23:54:06] <anonimasu> yep
[23:54:13] <toastydeath> my only complaint with emc + lathes
[23:54:16] <toastydeath> is that emc programs like a mil
[23:54:17] <toastydeath> l
[23:54:20] <anonimasu> :)
[23:54:21] <toastydeath> at least, from what i saw
[23:54:32] <toastydeath> and tried to use in the simulator thingy
[23:54:56] <ds2> toastydeath: that's why you using use only drills powered by a single AA =)
[23:55:15] <feoc> well i can mill with my lathe aswell :)
[23:55:17] <toastydeath> this would not have happened if i was using the okk
[23:55:21] <toastydeath> i hate bridgeports
[23:55:40] <toastydeath> it would have spun, and i would have been a safe seven feet away
[23:55:45] <anonimasu> lol
[23:55:47] <anonimasu> yeah
[23:55:48] <ds2> bridgeports are overpowered!
[23:56:01] <anonimasu> dont use your fingers nearby spinning stuff.
[23:56:01] <toastydeath> bridgeports are underpowered, flimsy, and dangerous to the operator!
[23:56:14] <toastydeath> or maybe just dangerous to me, i can't tell yet
[23:56:26] <ds2> now if you used an import minimill, it'd just stall after it hit your finger }:-)
[23:56:27] <anonimasu> dont take this personal but it's just you..
[23:56:31] <toastydeath> DAMN
[23:56:32] <toastydeath> =(
[23:56:33] <anonimasu> :/
[23:56:51] <toastydeath> you know, that is the best arguement i've ever heard for a taig
[23:56:52] <anonimasu> toastydeath: you are lucky to have your finger
[23:56:58] <feoc> all machines are dangerous it just depends on the operator
[23:57:00] <toastydeath> i'm real goddamned lucky
[23:57:10] <toastydeath> i was so pissed
[23:58:01] <toastydeath> it damn near broke my thumb
[23:58:14] <feoc> im off to bed
[23:58:17] <toastydeath> but really damn lucky for me, it was freewheeling on the drill
[23:58:17] <feoc> gnight all
[23:58:21] <toastydeath> and wasn't actually stuck on it
[23:58:26] <toastydeath> or it would have been a whole lot worse
[23:58:39] <ds2> no hass mills around to run with the jog knob? ;)
[23:58:55] <toastydeath> i don't get it?
[23:59:24] <ds2> haas mills have a encloser all around
[23:59:29] <toastydeath> does haas have a problem with the jog... oh
[23:59:44] <ds2> no... not a problem, just a waste to use a haas for manual work ;)
[23:59:50] <toastydeath> not really?