Powerflex 525 Encoder for Speed Feedback

Hi all,

Using a powerflex 525 with a quadrature encoder for the first time. The application is to track product movement along a belt from a metal detector to a reject point. The PF525 is connected to a GuardLogix PLC using the embedded ethernet port, so I want to try to get the speed feedback data over that link.

I've read through the manual and think I have my head around how it works, but the manual gives me a few options for the encoder setup and I'm not sure which is best for my application...

1. If enabled by P047 [SpeedReference1], the encoder or pulse train will be used directly as a commanded speed (normally used with a pulse train) or as a position reference (normally used with a quadrature encoder).

Click to expand...

If I understand correctly, this method would mean that I can either give the drive a speed reference via pulse train, or give it a position reference and have the drive go to that position using the encoder as position feedback. Neither of these are what I want - can I give the drive a speed reference and have it go to that speed using the encoder to confirm speed feedback? I'm not sure whether "normally used with a quadrature encoder" and "normally used with a pulse train" should be taken to mean "that's the standard but other options are available" or "that's really the way to do it, if you try to do it any other way you're doing it wrong".

2.If not enabled by P047 [SpeedReference1], when the PID Feedback or PID Reference are set to use an encoder then the PID function will use the encoder or pulse train input.

Click to expand...

I don't think this is what I need - a PID speed loop seems way overkill for this. I just need to know an accurate belt speed.

3.If not enabled by P047 [SpeedReference1] or the PID parameters, then if A535 [Motor Fdbk Type] is set the encoder or pulse train is used for direct feedback and trim of the speed command. The normal slip compensation is not used in this case. Instead the drive will use the encoder or pulse train to determine actual output frequency and adjust the output frequency to match the command. Parameters A538 [Ki Speed Loop] and A539 [Kp Speed Loop] are used in this control loop. The primary benefit of this mode is increased speed accuracy when compared to open-loop slip compensation. It does not provide speed bandwidth improvement.

Click to expand...

This one seems like it might be what I'm after. If I understand correctly, I will give the drive a speed reference of, say, 47.5Hz, and it will run at whatever frequency is required to make the encoder input match the 47.5Hz command. Am I right so far? If so, I guess that just means I will have to tune up parameters A538 and A539 to give consistent speed control. How would I go about this? Is it just a matter of commanding rapid speed changes and massaging the values until I get a smooth response? Or is there a more "scientific" approach I could take?


I feel that option 1 is the simplest, but I'm not sure if it actually does what I want - if not I guess I'm looking at option 3. Any tips?

Secondary question: I've found that I can read display parameter d378 (encoder speed) as a datalink, which would potentially mean that the drive could just keep on doing what it's always done with no attempt to control at a certain speed based on the encoder feedback - and just read the actual speed from the drive. This is an option, although there are a couple of problems that I can see...
1. It's a 32-bit parameter, so it takes up two of my precious four datalinks. Is there any other way of retrieving this value?
2. Accurately measuring the speed and calculating position based off that is probably not as robust a solution as accurately controlling the speed and calculating based off that.

Thoughts?

How accurate does this need to be? Is the encoder on the motor or the conveyor? If it's on the motor, I wouldn't even try to read the speed feedback, I would just assume the commanded speed is the speed (aside from ramping.) If it's on the conveyor (which is where it should be if you're trying to do accurate positioning) I probably wouldn't wire it to the drive itself, I'd wire it to a high speed counter. Just my $.02 of course.

It doesn't need to be super-super precise. It's a very slow moving process, we're talking a handful of metres per minute. It's just a matter of the reject point being a good 5-6 metres away from the detection point, so I have to track it for a good little while.

The encoder is going on the conveyor itself - I explored the option of a HSC and also an Ethernet/IP encoder, but going direct to the drive was the most cost effective option given that the drive is already in place, but the ethernet switch is all but maxed out and there is no HSC module in place.

ASF said:

It doesn't need to be super-super precise. It's a very slow moving process, we're talking a handful of metres per minute. It's just a matter of the reject point being a good 5-6 metres away from the detection point, so I have to track it for a good little while.

The encoder is going on the conveyor itself - I explored the option of a HSC and also an Ethernet/IP encoder, but going direct to the drive was the most cost effective option given that the drive is already in place, but the ethernet switch is all but maxed out and there is no HSC module in place.

Click to expand...

So will the conveyor speed vary? Is it just a matter of the conveyor stopping and starting? If the position isn't super critical and and the ramp isn't particularly long, it would seem a simple RTO instruction would do the trick without examining the speed feedback. Using a 525 with an encoder on the conveyor itself seems a bit advanced for that drive, you're trying to regulate a speed loop with feedback after the transmission and then do position control. Either the application is really simple and you can just use a timer, or you're asking for trouble not using the right hardware. I'm not sure which, I haven't seen the conveyor

The conveyor speed typically doesn't vary, only when they change products.

We are allowing an encoder because the belt is quite long, so we're putting the encoder at the tension take-up mechanism to ensure that any slippage at the motor end doesn't give us any errors.

I mean, right now, the reject is done with hardware timers and relays, and doesn't take belt speed into account at all. So anything is an improvement on that. But the customer wants to be able to be certain that they're accurately tracking and rejecting all traces of metal from their process, and they want it measured, not just guesstimated. Hence the encoder - it was specified by the customer's engineer.

Ultimately the arrangement is what it is, I just need a little more of an in-depth description of how those three options from my first post work, so that I can determine which is most suitable for what I'm trying to do, with the setup I have.