Hello Guest it is April 26, 2024, 11:54:29 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - simpson36

761
The 3D nature of the part more than likely requires the segmented line approach. On the other hand, even arcs ultimately are segmented lines, albeit very small ones. If you are running say 1000 steps per inch, a .001" segment is as small as the machine can physically resolve. Moreover, there is no point in using a line segment much smaller then the tooth load, so for example it is physically possible for a .005" segment to produce an arc that is effectively as smooth as with a .001" segment.

In the OP's case, the segments are an order of magnitude too large, and I have to agree that this will be visible even with a high accelleration. Generating G-code with smaller segments should cure that, but loosing position is a separate and far more serious problem, methinks.

Here is a link a similar power supply.  Spec is slightly different, but the info is similar and the link works.

http://www.antekinc.com/details.php?p=342

762
I don't think bigger motors are going to solve your problem. I can think of four places a servo motor can loose position due to acceleration; mechanical slippage (loose pulley,etc), the servo drive itself (unlikely), the parallel port hardware or Mach's port driver. I did quite a bit of research on all of the servo drives that I reviewed and never heard of Rutex (or any others) loosing position. I have not heard of, nor do I see where an encoder can cause such a problem (although the wiring definately can). So assuming you have checked the mechanics of your machine, that leaves the port harware, or Mach.

I have occasionally had a spooky random problem with the Z axis creeping very slowly on it's own while the X and Y are moving simultaneously and the spindle is running.  Since Mach is not commanding the move, and it is open loop, it is unaware with the result being lost Z position. I had it solved for quite a while, but I recently changed the Z axis servo drive and the problem has returned. Slowing Mach to 25 clears the problem for now.  

Some specific things you can try that cost very little is
1) if not already done, shield all control wires (encoder and step/dir) and keep them as far away from the motor power wires as possible. Turn off any wireless devices (phone, network, etc) that are anywhere near the machine.

2) an add-in parallel port. These generally work better than built in ports anyway in my experience and a good one that will work fine is only $15. I posted here the exact one to buy, where to buy it and where to get the correct drivers. Do a search and it should turn up.

Very cool manifold, BTW!


763
General Mach Discussion / Re: Paralell port trouble
« on: June 22, 2010, 04:44:09 PM »
Windows printer drivers can take over the port and will typically poll the port either occasionally or constantly (Epson is particularly bad) to determine if the printer is still attached, needs ink, etc. If your print spooler has anything in it waiting to print, (or sometimes even if it doesn't) it will also poke its head in to see what's going on with the port.

These activities can interfere with Mach's port driver. Many people have posted here that removing a printer driver cleared up a random port problem, and it stands to reason considergin how the PC communicates internally.

764
Your comment about 'loosing steps' is a bit confusing. This should not be possible with servo motors.

What is your encoder resolution and what are your steps per inch in Mach. Something I have seen a lot is people converting from steppers and using stepper appropriate reductions or even direct coupling. Gearing for a 1,000 RPM stepper with max torque at zero RPM and a 4,000 RPM servo with relatively continuous torque should be very different.

Just for an example, if you have a 600 oz-in motor at 2:1 ratio,then you get 1,200 oz-in at the lead screw. If you increase the gearing to 3:1, then you get 1,800 at the screw. Huge difference. If your max desired travel is say 200 IPM, the you might look at gearing for the servo motor to be at about 80% of it's rated RPM at 200 IPM of travel. If you over size the power supply , then you can use 100% of the motor's RPM rating. That should give you the max available acceleration from the motor . . provided you give the motor it's max amps.

Stepper motors sort of pour power where servos sip, sip, sip . . . but servos want a BIG straw.  I did a lot of testing with DC brush servo motors from little36V NEMA23 to 90V NEMA34. With the bigger motors, the difference in acceleration between 17.5A max drive output and 35A max drive output is incredible.


765
My spindle is set up with 90V servo motor and timing belts for hard tapping, indexing and similar functions, but I have not found a suitable servo drive for it, so for the moment it runs off a 125V 10A Minaric speed controller, and I cannot do the functions intended, but on the other hand, it does not draw power from my current PS, which allows me to run the 4th axis for now.

I am using the following PS to run the X,Y, and Z motors on the mill, but it is not enough power for simultaneous 4th axis and spindle motor.
http://www.kelinginc.net/KL7220.pdf   (72V 20A)

So I am supplementing with the following to run both the 90V spindle and the 72V 4th axis. This is the one you might consider for your X,Y,and Z axis:
http://www.antekinc.com/details.php?p=345  (ignore the photo of a toroid coil, the product is actualy a full power supply)

Reducing the motor max speed in tuning will probably have no effect on your problem unless you are actually cutting at the MAX speed. You did not say what the material is you are cutting or the tool and RPM used, so it's no possible to suggest anything specific. However, I do have a few comments on what you have provided:

First, .090 seems like a huge segment length to me. I would think that is going to be visible no matter what you do. The .3xx chatter seems like a rigidity issue, but Mach anticipates direction changes and it must start a turn early if you do not have enough acceleration to make the direction change at the current feed rate. You are running a high feedrate and reportedly have poor acceleration which my be forcing Mach to 'round the corners'. This *might* be an explanation for the delta between the segment length and the chatter marks. You need to eliminate possibilities in order to zero down to the cause (or combination of causes). I would suggest that you climb mill with a slow, small DOC finish pass and see if you can get a smooth cut.  The result will give you a direction for further diagnosis.

766
I have a 4' x 5' Gantry router using 600 OZ Ametech servos driven 2:1 and Rutex 990H drives.
My thought is to switch to the Keling KL34-180-90 1125 oz servo and a new power supply. I'm hoping to retain the Rutex drives and limp it along until I can replace the drives with a set of Dugongs down the road.
I published my experience with several DC servo drives in this document: http://www.thecubestudio.com/ServoDriveReview.htm

I did not review the older Rutex drives, but as stated in the review, the Rutex model current at the time I reviewed it had the best performance of all of the drives. The issue was reliability at the drives rated output. The Rutex drives should be capable of doing the job provided they can handle the motor's max amps.

You did not state the voltage, amperage or type of power supply you are using. What I have found it that for acceleration, you need to have the motor's MAX amps available to the motor . . and set in the servo drive.

In DC servo land, a 9 Amp 'continuous' rated motor can want 40 Amps during acceleration. Having this available to the motor is the key to performance with DC servo motors. The 'continuous' amp rating is only relevant if you are running a spindle or a conveyor or other application where the torque is actually continuous. Machine tool axis typically operate as an endless series of near max amp draw to accelerate and decelerate with 'coasting' in between.

If you provide a DC brush servo motor with it's continuous rating, your performance will be quite dismal. If you provide a 40 Amp max motor with only 20 Amps, you will not get anywhere near the motor's actual acceleration capability. A common example would be running big motors with a little Gecko servo drive. They do run fine, but you are never going to have the acceleration that the motor is capable of. Size your power supply about 20% over the motor's voltage with amps at the motor's MAX. Set the servo drives to the motor's MAX (or the drives MAX if the motor exceeds the drive) and you will have acceleration beyond what you can probably use. Unfortunately, Rutex drives don't seem to be able to run anywhere near their actual ratings.

I am just completing a review of another servo drive which will be added very soon to the review document. After many requests and an absolute need for certain features, I am looking at the Granite devices VSD-XE drive. I am so far extremely pleased with the Granite drive's performance and feature set.

 


767
General Mach Discussion / Re: Paralell port trouble
« on: June 21, 2010, 07:24:52 PM »
Remove the printer driver. Deactivate the print spooler.

768
General Mach Discussion / Re: how to control z-axis brake
« on: June 07, 2010, 08:08:42 AM »
Both the swapaxis function and the spindle lock function are already transparent to Mach.

For those unable to accomplish a task, it is comforting to believe it impossible.

http://www.ucsofa.com/famousquotes.htm

769
General Mach Discussion / Re: how to control z-axis brake
« on: June 06, 2010, 09:44:27 AM »
Try running your setup without the wait states, I bet you will randomly trip from positional errors with a servo OR miss steps from a stepper

There are no wait states other than a sleep(10) in the macro that is there to make MACH execute reliably. 'Hard' delays seem to be needed in many cases or MACH gets ahead of itself. For example, Mach does not update the var monitor reliably without a G4 in the code where the update should occur. This is an anomaly in the software that has nothing to do with an axis lock or any other specific application.

In my testing, I was watching DROs that show both real time following error and record the max following error, so there is no need to speculate on how close it was to faulting. Theorizing is only meaningful prior to quantification. Why bet on a race that is already run.  ;)

770
General Mach Discussion / Re: how to control z-axis brake
« on: June 05, 2010, 04:58:25 PM »
BR549; just to comment on your statement, I also dislike the idea of monitoring MACH for the purpose of controlling a lock, and for the reasons you cited.

However, I did fairly extensive testing of the servo error induced by using a Macro embedded in g-code and most of the time there was no increase. In order to get even a measurable increase in following error (obviously we are talking servo here), the acceleration had to be set up to a rather ridiculous degree which would not be used in 'real life', so by any measure, the additional following error introduced by the embedded macro method was zero in actual practice. I posted the results somewhere in this forum.

The reason I believe there was no significant error introduced in *my* case, was the combination of two factors. 1) Mach was automatically prevented from starting the next coordinated move until the M code was processed and 2) the total amount of time required to release the disk brake either occurred within the time it took mach to start execution of the subsequent move . . -or- . . . . the time to release the brake occurred somewhere within the early part of the acceleration and therefor had a negligible effect.  

In a 'transparent' arrangement, the drive itself (at least the one I am playing with) changes the pin state within in a few milliseconds of new steps coming in and the instant the air valve is closed, the disk brake begins to release as the air pressure bleeds out of the cylinder. I do not have equipment to quantify this effect, but it stands to reason that whatever residual drag the lock may momentarily impart would be handled no differently by the drive than any other variable force. In practical terms the rapidly diminishing drag that might be present from the brake at the start of a move would not be different than the additional drag imposed by a heavier workpiece. These types of load are automatically accommodated by the PID scheme utilized by the servo drive.