Re: [Emc-users] Old Siemens Servo Motors With Allen-Bradley Ultra3000 Drives
On 25 October 2012 13:56, Bruce Layne linux...@thinkingdevices.com wrote: I think part of the problem I'm having might be caused by not using the Hall Effect sensors. The old Siemens motor uses 15V Hall Effect sensors and the Ultra3000 wants them to be modern 5V Hall Effect sensors, so rather than making a custom circuit for voltage translation, I've been trying to get the Ultra3000 to self-sense the commutation at startup. Not doing his would be my first approach so fixing things. Though, converting might not help if the commutation patterns are different. If the drives are using the encoders for commutation after an auto sense then the locked-rotor situation might be caused by the encoder and motor having a different idea of clockwise. I would certainly try swapping two motor power leads to reverse the motor relative to the encoder. The drives are going to need to know the encoder counts per rev and motor pole count, I guess you have configured these? (I assume that it is _possible_ to configure these) It is possible to run Hall-pattern translation inside the LinuxCNC software. The bldc component can do this, but it would not be the optimum solution. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Old Siemens Servo Motors With Allen-Bradley Ultra3000 Drives
Voltage translation of the 24V hall sensor outputs to 5V would be straight forward. Inside the Ultra the hall sensor inputs are pulled up to 5V by 1K and also the input goes through 1K to the input of a 74HCT14. There are clamp diodes at the 74HCT and a small cap. On Oct 25, 2012 8:02 AM, Bruce Layne linux...@thinkingdevices.com wrote: I'm doing a LinuxCNC conversion of a huge CNC saw and dual gantry router. I call it The Beast. It's a gantry machine with a 7.5 HP radial arm saw, two 15 HP routers, and two air drills. It's made the enclosures for some of the finest loudspeakers ever built, and needs to do so again. http://209.197.93.201/beast/Beast04.jpg For a sense of scale, the aluminum bed is 4 feet by 8 feet. Note LinuxCNC running in the lower right of the image. Also note the 44 ounce Mountain Dew next to the monitor... one a night, for too many nights to count. I'm finally close to finishing this LinuxCNC project, but progress has now come to a halt as I try to get the Allen Bradley Ultra3000 servo drive to work with the old Siemens brushless DC servo motor. Depending on the PID parameters, attempts to auto tune result in either a locked rotor or slow jerky motion in one or both directions, but auto tuning always fails. These are ancient motors, some of the first brushless DC motors to be used in CNC machines. Online info is almost nonexistent. Here's all of the data I have on the Z axis motor. Z Axis Motor: Siemens 1FT-5064-0AC01 4.5 Nm = 39.8 inch pounds = 3.32 foot pounds 2000 RPM Max 16.0 Amps Max 7.2 Amps Continuous 4.5 Kp(I) (current controller integral gain) 1.7 ohms (measured with a meter) 11.54 mH (measured with a meter) 100K PTC thermistor 6 pole 3 phase tachometer: 40V @ rated RPM short designation A18, A28, A38, H18, H28 or H38 The motor database in Ultraware, the Allen Bradley Ultra3000 servo drive configuration software, is asking for the motor's rotational inertia which I don't have, and the torque constant, which I don't have unless it's related to the 4.5 Kp(I) shown above. I made some (probably bad) guesses. I think part of the problem I'm having might be caused by not using the Hall Effect sensors. The old Siemens motor uses 15V Hall Effect sensors and the Ultra3000 wants them to be modern 5V Hall Effect sensors, so rather than making a custom circuit for voltage translation, I've been trying to get the Ultra3000 to self-sense the commutation at startup. The old Heidenhain encoders work as they should, for both the Ultra3000 servo drive and LinuxCNC. Does anybody have any suggestions that might get the Siemens motors to work with the Ultra3000 drives? Please contact me off list if you'd prefer. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Old Siemens Servo Motors With Allen-Bradley Ultra3000 Drives
On 10/25/2012 11:41 AM, andy pugh wrote: If the drives are using the encoders for commutation after an auto sense then the locked-rotor situation might be caused by the encoder and motor having a different idea of clockwise. I would certainly try swapping two motor power leads to reverse the motor relative to the encoder. My thoughts exactly. That was the last thing I tried. I bought an LCR meter so I could measure the armature inductance. It was 3X my best guess value I had been using. I plugged in the correct value and the auto tuning failed as before. Then I swapped two of the motor leads at the servo drive. It did behave a bit differently. It moved a little bit (still jerky) and then generated an E39 error - Self-sensing Commutation Startup Error. I had seen that before, when I first connected the motor and tried to move it before doing the commutation diagnostics. That suggested to me that the servo drive probably did know the correct commutation. The drives are going to need to know the encoder counts per rev and motor pole count, I guess you have configured these? (I assume that it is _possible_ to configure these) There is a place in the motor configuration database for the motor poles, which I've correctly configured. There's a place in Ultraware for the encoder counts. This may be the crux of the biscuit. I'm not that sure of the encoder counts per revolution. I've been so focused on the motor that I forgot about that gross assumption. This is the top of my list of things to do tonight. Put the motor leads back the way they were so the E39 error goes away, and take a long hard look at the encoder. It's mounted on the motor so I assume it's turning in a 1:1 ratio with the motor, but I'm not that sure of my facts, including the 2000 line encoder count. At the very least, it won't take long to try different encoder counts and see if the auto tuning changes. Of course, what I failed to do in my Mountain Dew addled sleep deprivation was put a mark on the motor pulley, manually rotate the motor one complete turn, and see how much the encoder count changes in Ultraware. That's DUH obvious now in the light of day. It is possible to run Hall-pattern translation inside the LinuxCNC software. The bldc component can do this, but it would not be the optimum solution. That's another great suggestion that I hadn't considered. The Ultra3000 servo drive wants to be first in line to the encoders (doesn't everyone?) and they offer the option of buffering the encoder signals before sending them to the CNC controller. Currently, I'm running the Ultra3000 and the MESA 7i77 connected to LinuxCNC in parallel on the unbuffered encoder signals. I did measure to make sure that the combination of the Ultra3000 and 7i77 didn't load the encoder signal too much when I originally wired it. But I never considered using the very versatile 7i77 as the voltage translation device, buffering the signal for the Ultra3000. BTW - Todd gets credit for this suggestion because he answered off list, 30 minutes before Andy. :-) On 10/25/2012 02:14 PM, John figie wrote: Voltage translation of the 24V hall sensor outputs to 5V would be straight forward. Inside the Ultra the hall sensor inputs are pulled up to 5V by 1K and also the input goes through 1K to the input of a 74HCT14. There are clamp diodes at the 74HCT and a small cap. I had already looked ahead that far, so I wasn't too concerned about the 15V encoder signals into the Ultra3000. I hadn't looked into the 7i77 encoder inputs yet, and was thinking that in the worst case, I might need to use the Ultra3000 to buffer the encoder signals to the 7i77. Mostly, I wasn't happy about soldering a new high density D-sub connector cable to get the Hall Effect sensor data into the three Ultra3000 servo drives. There was also the ugliness of using a zener diode to make 15V from 24V that I was hoping to avoid if it wasn't necessary. All of these are viable suggestions. My prioritized To Do list: 1) Verify the encoder counts per revolution. 2) Verify that the Ultra3000 is configured for the proper encoder resolution. 3) See if the Hall Effect sensors will operate from 5V. 4) If not, run the Hall Effect sensors from 15V. 5) Sell the antique Siemens servo motors on eBay for outrageous prices to some desperate souls who need to keep their ancient CNC machines running, buy shiny new plug-n-play Allen Bradley servo motors, and let Joe the brilliant maintenance guy figure out how to mount them to The Beast. :-) Big thanks to everyone for taking the time to reply to my desperate cry for help. Your replies were very helpful, and are much appreciated. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today:
