Back
[01:51:44] <ChanServ> [#emc] "This is the #emc channel - talk related to the Enhanced Machine Controller and general machining. Website:
http://www.linuxcnc.org/, wiki at
http://wiki.linuxcnc.org/"
[01:52:01] <cradek> vacuum
[01:52:05] <glackins_> you could go to vaccum wipers as well )
[01:52:25] <glackins_> nm - see you already have
[01:52:26] <Valen> vacuume isnt from the manifold?
[01:52:28] <cradek> yeah that's what they are
[01:52:51] <glackins_> yep - most old cars are manifold vacum - great when the line cracks
[01:52:54] <cradek> Valen: if you want wipers going uphill too, you pretty much need the fuel pump assist
[01:53:16] <Valen> lol dude that whole thing is messed up ;->
[01:53:26] <glackins_> do you have a generator as well instead of an alternator?
[01:53:28] <cradek> I drove a truck without - wipers only worked going downhill - pretty irritating
[01:53:35] <cradek> yes original generator
[01:53:54] <Valen> spend a few pennies, upgrade to 12 volts with lights and electric wipers ;->
[01:54:09] <glackins_> soo - idling - you can barely see and doing 60 (or high revs) the countryside is lit up?
[01:54:28] <cradek> glackins_: who can go 60? haha
[01:54:42] <glackins_> downhill with the wind at your back of course
[01:55:08] <Valen> what year is it?
[01:55:11] <cradek> the lights work fine for driving - but they will definitely run it down at idle.
[01:55:15] <cradek> 52
[01:55:31] <Valen> heh put some HID's in it
[01:55:48] <glackins_> agree wiuth valen - upgrade to 12 volts - there only has to be like 3 wires in the whole vehicle anyway...
[01:55:49] <Valen> piggyback a 12 volt system into it
[01:56:29] <Valen> new bulbs throughout, new flasher relay thingie (or it'll flash real fast) and hack a wiper motor onto it
[01:56:41] <cradek> that's crazy talk
[01:56:47] <glackins_> wiring a mill is probably more complicated
[01:56:52] <Valen> probably looking at $150 or so all up if you pull it from a wreckers
[01:56:55] <cradek> it works fine :-)
[01:57:00] <Valen> including the alternator
[01:57:20] <Valen> cmon you know you want a 52 truck with HID headlights and LED indicators ;->
[01:57:38] <glackins_> add some neon underneath and yer pimpin
[01:57:45] <Valen> blam!
[01:58:18] <SWPadnos> http://customwheel.com/custom_wheels/product_info.php/products_id/1687
[01:58:37] <Valen> otherwise I'd just get a check valve from an industrial supplier and stick that in your fuel line downstream from your pump
[01:59:27] <cradek> SWPadnos: hahaha
[01:59:32] <SWPadnos> heh
[01:59:50] <cradek> yeah, only $14,000
[01:59:56] <cradek> perfect
[02:00:01] <SWPadnos> so you need the 10" ones, huh? :)
[02:00:20] <SWPadnos> might as well get the 26" diameter and jack the thing up at the same time
[02:00:23] <Valen> 24" rims too
[02:00:32] <Valen> why not while your at it
[02:00:42] <SWPadnos> 24 is wimpy
[02:00:49] <SWPadnos> 26 is where it's at
[02:00:51] <SWPadnos> yo
[02:01:19] <cradek> https://www.nationalchevyassoc.com/shop-online/product/image/1927/original
[02:02:20] <Valen> am i guaranteed to "pull the bitches" like that fugly dude?
[02:02:43] <Valen> is that your pump cradek?
[02:02:43] <SWPadnos> yes, for only 12000, 14000, or 16000 dollars
[02:03:13] <Valen> $16000 buys alot of time with better looking women i'd imagine
[02:03:24] <SWPadnos> hmmm. better check those prices
[02:03:30] <cradek> err, it's this one
https://www.nationalchevyassoc.com/shop-online/product/image/1930/original
[02:03:47] <cradek> no glass top (same pump otherwise - they came both ways)
[02:03:50] <Valen> heh no glass top
[02:03:59] <Valen> glass top thats just crasytalk
[02:04:06] <Valen> be carefull with the spanner eh
[02:04:21] <cradek> very nice - you can see if it's primed
[02:04:34] <cradek> I have a glass filter right in front of mine though - same purpose
[02:04:51] <Valen> stick an electric fuel pump in, you'll know its primed then ;->
[02:05:04] <Valen> I have a clear plastic one in my old one
[02:20:55] <sed> Does emc work with the DSPMC/IP ethernet motion controller from Vital?
[02:21:07] <SWPadnos> no
[02:21:33] <sed> I guess I will stick with my STG card....
[02:21:38] <SWPadnos> heh
[02:22:06] <sed> I have to go dig out another ISA MB
[02:22:21] <SWPadnos> you could get a mesa card instead
[02:22:25] <SWPadnos> or some other PCI card
[02:22:32] <SWPadnos> (unless it's easier to find an ISA card)
[02:22:37] <SWPadnos> err, ISA motherboard
[02:23:05] <jepler> who doesn't have a basement full of 'em
[02:23:06] <jepler> ?
[02:23:09] <sed> I was thinking a usb/firewire or ethernet based controller would be the most computer independant
[02:23:12] <SWPadnos> me, me
[02:23:26] <SWPadnos> it would be, but it would also have to be independent of EMC2 at this point
[02:23:58] <SWPadnos> there's some potential for making an ethernet based solution. USB is a lot trickier and is unlikely to ever work
[02:24:05] <sed> im wishfuly waiting.. I wish I understood more so I could help out...
[02:24:15] <SWPadnos> me too :)
[02:24:32] <sed> I have not had time to even get emc2 working with the STG
[02:26:21] <SWPadnos> that will be a lot easier than writing a driver for an ethernet device
[02:26:44] <sed> yea it would, but emc1 still works for now..
[02:27:01] <jepler> unless you write device drivers for fun, it's a much more practical idea to buy hardware with drivers already written
[02:27:20] <SWPadnos> if you have a working system, and you don't need any of the features and bugfixes in emc2, I'd stick with emc1
[02:27:36] <sed> STG card works with emc2 I just have to convert my .ini to whatever I need for HAL and all that in emc2
[02:27:48] <SWPadnos> I'll deliver the hardware to you, if you pay the airfare :)
[02:28:19] <sed> heh thanks!.. I think I have a couple of boards at home..
[02:28:19] <jepler> no doubt hal is a bit of a hill to climb the first time
[02:28:26] <SWPadnos> there's a sample config that should be pretty similar to the EMC1 setup - shouldn't need much changing unless you did a lot of stuff
[02:28:30] <jepler> Software Source Code Return Policy
[02:28:30] <jepler> •
[02:28:31] <jepler> Source Code shipped to customer cannot be returned or exchanged.
[02:28:57] <sed> sample config that comes with emc2?
[02:29:04] <SWPadnos> I think so
[02:29:13] <cradek> I think both stg1 and stg2 are fully working in emc2 now
[02:29:31] <SWPadnos> http://cvs.linuxcnc.org/cvs/emc2/configs/stg/
[02:29:37] <SWPadnos> those files are included with emc2
[02:29:39] <sed> I may have one of each of those cards...
[02:29:53] <SWPadnos> you can probably use them both at the same time with emc2
[02:30:15] <SWPadnos> (I'm not sure if the cards support that, or if the driver can handle both types at once, but it should be possible)
[02:30:18] <SWPadnos> (and untested)
[02:30:50] <sed> wouldnt know what to do with 16 axis support....
[02:31:02] <cradek> index handling on those is funky - don't try to home more than one axis at the same time
[02:31:10] <cradek> (hardware limitation, not emc's fault)
[02:31:12] <sed> I could run CNC blenders in a smoothie shop..
[02:31:43] <SWPadnos> the outputs are just DACs and the inputs are just encoders, with EMC2
[02:31:47] <jepler> perhaps closed loop would lead to better smoothies
[02:31:50] <SWPadnos> unless the STG is very different from other hardware
[02:32:12] <SWPadnos> how many axes do you need for a robotoc sushi chef?
[02:32:33] <sed> depends on knife control
[02:33:02] <SWPadnos> and whether blowfish is on the menu, I guess :)
[02:34:57] <sed> thanks for the chat, I gota blow home and dig for ISA MB's...........
[02:35:56] <SWPadnos> see you
[03:32:13] <dareposte> hi all
[03:34:04] <dareposte> anybody have a suggestion for improving surface finish on free machining steel parts?
[03:34:20] <dareposte> it's not *bad*, but not really stellar either
[03:34:50] <dareposte> i've been using 1215 steel, with about 70m/min and .15 mm/rev
[03:35:00] <dareposte> comes out okay, but sort of dull
[03:35:33] <toastydeath> use a surface grinder
[03:35:35] <dareposte> i found a reference that recommends 0.4mm/rev... but that seems like it might be a bit fast?
[03:35:38] <dareposte> lol
[03:35:46] <dareposte> if i had a surface grinder that would be wonderful
[03:35:54] <dareposte> all i have is a small wimpy lathe though
[03:36:16] <toastydeath> your dreams of surface finish will probably rely on sandpaper and polishing, then
[03:36:26] <dareposte> eh
[03:36:40] <dareposte> i have seen better turned finishes than what i have
[03:37:13] <dareposte> just not sure how to get one
[03:37:31] <dareposte> i threw them in the vibration polisher for now, but i'd like to eliminate that step eventually for this part
[03:37:41] <cradek> 70m/min is fast for steel. you are using carbide I assume?
[03:37:52] <dareposte> yeah carbide
[03:38:01] <dareposte> think i should slow it down?
[03:38:03] <cradek> how deep is your cut?
[03:38:11] <dareposte> 0.5mm depth of cut
[03:38:19] <cradek> slowing it down is sure something to try...
[03:38:25] <dareposte> okay
[03:38:33] <cradek> ok you're not trying to take off .02mm or something - that doesn't work with carbide
[03:38:42] <cradek> deeper cut often leaves a better finish
[03:38:53] <dareposte> no i'm sticking to about 0.5mm which seems to work pretty well for the chip formation
[03:39:02] <dareposte> smallest finish cut is 0.3
[03:39:09] <dareposte> but that's on the radius
[03:39:50] <dareposte> does the feed seem reasonable?? i found a material sheet that recommends 0.4mm/rev
[03:40:09] <dareposte> 0.016"/rev
[03:40:27] <cradek> what's the tip radius on the insert?
[03:40:28] <Valen> how does one go putting a surface grinder on a CnC mill? I have always wondered how one would do grinding CnC style without uber equipment
[03:41:36] <dareposte> cradek: here's where I got my starting points:
http://www.jmmachineinc.com/products_tips_sfhhs.htm
[03:41:39] <toastydeath> valen: it's usually completely unsuccesful
[03:41:50] <toastydeath> because a grinder has more in common with a planer than a mill
[03:41:57] <dareposte> 151-200 fpm / 0.016 ipr is what they recommended
[03:42:04] <cradek> also, grinding dust destroys sliding parts
[03:42:29] <cradek> so grinders have everything nicely covered and often have "slides" that roll on balls instead of sliding
[03:42:56] <toastydeath> they're also an order of magnetude more rigid
[03:42:57] <toastydeath> than a mill
[03:43:05] <Valen> sanding block and buffing wheel it is then ;->
[03:43:08] <toastydeath> there've been several deaths from people trying to build grinders
[03:43:16] <toastydeath> on a mill, you get chatter
[03:43:38] <toastydeath> on a grinder, the wheel disintegrates into chunks
[03:44:00] <Valen> yeah grinding wheels are scary
[03:45:00] <Valen> I thought there might be some way of putting a grinding type tip in thats the same sort of size as a typical milling bit
[03:45:13] <toastydeath> oh, diamond mandrels, yeah.
[03:45:16] <toastydeath> but you need speed
[03:45:18] <toastydeath> lots of speed
[03:45:42] <toastydeath> 60k-80k is a good range for 1/4" grinding bits
[03:45:56] <Valen> can they give you a similar result to traditional grinding?
[03:46:03] <toastydeath> no
[03:46:32] <Valen> ahh :-<
[03:46:43] <toastydeath> there are equally specialized machines that are even more expensive than surface grinders that resemble mills, called jig grinders
[03:46:59] <toastydeath> they will give you the same results, but no cnc mill with a grinding head will
[03:47:45] <jmkasunich> * jmkasunich was once in a steel mill when a 6ft diameter x about 3/8" thick cutoff wheel disintegrated
[03:48:04] <jmkasunich> we thought a transformer had blown up
[03:48:33] <toastydeath> niiice
[03:48:48] <dareposte> i hope there are guards for stuff like that...
[03:49:01] <jmkasunich> yes - strong ones
[03:49:09] <Valen> and a bunker ;->
[03:49:11] <jmkasunich> the guys that worked there just shrugged and got another wheel
[03:49:17] <toastydeath> big grinding equipment tends to be almost fully enclosed
[03:49:33] <dareposte> must be neat to not think much of something like that
[03:49:57] <jmkasunich> this was at a rolling mill - about 12" square going in, 3" round coming out - the grinder was used to cut the bars to length after cooling
[03:50:04] <dareposte> sort of like the guys who set telephone poles... if they hit rock they just throw a stick of dynamite in, lean back on the truck and sip their coffee
[03:50:12] <dareposte> then go back to drilling
[03:50:41] <dareposte> cool
[03:50:46] <dareposte> i'd like to see that
[03:51:24] <dareposte> the rolling part, not the disintigrating disc part
[03:51:27] <jmkasunich> I'm convinced that nothing in a steel mill is small
[03:52:08] <Valen> stuff in the chemistry lab might be
[03:52:20] <jmkasunich> they had about 25 oxygen cylinders manifolded together - if something happened that stopped the line (like our drive tripping out - the reason I was there), they had to oxy-cut the steel out of the line
[03:52:54] <dareposte> was it a continuous rolling process then?
[03:53:04] <jmkasunich> semi-cont
[03:53:21] <jmkasunich> the incoming bars might be 12" x 12" x 50 feet long
[03:53:42] <jmkasunich> when squished to 3" diameter, they wind up maybe 800-1000 feet long
[03:53:42] <Valen> I heard a story once where they had a new guy on the job at a steel mill
[03:53:52] <Valen> anyway he was doing everything fine
[03:54:07] <Valen> except he dropped the slag into the train cars a bit too soon
[03:54:16] <jmkasunich> melted em?
[03:54:31] <Valen> it was still too hot and it sort of welded it self/stuck to the cars
[03:54:34] <Valen> then contracted
[03:54:36] <Valen> alot
[03:54:54] <Valen> pulled the bogeys off the tracks etc
[03:55:01] <jmkasunich> yeah, when stuff goes wrong there, it goes wrong on a large scale
[03:55:23] <jmkasunich> at the end of this rolling line, before the run-out table, there was a rotary shear
[03:55:36] <Valen> so they had to get a guy and a truck full of liquid oxygen to cut the cars up into about 5 chunks each to put into other cars to take away
[03:55:41] <jmkasunich> it snipped the leading end off the bar, then cut the bar into maybe 100' lengths to cool
[03:55:59] <SWPadnos> http://www.youtube.com/watch?v=3uCvZ7IeUFA
[03:56:17] <jmkasunich> the shear would cut a 3" steel bar about like a person cutting a tootsie roll with a pair of scissors
[03:57:54] <dareposte> swpadnos: i don't understand what caused that
[03:58:00] <jmkasunich> vacuum
[03:58:04] <Valen> pulling a vaccume in the tank
[03:58:10] <SWPadnos> they hooked it to a vacuum pump, according to some comment somewhere
[03:58:10] <dareposte> yeah i got that part
[03:58:20] <Valen> it can happen inadvertantly when they put a hot liquid into a tank
[03:58:21] <dareposte> oh so was it a destruct test?
[03:58:22] <jmkasunich> for example, steam clean the tank, then seal it while there is still mostly steam, not air, inside
[03:58:24] <SWPadnos> I don't see how though, I'd think that 15 PSI shouldn't do that
[03:58:42] <Valen> add up the inches on the surface area of the tank
[03:58:48] <jmkasunich> calculate the sq in in that PSI
[03:58:57] <SWPadnos> sure, tons (and tons) of force
[03:59:11] <Valen> need a few more and tons there
[03:59:31] <SWPadnos> they seem quite solid, but not much more so than things that are dunked 10m into water
[03:59:57] <Valen> what happens is the container takes the pressure for a fair while but as soon as it creases it instantly looses all strength
[04:00:02] <jmkasunich> its all a matter of design - that same tank could probably handle 100 PSI internal pressure
[04:00:33] <SWPadnos> sure, I understand the physics, it's just a somewhat surprising result based on how similar to underwater things those tankers seem
[04:00:49] <Valen> compression strength is typically much lower than tensile
[04:01:08] <SWPadnos> for steel, sure
[04:01:11] <jmkasunich> http://www.youtube.com/watch?v=Qskg_I-O8sg
[04:01:22] <Valen> underwater stuff is probably much much thicker or pressurised
[04:01:55] <jmkasunich> I wonder how many tons it takes to shear 20 or 30 1/2" steel bars at once
[04:02:00] <jmkasunich> (about 3:00 in that vid)
[04:03:01] <dareposte> i like the little walkway bridge going over the huge red hot bar of steel
[04:03:11] <dareposte> wonder if its frequently used...
[04:03:25] <jmkasunich> I've crossed such a bridge - although not when the steel was moving underneath
[04:03:43] <Valen> i heard that they used to give workers in those areas wooden sandals
[04:03:50] <Valen> to go over their boots
[04:04:21] <dareposte> what good would that do?
[04:04:29] <dareposte> if they smell smoke they need to keep moving?
[04:04:31] <Valen> so if they stepped on something a touch warm it would just catch fire rather than instantly melting through to their feet
[04:05:33] <jmkasunich> neat shear at 1:20
[04:06:00] <jmkasunich> again at 1:32
[04:07:09] <jmkasunich> rotary shear at 1:50ish
[04:07:31] <jmkasunich> dunno why those things fascinate me - matching speed and cutting a moving bar just seems neat
[04:15:06] <dareposte> http://www.youtube.com/watch?v=R2raRqZleeg&feature=related check out about 3:30
[04:15:14] <Valen> http://www.youtube.com/watch?v=hAG0O5d0wHY&feature=related
[04:15:15] <dareposte> huge abrasive wheel matches speed and chops it
[04:15:39] <Valen> unrelated just cool
[07:43:57] <pjm__> good morning
[07:44:00] <pjm__> pjm__ is now known as pjm
[08:20:24] <micges> good morning
[08:46:02] <Valen> its 6:45 here lol
[12:43:53] <skunkworks> BigJohnT: get the back off of the servos yet? :)
[12:44:16] <BigJohnT> not yet
[12:44:57] <BigJohnT> I did figure out that two pins are the power and the other two must be something else...
[12:45:33] <skunkworks> my guess would be temp sensor. maybe
[12:45:39] <BigJohnT> I'm going to take it apart in a bit
[12:46:18] <BigJohnT> in the 80's did they use thermocouples or thermisters or bimetal contacts for that?
[12:46:25] <BigJohnT> or all the above
[12:47:51] <skunkworks> * skunkworks doesn't know off hand
[12:48:28] <archivist> take it apart and find out, you know you want to
[12:48:42] <BigJohnT> I am in a bit archivist
[12:49:30] <archivist> I was told I should never marry, because the first thing I would do is take her to bits
[12:49:30] <rob__> BigJohnT, yes two will be a temp sensor it dont not need to be connected to work, the drives use it to monitor the inside motor temp and they cut off when it over temps in the drive
[12:49:48] <BigJohnT> thanks rob__
[12:51:18] <rob__> was it a 5M motor from what i read above yest ^
[12:52:19] <archivist> 5N
[12:52:55] <BigJohnT> Type 5N-2000M
[12:53:19] <rob__> hmm dont think i have any tech doc on that area of fanuc
[12:56:14] <rob__> i havea quick q on emc, the output_scale in ini should this be left as 1.0 or changed to some value of units?
[12:56:45] <rob__> using servos
[13:00:06] <BigJohnT> not much in the manual :(
[13:00:17] <alex_joni> rob__: depends how you set up the PID
[13:00:35] <alex_joni> BigJohnT: from what is that motor?
[13:00:55] <rob__> using mesa cards -10 to +10v to drive motor
[13:01:28] <BigJohnT> a rather large knee mill with a flying saucer looking tool changer that sits on top of the mill
[13:02:28] <alex_joni> rob__: velocity mode?
[13:02:39] <rob__> yes
[13:04:54] <alex_joni> then I guess you don't need to scale it
[13:06:12] <rob__> manual confused me alittle when trying to get my head around it etc
[13:07:29] <rob__> right, i gota go back to work, ill have a play with it abit more this evning
[13:07:30] <rob__> thx for pointer alex_joni
[13:08:12] <cradek> with velocity mode you want 9? volts to be your rapid speed. you can scale the dac so the dac input is in inches/second assuming an inch machine.
[13:08:17] <alex_joni> rob__: np, it helps if you tell us what part of the docs needs expending
[13:09:05] <cradek> so if your rapid speed is 4 inches/second and you want rapids to be 9 volts on the amp, the dac output scale should be 9/4
[13:09:34] <cradek> then turn the gain knob on your amp until 9v gives you that 4 inches/second
[13:10:05] <cradek> now your position loop tuning will be very simple to tune (mostly P and FF1)
[13:10:18] <skunkworks> mine will be scaled for voltage. +/-150v or so. (not velocity mode amps)
[13:10:44] <rob__> right that makes sence, yes im doing 10m/min at 10v
[13:10:45] <cradek> yeah voltage ~ torque so that makes perfect sense
[13:11:41] <cradek> ok, if your machine config is in mm, you want an output scale of 10/10000
[13:11:57] <cradek> errr
[13:12:06] <alex_joni> and /60
[13:12:09] <rob__> ye
[13:12:10] <cradek> 10/166.67
[13:12:22] <cradek> convert m/min => mm/sec
[13:12:46] <cradek> so you want an output scale of .06
[13:13:31] <cradek> if that scaling is right, you can set FF=1 and you'll get pretty decent following automatically
[13:14:14] <cradek> brb
[13:14:19] <rob__> thx cradek
[13:16:00] <rob__> thx for the help guys, gtg now
[13:16:26] <skunkworks> emc is great!
[13:22:48] <pjm> emc is more than great!
[13:23:57] <skunkworks> pjm: i posted your latest rigid tapping video in the thread
[13:24:33] <pjm> ah really! cool, thanks
[13:26:01] <pjm> i'm head scratching over mesa cards, cant decide if I need to get a 7i43 or a 5i20
[13:26:36] <pjm> i'm more tempted with the 7i43 because i can mount that directly in the box wiht the cnc electronics and just run a parport cable
[13:27:42] <alex_joni> bbl
[13:31:16] <skunkworks> I would go with the 5i20.. :)
[13:32:32] <pjm> i am tempted to go that route, but it means more ribbon cables from PC to cnc cabinet
[13:32:57] <pjm> where as the 7i43 can go in the same cabinet and only have a single parport cable
[13:33:08] <skunkworks> or you mount the motherboard in the cabinet.. ;)
[13:33:15] <skunkworks> I see your point though
[13:33:45] <pjm> it will certainly be nice to run the motor at full bollock and be able to clock the encoder properly
[13:34:56] <skunkworks> yes - but you certanly have a functional machine as it. (plus the mesa hardware does step generation also)
[13:35:17] <BigJohnT> skunkworks: the 4 pin plug is power + ground
[13:35:33] <skunkworks> ah - 2 grounds?
[13:35:44] <BigJohnT> the encoder and temp is on the 17 pin
[13:35:55] <BigJohnT> no one pin is not used
[13:35:57] <skunkworks> is it encoder?
[13:36:08] <skunkworks> *an encoder?
[13:36:20] <BigJohnT> the encoder is a A860-0300-T001 2000P
[13:36:36] <BigJohnT> nothing else under the hood :)
[13:36:54] <skunkworks> http://fanuc.pennineuk.com/a860-0300-t001-2000p.htm
[13:37:03] <skunkworks> 2000 line sounds like
[13:37:08] <skunkworks> very nice
[13:37:27] <BigJohnT> yep that is the one
[13:38:06] <skunkworks> you have 3?
[13:38:26] <BigJohnT> yes and the mill if I want (can find space for it) too
[13:38:48] <skunkworks> wow - I see an emc conversion in your future.
[13:39:03] <archivist> is it collected yet?
[13:39:07] <archivist> :)
[13:39:09] <BigJohnT> and a servo conversion to boot
[13:39:34] <archivist> lucky bar steward
[13:39:37] <BigJohnT> archivist it is safely stored at my buddys
[13:40:06] <BigJohnT> I'll have to take a picture next time I'm over there
[13:41:02] <skunkworks> Neat!
[13:41:30] <skunkworks> mesa card + 3 diy servo amps. ;)
[13:41:45] <BigJohnT> yep sounds like a plan
[13:42:05] <BigJohnT> gotta get the THC comp done and installed first
[13:52:45] <Optic> mooo
[13:54:48] <skunkworks> how is the laser coming?
[13:55:01] <Optic> oh pretty good!
[13:55:05] <Optic> we've been cutting lots of acrylic
[13:55:49] <Optic> the hardest part is still the workflow of getting useful gcode out of original artwork/designs
[13:55:59] <Optic> but overall the laser and emc are both working like a charm
[13:56:38] <Optic> I've been using qcad -> that german dxf2gcode python script
[13:56:53] <Optic> qcad is surprisingly good
[14:18:14] <tomp> dgarr's ornamental turning with emc is great.
http://www.youtube.com/watch?v=9A_YlKrPDuc the probing is real impressive. what was the scope like window? ( looked like audio tracks )
[14:18:26] <cradek> it was halscope, silly
[14:18:42] <tomp> really, what signals look that wiggly?
[14:19:10] <cradek> I'm not sure what the signals were. maybe following error if it's servos?
[14:20:51] <tomp> i really liked the probing. i didnt think anyone was using voltage drop ( very edm )
[14:21:24] <cradek> yes the profile probing, and then mapping the gcode to it, is really clever
[14:22:27] <tomp> raab of cnctoolkit has been doing some mapping onto surfaces
[14:23:32] <SWPadnos> sort of. actually he lets gmax do the mapping, then outputs g-code based on the resulting path
[14:23:44] <SWPadnos> (at least I'm pretty sure that's what he's doing)
[14:25:40] <tomp> saw this today,
http://www.icpdas.com/products/DAQ/pc_based/pio_d168.htm 168 points of opto22 control on pci card
[14:25:50] <tomp> yep, gmax
[14:25:53] <Valen> pjm I'm leaning towards the PCI card just for the gut feel that it will help reduce latency
[14:26:33] <pjm> Valen yeah i think also the 7i43 will to, from what i have read it handles all the real time step gen stuff etc, so should help a lot etc
[14:27:01] <Valen> i meant that the PCI would reduce it over the 7i43
[14:27:09] <SWPadnos> tomp, you mean 168 TTL I/O points, which could be conected to opto-22 boards :)
[14:27:49] <SWPadnos> I wonder how much that thing costs
[14:27:51] <pjm> i'm not sure it can reduce it, there will be another pci slot to service by adding in the card, where as using the existing parport may mean the latency stays as is - this is only a guess tho
[14:27:53] <tomp> yep 168 points . and its bring your own opto22 racks BYOO22R )
[14:27:57] <Valen> because as far as i understand the top end so far, step rate changes etc in a stepper system are still controlled by the host
[14:27:59] <SWPadnos> heh
[14:28:27] <Valen> parallel ports are pretty crummy in terms of addressing, there be many hoops to jump through
[14:28:36] <skunkworks> with step generation in the mesa hardware - you only have to send updates ever 1 to .5ms
[14:28:52] <SWPadnos> Valen, latency for what?
[14:29:02] <skunkworks> But if you want to run outputs at the base thread - then you will need the pci card
[14:29:11] <SWPadnos> updating the 7i43 takes maybe 50-80 microseconds
[14:29:13] <Valen> in terms of getting an encoder input, acting on it and sending it back out
[14:29:37] <SWPadnos> encoder from a high speed spindle, a jogwheel, what?
[14:29:45] <Valen> I was assuming that even if the 7i43 is fast it would be faster still for the PCI
[14:29:48] <skunkworks> Valen: that is all done within the mesa hardware
[14:29:59] <SWPadnos> the PCI cards are definitely faster, and will allow you to run a faster base thread if it's needed
[14:30:25] <SWPadnos> skunkworks, not all of it, just hte raw encoder reading and PWM/step generation
[14:30:44] <Valen> my understanding of the hardware as its used by EMC is that it will (i have been looking at it for servo systems) is it just does the PWM out and reads encoder pulses
[14:31:06] <SWPadnos> look at it from the software side:
[14:31:10] <pjm> i cant forsee a situation where i need to output something at base thread speed, as long as i can drive my steppers, and read from encoders, and have gpio pins for buttons, jogwheels etc, then i think the 7i43 is the card for me
[14:31:24] <Valen> if you get too many pulses it could drop some and if you have a hickup in your processing you could have the thing drive the wrong way
[14:31:26] <SWPadnos> every 1ms (by default), read the inputs, do some calculations, then write the outputs
[14:31:43] <SWPadnos> you would need something going 1000 MPH to lose pulses with the mesa hardware
[14:32:29] <Valen> is the mesa hardware actually reading and converting the pulses into a position or is it just toggling a pin and EMC comes along and looks for a change?
[14:32:40] <Valen> my understanding is the latter
[14:32:53] <archivist> fpga, its in the chip
[14:33:15] <SWPadnos> it counts
[14:33:23] <Valen> FPGA is anything you want it to be. mesa have code for it that uses the FPGA as the motion controller
[14:33:37] <SWPadnos> software reads the counts and other info
[14:33:37] <Valen> IE you put the PID loop into the hardware
[14:33:50] <SWPadnos> that's not how we do it. EMC2 uses something in between
[14:33:56] <Valen> I'd like to run that mode personally
[14:34:02] <SWPadnos> maybe, maybe not
[14:34:12] <Valen> whats the negative?
[14:34:19] <SWPadnos> changeability
[14:34:32] <Valen> its a FPGA there should be no difficulty in changing it
[14:34:41] <Valen> the VHDL is given away with the cards
[14:34:44] <SWPadnos> you can configure EMC2 to do just about anything you want, including writing new functions, between the inputs nad the outputs
[14:35:05] <SWPadnos> s/no diffifculty/a possibility/
[14:35:15] <tomp> i think the mesa is keeping a count, and emc gets an update, emc makes a decision, and emc sends new info to mesa, mesa converts a number into a pwm and maybe direction ( rinse lather repeat )
[14:35:40] <SWPadnos> you could certainly make new FPGA configs, but changing how things work on the fly, or just from run to run, is a little harder with the FPGA
[14:35:43] <Valen> VHDL isn't that insane to write in ;->
[14:35:53] <SWPadnos> no, it's just insane to debug :)
[14:36:10] <Valen> lol in some respects ;->
[14:36:35] <Valen> thing is they just implement a micro controller in the FPGA anyway so really your just programming a micro
[14:37:52] <Valen> Heck I'd like to be able to tell the mesa card a single "g-code like" statement about where all the axes need to be and at what rate at time X and let it solve it
[14:38:18] <SWPadnos> the program is part of the VHDL, AFAIK
[14:38:35] <SWPadnos> how would you implement feed override in that case?
[14:38:56] <Valen> what do you mean feed override?
[14:38:57] <skunkworks> Valen: then you don't need emc. There is a basic motion control firmware for the mesa.. (no clue what it does)
[14:39:01] <Valen> estop or something
[14:39:14] <SWPadnos> a single move could take minutes, what if the user tweaks the feed override control during a long move
[14:39:18] <Valen> yeah but you cant feed G-Code into it skunkworks
[14:39:36] <Valen> send it an update SWPadnos
[14:39:49] <SWPadnos> G-code has no provision for updating a move in progress ;)
[14:40:00] <Valen> hence G-Code like
[14:40:13] <Valen> not actual G-Code cos that is big and complex
[14:40:15] <SWPadnos> the softDMC code is great for some situations, but EMC2 really likes to be on control
[14:40:22] <SWPadnos> in control, that is
[14:40:30] <Valen> just the simplest of commands
[14:40:30] <SWPadnos> it is, after all, a machine controller :)
[14:40:40] <SWPadnos> well, if you get it working, let us know
[14:40:54] <SWPadnos> until then, the card counts encoder inputs and reports a binary number to EMC
[14:40:56] <Valen> yeah, It just makes me nervous to have a fully fledged desktop machine running the mill
[14:41:38] <skunkworks> you can make it as 'safe' as you want.
[14:42:07] <Valen> I'm going bog standard EMC first up and i'll play in my "copious spare time"
[14:42:17] <pjm> so the recommended 'firmware' for most mini mill / stepper configs would be the HostMot2 ?
[14:42:48] <Valen> I'm not too concerned about "safe" more about quality
[14:42:49] <SWPadnos> hostmot2 is the way to go at this point
[14:42:56] <SWPadnos> since the driver is maintained and all :)
[14:43:04] <Valen> lol
[14:43:09] <pjm> ok good, thanks - the mesa will be a new world of learning
[14:43:34] <Valen> pjm your one up on me, this is my first step into the world of EMC
[14:43:42] <Valen> tis scary ;->
[14:44:13] <pjm> ah well, u can be relived that windows isnt in control of your machine, that would be scary!!
[14:44:19] <Valen> dern tootin
[14:44:26] <pjm> (real time control that is)
[14:44:40] <Valen> is there a return to home through job command in G-Code?
[14:45:02] <pjm> i put a 'go to home' button on my axis display
[14:45:09] <archivist> most prefer to go around the job you just made
[14:45:18] <pjm> it moves the table out to the front and the Z up so u can change the job
[14:45:20] <Valen> I'd be tempted to run EMC on the most stripped out embedded OS there is, ubuntu-minimal and then just talk to it via network
[14:45:30] <Valen> archivist, i was thinking the windows version ;->
[14:45:40] <archivist> I use the cnc pc for other work as well
[14:45:48] <Valen> (not that ubuntu-minimal is that stripped out)
[14:45:49] <tomp> nothing minimal in ubuntu
[14:46:06] <Valen> the ubuntu-minimal package is kinda small
[14:46:11] <Valen> compared to a DVD say
[14:46:58] <cradek> the motion control part of emc DOES run on a very very minimal "OS" called RTAI. The rest of Linux also runs on it -- but only when there's some spare time between what EMC's doing
[14:48:05] <Valen> RTAI is just an extension to the stock kernel
[14:48:18] <Valen> its not an OS itself
[14:48:32] <cradek> yes, but when RTAI is running, all of Linux is subservient to it
[14:49:03] <cradek> Linux only runs when no realtime tasks need to run
[14:49:24] <Valen> is all of EMC implemented in realtime?
[14:49:42] <cradek> all the motion control is
[14:49:54] <cradek> the gui stuff is not (can't be)
[14:50:15] <cradek> interpreting the gcode is not (doesn't need to be)
[14:50:45] <Valen> unless you run out of Gcode cos youtube is pulling all your CPU ;->
[14:50:58] <cradek> sure, but then motion safely stops and waits
[14:51:14] <cradek> in reality, the gcode reads WAY ahead and the motion gets queued up.
[14:51:33] <cradek> most gcode programs interpret completely in just a few seconds.
[14:52:10] <cradek> it makes not one bit of difference to the realtime code whether youtube is showing (try it!)
[14:52:17] <tomp> does that mean its all queued up in a few seconds?
[14:52:43] <cradek> tomp: yes for some programs. some things can't be queued past (tool change, spindle on/off, etc)
[14:53:08] <tomp> can the queue be dumped to a file?
[14:53:49] <cradek> tomp: sure, that's sort of what the standalone interpreter does
[14:54:03] <Valen> if all that is so why are there different results for latency with a loaded and unloaded system?
[14:54:20] <tomp> thx thats real interesting
[14:54:39] <cradek> tomp: fire up AXIS and open up the EMC Status window. watch "read_line" when you run a program. that shows how far ahead the program is interpreted. When I run the splash screen, it instantly goes to 423 (last line)
[14:55:02] <tomp> ah cool, will try
[14:55:20] <cradek> Valen: because the computer hardware itself is not perfectly predictable
[14:56:25] <Valen> but what does "load" IE userland CPU use have to do with it if its all perfectly handled by RTAPI?
[14:56:51] <anonimasu> how fast the ui responds
[14:56:52] <cradek> it's not so much userland CPU as hardware activity (hard disk interrupts, DMA, etc)
[14:57:58] <cradek> certain hardware can occupy the CPU for a long time without it being available to the software/OS at all (like nvidia cards). obviously there is no software fix for this except to try not to trigger that unfriendly behavior
[14:58:27] <cradek> that's why some hardware is better than other hardware for realtime
[14:58:43] <cradek> removing open office makes no difference -- removing the nvidia card makes a huge difference
[14:59:04] <cradek> often, folks who talk about making special stripped-down distributions don't understand this
[14:59:28] <Valen> mmm good point cradek
[14:59:39] <SWPadnos> running openoffice or glxgears only makes a difference because the userspace code causes functions in the hardware to be activated (bitblt, 3D triangle setup ...)
[14:59:51] <cradek> yes
[15:00:34] <Valen> It still seems like moving the PID loop itself out to hardware (which can handle it) may provide some improvements
[15:01:12] <cradek> when you start moving the realtime code, you lose the flexibility that lets us do many neat things, like rigid tapping
[15:01:23] <Valen> so you can have your NVIDIA card and still get a decent cut
[15:01:35] <Valen> why would you loose rigid tapping?
[15:01:45] <cradek> because you'd need to do it in your special hardware now
[15:01:51] <Valen> its just a co-ordinated move
[15:02:00] <Valen> yeah the mesa card
[15:02:30] <Valen> I was thinking that if you have the ability then you may as well use it
[15:02:31] <cradek> ok, your mesa program just got more complicated, and you can only rigid tap if you buy a mesa card
[15:02:41] <cradek> that's not an improvement, IMO
[15:03:06] <cradek> ppmc and mesa need separate rigid tapping implementations, STG can't do it at all, parport - forget it
[15:03:27] <cradek> I'd rather change my video card :-)
[15:03:34] <cradek> tradeoffs are everywhere
[15:04:21] <Valen> I wasn't saying to remove the functionality from EMC
[15:04:48] <Valen> I was viewing it more as an additional driver for the mesa/ppmc cards
[15:04:58] <cradek> then you have many different implementations to maintain, with no benefit that I can see
[15:05:10] <cradek> what do you think the benefit is?
[15:05:15] <Valen> warm fuzzies? ;->\
[15:05:22] <cradek> haha
[15:05:50] <cradek> that will be a hard sell on the devel list :-)
[15:06:01] <Valen> I just see the computer itself being good for handling complex tasks, and the FPGA being good for hard determinism
[15:06:18] <cradek> yes that's why it counts the encoder pulses for us - it can do it FAST
[15:06:27] <cradek> that's a very good task for it
[15:06:46] <Valen> thing is if you offloaded the PID to the mesa card it could also respond as each pulse came in
[15:07:10] <Valen> at pretty much any pulse rate you cared about
[15:08:03] <cradek> we can already get 10? kHz of servo updates with the current architecture - I don't think any faster speed is needed except for _extremely_ specialized machines
[15:11:42] <tomp> 100uS update!
[15:12:13] <Valen> Its the difference between 92% and 97% I admit
[15:13:06] <Valen> its still a little supriseing given the personality types in the linux world its not been made "better at the expense of good enough" perhaps
[15:13:16] <SWPadnos> more like the difference between 99.5 and 99.9%
[15:14:26] <Valen> same relative difference ;->
[15:14:42] <SWPadnos> sadly, it takes a lot of effort to design a motherboard, and that's about what we'd have to do to improve things
[15:16:24] <SWPadnos> or get some very very specialized debugging equipment, and probably write our own BIOS
[15:16:43] <SWPadnos> but that would of course require access to chipset docs, which are generally only available vie NDA
[15:16:59] <archivist> debugging toys cost
[15:18:03] <Valen> what would you improve over shifting the motion control into a FPGA?
[15:18:31] <pcwalrus> 10 KHz and > sample rates are not too useful unless you are driving a voicecoil/ galvo
[15:18:50] <SWPadnos> motion control in the FPGA isn't a compelte solution
[15:19:02] <SWPadnos> additionally, PID and motion control aren't the same thing
[15:19:49] <SWPadnos> PID keeps something "on track", motion control decides what that track should be, and across multiple "things"
[15:20:20] <archivist> next step is synchronising machines for uber qty of axis
[15:20:40] <SWPadnos> processors inside FPGAs are generally pretty limited, in code space, processing power, or breadth of instruction set (or all 3)
[15:20:52] <SWPadnos> yep, there's that too
[15:20:55] <tomp> would a separate cpu running rtai and emc2, sitting in a pci backplane help the latency problems? the motherboard can be stock and can run any os that can talk to the emc board. this pci card is a bit less than designing a mobo.
[15:21:05] <SWPadnos> what if you need more axes than a single board can support
[15:21:18] <SWPadnos> tomp, I don't know. it's possible
[15:21:29] <Optic> any Java people here?
[15:21:44] <archivist> SWPadnos, I saw some simulation software the other day and largest they dealt with was >200
[15:21:55] <SWPadnos> >200 what?
[15:22:01] <archivist> axis
[15:22:09] <SWPadnos> oh. that's a lot
[15:22:11] <pjm> wow that is a lot!
[15:22:22] <pcwalrus> Having all the loop contol in the PC has many advantages for higher performance systems
[15:22:24] <pcwalrus> If all control is done in FPGA you have the limitations SWP mentioned plus the inaccessibility
[15:22:24] <SWPadnos> Optic, I don't think so (re: java folks)
[15:22:25] <pcwalrus> of the code to a broad range of people
[15:23:09] <SWPadnos> and generally, the code is "precompiled" - ie, you can't change the software that the embedded processor runs without changing the FPGA code itself
[15:23:15] <SWPadnos> (except in rare and more complex cases)
[15:23:39] <SWPadnos> (you should listen to pcwalrus - he designs the Mesa boards ;) )
[15:23:44] <pcwalrus> If the control loop is done on a PC, you have almost unlimited processing power
[15:23:46] <pcwalrus> and a fully open and debuggable system
[15:23:59] <archivist> controls then need their own clock and motion planners and the ability to know how others related are doing
[15:24:20] <SWPadnos> clock sharing is a pretty big topic these days
[15:24:31] <SWPadnos> IEEE1588 is a whole protocol for time sync
[15:24:35] <archivist> seems the way to go
[15:24:46] <SWPadnos> I think SERCOS uses some system tick
[15:24:57] <SWPadnos> which can come from anywhere, to allow for electronic gearing
[15:25:02] <SWPadnos> (or something like that)
[15:25:12] <SWPadnos> john_f may know more about that stuff
[15:25:13] <archivist> one of the toy ones has it after a fashion
[15:25:25] <SWPadnos> mindstorms? :)
[15:25:44] <pcwalrus> (clock sync can alo be handeled by a DPLL in the FPGA that syncs to the software sample rate)
[15:25:59] <archivist> no , can remember the name but I know OIC chips are used
[15:26:03] <tomp> pcwalrus, any ideas on how the pc control loop can avoid the timing interruptions we see ( the 'unexpect realtime delay' issues ) ?
[15:26:04] <archivist> can/cant
[15:27:15] <pcwalrus> Latencys of 100 usec or so are not as much of a problem for servo or hardware stepgen systems
[15:27:17] <pcwalrus> re you asking about longer latencies?
[15:27:36] <pcwalrus> (are)
[15:29:02] <archivist> SWPadnos, I know a local got some cards, have emailed to get the name
[15:29:16] <tomp> my tests showed what appeared to be good systems when tested for hours to go very bad when tested for days. a few milliseconds to tenths of seconds. i dont think others have tested for long periods or reported thier findings if they did.
[15:30:25] <Valen> mmm voice coil driven mill
[15:30:44] <Valen> now that would have a decent traverse speed
[15:33:26] <Valen> tomp are they one offs or do they happen often?
[15:34:14] <cradek> tomp: I leave EMC running for weeks on my lathe and I have never seen the 'realtime delay' error
[15:34:54] <tomp> Valen: teh reports show a max or peak value , i dont recall if several sub peaks existed. i posted the result to the wiki buit they seem to be gone.
[15:35:48] <tomp> yes, i know many people are running without the delay. i say that it is at least not uncommon to see what i saw also. my results were with several different mobos.
[15:36:13] <pcwalrus> Latencies the long would require a buffered motion profile to fix, with all the problems
[15:36:15] <pcwalrus> of splitting the control locus. Dont know where PC motherboards are going latency wise
[15:36:16] <pcwalrus> but I would think tenths of seconds would screw up audio and video as well
[15:39:20] <Valen> they are happy with about 60 frames per second on video
[15:39:26] <eric_unterhause1> I usually see the realtime delay when I start emc
[15:39:41] <Valen> so anything above that is probably not guaranteed
[15:40:10] <BJT-Work> eric_unterhause1: you will only see the popup once per session
[15:40:19] <eric_unterhause1> I know
[15:40:22] <cradek> yeah something needs work then...
[15:40:38] <tomp> yes it may be happening a lot, or jsut once ( inrush latency ;)
[15:40:49] <eric_unterhause1> It seems like my latency measurements are missing something
[15:41:12] <archivist> I retested latency on one here and its changed :(
[15:41:23] <eric_unterhause1> it will change
[15:42:17] <archivist> 12k to 18k
[15:42:34] <eric_unterhause1> you got lucky one time and unlucky another time
[15:43:04] <archivist> I ran for a long time and abused it as much as I could forst time
[15:43:40] <eric_unterhause1> the actual mechanism is not always possible to replicate through intentional abuse
[15:43:51] <Valen> pcwalrus a real world question just to make life interesting, I'm planning on using a bank of lead acid batteries (that i can get for cheap cheap) for a 150V supply for the 2Kw controllers, with a ~300W CC/CV supply to charge them back up again, any pitfalls you can see?
[15:44:34] <cradek> only one, the pitfall is having a bank of lead acid batteries
[15:45:00] <pcwalrus> Use good disconnects and fuzes, since you cant turn batteries off...
[15:45:16] <cradek> Do you have very unreliable power or something?
[15:45:19] <archivist> acid fumes causing a rusty machine
[15:45:25] <cradek> trying to understand why you chose this plan
[15:45:54] <tomp> 2Kw out of a 110 socket wont happen
[15:46:42] <pcwalrus> You dont need that much power for a reasonably sized servo machine anyway (other than spindle)
[15:47:17] <archivist> power is only in bursts except spindle
[15:47:42] <pjm> how about using the same socket type as either big air-con units or electric cookers?
[15:48:12] <tomp> yeh most houses have a 1phase 220 good for 25 to 30A (iirc)
[15:48:43] <tomp> us/ca
[15:49:13] <cradek> yes everyday common 1phase 220 can run a 2-3 hp spindle and servo machine
[15:49:32] <cradek> unplug electric dryer, plug in mill
[15:49:40] <pcwalrus> Also you only need voltage but little current during rapids
[15:49:42] <pcwalrus> and current but little voltage during cutting, so total power
[15:49:43] <Valen> I am planning on using mag motors for the axis drives and I wanted to be able to handle the pulse loads
[15:49:43] <pcwalrus> in a servo system is usually quite low
[15:49:58] <tomp> i got lucky, my house had an electric dryer outlet, ready for my mill
[15:50:12] <Valen> hence using the batteries to supply the pulse load and a 300W for the sustained
[15:50:30] <Valen> I can get ~150V worth of 200Ah lead acids for ~$100
[15:50:31] <pcwalrus> Pulse loads during rapids are a bad thing :-)
[15:50:48] <Valen> I was mainly thinking about being able to start the rapid
[15:50:49] <cradek> I'm sure you know already, but capacitors are the traditional way to do that
[15:51:07] <Valen> you need a *lot* of cap to equal a little bit of battery ;->
[15:51:10] <cradek> true
[15:52:00] <tomp> batteries are 'non-traditional capacitors', one way to get smooth dc is to use a battery
[15:53:14] <pcwalrus> Say you have a 20 peak drive motor, the Hbridge may only require 2-3 A of 150V power
[15:53:15] <pcwalrus> to supply 20A of motor current at 15V and 10% speed...
[15:54:17] <pcwalrus> So unless you have peak torque at full rapid speed
[15:54:18] <cradek> battery banks are a pain because they need to be kept warm, but ideally you want them outside your living/working area because of the hydrogen gas they make
[15:54:18] <pcwalrus> you need a lot less current than you think
[15:55:08] <cradek> sometimes wind-solar energy folks make sealed battery boxes that are indoors but that vent outdoors
[15:55:09] <alex_joni> cradek: maybe you can harvest the gas and build a blimp
[15:55:31] <tomp> oh the humanity
[15:55:37] <archivist> make a fuel cell
[15:55:40] <cradek> tomp: I so wanted to say that
[15:56:48] <Valen> what are people are using for 150V DC supplies off 240V power?
[15:57:00] <Valen> I also have some experience with battery banks from electric cars
[15:57:02] <cradek> just a transformer
[15:57:16] <Valen> although there its normally a bank of lithiums
[15:57:30] <cradek> a 240-120 will give you more like 170 - very common
[15:58:36] <tomp> ask for 'buck boost' trafo, it can go 240-120 or 120-240 as you like, easy to find
[15:58:52] <cradek> I needed 100v dc, a little harder to find a transformer for that
[15:59:07] <Valen> The mag i was thinking of using
[15:59:16] <Valen> S28 -400
[15:59:29] <Valen> has a 5.5 ohm terminal resistance and peak torque at 23A
[15:59:45] <Valen> V = IR so max torque at 0 RPM is 110V yes?
[15:59:53] <BJT-Work> http://www.lcmagnetics.com/?page_id=37
[16:00:02] <Valen> 126
[16:00:15] <cradek> http://www.hgrindustrialsurplus.com/sub/product_detail.aspx?id=80-415-263&searchtable=1&sortExpression=&SortASC=&pageSize=50¤tPageIndex=0&searchNAP=
[16:00:22] <cradek> $50, 5kVA
[16:00:26] <Valen> back soon having dinners
[16:01:18] <skunkworks> pcwalrus:
http://www.electronicsam.com/images/KandT/servostart/schem/latestcurrentlimit/right.JPG
[16:01:27] <cradek> some have multiple taps so you can fine-tune the secondary voltage
[16:02:07] <BJT-Work> 5v to 800v
http://www.antekinc.com/trans.html
[16:02:44] <BJT-Work> hmm too small
[16:03:39] <BJT-Work> SW SP3 download 1753 MB!
[16:03:51] <pcwalrus> skunkworks: neat, sure that capacitor is big enough?
[16:04:08] <tomp> 75V full wave rectified is close to 100V=
[16:04:13] <cradek> wonder what "EL: 1/60/120/240/480" means
[16:04:30] <skunkworks> pcwalrus: what I have a bunch of.. :) 160v 20a so far.
[16:04:45] <cradek> no PV, SV like the others - maybe it's an autotransformer (bad for our app)
[16:06:22] <archivist> our local transformer co closed down :( but at least we got some winding machines
[16:06:29] <pcwalrus> Good to have a bunch of capacitance for regeneration dumping (or have a brake V sensor and dump circuit)
[16:07:15] <cradek> Valen: here is a nice cheap one if 2kVA is enough:
http://www.hgrindustrialsurplus.com/sub/product_detail.aspx?id=06-271-214&searchtable=2&sortExpression=&SortASC=&pageSize=50¤tPageIndex=2&searchNAP=
[16:08:08] <pcwalrus> Cradek: how many VA is the servo supply on your lathe?
[16:08:47] <cradek> pcwalrus: I'm not sure - the transformer came with it
[16:09:10] <cradek> oooh, 435/200 * sqrt2 = 156:
http://www.hgrindustrialsurplus.com/sub/product_detail.aspx?id=07-247-015&searchtable=2&sortExpression=&SortASC=&pageSize=50¤tPageIndex=2&searchNAP=
[16:09:50] <cradek> pcwalrus: the original transformer is single phase (surprisingly) and easy to lift (60lb?)
[16:10:50] <cradek> err, I meant 240 * (200/435) * sqrt2 = 156
[16:11:49] <cradek> derate 50% because of driving the primary at half the voltage, but add a bit because it's rated for 50Hz: probably would give you 3kVA
[16:21:23] <skunkworks> cradek: did you find one for you mill?
[16:22:16] <cradek> yes I have one waiting for it
[16:22:33] <cradek> jmkasunich was kind enough to pick it up and ship it for me (he rocks)
[16:22:42] <skunkworks> nice! :)
[16:23:09] <cradek> I forget how it's marked, but the ratio works out (pretty uncommon)
[16:33:57] <Valen> back for a bit
[16:33:57] <Valen> so yeah like i was saying the worst case for a single drive with those mag motors is 20A at 126 volts
[16:33:57] <Valen> 23A rather
[16:33:57] <Valen> I spose a generic transformer could probably be over driven to source that, but if you had 3 axes do that simultaniously
[16:33:57] <Valen> thats 8.7Kw
[16:33:59] <fenn_> fenn_ is now known as fenn
[16:34:09] <Valen> the best sustained we can pull from mains is 2400W
[16:34:36] <Valen> so its 4x more than your sposed to pull from the wall, excluding running the spindle
[16:35:01] <pcwalrus> thats roughly 2500 VA / motor peak, but 2500 VA will likely run all three axis just fine
[16:35:15] <cradek> Valen: do you not have 240V power available?
[16:35:26] <Valen> australia its the default
[16:35:29] <Valen> 240 that is
[16:35:38] <Valen> but its 240v at 10A
[16:35:44] <cradek> why only 2400W then? that's inadequate for many appliances
[16:35:58] <Valen> it runs all the ones we have lol?
[16:36:16] <Valen> the only thing thats wired seperatly in most houses is an electric hot water system
[16:36:17] <cradek> do you not have electric clothes dryers or ovens?
[16:36:27] <Valen> oh yeah and some cook tops
[16:36:37] <cradek> ok you need to plug in to one of those places :-)
[16:36:48] <Valen> those are typically hard wired
[16:36:55] <cradek> yeah I understand
[16:37:08] <Valen> as in the applience comes with bare wires or a terminal block on it
[16:37:20] <cradek> sorry, I didn't mean that literally
[16:37:37] <cradek> I mean you have the power available in your house - you could hook up to it somehow
[16:37:47] <Valen> you see why the lead acid bank sounds nice in some respects
[16:37:57] <Valen> if i can get them for ~$100
[16:38:16] <Valen> thats about $60 US atm lol
[16:38:27] <cradek> not really, when compared to a $50 transformer with no maintenance or storage problems
[16:38:49] <Valen> true that
[16:39:05] <Valen> how much can you pulse overload a typical supply by?
[16:39:15] <Valen> as in the wall
[16:39:35] <cradek> saturating the transformer is the issue - if you do it too much, it will overheat
[16:40:23] <pcwalrus> Your spindle will be the real energy drain
[16:40:24] <pcwalrus> 2.5 KVA will run your motors just fine
[16:40:43] <cradek> very true
[16:40:49] <Valen> i have no problems with the sustained load, thats going to be 200W or so per motor tops
[16:40:58] <Valen> its the peak that worries me
[16:40:59] <archivist> capacitors deal with the pulses
[16:41:18] <cradek> I bet accel current requirements aren't as bad as you think
[16:41:22] <cradek> how heavy is the machine?
[16:41:33] <Valen> ~500kgs
[16:41:37] <archivist> transformers and diodes can deal with overloads
[16:41:44] <cradek> yes
[16:41:46] <Valen> direct drive servo motor
[16:41:58] <cradek> oh, so it's tiny :-)
[16:42:03] <archivist> :)
[16:42:04] <cradek> bbl
[16:42:23] <Valen> I am still looking at pulling 4X the rated current from the wall on a burst excluding the spindle
[16:42:55] <archivist> Valen, peak pulses from the mains are way bigger than 4x
[16:42:58] <pcwalrus> Peak load will be starting from stop, so the power supply will not see it (only the motors)
[16:43:00] <pcwalrus> The Hbridges work as switching power supplies so you can get your 23 stall current with
[16:43:01] <pcwalrus> only a few amps of primary power
[16:43:20] <Valen> its 23A at 126 volts
[16:43:32] <pcwalrus> No its not...
[16:43:35] <archivist> 12A at 240
[16:43:39] <Valen> 5.5 ohm terminal resistance
[16:43:47] <pcwalrus> No No NO
[16:43:53] <Valen> 23 * 5.5 = 126
[16:44:04] <pcwalrus> Explode!
[16:44:06] <Valen> V != IR?
[16:44:10] <archivist> doesnt work like that for inductive load Valen
[16:44:22] <pcwalrus> Not under control
[16:44:47] <Valen> so how do you get 23A without putting 126 volts through it with 5.5 ohm terminal resistance?
[16:45:14] <Valen> otherwise there is no way of getting the peak torque out of the motor
[16:45:29] <pcwalrus> You do but only for VMotor/VPower duty cycle
[16:45:35] <archivist> you never have the peak for that long
[16:45:45] <Valen> I understand its "not that long"
[16:46:02] <Valen> but "not that long" is different to "never"
[16:46:23] <archivist> any time its at peak its not under full control
[16:46:55] <Valen> why not? I assume that you should be able to hit a decent % of peak otherwise theres no point having it
[16:47:13] <Valen> so say 18A at 100 voltd
[16:47:17] <Valen> volts
[16:47:30] <anonimasu> the ting is that you never load your machine while doing rapids..
[16:47:35] <pcwalrus> so at 10% speed and peak torque your HBridge is on for 10% (say 5 usec) and off for 45 usec
[16:47:37] <pcwalrus> so the average supply current to the bridge is only 2.3A.
[16:48:20] <Valen> at 10% speed it needs to be > 126 volts in order to *get* the peak torque
[16:48:33] <Valen> I am not looking at peak amps and peak volts and multiplying
[16:48:39] <pcwalrus> the high frequency peak currents are supplied by Skunkworks gigantic capacitor
[16:48:52] <pcwalrus> It is (for 5 usec)
[16:49:12] <Valen> PWM doesn't invent power
[16:49:22] <Valen> power into the bridge = power out
[16:49:28] <Valen> volts * amps = volts * amps
[16:49:52] <pcwalrus> Yes but you never need peak torque during rapids
[16:50:00] <anonimasu> you need peak torque to get up to speed...
[16:50:05] <Valen> how do you start the rapid?
[16:50:11] <Valen> at some stage you need to accelerate
[16:50:27] <pcwalrus> at 0 speed ;-)
[16:50:27] <archivist> for only milli secs
[16:50:32] <anonimasu> calculate how much power goes into accelerating your table to your rapid speed..
[16:50:47] <pcwalrus> (its not much)
[16:51:21] <Valen> If you hit top speed in a second its alot for a cap to supply
[16:51:29] <Valen> even in a quater of a second
[16:52:10] <Valen> (assuming the top speed is lower and the power output is constant)
[16:53:14] <archivist> you would be surprised at the energy available in agood sized cap
[16:53:22] <pcwalrus> You can ony get 1/2 peak at 1/2 full speed
[16:53:24] <Valen> boostcaps perhaps
[16:53:36] <pcwalrus> sorry 1/2 peak torque
[16:54:06] <Valen> peak torque occurs whenever you are at peak amps
[16:54:29] <Valen> its the number of electrons moving past the magnets that provide the force
[16:54:34] <Valen> more amps = more force
[16:54:38] <pcwalrus> You cant get ther when the motor is moving (BEMF)
[16:54:47] <archivist> peak torque with a stationary motor
[16:54:57] <Valen> you need more volts at speed to get the same amps to counter the back emf
[16:55:18] <Valen> untill you reach the peak voltage or instantanious power limits of the motor
[16:56:09] <pcwalrus> Yes peak current is stationary only
[16:56:11] <pcwalrus> at i/2 speed you only have 63V to drive your 5 Ohms
[16:56:52] <Valen> unless you raise supply to 126+63 volts
[16:57:01] <pcwalrus> explode
[16:57:07] <archivist> which one never does
[16:57:36] <Valen> and what makes it instantly explode if you are below the peak power rating of the motor?
[16:57:44] <Valen> ok lets scale it all the way down
[16:58:10] <Valen> you have a teensy servo drive that saturates its iron at 1A and needs 10V to do so
[16:58:22] <Valen> so peak torque is at 1A
[16:59:04] <pcwalrus> OK
[16:59:06] <Valen> you wouldn't think twice about running that motor with a 20 volt supply and putting 15 volts at 1A into it
[16:59:19] <Valen> your bridge doing a nice little step down
[16:59:51] <Valen> if you can overload the transformer in the wall by 8X you can do the same to the motor, the only difference is one has a set of brushes in it
[17:03:00] <Valen> actually with regards the "explode" commitment
[17:03:21] <Valen> the primary heat source in an electric motor is I^2R
[17:03:30] <pcwalrus> Well for brush motors especially overvoltage is not a good thing
[17:03:46] <Valen> agreed
[17:04:08] <Valen> but you can have a motor that will have a much higher maximum voltage than its stall voltage
[17:04:18] <Valen> IE current squared * resistance
[17:04:25] <Valen> thats the source of 90% of the heat
[17:05:05] <Valen> so 126V at 23A generates the same internal heat in the motor (to a first aproximation) as 150V at 23A
[17:05:31] <Valen> the excess energy in the 150V case is that which is actually doing work and going into the job
[17:05:46] <Valen> at stall the motor is perfectly inefficent and is just wasting all that energy
[17:05:52] <pcwalrus> Sure, thats the normal situation stall is usually 3-5 times continous rating
[17:06:20] <Valen> All i'm saying is that if you can maintain stall for .25 of a second
[17:06:40] <Valen> you can have that same current flowing and bring the voltage up as the item gets moving
[17:07:00] <skunkworks> http://www.electronicsam.com/images/KandT/servotag.JPG
[17:07:05] <skunkworks> look at the stall volts...
[17:07:29] <skunkworks> this motor is made to take 150v to get 1200rpm
[17:07:50] <Valen> yup?
[17:08:12] <Valen> you can sit 14 volts across it stalled permanently or 59 for a short while
[17:08:39] <Valen> so you can push 16.2 A through it continiously at any voltage up to 150V
[17:09:45] <skunkworks> yes - but at 0rpm for the motor to take 16.2a - the voltage across it is only 14v
[17:09:58] <Valen> yes thats correct
[17:10:16] <pcwalrus> So at stall (0 speed) the HBridge would draw about 1.6A
[17:10:31] <Valen> if you were to operate at its continious rating at stall
[17:10:56] <pcwalrus> and about 6A peak stall
[17:11:06] <Valen> yes
[17:11:15] <Valen> no
[17:11:46] <Valen> the *motor* current will be 82 amps and the supply current will start off at 6A
[17:11:55] <anonimasu> skunkworks: it's too bad you dont have the time constant
[17:11:59] <skunkworks> pcwalrus: now you lost me. When I have the clamp on amp meter on the servo - it is taking 16.2a at a stall (what the current limit of the h-bridge is set to)
[17:12:04] <Valen> but if you keep the same torque as the motor speeds up the supply current will increase
[17:12:48] <Valen> so you can run that motor up to ~1/3rd its peak speed at its peak torque
[17:12:56] <pcwalrus> sorry 82 *59/150 =~30 A but not 82!
[17:13:16] <Valen> the max stall current on that motor is 82A
[17:13:32] <anonimasu> Valen: PEAK...
[17:13:40] <Valen> ffs i understand peak
[17:13:52] <anonimasu> for that to be useful you need a time constant...
[17:13:53] <Valen> it means maximum
[17:14:13] <Valen> true, typically i believe its around 10 seconds
[17:14:42] <pcwalrus> Skunkworks put the ampmeter on the hBridge supply also
[17:15:06] <Valen> ok the 2 cases
[17:15:10] <skunkworks> pcwalrus: I remember it being pretty close to the same...
[17:15:19] <skunkworks> but I could be wrong
[17:15:29] <Valen> in both cases the motor will be putting out maximum torque
[17:15:42] <Valen> in effect we are seeing how fast the motor can accelerate a mass
[17:15:46] <pcwalrus> Skunkworks: with 150 v supply?
[17:15:47] <skunkworks> pcwalrus: this is a fast decay bridge. (both bottom fets are off)
[17:15:55] <skunkworks> * on
[17:16:00] <skunkworks> when the pwm is off.
[17:16:06] <Valen> we do this without breaking the maximum current or maximum voltage specs
[17:16:07] <skunkworks> pcwalrus: yes
[17:16:25] <skunkworks> or is that call slow decay? I don't remember
[17:16:50] <pcwalrus> Thats fast decay (max ripple)
[17:17:17] <skunkworks> so the servo gets shorted thru the bottom 2 fets when pwm isn't present.
[17:17:20] <Valen> starting off, motor current is 82A, motor volts are 59V motor power = 4838W , H bridge power = the same, if its supply voltage is 150V its amp draw is 32A
[17:17:41] <Valen> now we assume its .25 of a second later and the motor has accelerated somewhat
[17:17:44] <pcwalrus> OK thats slow decay
[17:18:19] <skunkworks> pcwalrus: so - I would assume that is why current in is pretty close to current out?
[17:19:06] <pcwalrus> No you should have much lower supply current then motor current at stall
[17:19:29] <Valen> the same 82A now at the maximum voltage the motor can handle, motor power is 12300W, (of which 8000W is going into the load, the heating in the motor is the same) supply current is now 82A
[17:19:32] <skunkworks> well that is interesting. I am pretty sure it is close to the same.
[17:19:38] <pcwalrus> (at peak torque and .25 seconds later, your at rapids speed)
[17:20:10] <Valen> yes, and at that point your power draw is going to drop off to practically nothing
[17:20:27] <pcwalrus> Thats the point!
[17:20:52] <Valen> the point is at the end of that .25 of a second you were pulling 12300W
[17:21:03] <Valen> which is 82 amps from the supply
[17:22:08] <pcwalrus> You can never get 82A from the supply
[17:22:27] <Valen> you can if its a stack of 200Ah lead acid batteries ;->
[17:22:38] <Valen> its a fairly stiff supply ;->
[17:23:05] <Valen> pulling 8Kw from that battery bank i'd expect it to sag ~10v
[17:23:23] <skunkworks> and what kind of H-bridge are you going to build?
[17:23:29] <skunkworks> that can hadle that?
[17:23:34] <skunkworks> *handle
[17:23:38] <Valen> actually i was going to use the mesa 20A 2Kw supply
[17:24:03] <skunkworks> ok - so why are we having the conversation? ;)
[17:24:05] <Valen> its within the limits of that (if i tone it down to 20A) and limit the top speed of the servo to 2500RPM or so
[17:24:12] <justa> Black Mesa. research lab ?
[17:24:36] <Valen> because you were all saying that a 300W transformer is going to run my 8-16KW worth of peak load ;-P
[17:25:05] <pcwalrus> You will never see the peak load
[17:26:02] <pcwalrus> Unless you use max stall torque for rapids acceleration
[17:26:04] <pcwalrus> (probably a bad idea)
[17:26:16] <Valen> i was going to use something near it
[17:26:23] <Valen> not peak obviously
[17:26:36] <Valen> I just don't see the point in having mismatched equipment
[17:26:51] <pcwalrus> 2 KVA should be plenty
[17:27:06] <Valen> if the motors, ballscrews and controllers can handle it then i assume i should have a supply to match
[17:27:28] <Valen> I'll keep an eye out for one, i think they are a little rarer in australia lol
[17:27:33] <Valen> theres just fewer people
[17:29:09] <Valen> anyway its 3:30 AM here and the missus is pissed
[17:29:21] <Valen> catch you all in a few hours
[19:11:24] <skunkworks> maybe gave up?
http://www.cnczone.com/forums/showthread.php?t=77819
[19:13:06] <archivist> didnt see what software he failed with
[19:14:45] <alex_joni> maybe he gave up CNC-ing :)
[19:17:04] <skunkworks> he had been working with emc but had lots of issues
[19:18:14] <alex_joni> odd
[19:18:17] <BJT-Work> yep he had lots of issues
[19:18:56] <archivist> what was his nick in here, or did he never come in here
[19:22:46] <BJT-Work> I don't remember
[19:27:19] <anonimasu> for some nothing works..
[19:27:28] <anonimasu> and for others it just works...
[19:29:11] <archivist> hmm pc and latency
[19:44:54] <skunkworks> lerneaen_hydra: Long time no see...
[19:45:32] <lerneaen_hydra> skunkworks; hey there, yeah it's been a while since I was active here, though I've been idling for a while
[19:45:53] <cradek> hey LH
[19:45:58] <cradek> still using your little lathe?
[19:46:52] <lerneaen_hydra> yeah, it's working just great with the bleeding edge CVS snapshot I've got on it (knock on wood), though I haven't really used it as much recently. I've done more in the way of electronics. Still, I use it now and again
[19:47:09] <lerneaen_hydra> how goes EMC2? any new slick features?
[19:48:49] <cradek> a whole mess of 'em:
http://cvs.linuxcnc.org/cvs/emc2/debian/changelog?rev=1.62
[19:48:52] <alex_joni> a "short" feature list for 2.3
[19:49:15] <lerneaen_hydra> any new cool machines that people have made? anything new or unorthodox?
[19:50:32] <cradek> I haven't seen much like that lately... stuart's doing his 5 axis machine but that's not too unorthodox
[19:51:04] <archivist> stepconf: /me contemplates adding a bug, should read ini file and edit not its own stepconf file
[19:51:43] <lerneaen_hydra> any progress with the PUMA-style robots? IIRC jepler was doing some simulation of one in opengl
[19:51:53] <cradek> archivist: that's pretty much impossible, I think. consider the HAL stuff it writes and that you might change.
[19:52:33] <cradek> lerneaen_hydra: skunkworks has one that he's going to have going any day now
[19:52:36] <archivist> impossible or just damned difficult
[19:52:47] <skunkworks> any day.. any day..
[19:52:50] <cradek> in fact, he's going to have it running and bring it to fest in May :-)
[19:53:05] <lerneaen_hydra> nice =)
[19:53:12] <cradek> he better get started, fast
[19:53:13] <archivist> with or without smoke
[19:53:26] <skunkworks> I tell you - no smoke
[19:55:11] <SWPadnos> hmmm. is there a logo that says "smoke inside" yet? :)
[19:55:12] <archivist> an enemy let the smoke out of one of my chinese multimeters the other day
[19:55:12] <lerneaen_hydra> one thing I was thinking about a while back was the choice of PID for closed loop control, I take it there's nothing that says that PID is the optimal regulation system, but rather one chosen for it's proven track record and relatively low calculation cost?
[19:55:13] <cradek> skunkworks: "Price?" "PM'd you." "Thanks anyway"
[19:55:13] <lerneaen_hydra> SWPadnos; haha, that would be great
[19:55:15] <SWPadnos> it's simple, reliable, and proven. I'm sure it's also not the only thing that can be used
[19:55:16] <cradek> lerneaen_hydra: we use PID+FF, fwiw
[19:55:18] <lerneaen_hydra> FF = feed forward?
[19:55:26] <cradek> yes
[19:55:35] <cradek> we have FF of the first couple derivs
[19:55:42] <lerneaen_hydra> oh, cool. how is the system modeled for feed forward?
[19:55:43] <cradek> helps a ton
[19:55:46] <lerneaen_hydra> oh from the PID model?
[19:56:19] <cradek> += K* for each of commanded position, ddt, ddt2
[19:56:49] <cradek> K*position is pretty useless, but K*vel and K*accel are very useful
[19:58:13] <lerneaen_hydra> oh, ok, that's interesting. how well does a correctly tuned system track? more than good enough (as in far less than any possible system's stability/accuracy)?
[19:58:21] <cradek> any closed loop control that can move a wide variety of mills at accel, rapid speed, decel, and stay within a few encoder counts is sure good enough
[19:59:00] <lerneaen_hydra> oh, a few encoder counts? that's really good
[19:59:01] <cradek> yeah my results are very good. I think on my lathe I have the following error trip set at .002 inches and it rapids at 250 inch/min (pardon my inches)
[19:59:44] <lerneaen_hydra> whoa, nice. I take it the following error at lower speeds is far less?
[19:59:52] <skunkworks> cradek: what is your error at say 10ipm?
[20:00:02] <cradek> "a few" is relative - I have 409600/inch iirc
[20:00:08] <lerneaen_hydra> if you've got an encoder with a high enough resolution that is
[20:00:18] <cradek> skunkworks: .0002 I bet
[20:00:22] <skunkworks> nice
[20:00:22] <cradek> inches
[20:00:32] <lerneaen_hydra> not bad at all
[20:01:18] <cradek> the .002 is set so high because there's a little spike of ferror when it jerks (beginning and end of accel regions)
[20:01:37] <cradek> that's hard to get rid of without a better trajectory profile
[20:01:43] <lerneaen_hydra> oh, so it applies an infinite da/dt?
[20:01:50] <cradek> yes
[20:02:13] <lerneaen_hydra> right, that'll cause some (possible) problems obviously
[20:02:27] <cradek> the problem is very small on all machines I've worked on so far
[20:02:36] <cradek> on an extremely high accel machine it is worse I bet.
[20:03:11] <cradek> oops, my resolution is 204800/inch
[20:03:52] <skunkworks> mine will only be 60960
[20:04:00] <cradek> http://timeguy.com/cradek-files/emc/no-backlash.png
[20:04:15] <cradek> I rigged a glass scale to X to get this plot
[20:04:38] <cradek> red line is the resolver, cyan is the glass scale
[20:05:08] <skunkworks> very neat
[20:05:29] <skunkworks> was that the ballscrew you re-loaded?
[20:05:32] <cradek> .001" per div
[20:05:36] <lerneaen_hydra> oh, uh, resolver, that's a cos/sin analog output from the drive axis right? and glass scale is a quadrature-type length sensor?
[20:05:38] <cradek> no, this is the good one :-)
[20:05:47] <cradek> lerneaen_hydra: yes
[20:06:00] <lerneaen_hydra> that's not a whole lot of backlash
[20:06:03] <cradek> the resolver is on the ballscrew itself on this lathe - very precise
[20:06:28] <cradek> no, it has very very little on X
[20:06:34] <lerneaen_hydra> that's under 20 microns in backlash, that seems suspiciously low
[20:06:41] <cradek> it is real
[20:06:50] <lerneaen_hydra> congratulations :)
[20:07:18] <cradek> I think it's less than that, actually
[20:07:35] <cradek> consider that you need to read the value from the glass scale as it changes, which is the right side of the up or down step
[20:08:40] <lerneaen_hydra> oh, true. you need a better glass scale
[20:08:56] <lerneaen_hydra> do you use both sensors when running?
[20:10:57] <alex_joni> 22:55 < cradek> I rigged a glass scale to X to get this plot
[20:11:03] <alex_joni> that sounds like testing only :)
[20:11:17] <lerneaen_hydra> ah, oops
[20:12:37] <skunkworks> I might actually have my h-bridge working the way I want..
[20:12:42] <skunkworks> If that is exciting
[20:13:20] <lerneaen_hydra> how was it working when it didn't work the way you wanted?
[20:14:22] <skunkworks> started out with too much noise in the logic. Then the current limit was not working great. then I hit the limit of the mosfets I had..
[20:14:55] <skunkworks> so I just did the smoke test of 160v/20a and so far so good.
[20:15:20] <lerneaen_hydra> that's quite a lot of power
[20:15:52] <lerneaen_hydra> how's the current limit work? series resistor somewhere and some amplification and averaging?
[20:16:31] <skunkworks> mainly comparator comparing the voltage across the sense resistor against the reference voltage
[20:16:53] <skunkworks> messy schematic
http://www.electronicsam.com/images/KandT/servostart/schem/latestcurrentlimit/latestschem.png
[20:17:05] <lerneaen_hydra> oh so it's just an ok/not ok current sense
[20:17:25] <skunkworks> ended up adding 'blanking' also so it doesn't see turn on spike of the devices.
[20:18:09] <skunkworks> it is cycle by cycle current limit. - current trips - has to wait until the next pwm rising edge before the current trip is reset.
[20:18:31] <lerneaen_hydra> oh, why use gate resistors? EMC? burning out the mosfet driver?
[20:19:22] <skunkworks> It was just to slow the turn on just a bit.
[20:19:48] <lerneaen_hydra> why would you want that?
[20:20:03] <skunkworks> mosfets ring if they are turned on too fast.
[20:20:25] <skunkworks> puts some nasty noise in things
[20:20:49] <lerneaen_hydra> um, what? oscillation where? gate capacitance and wire-to-gate inductance LC resonance?
[20:21:01] <lerneaen_hydra> what type of risetime do you have?
[20:22:04] <skunkworks> 9&*@
[20:22:08] <skunkworks> heh
[20:22:34] <skunkworks> 680ns on and 270ns off. All part of the gate drive
[20:22:41] <cradek> Q9R&*@RNY^N ?
[20:23:16] <skunkworks> copy and past error
[20:23:41] <skunkworks> I am actually using igbt's for the final solution
[20:24:18] <lerneaen_hydra> oh, do they get hot?
[20:25:22] <lerneaen_hydra> I'd assume that with about .5µs for rise/fall time and say 100µs period time then you'll dump 16W in them if you've got 20A and 160V @ 5khz
[20:25:35] <skunkworks> they get slightly warm so far.
[20:25:56] <skunkworks> 20khz
[20:26:23] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/schem/latestcurrentlimit/right.JPG
[20:27:29] <lerneaen_hydra> oh, that's quite the heatsink and capacitor
[20:28:14] <lerneaen_hydra> surely the stray inductance in 15cm wire isn't that bad?
[20:28:21] <lerneaen_hydra> ;)
[20:31:36] <skunkworks> heh
[20:33:14] <alex_joni> well.. off to bed for me
[20:33:17] <alex_joni> good night all
[20:33:22] <lerneaen_hydra> 'night
[20:44:12] <Optic> * Optic thinks about going
[22:20:30] <Guest247> hello
[22:21:02] <BigJohnT> hi
[22:21:08] <Guest247> anybody on that can answer a stepconf question, specifically how to set home_ingnore_limits?
[22:21:21] <BigJohnT> ask away
[22:22:18] <Guest247> I have a switch on each end of the axis, bot wired to the same pin. One end I want as a limit the other end as home.
[22:22:49] <BigJohnT> you can use the home switch as both a limit and a home
[22:23:04] <Guest247> But how do I do that with stepconf
[22:23:35] <BigJohnT> let me load up sc
[22:23:50] <Guest247> if I answer both limits and home I get a joint error when it hits the home end
[22:24:19] <BigJohnT> is your home switch not near the end of the travel?
[22:24:33] <Guest247> yes it's near the end of travel
[22:25:08] <BigJohnT> then it is working if you get an error when you jog into the home/limit switch
[22:25:56] <Guest247> the problem is when do a HOME action, it doesn't ingnore the limit action of the switch
[22:26:17] <BigJohnT> ok, now I understand
[22:27:09] <Guest247> looking at the documentation there is a variable home_ignore_limits that is used as a part of the homing sequence I suspect is the variable that stepconf needs to set
[22:27:19] <Guest247> to the proper state
[22:27:20] <BigJohnT> are you sure you have them wired correctly? homing joint0 gives a joint 0 error...
[22:27:26] <Guest247> yes
[22:27:42] <BigJohnT> 2.2.x or 2.3 beta?
[22:27:50] <Guest247> 2.2.x
[22:28:44] <BigJohnT> look in your ini file for ... let me look it up
[22:29:18] <Guest247> I'm away from the machine, it's at a different location
[22:29:56] <Guest247> no internet connection at the machine
[22:30:27] <BigJohnT> in the ini file make sure you have HOME_IGNORE_LIMITS = YES in each AXIS section... should be one section for each axis
[22:30:55] <BigJohnT> stepconf should do this automagiclly
[22:31:46] <pjm_> evening, i have limit switches at each end of the travel on X, Y axis and i have HOME_IGNORE_LIMITS = YES, HOME_SEQUENCE = 1 in my INI
[22:31:51] <Guest247> thanks, I'll look at it and get back with you in ten minutes or so
[22:32:21] <BigJohnT> pjm one should have home sequence 0
[22:33:08] <pjm_> ah yes Z is homed first, idea is that it moves it up out the way of the table before X,Y move around
[22:33:24] <BigJohnT> HOME_SEQUENCE
[22:33:26] <BigJohnT> numbers start with 0 and there may be no unused numbers.
[22:33:39] <BigJohnT> hmmm, that pasted funny
[22:33:52] <pjm_> heh, yeah i have z=0, x=1, y=2
[22:34:14] <BigJohnT> you can have x and y home at the same time if you want
[22:34:23] <BigJohnT> I like to watch each one
[22:34:50] <pjm_> ah yeah i did wonder about that, just set the sequence on both to 1 for example?
[22:35:00] <archivist> I can imaging some fixtures changing the homing sequence
[22:35:03] <BigJohnT> yep
[22:35:45] <pjm_> cool, i didnt know that. actually i found in my boxes of crap, 3 of these inductive position sensor things, so i'm gonna try one out as the Z home switch
[22:36:11] <BigJohnT> * BigJohnT wanders off to check on the cat
[22:36:33] <pjm_> they are tubes about 75mm long with M10 thread around them, a plastic window one end and some connector the other, when u put ferrous metal near them the light comes on ;-)
[22:36:46] <archivist> pjm do you have the needed electronics for those sensors
[22:37:04] <BigJohnT> sounds like a prox
[22:37:10] <pjm_> well i put a meter on the output, and there is a line that toggles to 12V when near metal
[22:37:20] <pjm_> co-incides with the LED coming on
[22:37:31] <archivist> ah proximitry not lvdt as I thought
[22:37:33] <pjm_> so probably just run it into an opto and logic out into the card
[22:41:17] <pjm_> hmm just looked on ebay at the prices these mitsubishi PLC's go for! wow, it would fund my mesa card plus a couple of break out boards with optos etc!
[22:42:26] <archivist> some fleabay prices are way too high
[22:42:37] <pjm_> yeah! well i'll stick one of these on and see what happens
[22:42:49] <pjm_> hopefully it will go far too high!!
[22:43:13] <pjm_> i found a error in my wiring tonite, i missed a shield ground connection
[22:43:28] <pjm_> the sympton was quite interesting, on the Z axis i have up/down buttons
[22:43:33] <archivist> the noise cured now?
[22:43:40] <pjm_> and starting the spindle at 3000rpm made Z move down 5mm or so
[22:44:05] <Guest247> I looked at my ini file and home_ingnore_limits = yes. Problem is when it's at home it gives me a "joint 0 in limit switch error" and is unmovable
[22:45:03] <Guest247> I have to manually move it off "home" which makes "home" worthless
[22:45:15] <pjm_> Guest247 i recall having a simiar problem when i set up my mill, it was sometihng to do with the homing direction i think
[22:45:17] <Guest247> emc is 2.2.8
[22:45:39] <pjm_> so it travels towards the switch, backs off a bit, slowly travels towards it again, then backs off and rapids to a datum
[22:46:39] <Guest247> if I set it up as home only in stepconf it's fine, it's trying to use it in conjunction with a limit switch on the same pin
[22:46:52] <Guest247> that is the problem
[22:47:39] <pjm_> one sec just looking in my config
[22:48:02] <pjm_> so in the .hal i have net both-home-x <= parport.0.pin-10-in
[22:48:21] <pjm_> then net both-home-x => axis.0.home-sw-in
[22:48:22] <pjm_> net both-home-x => axis.0.neg-lim-sw-in
[22:48:22] <pjm_> net both-home-x => axis.0.pos-lim-sw-in
[22:49:14] <Guest247> in your ini file is home_is_shared set?
[22:49:27] <pjm_> let me check
[22:49:52] <pjm_> no i dont have that in the file
[22:50:28] <Guest247> I'll look at my hal file
[22:50:51] <pjm_> my last set of backups of the configs are at
http://pjm.dyndns.org/cam/pjm_emc2_configs_230109/configs/my-mill/
[22:50:58] <pjm_> if u want to pick through
[22:51:16] <pjm_> its a stepper machine with limit/home switches each end of X,Y travel, and Z+ travel
[22:54:49] <Guest247> my hal is setup the same as yours
[22:54:58] <pjm_> ah ok good
[22:55:09] <Guest247> yes but yours works
[22:55:20] <pjm_> so when u home X for example, which way does the table move?
[22:55:50] <pjm_> i think my initial problems were to do with the direction
[22:56:01] <Guest247> I defined my home as -.5 not zero I wonder if that could be it
[22:56:11] <pjm_> possibly
[22:56:22] <pjm_> as that may be past the switch?
[22:56:43] <Guest247> no the switch es defined as -.5 also
[22:56:51] <pjm_> ahh ok
[22:56:58] <pjm_> that should be ok then
[22:57:24] <pjm_> i thikn the home and limit switch positions can be defined anywhere in terms of position
[22:58:03] <Guest247> I could modify the hal file to disconnect one of the limits, but I would like to do it via stepconf rather than manually
[22:58:25] <pjm_> btw is the homing speed slow enough?
[22:58:36] <pjm_> so the mass can stop in time etc
[22:58:56] <pjm_> i smashed a few microswitches during the initial learning process
[22:59:01] <Guest247> I tried various home speed setting with no difference
[22:59:37] <Guest247> thanks for the help, I'll go try some other things
[23:00:02] <pjm_> ok np, check the max / min limits
[23:00:16] <pjm_> and the home offset / home =
[23:00:36] <BigJohnT> Guest247: did you make any headway?
[23:00:40] <pjm_> ok i need to hit the sack, its midnight already, catch u folks tmw, gn all!
[23:00:49] <BigJohnT> g'night
[23:01:44] <Guest247> no not really
[23:02:21] <BigJohnT> does it error on the first contact with the home switch?
[23:03:05] <Guest247> I'm not sure I can check
[23:04:07] <BigJohnT> the basic is it travels toward the home switch at search speed then backs off then goes back at final speed (slower) then moves to home position
[23:04:15] <BigJohnT> so that is three moves
[23:06:51] <Guest247> it does it after the 3rd move
[23:07:19] <BigJohnT> the move to the final position. did you tell it that home was just a bit away from 0?
[23:07:45] <Guest247> hoe is defined as -.5 not zero, same for the position of the switch
[23:08:19] <BigJohnT> does minus move that axis away from the switch?
[23:08:41] <Guest247> no plus moves it away fron the switch
[23:08:58] <Guest247> axis is defined as -.5 to +x inches
[23:09:03] <BigJohnT> make your home position 0.5 then
[23:09:23] <Guest247> ?
[23:09:58] <Guest247> switch is at the end of travel (not absolute end)
[23:10:09] <BigJohnT> not the axis limits but the home position
[23:11:21] <BigJohnT> what do you have for the home switch location?
[23:11:23] <Guest247> the actualy axis limit is set to -.9 home switch is defined as -.5
[23:11:26] <SWPadnos> if the switch is at -0.5, you could just make HOME_POSITION=0.0, and HOME_OFFSET=-0.5 (or +0.5, I don't know which way the sign goes)
[23:11:49] <BigJohnT> I don't think there is a home offset in stepconf...
[23:11:52] <SWPadnos> this will move to 0.0, which is off the switch, as the last step in the homing sequence
[23:12:02] <SWPadnos> no, I don't think the homing parameters are in there
[23:12:33] <SWPadnos> actually, they are there in 2.2
[23:12:36] <BigJohnT> home switch location, search vel, latch dir, home location
[23:12:46] <BigJohnT> is home switch location really home offset?
[23:12:51] <SWPadnos> or at least in 2.3 beta (I'm not swure which one I compiled here)
[23:13:02] <SWPadnos> I bet it is
[23:13:15] <BigJohnT> I'm thinking your right
[23:13:22] <Guest247> what is the difference between home_position and home_offset
[23:13:52] <SWPadnos> one of them tells where the switch is, the other tells EMC where you want that axis to move to after homing
[23:14:29] <Guest247> so if I don't want it to move off of home I can set it equal t the home switch location, correct
[23:15:25] <Guest247> my switch is located at machine -.5 inches, home_position=-.5, home_sequence=0.5
[23:15:43] <Guest247> correction
[23:15:44] <SWPadnos> if you don't move off the home switch, you can't also use it as the limit switch
[23:16:12] <Guest247> my switch is located at machine -.5 inches, home_position=-.5, home_offest=-.5
[23:16:26] <Guest247> ahh
[23:16:31] <Guest247> thats the problem
[23:16:55] <SWPadnos> HOME_IGNORE_LIMITS will ignore the limit switch while homing, it doesn't ignre the home (and limit) switch the rest of the time :)
[23:17:10] <Guest247> thats the way it's acting
[23:17:49] <Guest247> so I need to set home_offset to something slightly away from -.5 like -.3
[23:17:54] <SWPadnos> yep
[23:18:06] <SWPadnos> if the machine isn't very slow, you could just set it to 0.0
[23:18:10] <Guest247> a huge thanks!!!!!!!!!!!!!!!!!!!!!!!!
[23:18:16] <SWPadnos> sure
[23:18:27] <SWPadnos> moving 0.5 inches shouldn't take too much extra time :)
[23:23:40] <BigJohnT> yea! SWPadnos to the rescue
[23:24:01] <SWPadnos> strange. I thought you gave the same answer before I got here ;)
[23:24:50] <BigJohnT> sometimes I speak in tongue
[23:27:13] <Guest247> He did, it was the "if you don't move off the home switch, you can't also use it as the limit switch " that turned on the mental light. Problem solved, thanks to all
[23:27:57] <SWPadnos> cool. have fun with it
[23:28:00] <SWPadnos> bye
[23:28:02] <SWPadnos> see you later
[23:28:06] <SWPadnos> have fun storming the castle
[23:30:54] <BigJohnT> too late he is gone
[23:31:29] <SWPadnos> yeah, I noticed :
[23:31:32] <SWPadnos> )
[23:31:34] <SWPadnos> :)
[23:33:33] <ds3> castle storming?!
[23:33:44] <SWPadnos> "The Princess Bride"
[23:33:50] <SWPadnos> see it, it's a great movie :)
[23:34:32] <ds3> * ds3 had pictures of a mob with pitchforks and torches assembling outside of a castle
