Back
[02:07:01] <skunkworks> so.. where can I get 50pf thru hole caps?
[02:07:41] <skunkworks> in quantities less than 1000 ;)
[02:08:05] <cradek> is that hard to find? I'm surprised (without looking first)
[02:08:18] <skunkworks> Well - digikey was no help.
[02:09:42] <skunkworks> some random searching didn't help
[02:10:06] <jmkasunich> I'm surprised digikey didn't have them
[02:10:08] <cradek> http://www.mouser.com/Search/ProductDetail.aspx?qs=XeJOwCSCkv8TfOZSduXdBA%3d%3d
[02:10:18] <jmkasunich> thru-hole is getting less common, but not gone yet
[02:10:43] <cradek> ceramic disc, 50pF, 1kV, radial 6.4mm lead spacing
[02:10:46] <skunkworks> well - there you go.
[02:10:55] <cradek> they seem expensive though
[02:10:58] <skunkworks> Thanks - I forget about mouser for some reason.
[02:11:38] <jmkasunich> do you need 50pf? 47 is more standard
[02:12:19] <jmkasunich> digikey has 42,000 pieces, min order 1 pc, $0.19 each
[02:12:56] <jmkasunich> also lots of ones with a 10pc minimum, as low as $0.076 each
[02:13:27] <cradek> if 50V instead of 1000V is ok, mouser has them for .08 qty 1
[02:13:31] <cradek> (47pF)
[02:13:55] <cradek> that's more like it I think
[02:14:38] <skunkworks> nice - thanks
[02:14:39] <SWPadnos> regarding jogging before homing - would an additional ini file setting called something like UNHOMED_JOG_VEL make sense?
[02:14:52] <SWPadnos> and use that for any unhomed joints
[02:15:12] <jmkasunich> that may or may not be a good feature, but it has nothing to do with the user request
[02:15:18] <jmkasunich> the user is afraid people will forget to home
[02:15:24] <SWPadnos> more like a response to cradeks response :)
[02:15:30] <jmkasunich> so they _want_ a "no user action required" home
[02:15:38] <SWPadnos> yes, another setting to prevent "run" before homing would fix that
[02:15:41] <cradek> I don't agree with that analysis
[02:15:55] <SWPadnos> a "user can't runn programs until they home" switch could help
[02:16:16] <jmkasunich> yeah, I guess they really want "force home before program run"
[02:16:49] <cradek> Even that's not entirely clear, but that's probably close to what the request really is
[02:17:23] <SWPadnos> auto-homing would require some scripting or something (loadusr axis-remote ...)
[02:17:28] <cradek> oops, I'm wrong, it does say "scared of forgetting ... before running a program"
[02:18:09] <SWPadnos> I'd bet that preventing a run before homing, and/or limiting jog speed while unhomed, would satisfy that user
[02:18:12] <SWPadnos> and many others
[02:18:19] <cradek> I suspect that's true
[02:18:39] <SWPadnos> I suppose I can ask a question to that effect on the list :)
[02:22:07] <cradek> jmkasunich: the coolant motor on my lathe is marked 1/6 HP 240V 3ph. I got it running with a 7uF motor run capacitor. It starts fine and sounds fine, voltage when running across all three phase is within 5-10V. But it seems to run very hot. I do not know if the hot is normal. Am I doing something crazy?
[02:23:02] <jmkasunich> hard to say
[02:23:13] <jmkasunich> "very hot" = 70C? 100C? 130C?
[02:23:19] <jmkasunich> 70 would be OK
[02:23:21] <jmkasunich> 100 marginal
[02:23:27] <jmkasunich> well, very marginal
[02:23:47] <cradek> I have not probed it but I will when I find my probe (which I also need for the car)
[02:23:58] <jmkasunich> is there a speed on the nameplate? and can you measure the actual speed?
[02:24:24] <jmkasunich> if it is for example a 1750 RPM motor, and it is doing 1700, that would indicate that it is overloaded, or underdriven
[02:24:25] <cradek> I will go look, brb.
[02:24:43] <jmkasunich> also, can you measure current draw? compare that to nameplate
[02:26:06] <cradek> It is marked 3450 rpm. I have no way of measuring the speed though.
[02:26:49] <jmkasunich> check the current draw if you can (that actually makes more sense than RPM, I was being dense)
[02:26:54] <skunkworks> encoder.. emc..
[02:27:06] <jmkasunich> no accessble shaft I bet
[02:27:18] <cradek> it says 230/460V 1/.5A
[02:27:26] <cradek> no accessible anything unfortunately
[02:27:53] <cradek> speaking of dense, how do I measure the current draw?
[02:28:13] <SWPadnos> does it get hot when "idling", or only when you're turning?
[02:28:14] <cradek> there is 1ph hooked to two leads. there is a run cap hooked from one of those to the third lead.
[02:28:46] <SWPadnos> uh - nevermind. I just noticed you mentione d"coolant pump" :)
[02:28:47] <cradek> SWPadnos: it doesn't know the difference, it's just coolant/oil, it's on or off
[02:28:59] <cradek> aha, had me wondering there :-)
[02:29:02] <SWPadnos> I was wondering how a tiny motor like that could be on your lathe
[02:29:16] <jmkasunich> do you have an ammeter?
[02:29:45] <cradek> this one says "DC 10A"
[02:29:52] <cradek> no AC amps
[02:29:55] <jmkasunich> oh
[02:29:58] <cradek> looking...
[02:29:59] <SWPadnos> you may want caps from each driven leg to the third leg
[02:30:04] <jmkasunich> you need a better meter ;-)
[02:30:56] <cradek> I have plenty to choose from ... somewhere ... but whether any are better is hard to say
[02:31:30] <jmkasunich> if you don't have a meter with AC amps, you need a better meter
[02:31:46] <jmkasunich> that is pretty much standard on most DMMs these days (last 10 years even)
[02:32:14] <cradek> fancyish digital says 20A, does not specify AC/DC
[02:32:48] <cradek> I like my ancient analog for most stuff - way older than 10 years I suppose
[02:33:06] <cradek> the digital has an AC/DC switch and the A section of the rotary switch just says "A"
[02:33:16] <cradek> so maybe ...?
[02:33:17] <jmkasunich> dunno if a Simpson does AC amps or not ;-)
[02:33:22] <jmkasunich> maybe
[02:33:40] <jmkasunich> test it by measuring the current drawn by a 100W light bulb?
[02:34:20] <jmkasunich> anyway, if the motor is running at >= rated RPM and drawing <= rated current, it should be ok
[02:34:38] <jmkasunich> 40-50C rise above ambient is no big deal for a loaded motor
[02:36:04] <jmkasunich> if it is above rated current, maybe your pump has issues - oil viscosity too high, shaft seal sticking, impeller rubbing on something, etc
[02:38:04] <cradek> 100W bulb says .80A at 120V
[02:38:14] <jmkasunich> looks like that meter is good for AX
[02:38:15] <jmkasunich> AC
[02:38:16] <cradek> so that's promising
[02:38:17] <SWPadnos> sounds about right :)
[02:39:23] <cradek> so I just insert the meter into any wire to the motor?
[02:39:41] <jmkasunich> ideally you measure all three (one at a time)
[02:39:58] <jmkasunich> gross imbalance (>10-15%) or overcurrent on any phase would be a problem
[02:40:08] <jmkasunich> balanced and at or below nameplate, and all is good
[02:45:50] <cradek> hm, tonight it doesn't want to start, and it sits around 4A on the winding I'm measuring
[02:46:44] <jmkasunich> don't let it sit long
[02:47:06] <jmkasunich> this is a centrifugal pump?
[02:47:08] <cradek> well that's not right, is it
[02:47:13] <jmkasunich> hell no
[02:47:16] <cradek> yes I think it is
[02:47:30] <jmkasunich> that should require very little starting torque
[02:47:49] <jmkasunich> centrifugals require torque proportional to speed squared
[02:47:54] <cradek> yeah, at low speed it should have ... yeah that
[02:47:55] <SWPadnos> you've got 7uF on it?
[02:48:16] <cradek> I guess it is 7.4uF
[02:48:18] <cradek> 7.5
[02:48:24] <jmkasunich> do you have any access whatever to the shaft? can you tell if it is free-turning?
[02:48:30] <SWPadnos> hmmm. that sounds about right. I think it's supposed to be ~50-100/HP
[02:48:40] <cradek> I also have a 5 and a 6uF I could swap in
[02:48:46] <cradek> jmkasunich: unfortunately none
[02:48:59] <jmkasunich> which phase did you measure the current on? the cap phase, or one of the others?
[02:49:28] <cradek> the one hooked to real power and one side of the cap
[02:49:36] <cradek> I measured between the cap and motor on that wire
[02:49:53] <jmkasunich> check the cap phase if you can, maybe the cap is low or open, and you aren't getting any starting current
[02:50:12] <cradek> I'll just try another cap, it's very simple
[02:51:05] <jmkasunich> put the meter in series with the new cap
[02:51:28] <cradek> no difference ... adding meter
[02:54:17] <cradek> 0.3A on the cap phase
[02:54:48] <cradek> my unease goes up with the square of the voltage I'm working around
[02:54:58] <skunkworks> Bang
[02:55:00] <SWPadnos> so this should be pretty uneasy
[02:55:09] <skunkworks> I see a small inverter in your future
[02:55:26] <cradek> I wonder what the smallest/cheapest VFD would cost
[02:55:56] <jmkasunich> if you have 4A on the regular phase, and 0.3A on the cap phase, either the cap is busted, its too small, or the winding is busted
[02:56:07] <jmkasunich> this is 240V, right?
[02:56:10] <cradek> yes
[02:56:18] <jmkasunich> btw, wise to be uneasy
[02:56:27] <cradek> I'm wiring it right, right?
[02:56:59] <jmkasunich> to the extent that there is a "right" way to run a three phase motor on single phase, yes
[02:57:19] <jmkasunich> the reactance at 60Hz of a 7.4uF cap is 358ohms
[02:57:29] <jmkasunich> you're not gonna get a lot of starting current thru that
[02:57:59] <jmkasunich> did you choose that cap value, or was it already there?
[02:58:01] <skunkworks> http://web4.automationdirect.com/adc/Shopping/Catalog/AC_Drives/GS1_(120_-z-_230_VAC_V-z-Hz_Control)/GS1_Drive_Units_(120_-z-_230_VAC)/GS1-20P2
[02:58:01] <SWPadnos> you should have a large start cap that gets switched out once the motor is more or less up to speed, and a much smaller run cap from each powered leg to the wild leg
[02:58:09] <cradek> I could easily make 6+7.5uF
[02:58:33] <jmkasunich> SWPadnos: the run caps might not even be needed
[02:58:35] <cradek> jmkasunich: I chose it based on likely-ill-informed stuff I found online
[02:58:40] <SWPadnos> maybe not
[02:59:37] <cradek> like SWPadnos said, I read somewhere ... so many uF per HP
[02:59:48] <cradek> that might not be linear - might work for bigger motors
[02:59:56] <jmkasunich> that depends on voltage, did they give different factors for 240 and 480?
[03:01:00] <jmkasunich> I just found a page on "static phase converters" that recommends 100uF/HP at 230V
[03:01:37] <cradek> I'm going to try 6+7.5uF
[03:01:51] <SWPadnos> http://cgi.ebay.com/SINGLE-THREE-PHASE-VFD-VARIABLE-FREQUENCY-DRIVE-1-2HP_W0QQitemZ190258455532QQcmdZViewItem?hash=item190258455532&_trkparms=72%3A1418%7C39%3A1%7C66%3A2%7C65%3A12%7C240%3A1318&_trksid=p3286.c0.m14
[03:02:07] <jmkasunich> heh, even the cheapest drive is >$100 I suspect
[03:02:23] <cradek> that started right up with 1.25A on the generated leg
[03:02:59] <jmkasunich> measure all three currents while running, if they are within rating (under load) you should be good to go
[03:03:24] <SWPadnos> there sure are a lot of nixie tubes in the way when you search eBay for a VFD :)
[03:03:27] <cradek> well 1.25 > 1 already
[03:03:31] <jmkasunich> is there a valve or anything on the coolant line? max load may occur at something other than full on or full off
[03:03:43] <jmkasunich> duh
[03:04:13] <jmkasunich> 1.25 > 1.0, so you need a plan B
[03:04:16] <cradek> more C? I can try 5+6+7.5
[03:04:33] <jmkasunich> you can try that
[03:04:48] <jmkasunich> if all three phases are at 1.25 tho, changing the cap isn't gonna improve things
[03:05:09] <jmkasunich> in general, a motor on single phase is only good for about 2/3 of the nameplate HP
[03:05:30] <cradek> it's pumping fine, for whatever that's worth
[03:05:35] <jmkasunich> if your pump actually needs more than 1/9 HP at the shaft, it's not gonna be happy
[03:06:08] <cradek> I'll measure another phase
[03:08:36] <cradek> on one of the wires hooked to the real power, it shows 3A or so while starting, then 0.89 while running
[03:08:47] <jmkasunich> running current is what matters here
[03:08:57] <jmkasunich> starting can easily be 4-6x running, and that is OK
[03:09:04] <cradek> so maybe more C will help?
[03:09:13] <cradek> 1.2 is not much > than 1
[03:09:13] <jmkasunich> maybe
[03:09:23] <cradek> I'll try it. (what else would I do?)
[03:09:42] <jmkasunich> motor heating goes as I^2, so a little too much current is more than a little too much heat
[03:09:48] <jmkasunich> but try it and see what effect it has
[03:10:16] <jmkasunich> also, if you are on the edge, perhaps run caps as SWP suggested might help - one to each phase, instead of all on one phase
[03:10:34] <cradek> those squares seem to pop up wherever you don't want them
[03:17:57] <cradek> with all three, I get a much faster start and the running current on the non-fake wire is 1.1A
[03:18:37] <jmkasunich> check all three wires - if 1.1 is the worst, you're probably ok
[03:18:50] <jmkasunich> especially since you won't likely be running it for hours on end
[03:21:13] <cradek> darn, cap phase is 1.8.
[03:22:04] <SWPadnos> you probably want to switch out most of the start capacitance for run mode
[03:23:20] <jmkasunich> can you set up a switch so you can disconnect _all_ the capacitance after it is started?
[03:23:40] <jmkasunich> then measure the current in either of the remaining legs (both must be the same in that case)
[03:24:56] <cradek> with a certain cap configuration, I get .9/.9/1.25
[03:27:10] <cradek> yes I can unhook the cap once it's running...
[03:29:10] <cradek> when I do that, current goes up to 1.19 and I don't hear any difference
[03:30:04] <jmkasunich> so you have 0.9/0.9/1.25, and 1.19/1.19/0.0
[03:30:21] <jmkasunich> switching out part of the cap and leaving part in might let you split the difference
[03:30:40] <cradek> tomorrow when it's completely cool, I might try the .9/.9/1.25 setup for a while and see how warm it gets
[03:32:03] <cradek> 2*1.19^2 = 2.83, 2*.9^2+1.25^2 = 3.18
[03:32:24] <cradek> but does that mean anything?
[03:32:46] <jmkasunich> should be a valid measure of heating
[03:32:54] <jmkasunich> total heating anyway
[03:33:07] <cradek> they look roughly comparable to me then
[03:33:18] <jmkasunich> and the first one is also better in terms of per-winding heating as well - 1.19 < 1.25
[03:35:09] <cradek> that's the one that's more complex to do
[03:35:21] <jmkasunich> because of switching it out?
[03:35:41] <cradek> yes
[03:35:53] <cradek> I don't have a contactor (and a mesa output) to spare
[03:36:04] <jmkasunich> got a time-delay relay?
[03:36:05] <cradek> maybe I could get a time delay thingy
[03:36:09] <cradek> nope
[03:37:44] <SWPadnos> uh. 0.9^2 = 0.81, 1.25^2 = 2.25, so 2x0.9^2+1.25^2 = 1.62+2.25 = 3.87
[03:38:54] <cradek> SWPadnos: 1.25^2 = 1.56
[03:39:05] <SWPadnos> right!
[03:39:13] <SWPadnos> 1.5^2=2.25 though
[03:39:15] <SWPadnos> I'm sure of it
[03:39:17] <SWPadnos> :)
[03:39:52] <SWPadnos> next time I could use a calculator
[03:43:01] <cradek> I ran it "for a while" and it feels "not too hot"
[03:43:15] <SWPadnos> "sounds good"
[03:43:20] <jmkasunich> sounds encouraging
[03:43:31] <jmkasunich> is this the 0.9/0.9/1.25 version?
[03:43:57] <cradek> yes
[03:44:22] <cradek> I assume it's way under 100c, since it feels less hot than a hot cup of coffee
[03:44:49] <jmkasunich> the thermal time constant of a motor is probably a significant fraction of an hour
[03:45:00] <cradek> yea
[03:45:01] <cradek> h
[03:45:08] <cradek> it seems like it's still getting warmer though.
[03:45:17] <cradek> I'll find my probe tomorrow.
[03:45:21] <jmkasunich> the nominal IR loss is 3*1^2 = 3
[03:45:21] <cradek> tonight, I should go to bed
[03:45:28] <cradek> I really appreciate your help
[03:45:38] <jmkasunich> you're only 6% over that, I bet it will be OK
[03:46:12] <jmkasunich> but you should re-check currents if you do anything that would change the load on the pump
[03:47:11] <cradek> I might remeasure once more when I'm not sleepy
[03:47:50] <cradek> the rated current is "1" - not many significant figures there
[03:48:31] <jmkasunich> I think its safe to assume 1.0
[12:27:24] <cradek_> cradek_ is now known as cradek
[13:05:00] <SWPadnos> jepler, have you seen this thread:
http://www.cnczone.com/forums/showthread.php?postid=432441
[13:05:11] <SWPadnos> it's old, but I'm not sure if the timings have been fixed
[13:41:58] <jepler> SWPadnos: nfc
[13:42:19] <SWPadnos> I guess I could look at the stepconf history myself, couldn't I
[13:43:30] <jepler> I don't know where I got my docs for the sherline timings
[13:43:40] <jepler> you'd think they'd be on the sherline website :-P
[13:43:52] <SWPadnos> heh
[13:43:53] <jepler> hm their website says this: "Step pulses should be at least 22 microseconds long."
[13:44:03] <jepler> http://www.sherline.com/8760pg.htm
[13:44:47] <SWPadnos> I guess I could take a look at a BDI disc to get the old sherline config
[13:47:20] <jepler> http://www.sherline.com/emc/mill_inch_freq.txt
[13:47:24] <jepler> PERIOD =0.000022
[13:47:33] <jepler> I think this is like setting BASE_PERIOD to 22000
[13:47:43] <jepler> so step length and space will be minimum 22000-jitter
[13:47:54] <jepler> SETUP_TIME = 2
[13:47:56] <jepler> HOLD_TIME =3
[13:48:05] <jepler> ^^ and these must be integer multiples of PERIOD
[13:48:10] <SWPadnos> yep
[13:49:08] <jepler> so in dog years, stepconf probably has the wrong values, but I still don't know what the right ones are
[13:49:34] <SWPadnos> it looks like they were trying to guarantee 22 uS, but didn't do it right
[13:49:44] <jepler> I'm not sure how much control emc1 had over that stuff
[13:50:00] <jepler> it could be that 22us was simply a good base period for the step rate they wanted
[13:50:15] <SWPadnos> not much - just a number of BASE_PERIODs for steplen/space and dir setup/hold
[13:50:26] <SWPadnos> no, their driver has some wacky requirements
[13:50:38] <SWPadnos> I remember Ray sasying that it was in the 20s of uS
[13:53:10] <jepler> http://www.sherline.com/8760pg.htm also has that the step pulses are active low. that would be "kinda similar" to swapping the step length and space parameters, except around direction changes, kinda
[13:53:46] <SWPadnos> hmmm. yeah, kinda
[13:57:40] <jepler> * jepler notices the source code comment: [1000, 6000, 24000, 20000], # Sherline XXX find proper values
[13:57:49] <SWPadnos> heh
[13:58:16] <jepler> * jepler grumbles
[13:59:39] <jepler> well this is interesting (the quoted text about how step pulse generation is done in mach):
http://groups.yahoo.com/group/SherlineCNC/message/9206
[14:00:08] <jepler> sounds like it is in a doublestep-like mode by default
[14:00:24] <jepler> .. and the very long step pulse length of sherline's driver box is a non-doublestep mode
[14:00:27] <jepler> makes sense
[14:01:02] <SWPadnos> actually, it's more like there's a fast loop that generates the steps (by busy-waiting sometimes)
[14:01:28] <SWPadnos> when an interrupt comes in, the code checks to see if a step should have been done already, or if it'll be necessary "soon"
[14:01:48] <SWPadnos> if "soon", then a busy-wait is used instead of waiting for the next interrupt
[14:01:50] <SWPadnos> or something like that
[14:02:05] <SWPadnos> kind of like an adaptive ("smart") double-step
[14:02:23] <jepler> I don't see what you're saying
[14:02:43] <SWPadnos> interrupt happens. TSC or something is read to see how close to a step edge it is
[14:02:55] <SWPadnos> if the edge has already "passed", then the step is output immediately
[14:03:11] <SWPadnos> if the edge is "really soon", then a busy-wait is used to wait for the edge time
[14:03:40] <SWPadnos> if it's not needed "really soon", then it waits for the next interrupt
[14:04:00] <jepler> are you interpreting something in that message, or are you telling me about some other knowledge you have about mach?
[14:04:07] <SWPadnos> other knowledge
[14:04:12] <jepler> ok
[14:06:25] <jepler> I kinda get what you're saying, I just didn't see any of what you were saying in that message :-P
[14:06:36] <SWPadnos> heh
[14:06:53] <SWPadnos> ahe sort of mentioned that there's a busy-wait for the step active druation
[14:07:20] <jepler> yeah but in emc terms that sounds a lot like parport.reset-time
[14:07:25] <SWPadnos> yes
[14:19:12] <jepler> bah, what you really want is a dual core machine with only a busy-loop "outb" running on the second core
[14:22:57] <jepler> voila, 500kHz step rates on common PCs
[14:26:01] <cradek> yeah, do that
[14:26:39] <skunkworks_> emc2 can do 500khz. Neener neener neener.
[14:32:21] <jepler> huh, I wonder why 'rdtsc' on amd64 still puts 32 bits in one register and 32 bits in another register, instead of putting all 64 bits in one 64-bit register
[14:34:33] <jepler> this instruction sequence generated by gcc is just tear-inducing -- particularly the 'mov's : rdtsc / mov %edx, %edx / mov %eax, %eax / shl $0x20, %rdx / or %rdx, %rax
[14:36:59] <jepler> hm, it's better by one 'mov' instruction on 8.04: rdtsc / shl $0x20, %rdx / mov %eax, %eax / or %rax, %rdx (earlier sequence was from 6.06)
[14:42:00] <jepler> after fixing for the damage introduced by treating source code as markup, this looks like the best rdtscll:
http://jira.secondlife.com/browse/VWR-975
[14:42:03] <jepler> no extra movs
[14:52:05] <SWPadnos> does the move %eax, %eax clear the top 32 bits?
[14:53:42] <cradek> it probably clears some flags but it doesn't seem like that would affect shl
[14:54:52] <SWPadnos> ok, yes - it does zero-extend
[14:57:04] <cradek> the mov %edx, %edx seems totally useless though
[14:57:21] <SWPadnos> that's probably why it's gone in the second example
[14:58:19] <SWPadnos> that secondlife example doesn't explicitly clear the top 32 bits of %rax
[15:06:57] <jepler> testing seems to show that the top bits are cleared by the rdtsc instruction, though my amd64 instruction set reference isn't clear on that
[15:13:28] <jepler> "The high-order 32 bits are loaded into EDX, and the low-order 32 bits are loaded into the EAX register." (description of RDTSC) "In 64-bit mode, the following rules apply to extension of results into the high 32 bits when results smaller than 64 bits are written: * Zero-Extension of 32-bit Results" -- general rules for instructions in 64-bit mode
[15:19:35] <SWPadnos> I wonder how many cycles "move %eax, %eax" takes? :)
[15:19:43] <SWPadnos> err - movl
[15:23:32] <jepler> probably not too many :-P
[15:23:41] <jepler> but it's a matter of *principle*
[15:26:12] <SWPadnos> well, I agree with that
[15:26:32] <SWPadnos> it *should* work without the movl on any amd64 CPU
[17:57:44] <skunkworks_> R18 can't be in circuit.
http://www.electronicsam.com/images/KandT/servostart/schemagain.png
[17:58:05] <skunkworks_> (must be 0 ohms)
[17:58:16] <cradek> * cradek gives up after 2 seconds of searching for R18
[17:58:35] <skunkworks_> heh - sorry - it is in series with the input of the comparator.
[17:59:09] <skunkworks_> noise must have been getting into it - the current limit was spastic at best.
[17:59:35] <skunkworks_> Seems to be better - but I need a better motor supply.
[18:06:33] <skunkworks_> I was doing pdm out of the printer port.. The torque at 99% duty cycle durring current limit seemed to be lacking.. I think because the current limit trips an then there is a long time until the next on cycle to reset the flip flop.
[18:06:44] <skunkworks_> * skunkworks_ can dream..
[18:06:50] <skunkworks_> plus the power supply sucked.
[18:08:46] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: disallow MDI commands and program execution on an unhomed machine
[18:19:27] <jepler> skunkworks_: I think that these kinds of drivers are supposed to not hit the current limit during regular operation
[18:20:26] <cradek> IMO, a servo drive hitting its current limit is an error condition
[18:20:44] <cradek> it necessarily means that the motor is not able to keep up
[18:21:26] <SWPadnos> possibly true for DC, but a PWM certainly could hit current limit within a cycle under normal conditions
[18:21:39] <jepler> it may be hard to drive it close to the edge with a slow signal like parport
[18:22:15] <jepler> because the on-times become "very long" compared to high speed PWM signals with dead time
[18:23:21] <jepler> e.g., 99% PDM at 20us BASE_PERIOD = 1980us on, 20us off
[18:24:43] <jepler> that's what skunkworks_ was saying, I think
[18:26:34] <SWPadnos> I don't know if current limit should shut down for the rest of the PWM cycle
[18:27:12] <SWPadnos> it may be better to have a fast chopper that will drive at the current limit for as long as the PWM input is "on"
[18:27:50] <SWPadnos> it would need to shut down/turn on the output based on the current feedback with some hysteresis, but only when enabled by the PWM input
[18:28:09] <SWPadnos> dunno how fast it would need to be though, or how bad that would be for transistor heating
[19:03:47] <cradek> I feel like I win when nobody comments on a commit like that
[19:04:06] <alex_joni> well.. it's commited now
[19:26:04] <skunkworks_> heh - I was away.
[19:26:18] <skunkworks_> I was just testing the current limit. I plan on not hitting it. :)
[19:26:49] <skunkworks_> jepler: exactly what I was trying to explain.
[19:37:32] <skunkworks_> From reading - a lot - cycle by cycle current limit seems to be common. (where the drive doesn't turn back on until the next rising edge of the pwm signal)
[19:38:09] <alex_joni> skunkworks_: pick jmkasunich's oppinion on the subject
[19:38:27] <alex_joni> good night all
[19:43:01] <issy> hi all
[19:43:07] <skunkworks_> alex_joni: :)
[19:43:32] <issy> haw the interpreter is dealing with the Tcomands
[19:43:57] <issy> i need to call scripts when meet tool change command
[19:46:54] <cradek> tool is changed with M6, not T
[19:47:03] <cradek> the only way to call a script is with a user-defined gcode M10x
[19:47:39] <issy> the command is T1M6; , but what happend when the interpreter meet this command
[19:48:00] <cradek> the hal layer is told to do the tool change
[19:48:17] <cradek> can you ask a more specific question? what exactly are you trying to do?
[19:49:29] <issy> Y have to make the tool change sequence.usualy most of the cnc systems when met toolchange command execute a script with variable the tool number
[19:49:52] <cradek> in emc2 that is done by HAL
[19:50:08] <issy> yes , but i dont know when to look
[19:50:16] <issy> so this is my question
[19:52:08] <cradek> http://www.google.com/search?q=emc2+tool+change+hal
[19:52:18] <cradek> the first hit tells you what hal pins are used
[19:52:39] <issy> thanks.!
[20:00:58] <issy> cradec as i see when the the emc meet m6 command , stops and wait the tool to be changed , in my case i need to have automatic toolchange , so i need to move the machine with subroutine
[20:01:13] <issy> this is not clear tome.
[20:03:10] <micges> cradek: you last feature is cool but is there a way to disable it for a while ? (disallow mdi and run without homing)
[20:03:10] <cradek> you can have the machine move to a tool change location, or if using trunk, there are some other options for motion
[20:03:44] <cradek> what do you mean for a while?
[20:04:04] <cradek> maybe I don't understand, but you can use whatever version of the source you want for as long as you want
[20:06:42] <micges> I mean that I have this option half year in my axis and I must have switch off button to allow mdi without homing
[20:07:06] <micges> It is nessesary to intergrate machine
[20:07:21] <cradek> issy: for TRUNK, the options are described here:
http://www.linuxcnc.org/docs/devel/html/config_ini_config.html#sub:%5BEMCIO%5D-Section
[20:07:48] <cradek> micges: sorry, I don't understand what you are saying
[20:08:51] <issy> so, at that moment (when EMC is waiting for tool change) we can send commands to move machine to a new location (something like manual move, or mdi move)
[20:10:44] <micges> ok
[20:11:13] <micges> from begin
[20:11:32] <cradek> micges: sorry I think I understand what you are saying now. you want a button that allows MDI even though it is not homed, even though you want this to usually be not allowed
[20:11:50] <micges> yep
[20:12:01] <cradek> while that may be needed for your system I don't think it's needed in general, and it would just be confusing
[20:12:21] <cradek> so this will probably just need to be a change you make to your own system
[20:12:37] <jepler> micges: what is a specific example of something you must do in MDI mode before homing the machine?
[20:12:56] <cradek> issy: what motion specifically do you want?
[20:13:31] <jepler> for instance, it doesn't make sense to me do an M6 toolchange in that state. it does make sense to move the machine, but that can be done with a jog.
[20:15:05] <issy> set absolute cordinate , move to first reference point , move to first reference + tool number , lower the spinde , opeh tiool holder , position the tool in the toolholder , clse toolholder ,release tool , spindle up......
[20:15:24] <issy> this generay is the sequence for toolcgange
[20:15:51] <issy> so , when meet the m6 , i have to perform all this in order to change the tool
[20:16:26] <cradek> moving the spindle up and down after moving to the tool change position is challenging in HAL but some have done it
[20:16:58] <issy> yes
[20:17:15] <jepler> the current tool change is not very good for the case where coordinated motion is needed at multiple steps of the process.
[20:17:45] <jepler> it's fine for things like "open collet, activate solenoid, wait, close collet"
[20:17:54] <jepler> if a patch to improve this were submitted, I would be happy to review it.
[20:18:24] <issy> yes , so my idea is when got m6 , to call a subroutine that can perform the toolchange , but the machine is stopping at m6 , and i cant move it
[20:20:15] <jepler> yes, right now M6 is hardcoded to do zero or one movements and it is not configurable as a (gcode?) "subroutine".
[20:20:24] <micges> cradek: sorry I was wrong, correct assumptions
[20:20:25] <issy> ususaly , this is performed in absolute coordinate system , not in relative , but why i cant see any way to make the emc to call subroutine at m6 and to wait until complete it
[20:20:59] <jepler> if you want it to be different, your best course of action is to write what you want in C++ (modify and recompile emc)
[20:21:35] <jepler> if you make it generic enough to handle other machines that require movement during toolchange, you should submit that for inclusion in a future release of the software
[20:23:39] <issy> maybe i will have to do it. in my machine the toolholders are at the back of the machines , so i have to move to change
[20:25:27] <cradek> issy: it would be nice to cleanly be able to handle a tool changer like yours. I hope you get it working.
[20:25:30] <micges> jepler: It just last you all adding features that I have in my modifications but when I suggested it long ago nobody wanted it
[20:26:31] <micges> It make me little angry but in another manner I know emc code very good now
[20:28:00] <jepler> micges: besides the polish translation (for which I thank you) i'm not aware of any patches you've submitted
[20:29:36] <jepler> if I gave you the impression that nobody is interested in your improvements, I apologize. I don't mean to give that impression. When you feel that you have made a change that is valuable to others, please submit a patch. That's the only way it will ever be included in a future version for others to benefit from.
[20:29:41] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CVS#Patch_Submission
[20:30:59] <micges> ok, less talking more patches, I understand
[20:33:21] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/src/po/ (fr.po fr_axis.po fr_rs274_err.po): french translation update
[20:34:30] <micges> ok enough crying for me ;)
[20:34:54] <issy> cradec , i will make all the modifications for the toolchange , no ptoblem , there is 3 general type of toolchanges , the arm , the carousel (buterfly) and the fixed position , all of them must be included
[20:34:54] <cradek> hi ken
[20:35:42] <micges> first issue: halui have pins to connect encoder to control feedrate, right ?
[20:36:01] <cradek> issy: only the tool change systems that require several axis motions are currently poorly supported
[20:36:05] <cradek> issy: "cradek"
[20:36:36] <cradek> micges: "man halui"
[20:36:51] <issy> sorry k
[20:37:17] <cradek> micges: the man page tells all the different way you can control feed override with halui
[20:37:21] <cradek> ways
[20:37:36] <micges> I know
[20:37:48] <issy> the movement cannot be made in auto as the interpreter stops at m6 , i have to go deep in it.
[20:37:51] <issy> let see
[20:38:18] <jepler> I remember something about this -- there are "enable" pins missing from halui, so you can't share that jogwheel with another function
[20:39:03] <cradek> ah, that would be nice to have
[20:39:07] <jepler> (it's the axis.#.jog-enable pin that allows the jogwheel to be shared among all axes)
[20:39:14] <jepler> micges: is that the issue want to raise?
[20:39:19] <micges> I 've connected halui with my module to control feedrate with .counts pin
[20:39:45] <micges> but feedrate is bouncing after changing it with slider
[20:40:33] <micges> amplitude of bounces is changing while changing my hal module frequency
[20:40:49] <micges> I cannot imagine what is happening
[20:42:39] <issy> jepler thanks , begining to test , let you know tomorow
[20:43:46] <jepler> hm
[20:43:55] <jepler> I first did halcmd setp halui.feed-override.scale .1
[20:44:00] <jepler> so that 10 counts = change by 100%
[20:44:27] <jepler> then at the shell I ran this to quickly change the number of counts:
[20:44:28] <jepler> for i in `seq -1 -1 -10`; do halcmd setp halui.feed-override.counts $i; sleep .01; done
[20:44:43] <jepler> only looking at the FO slider in the axis gui, I don't see anything weird
[20:45:17] <jepler> I wonder what is different about our testing situations
[20:45:43] <micges> my scale is .0001
[20:46:07] <micges> to have control speed at level 1mm/min
[20:46:14] <cradek> what do you mean bounces? how many times does it bounce?
[20:46:34] <cradek> how and where do you see the bounce?
[20:46:45] <micges> with emctop
[20:48:48] <micges> I mean commanded value was 1.2 and for about 20 sec value changing from 0 to 3.0 about 5 times per sec
[20:49:19] <micges> my hal module was connected to servo-thread 1kHz
[20:49:45] <cradek> do you realize that halui is not realtime and cannot give you 1kHz response or anything close to that?
[20:49:57] <micges> yes I know
[20:50:00] <cradek> maybe you should consider using motion.adaptive-feed?
[20:50:13] <issy> jepler is this missing pin comming from the nml?
[20:51:13] <micges> I delayed sending command to halui to about 5hz and bounces are very small
[20:51:15] <issy> the jog-enable i mean?
[20:51:52] <jepler> issy: axis.#.jog-enable is a pin created by the real-time motion controller. it is intended to be used together with .jog-counts for handwheel jogging.
[20:52:15] <cradek> halui only polls its inputs every so often. maybe you have oscillation because your feedback response is too fast
[20:53:20] <cradek> bbl
[20:53:34] <jepler> maybe halui needs logic like axis has to keep the feed override slider from bouncing around while it's being dragged
[20:54:22] <jepler> (for a certain amount of time after it's changed in the axis gui, axis ignores the values that come from the stat buffer, because it assumes there is a minimum amount of time before task reacts, changes its internal FO%, and places the result in the status buffer)
[20:54:27] <micges> yes but I cannot imagine test case to prove this
[20:54:47] <jepler> (halui might do the same thing, using the last commanded FO% instead of the stat buffer FO% when applying the change requested on its input pins)
[20:55:07] <jepler> (er, halui *could* do the same thing; I'm pretty sure it doesn't right now)
[20:55:10] <jepler> ooh it's quitting time
[20:55:13] <jepler> * jepler runs for the door
[20:57:48] <issy> jepler the jog enable will allow to do the moves but will not permit any m commands as open collet close collet.... so will not work
[20:58:09] <jepler> issy: oh, I'm sorry if I created confusion. I wasn't trying to address your issue
[20:58:27] <jepler> I was trying to guess at the issue micges was raising, but I got that wrong too
[20:58:31] <jepler> it's a bad day for me :-P
[20:59:51] <issy> the problem is dipper as any automatic toolchange require subroutine to complete and the interpreter is not done for this , i will have to work on it.
[20:59:53] <issy> thanks
[21:09:18] <issy> jepler the m6 comand is stopping the interpreter waiting for toolchange confirmation
[21:09:47] <issy> instead of doing this the onterpreter must perform the m98 p9001 call
[21:10:45] <issy> the o9001 will be the system subroutine for toolchange. in this way it can be used for any type of automatic toolchangers , but not for manual
[21:11:26] <issy> so will not be compatibe for manual toolchange and the axis gui that is used now
[21:20:06] <issy> bbl
[22:07:44] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/html/gcode_fr.html: french translation update, better terms (sonde -> palpeur, chemin -> parcours)
[22:07:45] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/common/ (Document_Header_fr.lyx Linux_FAQ_fr.lyx): french translation update, better terms (sonde -> palpeur, chemin -> parcours)
[22:07:45] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/gcode/ (main_fr.lyx tool_compensation_fr.lyx): french translation update, better terms (sonde -> palpeur, chemin -> parcours)
[22:07:46] <CIA-40> EMC: 03tissf 07TRUNK * 10emc2/docs/src/gui/axis_fr.lyx: french translation update, better terms (sonde -> palpeur, chemin -> parcours)
