so.. where can I get 50pf thru hole caps?
in quantities less than 1000 ;)
is that hard to find? I'm surprised (without looking first)
Well - digikey was no help.
some random searching didn't help
I'm surprised digikey didn't have them
[02:10:08] <cradek> http://www.mouser.com/Search/ProductDetail.aspx?qs=XeJOwCSCkv8TfOZSduXdBA%3d%3d
thru-hole is getting less common, but not gone yet
ceramic disc, 50pF, 1kV, radial 6.4mm lead spacing
well - there you go.
they seem expensive though
Thanks - I forget about mouser for some reason.
do you need 50pf? 47 is more standard
digikey has 42,000 pieces, min order 1 pc, $0.19 each
also lots of ones with a 10pc minimum, as low as $0.076 each
if 50V instead of 1000V is ok, mouser has them for .08 qty 1
that's more like it I think
nice - thanks
regarding jogging before homing - would an additional ini file setting called something like UNHOMED_JOG_VEL make sense?
and use that for any unhomed joints
that may or may not be a good feature, but it has nothing to do with the user request
the user is afraid people will forget to home
more like a response to cradeks response :)
so they _want_ a "no user action required" home
yes, another setting to prevent "run" before homing would fix that
I don't agree with that analysis
a "user can't runn programs until they home" switch could help
yeah, I guess they really want "force home before program run"
Even that's not entirely clear, but that's probably close to what the request really is
auto-homing would require some scripting or something (loadusr axis-remote ...)
oops, I'm wrong, it does say "scared of forgetting ... before running a program"
I'd bet that preventing a run before homing, and/or limiting jog speed while unhomed, would satisfy that user
and many others
I suspect that's true
I suppose I can ask a question to that effect on the list :)
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?
hard to say
"very hot" = 70C? 100C? 130C?
70 would be OK
well, very marginal
I have not probed it but I will when I find my probe (which I also need for the car)
is there a speed on the nameplate? and can you measure the actual speed?
if it is for example a 1750 RPM motor, and it is doing 1700, that would indicate that it is overloaded, or underdriven
I will go look, brb.
also, can you measure current draw? compare that to nameplate
It is marked 3450 rpm. I have no way of measuring the speed though.
check the current draw if you can (that actually makes more sense than RPM, I was being dense)
no accessble shaft I bet
it says 230/460V 1/.5A
no accessible anything unfortunately
speaking of dense, how do I measure the current draw?
does it get hot when "idling", or only when you're turning?
there is 1ph hooked to two leads. there is a run cap hooked from one of those to the third lead.
uh - nevermind. I just noticed you mentione d"coolant pump" :)
SWPadnos: it doesn't know the difference, it's just coolant/oil, it's on or off
aha, had me wondering there :-)
I was wondering how a tiny motor like that could be on your lathe
do you have an ammeter?
this one says "DC 10A"
no AC amps
you may want caps from each driven leg to the third leg
you need a better meter ;-)
I have plenty to choose from ... somewhere ... but whether any are better is hard to say
if you don't have a meter with AC amps, you need a better meter
that is pretty much standard on most DMMs these days (last 10 years even)
fancyish digital says 20A, does not specify AC/DC
I like my ancient analog for most stuff - way older than 10 years I suppose
the digital has an AC/DC switch and the A section of the rotary switch just says "A"
so maybe ...?
dunno if a Simpson does AC amps or not ;-)
test it by measuring the current drawn by a 100W light bulb?
anyway, if the motor is running at >= rated RPM and drawing <= rated current, it should be ok
40-50C rise above ambient is no big deal for a loaded motor
if it is above rated current, maybe your pump has issues - oil viscosity too high, shaft seal sticking, impeller rubbing on something, etc
100W bulb says .80A at 120V
looks like that meter is good for AX
so that's promising
sounds about right :)
so I just insert the meter into any wire to the motor?
ideally you measure all three (one at a time)
gross imbalance (>10-15%) or overcurrent on any phase would be a problem
balanced and at or below nameplate, and all is good
hm, tonight it doesn't want to start, and it sits around 4A on the winding I'm measuring
don't let it sit long
this is a centrifugal pump?
well that's not right, is it
yes I think it is
that should require very little starting torque
centrifugals require torque proportional to speed squared
yeah, at low speed it should have ... yeah that
you've got 7uF on it?
I guess it is 7.4uF
do you have any access whatever to the shaft? can you tell if it is free-turning?
hmmm. that sounds about right. I think it's supposed to be ~50-100/HP
I also have a 5 and a 6uF I could swap in
jmkasunich: unfortunately none
which phase did you measure the current on? the cap phase, or one of the others?
the one hooked to real power and one side of the cap
I measured between the cap and motor on that wire
check the cap phase if you can, maybe the cap is low or open, and you aren't getting any starting current
I'll just try another cap, it's very simple
put the meter in series with the new cap
no difference ... adding meter
0.3A on the cap phase
my unease goes up with the square of the voltage I'm working around
so this should be pretty uneasy
I see a small inverter in your future
I wonder what the smallest/cheapest VFD would cost
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
this is 240V, right?
btw, wise to be uneasy
I'm wiring it right, right?
to the extent that there is a "right" way to run a three phase motor on single phase, yes
the reactance at 60Hz of a 7.4uF cap is 358ohms
you're not gonna get a lot of starting current thru that
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
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
I could easily make 6+7.5uF
SWPadnos: the run caps might not even be needed
jmkasunich: I chose it based on likely-ill-informed stuff I found online
like SWPadnos said, I read somewhere ... so many uF per HP
that might not be linear - might work for bigger motors
that depends on voltage, did they give different factors for 240 and 480?
I just found a page on "static phase converters" that recommends 100uF/HP at 230V
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
heh, even the cheapest drive is >$100 I suspect
that started right up with 1.25A on the generated leg
measure all three currents while running, if they are within rating (under load) you should be good to go
there sure are a lot of nixie tubes in the way when you search eBay for a VFD :)
well 1.25 > 1 already
is there a valve or anything on the coolant line? max load may occur at something other than full on or full off
1.25 > 1.0, so you need a plan B
more C? I can try 5+6+7.5
you can try that
if all three phases are at 1.25 tho, changing the cap isn't gonna improve things
in general, a motor on single phase is only good for about 2/3 of the nameplate HP
it's pumping fine, for whatever that's worth
if your pump actually needs more than 1/9 HP at the shaft, it's not gonna be happy
I'll measure another phase
on one of the wires hooked to the real power, it shows 3A or so while starting, then 0.89 while running
running current is what matters here
starting can easily be 4-6x running, and that is OK
so maybe more C will help?
1.2 is not much > than 1
I'll try it. (what else would I do?)
motor heating goes as I^2, so a little too much current is more than a little too much heat
but try it and see what effect it has
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
those squares seem to pop up wherever you don't want them
with all three, I get a much faster start and the running current on the non-fake wire is 1.1A
check all three wires - if 1.1 is the worst, you're probably ok
especially since you won't likely be running it for hours on end
darn, cap phase is 1.8.
you probably want to switch out most of the start capacitance for run mode
can you set up a switch so you can disconnect _all_ the capacitance after it is started?
then measure the current in either of the remaining legs (both must be the same in that case)
with a certain cap configuration, I get .9/.9/1.25
yes I can unhook the cap once it's running...
when I do that, current goes up to 1.19 and I don't hear any difference
so you have 0.9/0.9/1.25, and 1.19/1.19/0.0
switching out part of the cap and leaving part in might let you split the difference
tomorrow when it's completely cool, I might try the .9/.9/1.25 setup for a while and see how warm it gets
2*1.19^2 = 2.83, 2*.9^2+1.25^2 = 3.18
but does that mean anything?
should be a valid measure of heating
total heating anyway
they look roughly comparable to me then
and the first one is also better in terms of per-winding heating as well - 1.19 < 1.25
that's the one that's more complex to do
because of switching it out?
I don't have a contactor (and a mesa output) to spare
got a time-delay relay?
maybe I could get a time delay thingy
uh. 0.9^2 = 0.81, 1.25^2 = 2.25, so 2x0.9^2+1.25^2 = 1.62+2.25 = 3.87
SWPadnos: 1.25^2 = 1.56
I'm sure of it
next time I could use a calculator
I ran it "for a while" and it feels "not too hot"
is this the 0.9/0.9/1.25 version?
I assume it's way under 100c, since it feels less hot than a hot cup of coffee
the thermal time constant of a motor is probably a significant fraction of an hour
it seems like it's still getting warmer though.
I'll find my probe tomorrow.
the nominal IR loss is 3*1^2 = 3
tonight, I should go to bed
I really appreciate your help
you're only 6% over that, I bet it will be OK
but you should re-check currents if you do anything that would change the load on the pump
I might remeasure once more when I'm not sleepy
the rated current is "1" - not many significant figures there
I think its safe to assume 1.0
cradek_ is now known as cradek
jepler, have you seen this thread: http://www.cnczone.com/forums/showthread.php?postid=432441
it's old, but I'm not sure if the timings have been fixed
I guess I could look at the stepconf history myself, couldn't I
I don't know where I got my docs for the sherline timings
you'd think they'd be on the sherline website :-P
hm their website says this: "Step pulses should be at least 22 microseconds long."
[13:44:03] <jepler> http://www.sherline.com/8760pg.htm
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
I think this is like setting BASE_PERIOD to 22000
so step length and space will be minimum 22000-jitter
SETUP_TIME = 2
^^ and these must be integer multiples of PERIOD
so in dog years, stepconf probably has the wrong values, but I still don't know what the right ones are
it looks like they were trying to guarantee 22 uS, but didn't do it right
I'm not sure how much control emc1 had over that stuff
it could be that 22us was simply a good base period for the step rate they wanted
not much - just a number of BASE_PERIODs for steplen/space and dir setup/hold
no, their driver has some wacky requirements
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
hmmm. yeah, kinda
* jepler notices the source code comment: [1000, 6000, 24000, 20000], # Sherline XXX find proper values
* jepler grumbles
well this is interesting (the quoted text about how step pulse generation is done in mach): http://groups.yahoo.com/group/SherlineCNC/message/9206
sounds like it is in a doublestep-like mode by default
.. and the very long step pulse length of sherline's driver box is a non-doublestep mode
actually, it's more like there's a fast loop that generates the steps (by busy-waiting sometimes)
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"
if "soon", then a busy-wait is used instead of waiting for the next interrupt
or something like that
kind of like an adaptive ("smart") double-step
I don't see what you're saying
interrupt happens. TSC or something is read to see how close to a step edge it is
if the edge has already "passed", then the step is output immediately
if the edge is "really soon", then a busy-wait is used to wait for the edge time
if it's not needed "really soon", then it waits for the next interrupt
are you interpreting something in that message, or are you telling me about some other knowledge you have about mach?
I kinda get what you're saying, I just didn't see any of what you were saying in that message :-P
ahe sort of mentioned that there's a busy-wait for the step active druation
yeah but in emc terms that sounds a lot like parport.reset-time
bah, what you really want is a dual core machine with only a busy-loop "outb" running on the second core
voila, 500kHz step rates on common PCs
yeah, do that
emc2 can do 500khz. Neener neener neener.
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
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
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)
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
no extra movs
does the move %eax, %eax clear the top 32 bits?
it probably clears some flags but it doesn't seem like that would affect shl
ok, yes - it does zero-extend
the mov %edx, %edx seems totally useless though
that's probably why it's gone in the second example
that secondlife example doesn't explicitly clear the top 32 bits of %rax
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
"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
I wonder how many cycles "move %eax, %eax" takes? :)
err - movl
probably not too many :-P
but it's a matter of *principle*
well, I agree with that
it *should* work without the movl on any amd64 CPU
R18 can't be in circuit. http://www.electronicsam.com/images/KandT/servostart/schemagain.png
(must be 0 ohms)
* cradek gives up after 2 seconds of searching for R18
heh - sorry - it is in series with the input of the comparator.
noise must have been getting into it - the current limit was spastic at best.
Seems to be better - but I need a better motor supply.
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.
* skunkworks_ can dream..
plus the power supply sucked.
EMC: 03cradek 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: disallow MDI commands and program execution on an unhomed machine
skunkworks_: I think that these kinds of drivers are supposed to not hit the current limit during regular operation
IMO, a servo drive hitting its current limit is an error condition
it necessarily means that the motor is not able to keep up
possibly true for DC, but a PWM certainly could hit current limit within a cycle under normal conditions
it may be hard to drive it close to the edge with a slow signal like parport
because the on-times become "very long" compared to high speed PWM signals with dead time
e.g., 99% PDM at 20us BASE_PERIOD = 1980us on, 20us off
that's what skunkworks_ was saying, I think
I don't know if current limit should shut down for the rest of the PWM cycle
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"
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
dunno how fast it would need to be though, or how bad that would be for transistor heating
I feel like I win when nobody comments on a commit like that
well.. it's commited now
heh - I was away.
I was just testing the current limit. I plan on not hitting it. :)
jepler: exactly what I was trying to explain.
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)
skunkworks_: pick jmkasunich's oppinion on the subject
good night all
haw the interpreter is dealing with the Tcomands
i need to call scripts when meet tool change command
tool is changed with M6, not T
the only way to call a script is with a user-defined gcode M10x
the command is T1M6; , but what happend when the interpreter meet this command
the hal layer is told to do the tool change
can you ask a more specific question? what exactly are you trying to do?
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
in emc2 that is done by HAL
yes , but i dont know when to look
so this is my question
[19:52:08] <cradek> http://www.google.com/search?q=emc2+tool+change+hal
the first hit tells you what hal pins are used
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
this is not clear tome.
cradek: you last feature is cool but is there a way to disable it for a while ? (disallow mdi and run without homing)
you can have the machine move to a tool change location, or if using trunk, there are some other options for motion
what do you mean for a while?
maybe I don't understand, but you can use whatever version of the source you want for as long as you want
I mean that I have this option half year in my axis and I must have switch off button to allow mdi without homing
It is nessesary to intergrate machine
issy: for TRUNK, the options are described here: http://www.linuxcnc.org/docs/devel/html/config_ini_config.html#sub:%5BEMCIO%5D-Section
micges: sorry, I don't understand what you are saying
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)
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
while that may be needed for your system I don't think it's needed in general, and it would just be confusing
so this will probably just need to be a change you make to your own system
micges: what is a specific example of something you must do in MDI mode before homing the machine?
issy: what motion specifically do you want?
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.
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......
this generay is the sequence for toolcgange
so , when meet the m6 , i have to perform all this in order to change the tool
moving the spindle up and down after moving to the tool change position is challenging in HAL but some have done it
the current tool change is not very good for the case where coordinated motion is needed at multiple steps of the process.
it's fine for things like "open collet, activate solenoid, wait, close collet"
if a patch to improve this were submitted, I would be happy to review it.
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
yes, right now M6 is hardcoded to do zero or one movements and it is not configurable as a (gcode?) "subroutine".
cradek: sorry I was wrong, correct assumptions
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
if you want it to be different, your best course of action is to write what you want in C++ (modify and recompile emc)
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
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
issy: it would be nice to cleanly be able to handle a tool changer like yours. I hope you get it working.
jepler: It just last you all adding features that I have in my modifications but when I suggested it long ago nobody wanted it
It make me little angry but in another manner I know emc code very good now
micges: besides the polish translation (for which I thank you) i'm not aware of any patches you've submitted
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
ok, less talking more patches, I understand
EMC: 03tissf 07TRUNK * 10emc2/src/po/ (fr.po fr_axis.po fr_rs274_err.po): french translation update
ok enough crying for me ;)
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
first issue: halui have pins to connect encoder to control feedrate, right ?
issy: only the tool change systems that require several axis motions are currently poorly supported
micges: "man halui"
micges: the man page tells all the different way you can control feed override with halui
the movement cannot be made in auto as the interpreter stops at m6 , i have to go deep in it.
I remember something about this -- there are "enable" pins missing from halui, so you can't share that jogwheel with another function
ah, that would be nice to have
(it's the axis.#.jog-enable pin that allows the jogwheel to be shared among all axes)
micges: is that the issue want to raise?
I 've connected halui with my module to control feedrate with .counts pin
but feedrate is bouncing after changing it with slider
amplitude of bounces is changing while changing my hal module frequency
I cannot imagine what is happening
jepler thanks , begining to test , let you know tomorow
I first did halcmd setp halui.feed-override.scale .1
so that 10 counts = change by 100%
then at the shell I ran this to quickly change the number of counts:
for i in `seq -1 -1 -10`; do halcmd setp halui.feed-override.counts $i; sleep .01; done
only looking at the FO slider in the axis gui, I don't see anything weird
I wonder what is different about our testing situations
my scale is .0001
to have control speed at level 1mm/min
what do you mean bounces? how many times does it bounce?
how and where do you see the bounce?
I mean commanded value was 1.2 and for about 20 sec value changing from 0 to 3.0 about 5 times per sec
my hal module was connected to servo-thread 1kHz
do you realize that halui is not realtime and cannot give you 1kHz response or anything close to that?
yes I know
maybe you should consider using motion.adaptive-feed?
jepler is this missing pin comming from the nml?
I delayed sending command to halui to about 5hz and bounces are very small
the jog-enable i mean?
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.
halui only polls its inputs every so often. maybe you have oscillation because your feedback response is too fast
maybe halui needs logic like axis has to keep the feed override slider from bouncing around while it's being dragged
(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)
yes but I cannot imagine test case to prove this
(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)
(er, halui *could* do the same thing; I'm pretty sure it doesn't right now)
ooh it's quitting time
* jepler runs for the door
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
issy: oh, I'm sorry if I created confusion. I wasn't trying to address your issue
I was trying to guess at the issue micges was raising, but I got that wrong too
it's a bad day for me :-P
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.
jepler the m6 comand is stopping the interpreter waiting for toolchange confirmation
instead of doing this the onterpreter must perform the m98 p9001 call
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
so will not be compatibe for manual toolchange and the axis gui that is used now
EMC: 03tissf 07TRUNK * 10emc2/docs/html/gcode_fr.html: french translation update, better terms (sonde -> palpeur, chemin -> parcours)
EMC: 03tissf 07TRUNK * 10emc2/docs/src/common/ (Document_Header_fr.lyx Linux_FAQ_fr.lyx): french translation update, better terms (sonde -> palpeur, chemin -> parcours)
EMC: 03tissf 07TRUNK * 10emc2/docs/src/gcode/ (main_fr.lyx tool_compensation_fr.lyx): french translation update, better terms (sonde -> palpeur, chemin -> parcours)
EMC: 03tissf 07TRUNK * 10emc2/docs/src/gui/axis_fr.lyx: french translation update, better terms (sonde -> palpeur, chemin -> parcours)