ACS800 Motion Control

[Peter Nachtwey]

I don't understand why there is a problem. The amplifier should be able to convert voltage to current in a dumb mode without an encoder input. Then the M02AE needs to run in torque mode where the control output is proportional to the current for the required acceleration instead of the required speed. The problem with this method is that if power goes out there is nothing to stop the motor and load unless there is an external brake.

 

[OkiePC]

In all my (old) experience with systems like this, the Amp used motor feedback for commutation, and if necessary, could repeat and even convert/scale the encoder signal to the controller...no splitter necessary...we used several different brand that would use resolver motor feedback but send quadrature signals to the motion controller. You may want to investigate if the ACS800 offers this as an option.

But I would expect them both to be connected to servo controller inputs, one configured master only, so you can coordinate the motion in the PLC (motion controller).

 

[Peter Nachtwey]

In all my (old) experience with systems like this, the Amp used motor feedback for commutation, and if necessary, could repeat and even convert/scale the encoder signal to the controller...no splitter

If so then I don't think a regular encoder will help because it won't know the phase within a turn unless the z pulse is used and there is some sort of homing routine for the commutation. Usually absolute encoders are used for commutation and the incremental encoder signal is generated from that.

 

[OkiePC]

If so then I don't think a regular encoder will help because it won't know the phase within a turn unless the z pulse is used and there is some sort of homing routine for the commutation. Usually absolute encoders are used for commutation and the incremental encoder signal is generated from that.

I looked up the old Kollmorgen BDS4 drives I remember most and they do use a resolver on the motor and the option interface board with quadrature output does include a marker pulse.

In case anyone needs a link to that fat pdf:
http://www.tallyrand.com/sitebuildercontent/sitebuilderfiles/BDS4install.pdf

Page 71 describes how to set it up. Maybe that's a throw back. I thought most of the high end servo drives had that option or feature back then...but I have been away from servos for the most part of the last 7 years.

 

[dmargineau]

I agree with Peter.
All the FCO applications I have encountered used a "slave" axis with a highly accurate absolute encoder (Hyperface type)for positioning/self-regulation
Widelto has a lot on his plate; he does need the motor encoder to "feed" both the ACS800 (self-regulation)and the motion controller (Positioning PID error computation) and I don't think the existing one will do since the ABB encoder module needs significantly higher pulse levels than the "mainstream" encoder interfaces.
ABB ACS800s are on the top tier of the VFD applications available hardware, however, they are "servo-duty" and not "servo-drives"; there are quite a few offered encoder interfaces options; maybe there is a functional encoder/splitter/encoder module set out there...I think this is what he is looking for...
And you always have the option to add another encoder...Yeah, right...

 

[widelto]

I was at the plant yesterday and found two (2) problems, there was a loose cable inside the encoder and there was also a wrong wiring. After soldering the loose cable, the RTAC-01 board seems to work, then we fixed the wrong wiring, Finally we replace the encoder with one with 1024 ppr and everything works fine, today I have to get an encoder with at least 4096 ppr, original one was 5000 ppr.
ABB also told us that we need to change the drive´s firmware for a motion control version.
I´ll let you know my advance as soon as I get replacements.

 

[dmargineau]

And yet I stand corrected for "did you check the cables and connections?" omission......It never fails, doesn't it?!...

 

[widelto]

Dmargineau: yep, I followed your recommendations, took me while but now a feel much better. Now i´m trying to get a new encoder a.s.a.p.
The main problem is that the customer doesn´t want to spend money on new parts as I recommended at the beginning.
I have other problems with some old part that´s another story.

 

[OkiePC]

Dmargineau: yep, I followed your recommendations, took me while but now a feel much better. Now i´m trying to get a new encoder a.s.a.p.
The main problem is that the customer doesn´t want to spend money on new parts as I recommended at the beginning.
I have other problems with some old part that´s another story.

I can't argue with the switch from AB to ABB for the drive, not knowing their preferences. If there are added engineering headaches due to those changes and others you mention, sometimes if you can show them the real costs they will pay now instead of forever after. I always try, so at least I can say I told you so later when they have a costly failure and it dwarfs the money they thought they saved.

Jump over a dollar to save a nickel.

And +1 for higher resolution on the carriage to get any decent precision/repeatability is entirely dependent on that device.

EDIT: +1 for higher resolution in general, what the hell this is 2013, 360 count encoders should not be available! You shouldn't be able to find one less than 1000ppr.

 

[widelto]

OkiePC, thanks for the answer and your´re 100% on the target.

 

[DickDV]

Hold on, Okie! There is still an application for 512 and 256PPR encoders. It's on shafts that are turning in the 15000rpm + range. I do a lot of test cell drive applications using special built two pole motors running 300 to 430Hz. The pulse encoder translator cards to plug into the drive have a frequency limit often around 250khz which forces you to drop the PPR at those shaft speeds.

But, generally speaking, you are correct. Better to get the pulse rate up there for accuracy purposes.

 

[OkiePC]

I know, I was just spouting nonsense.

Yeah, I was ranting a bout a particular encoder application on some OEM machines using 360ppr at less than 100 rpm...it made it easy on the PLC guy, No scaling just degrees from HMI to his spaghetti code which I don't have permission to change.

 

[DickDV]

None of that sounds very good. Of course, I couldn't program a single line of code in a PLC if my job depended on it so my opinion isn't worth much.

Did you see where some VFD manufacturers are now building their high end units with PLC front ends. Good grief! I was hoping to retire before that happened! Well, maybe not!

 

[widelto]

Motion control firmware

Customer did not find appropiate PPR encoder, however I gave a try to the one they got (2048 ppr instead of 4096) just because I want to finish this as soon as possible. In the mean time I found that ACS800 drives have a special firmware called Motion control program version APXR7300.
The unit I´m working with does not have this option (as i told before they bought it without telling me so), can this option be installed. Waiting for ABB colombia response.
Has anyone used this drive as a motion controller without this special firmware with success?? My application is a flying cutoff.

 

[dmargineau]

The "stock" ACS800 cannot be used as a Motion Controller; that's where the 1756-M02AE was intended to be used.
I've heard about the "ABB Motion Firmware" never used it though; the drive has multiple I/O ports hence two encoders could be interfaced as the Reference and Error Feedback respectively; the drive could be Ethernet/IP integrated within a Logx system (via RETA-01 adapter) so I guess it could be very well be one option of controlling your FCO.