I would fix the serial port, that would be 50 times more economical.
We have a 1985 J325 that we bought as a package deal with some other manual milling machinery. It powers on and we have been able to do some simple machining processes like cutting flanges and circular pockets and such, but we are now interested in setting it up to use contemporary CNC and CAM features. I have very little experience with CNC machinery, so bear that in mind when you read the following.
The machine has a Delta 20 but we were warned that the RS232 connection does not work. The rear cabinet has a DuraPulse GS3 installed and the side cabinet looks to have the original motor controllers and encoder. The axis drives are Baldor Permanent Magnet Servos. I would like to do something similar to the work this guy posted - search for utbiz cnc retrofit
Again, keeping in mind that I have no experience with this, can you guys point me in the right direction. What do I need - what are your recommendations?
1.Motor Controllers - x 3 for the X,Y,Z axis (Gecko G320X or Viper) ???
2. CAM software - we have Alibre that we design in but nothing to convert drawings into tool paths (Mach3 with LazyCam) ???
3. Breakout Board - (is this also called the Encoder? to connect Motor Controllers to PC) ???
4. Spindle Motor Controller - is this what the DuraPulse GS3 is currently controlling? Will it work with the Breakout Board and CAM software
5. Large DC Power Supply - Can I use the existing power supply in the cabinet???
Again, any help would be appreciated.
I would fix the serial port, that would be 50 times more economical.
Patience and perseverance have a magical effect before which difficulties disappear and obstacles vanish.
Why pull a decent servo drive and install something like a gecko? Baldor stuff is pretty good, and you have encoders, i wouldn't go back to open loop.
So, what you have is a mid 90's Tree, probably ~95, not 85. You have a delta 20, so you have graphics, calc assist, and RS232C (drip feed), also EIA programming, so a modified fanuc post can work. Checking/fixing the RS232 wouldnt be that big of deal. The original spindle drive was probably a Yaskawa, those had a tendency to fail because of the cooling vents getting plugged up, and the replacement was $$.
Personally, fix what you got. Its not a bad system once you get to know it.
Jeff, underthetire - I appreciate the advice. I also didn't mention the following quirks: Occasionally, an X or Y axis will stop working in the middle of a program. The program will not end, and the remaining good axis will continue to move which usually sends the end mill gouging into the part or breaking it. Also, it will always rapid too fast in the Z tripping the limit switch and faulting it. Before sending it to the home position, we have it slowly bring the Z back all the way before making any X-Y travel. You cannot leave the machine unattended as the operator must always be ready to turn the feedrate override way down for Z travel or to stop the program if an axis stops working.
The SN for the machine is 9-25-85-5596 so I assumed it was a 1985. What typically goes wrong with the RS232J connection - where do I start looking?
Sounds like the drives are way out of tune. Go to mode select 6 I believe (set up) and turn on the lag or servo error screen, can't remember what they call it now. Go to jog, and with the medium jog and override up, jog each axis. Note what the servo error is both directions. Then note what it is at stand still. Report back. My guess on the rs 232 is tree used a parallel type connector, and the previous owner was trying to use a std serial cable. Get a led light box before you dump any money there.
Mode - Select 5 (Setup)
Test Mode - TM4 (Servo Adj)
Mode - Select 0 (Jog)
Select 1 (Medium
...With the Feedrate Override turned all the way up (+) the readout screen also has a Axis Lag now and reads the following when I jog in the (-) and (+):
What is this tool you refer to "Led Light Box"?
You need to tune your drives, especially z. Don't think it will cut a great circle either with the x and y being off. At stand still, should read 0 +/- 1. Think you need to turn the tach pot on the drive till you get all 3 axis matched. There is a procedure you can get from bob Norman at zps. The light box is a simple rs232 tester that plugs in to the comm port.
About the axes:
The DynaPath 20 control had several parameters associated with axes control, so a few assumptions must be made. Assuming the fully CW position on the FRO pot was set to 150% in the parameters, then you are jogging the axes at 15 ipm (medium jog is 10 ipm). Other numbers set by parameter are Gain (below gain break) or KV1, Gain Break Velocity and Gain (above gain break) or KV2. Since your jogging at 15 ipm, you're well below gain break and only have to worry about KV1, which was usually set to 0.8 or 1.0. If the gain was set to 1, the lag at 15 ipm should be 0.015. If the gain was set to 0.8, the lag at 15 ipm should be 0.015/0.8 = 0.0188. I'd say you are in the ball park.
The lag at stand still (the balance) looks good. Ideally, it should be 0.0000", but a count or two in the last digit is no big deal. I you get 0.0005" or greater on the lag display during program execution, then the control may appear to stop program execution while it waits for an axis to come into position. If this were the case, then the balance for that axis may need adjusting, but I don't see it in your case.
The more important factor with the axes is that the lag on X and Y be equal when jogged at the same speed. Because you are jogging at 15 ipm, you are making adjustments pretty far down the curve. You may want to see how these numbers compare when you move at something like 80 ipm. If you leave the control in TM4 and run a part program that repeatedly moves the X and Y axes equal distances in the same block (a 45 degree move), then you don't have to worry about holding the jog buttons while you observe or make your adjustments.
The Z axis may be set up differently and I'm not shocked by the numbers you're getting. That being said, it does sound like you may have an intermittent connection on X or Y and some other issue on Z. A misadjusted or intermittent tach could give you a lot of overshoot. When you move Z quickly or at rapid, carefully observe how it stops. It should stop with very little overshoot and should not have to "back up." If it is, you may want to try turning up the tach gain. But if the tach is going bad and is intermittent, it may have to be replace.
It's a little puzzling that these "quirks" as you call them don't cause servo errors on the DynaPath control, but early 10s and 20s didn't have all the error checking on the axes movement that the newer ones do, so I guess it's possible. Sorry I can't be more specific.
On the RS-232C serial port:
The communication port on a DynaPath is always an RS-232C serial port. Serial ports, prior to USB, were accessed with a 9 pin D connector or, on the older 10s and 20s, it was a 25 pin D connector. "Really old" ones had MS-style connectors. The DynaPath web site (DynaPath CNC Controls & Machine Tools) has more information on the pin assignments. Look under 'Control Support' or follow this link:
DynaPath CNC Controls & Machine Tools
I would recommend trying to send from the control first to see if the port works in the send direction. I would also recommend using a null modem serial cable. The term "null modem" refers to the fact that the send and receive lines "cross." In other words pin 2 on one end goes to pin 3 on the other and vice-versa.
Be aware that Tree made the cable going from the Aux Control Card on the DynaPath control rack to the 25 pin connector at the skin of the cabinet. You may want to try a straight thru cable if the null modem cable doesn't work.
Let us know how you make out!
I appreciate the help guys - here is what we tried (but still cannot get the RS232 to work). We ordered the RS232 Breakout Box and it should be here soon. I went to the link for DynaPath and followed the instructions for using HyperTerminal to send and receive files. We still cannot manage to load or send files from the Dynapath. When the suggested parameters for HyperTerminal did not work, we tried numerous other settings (Parity-Even/None, Bits -7/8, COM1/3) and with/without null modem cable. We made sure to set the Baud, Parity, Echo, Buffer, etc. per the Dynapath manual and followed the instructions for load and record to the word. Then we tried different combinations of settings. We loaded a serial port monitor program for the computer and verified that the computer port (COM1) was outputting a signal when we hit transmit.
However, when we try to transmit from the Dynapath(RECORD in Dynapath terminology), the serial port monitor does not detect any incoming signal. Strangely, when you disconnect the null modem cable and hit RECORD, the DynaPath hangs up at BUSY unless you cancel the transmit. So no luck with transmitting or receiving with the Dynapath.
I looked at the pinout for RS232 connection and tested the voltage at pin 20 and 8 on the Dynapath connection and got ~20V and 8V. I also traced the RS232 wires back to the cabinet and pulled the board they were connected to. It said Auxiliary Control on the bottom. I inspected it carefully but I could not see any burnt trace or fried capacitors. I even gave it the 'sniff' test but could not smell any burnt electronics.
I guess I don't know what to diagnose now - what do I do with the Breakout Board? Is it unusual for the RS232 connection to stop working? Thanks again.
Ohh and FYI, if you pull the Aux Control board, it will erase all of your stored programs on Dynapath, so I have alot of keying in unless I can get this thing fixed.
Well, tree did do one strange thing I saw on some machines. Normally, you want a null modem cable, however on some tree models, i found that the 2-3 and 3-2 swap (normal) didn't work. You had to use a straight 2-2 and 3-3, 7-7, and pins 4-5 jumped and 6-8-20 jumped.(assuming 25-25 pin) Once you get the light box, you can then play around and test further.
The backup battery is on the Aux Control Board and the RAM it supports is on the Processor board, so pulling either from the rack will cause a loss of part program memory and tool offsets.