Re: [Emc-users] VFD Interference
I found a solution to my wandering spindle speed. I ended up changing out the spindle motor cable to three wires inside metal/vinyl conduit. That didn't help. Then I started replacing CAT5 control lines with shielded cable. No good. Finally, I changed, what now seems the most obvious thing, the analog output from the serial DAC to the VFD, with a shielded pair. Bingo. It makes sense because this is the highest impedance link in the chain. I am happy again. Now to get the limit and home switches installed and working. I still have not gotten any opinions about how to configure a home switch with steppers. Do I even need one? If so, should I have an index sensor on the ballscrew to get a reliable home signal within a quarter step? Then on to the Summit tool changer. This is looking pretty easy. There is a wire for each function; tool in, tool out, tool slot forward, tool slot reverse, tool slot home, and function done. A little off topic, I noticed on the X ballscrew lazy end bearing mount, I can see the balls within the bearing. There seems to be no provision for a seal. Has anyone else seen this practice? -- Kirk Wallace (California, USA http://www.wallacecompany.com/machine_shop/ Hardinge HNC/EMC CNC lathe, Bridgeport mill conversion, doing XY now, Zubal lathe conversion pending Craftsman AA 109 restoration Shizuoka ST-N/EMC CNC) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
I believe Axis "runs" the entire program at load time. The interpreter does read and interpret ahead, but I don't know how far or what the limits are. Ken - Original Message - From: "Andre' Blanchard" <[EMAIL PROTECTED]> To: "Enhanced Machine Controller (EMC)" Sent: Tuesday, April 22, 2008 9:29 AM Subject: Re: [Emc-users] VFD Interference > At 07:35 AM 4/22/2008, you wrote: >>To the best of my knowledge, there has been no attempt to optimize the >>performance of the interpreter. If there is strong feeling that this might >>be a problem, I suspect that it could be improved significantly. >> >>My general experience with products that have never been optimized is that >>a >>factor of two is generally easy. A factor of five or ten isn't unusual. >> >>Ken > > I thought EMC interpreted the entire G code program as it was loaded and > not in real time when it is running. Which explained why the modal codes > display is only correct at the end of the program run. > > If not why does it take so long to load a program? > If only for the graphics can it be disabled and the plot created as the > program is run? > > __ > Andre' B. Clear Lake, Wi. > > > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
I made this program http://pastebin.ca/993663 (same thing I think as Jon made) I ran it on the live cd (hardy is all I have handy at the moment) on a dual core 2.2ghz. (not the greatest latency - around 20us. Anyway.. With the default stepper_inch.ini - acceleration set to 20In/s/s the program takes 1min40sec. (side not - the velocity on the axis screen reads 0) I upped the traj and axis acceleration (x and y) to 100In/s/s and the program took 1min40sec.. :) as much as I could tell with a second hand on the clock. So that calculates out to about 3.77ipm. Now - If I add G64P.0005 - the program and leave the acceleration to 20In/s/s it cruises along at 30ipm.. :) cool. Takes about 13 seconds. sam John Kasunich wrote: Jon Elson wrote: At the request of a potential customer, I did some performance tests with EMC2. I created a program with 1 blocks like N123456 G01 F30 X1. Y0. with the coordinates working around a 2" diameter circle. Each chord is roughly 0.0006" long. I ran it with the feedrate at 30 and 60 IPM, no difference, so it wasn't acceleration-related. I got 4 minutes and 17 seconds both times. That works out to 38.91 blocks/second or 2335 blocks/minute. This is on a 600 MHz Pentium III running my universal PWM controller at a servo update rate of 1 KHz. Presumably a hot 3.0 GHz CPU would do this at least 5 times faster. Jon Your test is not measuring interpter speed, or anything else that is likely to be improved by a faster PC. I am almost certain you are seeing acceleration limited behavior, but without knowing the accel limits of your config I can't do the math to be sure. First a quick look at other "bottlenecks": There is no way the interpreter is only doing 39 lines per second. I would expect the interpreter to be able to handle tens of thousands of lines per second on a fast PC. I can't think of a meaningful test of interpreter speed at the moment, but for all practical purposes it is fast enough that we don't really care much. The next bottleneck is passing commands to the motion controller (realtime code). EMC's motion controller has basically two parts that both run once per servo cycle. One is the command handler (mostly in command.c) and the other is the control code (control.c and lots of files linked to it). Each time it runs the command handler takes precisely one command from the user space code and either executes it or queues it (depending on the type of command). That means it with the default servo rate of 1KHz you can at best send 1000 commands per second to the motion controller. In practice the limit will be a bit lower, since the user space code sleeps once it sees that the motion controller hasn't accepted a previous command. The controller will accept the command after 1mS, but if the Linux (non-real-time) doesn't wake up the interpreter for 3mS, the max throughput drops to 333 commands per second. Once the command handler gets a motion command it goes into a buffer that holds 200 moves. When you start a program, the interpreter and command handler quickly get 200 moves ahead of the motion (unless you have tiny moves like your test program). The 200 move buffer is what lets us run the interpreter in user space. It's also the reason that the active g-code display doesn't track the program. Neither of those things explains your results. You said the times were the same with feeds of 30 and 60 ipm, but that does NOT mean the timing is not acceleration related. Did you try with two different accel values? Your segments are 0.0006" long, and you are requesting 60 ipm or 1 inch per second. The only way you will reach the requested speed is if your move is a trapezoid - with accel, cruise, and decel phases. The only way you get a cruise phase is if the move is long enough to let you reach cruise speed. First lets look at the case where you are in exact stop mode. Every move will have to accel and decel. If a move is 0.0006 long, the decel part only gets 0.0003 inches. The distance covered during the accel or decel phase depends on the target speed and the acceleration. The math looks like this: Speed at start of ramp: V0 Speed at end of ramp: V1 Average speed during ramp: Vavg = (V0+V1)/2 Time to reach final speed: T = abs(V1-V0) / A (A is accel in in/sec^2) Distance traveled during ramp: D = Vavg * T Substitute for TD = Vavg * abs(V1-V0) / A Substitute for Vavg D = (V0+V1)/2 * abs(V1-V0)/A SimplifyD = (V0+V1)*abs(V1-V0)/(2*A) Solve for A A = (V0+V1)*abs(V1-V0)/(2*D) We are interested in the case where you are going from some speed V0 to a complete stop. So V1 is 0, and the you can simplify some more: Decel rate for full stopA = (V0*V0)/(2*D) If you are making moves that are only 0.0006" long, you have 0.0003" to accelerate and 0.0003" to decel
Re: [Emc-users] VFD Interference
Jon Elson wrote: > At the request of a potential customer, I did some performance > tests with EMC2. I created a program with 1 blocks like > > N123456 G01 F30 X1. Y0. > > with the coordinates working around a 2" diameter circle. > Each chord is roughly 0.0006" long. I ran it with the > feedrate at 30 and 60 IPM, no difference, so it wasn't > acceleration-related. I got 4 minutes and 17 seconds both > times. That works out to 38.91 blocks/second or 2335 > blocks/minute. This is on a 600 MHz Pentium III running > my universal PWM controller at a servo update rate of > 1 KHz. > > Presumably a hot 3.0 GHz CPU would do this at least 5 times faster. > > Jon > Your test is not measuring interpter speed, or anything else that is likely to be improved by a faster PC. I am almost certain you are seeing acceleration limited behavior, but without knowing the accel limits of your config I can't do the math to be sure. First a quick look at other "bottlenecks": There is no way the interpreter is only doing 39 lines per second. I would expect the interpreter to be able to handle tens of thousands of lines per second on a fast PC. I can't think of a meaningful test of interpreter speed at the moment, but for all practical purposes it is fast enough that we don't really care much. The next bottleneck is passing commands to the motion controller (realtime code). EMC's motion controller has basically two parts that both run once per servo cycle. One is the command handler (mostly in command.c) and the other is the control code (control.c and lots of files linked to it). Each time it runs the command handler takes precisely one command from the user space code and either executes it or queues it (depending on the type of command). That means it with the default servo rate of 1KHz you can at best send 1000 commands per second to the motion controller. In practice the limit will be a bit lower, since the user space code sleeps once it sees that the motion controller hasn't accepted a previous command. The controller will accept the command after 1mS, but if the Linux (non-real-time) doesn't wake up the interpreter for 3mS, the max throughput drops to 333 commands per second. Once the command handler gets a motion command it goes into a buffer that holds 200 moves. When you start a program, the interpreter and command handler quickly get 200 moves ahead of the motion (unless you have tiny moves like your test program). The 200 move buffer is what lets us run the interpreter in user space. It's also the reason that the active g-code display doesn't track the program. Neither of those things explains your results. You said the times were the same with feeds of 30 and 60 ipm, but that does NOT mean the timing is not acceleration related. Did you try with two different accel values? Your segments are 0.0006" long, and you are requesting 60 ipm or 1 inch per second. The only way you will reach the requested speed is if your move is a trapezoid - with accel, cruise, and decel phases. The only way you get a cruise phase is if the move is long enough to let you reach cruise speed. First lets look at the case where you are in exact stop mode. Every move will have to accel and decel. If a move is 0.0006 long, the decel part only gets 0.0003 inches. The distance covered during the accel or decel phase depends on the target speed and the acceleration. The math looks like this: Speed at start of ramp: V0 Speed at end of ramp: V1 Average speed during ramp: Vavg = (V0+V1)/2 Time to reach final speed: T = abs(V1-V0) / A (A is accel in in/sec^2) Distance traveled during ramp: D = Vavg * T Substitute for TD = Vavg * abs(V1-V0) / A Substitute for Vavg D = (V0+V1)/2 * abs(V1-V0)/A SimplifyD = (V0+V1)*abs(V1-V0)/(2*A) Solve for A A = (V0+V1)*abs(V1-V0)/(2*D) We are interested in the case where you are going from some speed V0 to a complete stop. So V1 is 0, and the you can simplify some more: Decel rate for full stopA = (V0*V0)/(2*D) If you are making moves that are only 0.0006" long, you have 0.0003" to accelerate and 0.0003" to decelerate. So, V0 = 1.0 ips and D = 0.0003. If we plug those into the last equation we get A = 1666.7 inches per second squared. That is a LOT of acceleration - over 4G. Most machines have accel limits well under 1G. That means most machines will not be able to reach the requested 60 ipm during a 0.0006" long move. So, exactly how fast _can_ the machine go during a 0.0006" move? That depends on the acceleration that the machine can deliver. Let's say the machine can do 50 ips^2. (That is still pretty good - it means you can go from stopped to a 120 ipm rapid in 1/25th of a second.) The best we can do is accelerate full blast for the first half of the move, then decel at the limit for the second half. To c
Re: [Emc-users] VFD Interference
At 07:35 AM 4/22/2008, you wrote: >To the best of my knowledge, there has been no attempt to optimize the >performance of the interpreter. If there is strong feeling that this might >be a problem, I suspect that it could be improved significantly. > >My general experience with products that have never been optimized is that a >factor of two is generally easy. A factor of five or ten isn't unusual. > >Ken I thought EMC interpreted the entire G code program as it was loaded and not in real time when it is running. Which explained why the modal codes display is only correct at the end of the program run. If not why does it take so long to load a program? If only for the graphics can it be disabled and the plot created as the program is run? __ Andre' B. Clear Lake, Wi. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
To the best of my knowledge, there has been no attempt to optimize the performance of the interpreter. If there is strong feeling that this might be a problem, I suspect that it could be improved significantly. My general experience with products that have never been optimized is that a factor of two is generally easy. A factor of five or ten isn't unusual. Ken - Original Message - From: "Jon Elson" <[EMAIL PROTECTED]> To: "Enhanced Machine Controller (EMC)" Sent: Monday, April 21, 2008 11:52 PM Subject: Re: [Emc-users] VFD Interference > At the request of a potential customer, I did some performance > tests with EMC2. I created a program with 1 blocks like > > N123456 G01 F30 X1. Y0. > > with the coordinates working around a 2" diameter circle. > Each chord is roughly 0.0006" long. I ran it with the > feedrate at 30 and 60 IPM, no difference, so it wasn't > acceleration-related. I got 4 minutes and 17 seconds both > times. That works out to 38.91 blocks/second or 2335 > blocks/minute. This is on a 600 MHz Pentium III running > my universal PWM controller at a servo update rate of > 1 KHz. > > Presumably a hot 3.0 GHz CPU would do this at least 5 times faster. > > Jon > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
At the request of a potential customer, I did some performance tests with EMC2. I created a program with 1 blocks like N123456 G01 F30 X1. Y0. with the coordinates working around a 2" diameter circle. Each chord is roughly 0.0006" long. I ran it with the feedrate at 30 and 60 IPM, no difference, so it wasn't acceleration-related. I got 4 minutes and 17 seconds both times. That works out to 38.91 blocks/second or 2335 blocks/minute. This is on a 600 MHz Pentium III running my universal PWM controller at a servo update rate of 1 KHz. Presumably a hot 3.0 GHz CPU would do this at least 5 times faster. Jon - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
Kirk Wallace wrote: > I miss-typed earlier, the three "extra" wires do not connect at the motor > end. They are bundled together in the connector box, but do not Ohm out. > So I have three motor wires U, V, W and three that connect to nothing. > It sounds like you have VFD cable. There are three main conductors and three grounds. That construction is chosen to keep stray capacitance and inductance balanced and symmetrical. Regardless of any "star grounding" you may be doing, the ground conductor(s) in any cable running from a VFD to a motor should be connected to the motor frame and to the ground terminal(s) on the VFD. As Peter Wallace pointed out, winding-to-frame capacitance in the motor _will_ inject currents into the motor frame. A proper ground conductor in the same cable or conduit as the motor leads allows those currents to return directly to the drive. If you don't provide a nice direct ground, the currents will find some other path, probably one you won't like. Regards, John Kasunich - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
On Mon, 2008-04-21 at 10:14 -0500, Jon Elson wrote: ... snip > I put a power line filter on the INPUT to my VFD, and have no > shielding or other treatment on the wires between VFD and motor. > I had some hash on my computer screen before I instaled that filter. > > Jon A VFD input filter is standard fare for me now. The Bandit came with a filter on the stepper supply input. -- Kirk Wallace (California, USA http://www.wallacecompany.com/machine_shop/ Hardinge HNC/EMC CNC lathe, Bridgeport mill conversion, doing XY now, Zubal lathe conversion pending Craftsman AA 109 restoration Shizuoka ST-N/EMC CNC) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
On Mon, 21 Apr 2008, Kirk Wallace wrote:
> Date: Mon, 21 Apr 2008 08:08:37 -0700
> From: Kirk Wallace <[EMAIL PROTECTED]>
> Reply-To: "Enhanced Machine Controller (EMC)"
>
> To: "Enhanced Machine Controller (EMC)"
> Subject: Re: [Emc-users] VFD Interference
>
> On Mon, 2008-04-21 at 05:52 -0700, [EMAIL PROTECTED] wrote:
>> Hi Kirk
>>
>> One needs to be just a bit careful about grounding these sorts of
>> shielding -- if that is what's going on. I recommend star or single
>> point grounding where only one end of the shielding is connected to
>> the frame. If you bond both ends of power wire shielding you'll see
>> ground loops through the metal of the machine as well as the radiated
>> power signals that you are trying to eliminate.
>>
>> Rayh
>
> I thought these might be for shielding because they were not connected
> at the motor end and had lugs at the controller end. I should have noted
> how they were connected before I started ripping everything apart
> (Dooh). Another thing, this is currently another one of my plywood
> specials, so electrically, everything is hanging in space. Once I get
> things mostly sorted out I will make a proper steel housing.
With a VFD (or AC servo) you really really need to ground the motor. This is
of course also a major safety issue for any line operated motor.
For VFD or AC servo motors, there are often 1000s of PF of capacitance from
the stator windings to the motor frame. The high speed switched outputs will
couple to the motor frame giving you huge noise problems, not to mention the
shock hazard...
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
On Monday 21 April 2008, [EMAIL PROTECTED] wrote: >Hi Kirk > >One needs to be just a bit careful about grounding these sorts of shielding > -- if that is what's going on. I recommend star or single point grounding > where only one end of the shielding is connected to the frame. If you bond > both ends of power wire shielding you'll see ground loops through the metal > of the machine as well as the radiated power signals that you are trying to > eliminate. > >Rayh > Very good advice Ray. I ground all my shielding at the controller only. Everything is third pin grounded at the wall plugs, and I've seen no evidence of miss-behavior. grounding of shielding etc should always be done in star fashion, one common center point only. No ground loops that way. >--- [EMAIL PROTECTED] wrote: > >From: Kirk Wallace <[EMAIL PROTECTED]> >To: "Enhanced Machine Controller (EMC)" >Subject: [Emc-users] VFD Interference >Date: Sun, 20 Apr 2008 22:42:31 -0700 > >I got the spindle VFD working on my Shizuoka and the speed varies quite >a bit. This seems to be due to interference coming from the spindle >motor leads. The cable has no shielding but there are six wires. One for >each phase, and three more that seem to connect together at the motor >end, but not to anything else. My guess is these are for shielding and >should be connected to ground at the controller end. Has anyone seen >this before? I would like to verify this before I ground these wires. I >could cut the motor connections apart to verify how they are connected, >but the factory did such a nice job, I hate the mess it up if I don't >need to. Thanks. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) How about some patent on "(a+b)^2 == a^2 + 2ab + b^2"? Choose free software! -- Laurent Szyster - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
Erik Christiansen wrote: > On Sun, Apr 20, 2008 at 10:42:31PM -0700, Kirk Wallace wrote: > >>I got the spindle VFD working on my Shizuoka and the speed varies quite >>a bit. This seems to be due to interference coming from the spindle >>motor leads. The cable has no shielding but there are six wires. One for >>each phase, and three more that seem to connect together at the motor >>end, but not to anything else. > > > That sounds an awful lot like the star point of your 3-phase motor. [1] > While it's usually within a few volts (or ten) of ground, _if_ supply > and load are reasonably balanced, it's > not_for_finger_poking_or_connecting_to_ground, I submit. (If one phase > goes open, there'll then be smoke, if not before. ;-) > The star point would be near ground with balanced 3-phase Wye power. There are also corner-grounded and center-tap grounded Delta systems where it is nowhere NEAR ground. With a VFD, it will NEVER be near ground, and will guarantee a wild fireworks show if grounded. The VFD has a floating 400 V DC supply that is bouncing between the peaks and valleys of the input power waveform, and the motor's star point will be centered between those + and - voltages. I put a power line filter on the INPUT to my VFD, and have no shielding or other treatment on the wires between VFD and motor. I had some hash on my computer screen before I instaled that filter. Jon - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
On Mon, 2008-04-21 at 05:52 -0700, [EMAIL PROTECTED] wrote: > Hi Kirk > > One needs to be just a bit careful about grounding these sorts of > shielding -- if that is what's going on. I recommend star or single > point grounding where only one end of the shielding is connected to > the frame. If you bond both ends of power wire shielding you'll see > ground loops through the metal of the machine as well as the radiated > power signals that you are trying to eliminate. > > Rayh I thought these might be for shielding because they were not connected at the motor end and had lugs at the controller end. I should have noted how they were connected before I started ripping everything apart (Dooh). Another thing, this is currently another one of my plywood specials, so electrically, everything is hanging in space. Once I get things mostly sorted out I will make a proper steel housing. -- Kirk Wallace (California, USA http://www.wallacecompany.com/machine_shop/ Hardinge HNC/EMC CNC lathe, Bridgeport mill conversion, doing XY now, Zubal lathe conversion pending Craftsman AA 109 restoration Shizuoka ST-N/EMC CNC) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
On Mon, 2008-04-21 at 18:14 +1000, Erik Christiansen wrote: ... snip > You could measure resistance across two phases, and compare with > resistance from one phase to the star point. (A needle poked through the > insulation is an alternative to ruining the neat job, if the pinhole is > insulated afterwards, in case a hand goes near, under power. If I compromise the insulation, I would wand to make it obvious, but I guess it's always good to assume that insulation might have holes. I miss-typed earlier, the three "extra" wires do not connect at the motor end. They are bundled together in the connector box, but do not Ohm out. So I have three motor wires U, V, W and three that connect to nothing. > If an oscilloscope shows hash or spikes on the VFD output, is there any > chance that a few of those chunky clip-on ferrite block suppressors > would do any good? (Some of 'em are about 2" long, with a 3/8" hole, > when the two halves are clipped together over a conductor.) I put one on and the speed variance went down by about half. > How long are the leads to the motor? I was looking at VFDs a year or > more ago, and vaguely remember something about a matching or suppressor > option being required in some cases. (Didn't buy one, so put the info in > the forgettery.) The leads are about 1.5m (4') long. Another thing that comes to mind is that even though the machine was originally a CNC, it had a variable speed pulley system and was not designed for use with a VFD. I suppose I should really be thinking about doing a proper shielding job. Now that I am thinking about it, the stepper leads are not shielded either. Bandit must not have thought that it would be a problem, which so far it's not. > [1] If the motor were delta-connected, each winding would be connected > to two phases, and there'd be no star point. > > Erik Thanks Erik. -- Kirk Wallace (California, USA http://www.wallacecompany.com/machine_shop/ Hardinge HNC/EMC CNC lathe, Bridgeport mill conversion, doing XY now, Zubal lathe conversion pending Craftsman AA 109 restoration Shizuoka ST-N/EMC CNC) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
Hi Kirk One needs to be just a bit careful about grounding these sorts of shielding -- if that is what's going on. I recommend star or single point grounding where only one end of the shielding is connected to the frame. If you bond both ends of power wire shielding you'll see ground loops through the metal of the machine as well as the radiated power signals that you are trying to eliminate. Rayh --- [EMAIL PROTECTED] wrote: From: Kirk Wallace <[EMAIL PROTECTED]> To: "Enhanced Machine Controller (EMC)" Subject: [Emc-users] VFD Interference Date: Sun, 20 Apr 2008 22:42:31 -0700 I got the spindle VFD working on my Shizuoka and the speed varies quite a bit. This seems to be due to interference coming from the spindle motor leads. The cable has no shielding but there are six wires. One for each phase, and three more that seem to connect together at the motor end, but not to anything else. My guess is these are for shielding and should be connected to ground at the controller end. Has anyone seen this before? I would like to verify this before I ground these wires. I could cut the motor connections apart to verify how they are connected, but the factory did such a nice job, I hate the mess it up if I don't need to. Thanks. -- Kirk Wallace (California, USA http://www.wallacecompany.com/machine_shop/ Hardinge HNC/EMC CNC lathe, Bridgeport mill conversion, doing XY now, Zubal lathe conversion pending Craftsman AA 109 restoration Shizuoka ST-N/EMC CNC) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] VFD Interference
On Sun, Apr 20, 2008 at 10:42:31PM -0700, Kirk Wallace wrote: > I got the spindle VFD working on my Shizuoka and the speed varies quite > a bit. This seems to be due to interference coming from the spindle > motor leads. The cable has no shielding but there are six wires. One for > each phase, and three more that seem to connect together at the motor > end, but not to anything else. That sounds an awful lot like the star point of your 3-phase motor. [1] While it's usually within a few volts (or ten) of ground, _if_ supply and load are reasonably balanced, it's not_for_finger_poking_or_connecting_to_ground, I submit. (If one phase goes open, there'll then be smoke, if not before. ;-) > My guess is these are for shielding and should be connected to ground > at the controller end. Has anyone seen this before? I would like to > verify this before I ground these wires. Good plan. ;-) :)) > I could cut the motor connections apart to verify how they are > connected, but the factory did such a nice job, I hate the mess it up > if I don't need to. Thanks. You could measure resistance across two phases, and compare with resistance from one phase to the star point. (A needle poked through the insulation is an alternative to ruining the neat job, if the pinhole is insulated afterwards, in case a hand goes near, under power. If an oscilloscope shows hash or spikes on the VFD output, is there any chance that a few of those chunky clip-on ferrite block suppressors would do any good? (Some of 'em are about 2" long, with a 3/8" hole, when the two halves are clipped together over a conductor.) How long are the leads to the motor? I was looking at VFDs a year or more ago, and vaguely remember something about a matching or suppressor option being required in some cases. (Didn't buy one, so put the info in the forgettery.) [1] If the motor were delta-connected, each winding would be connected to two phases, and there'd be no star point. Erik - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] VFD Interference
I got the spindle VFD working on my Shizuoka and the speed varies quite a bit. This seems to be due to interference coming from the spindle motor leads. The cable has no shielding but there are six wires. One for each phase, and three more that seem to connect together at the motor end, but not to anything else. My guess is these are for shielding and should be connected to ground at the controller end. Has anyone seen this before? I would like to verify this before I ground these wires. I could cut the motor connections apart to verify how they are connected, but the factory did such a nice job, I hate the mess it up if I don't need to. Thanks. -- Kirk Wallace (California, USA http://www.wallacecompany.com/machine_shop/ Hardinge HNC/EMC CNC lathe, Bridgeport mill conversion, doing XY now, Zubal lathe conversion pending Craftsman AA 109 restoration Shizuoka ST-N/EMC CNC) - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
