PF525 slow response when indexing due to active bit

Normally when writing to the PF525 over ethernet i use the active bit in the stop command as told to do so by many.

this is fine for most applications however. this means the drive has to ramp down and fully stop before start can be processed again.

is there a way of starting the drive while its still active and ramping down.

my application is a conveyor system that indexes and counts products onto a conveyor using a photocell.
when blocked it adds 1 to count and tell the next conveyor to run until photocell is clear. once count is full the conveyor holding the full batch of product runs off.

what im finding is because im waiting for the ramp down the next product catches up and after this happening a few times the products are back to back and i loose the gap for my count.

i have got around this by leaving the drive running at 0hz and switching to 50hz when told to run.

not convinced this is good practice running a drive at zero frequency?

for your application it is bad to use PF525 , since PF525 is usually continuous running VFD with fixed speed, in your application you have to fully stop then start again and so on.
so better to use servo drive (Kinetix 6000 or Kinetix 300/350).
that just my opinion.

servos just isn't an option.
the system is a basic conveyor system and servos are way over the top

when we used powerflex 4s or 4Ms hard wired this isnt a problem as the drive runs when the input to drive is on so even if it hasnt ramped down if the input comes back on, the drive starts to run again.

regards

Normally it's correct to use it, but for this application I think it's fine to skip the active bit. We have PF525's on CLX with and without the active bit, depending on the integrator. I never gave it much thought until reading about it in this forum. We have no problem either way and sometimes it's convenient to see 'stop asserted' on the HIM.

how do you stop the drive without the active bit.
at the moment if i'm not sending it the start command i'm sending it the stop command.
once the active bit turns off i then remove the stop command. if i dont use this the stop command will be on permanently and i would be able to start the drive again?

Another option would be to set the stop mode to coast instead of ramp. Then the active bit should instantly go low once a stop is asserted. Only downside is the increased amps if restarted again from 0Hz if the conveyor is still moving.

Decel is needed as I set this to allow the product to travel on the batch conveyor once it has cleared the photocell

Chances are with a coast stop it would stop pretty much straight away and the small conveyor won’t have much inertia to move it on.

I thought there would be a simple solution to this but appears there isn’t

Would be good if the drive started as if it was hard wired. Signal on to run signal off to stop.

I don't have a manual handy, but are there status bits for "stopping" or "starting"? That would be the key to doing what you want.

Here's a sample of the active bit. Without the active bits, start or stop is constantly asserted. It works but for many applications, having the bits in place is preferred. Others could explain why better than I.

1 scan of plc Will switch the drive from stop to start.

I will try but I’m sure I’ve had it where the drive hangs up and turning the start command off and on allows it to run again.
Like the stop and start bits are on at the same time. When this happens there’s no fault it just sits there doing nothing

I will play about with it on a test rig and see

Ben,

The asynchronous nature of the ControlLogix networked I/O scan is the issue. I've written about this extensively on this Forum and elsewhere.

If you have a simple "if not Start, then assert Stop" rung, then there is a chance that the I/O connection will time out and send both Start and Stop bits to the drive simultaneously, and the Stop bit will override the rising edge of the Start bit.

That's exactly what's shown above in the "without the bits" rung.

The issue usually gets described as "sometimes my drive won't start when I command it to do so".

The simple way to prevent that is shown in the "with the bits" rung; you assert the Stop only until the drive has actually stopped. That way it's off when the Start signal goes from false to true.

I don't use PowerFlex 525 drives and can't say for sure what status bit would be appropriate for use instead of the .DriveStatus_Active bit in this particular application. Maybe there's an At Speed bit that will work better for this application, where the Stop bit only needs to be held high until the drive begins to ramp to stop.

Scanning through some programs here, there's some logic that has the active bit in the branch for the start rung but not the stop rung. To my knowledge these haven't been trouble. Maybe the keeping stop asserted sounds safer. We are not trying to restart these as quickly as your system so I don't know if this would work for you. I didn't find any application without 'the bit' in the start command.

Edit: Thinking about it, that wouldn't get you any extra time anyway.

I have an idea. How about just do it "without the bits" but don't give the drive a start command until the stop has been off for at least one scan. That way both bits can never be on at the same time. Takes care of the "sometimes it won't start" issue and gets you the quick restart that you want.

I think just putting an XIO DriveLogicRslt_Stop between the XIC RunFWD and the OTE DriveLogicRslt_Start would do the trick.

I didn't read through all of the posts, but I believe the code in the photo will allow restarting before it's fully stopped, I vaguely remember testing that.

After still more thinking, the likely reason we don't have problems in the 'without bits' programs is they're inside a periodic task that allows time for the IO to update before next scan. The XIO suggestion from rupej would get you an extra scan. If you're in a continuous task, a TON delaying the start command could work.