PowerFlex 525 Comm Loss detection.

You're getting it exactly.

Let's say your system logic to start the drive becomes true, and the controller solves the ladder rung with the START bit on it.

But then, in the instant before the next rung is executed, the I/O connection Requested Packet Interval times out and the Logix operating system grabs the current status of the Drive:O.Command word (all sixteen bits) and sends it to the drive.

The very next rung, which would have set the STOP bit to False, has not executed when the whole Output.Command word was copied out to the communications subsystem.

So the output word includes both the .START and the .STOP bit as true.

In the A-B world, STOP commands always win. It's that way on terminal strips, and over networks, and in every other instance where both Start and Stop can be present at the same time.

The classic indication of this network problem is when an operator tells you "I've got to punch the Start button several times before it takes effect". You can even see that in the habits of operators hammering on a Start button even long after the problem has been solved.
 
...i'm wondering if writing to that tag (I.OutputFreq) could be the cause.

As you've no doubt established from the posts above, the issue is likely to be around the timing of your start/stop commands. But just because you asked this question specifically...

No. That couldn't be the cause. If you write over input data, it doesn't actually send that to the drive.

Essentially, your Input Data is just a tag structure, with data in it. If you have a 20ms RPI to your drive, then every 20ms the processor will gather values from the drive and dump them in that tag structure. You can also update the tags yourself, which is what you're doing in this program. But these tags don't actually go anywhere, they're just a memory area that the drive data gets put in when it arrives.

I do exactly the same thing with powerflex 525, only I use a different data bit which I generally don't need for anything else, rather than the output frequency. It works seamlessly, never any problems - and I use the start and stop timing as described by Ken above.

The GSV is probably a *better* way of detecting comms failure, but the disadvantage of that is that you can't do it within an AOI, because you have to point it to the ethernet object directly. Since I like to have everything to do with controlling and monitoring the drive packed into one AOI and tied up with a nice ribbon and a bow, I figured my way is the next best thing.
 
No. That couldn't be the cause. If you write over input data, it doesn't actually send that to the drive.

Essentially, your Input Data is just a tag structure, with data in it. If you have a 20ms RPI to your drive, then every 20ms the processor will gather values from the drive and dump them in that tag structure. You can also update the tags yourself, which is what you're doing in this program. But these tags don't actually go anywhere, they're just a memory area that the drive data gets put in when it arrives.
When you put it that way, yeah. of course the program doesn't send input data BACK to the drive. doh, why didn't I think of that.

Thanks!
 
Processor is a L32E

For some reason, I thought that there was a tag member that would give a status on Ethernet communications for a powerflex 525 VFD. But I cant find it anymore.

Currently program that i'm looking at is writing a negative value to the tag "I.OutputFreq" and then waiting for that value to be corrected by the VFD.

That system works for detecting com loss, but we've always had intermittent troubles with VFD's not starting when commanded (for no apparent reason) or not reaching the proper speed, faulting, or showing comm loss, and i'm wondering if writing to that tag (I.OutputFreq) could be the cause.


How do you guys detect when Ethernet communications to a PF525 are lost?

AB has a AOI and faceplate on their sample code site that will handle the com loss.
 
You're getting it exactly.

Let's say your system logic to start the drive becomes true, and the controller solves the ladder rung with the START bit on it.

But then, in the instant before the next rung is executed, the I/O connection Requested Packet Interval times out and the Logix operating system grabs the current status of the Drive:O.Command word (all sixteen bits) and sends it to the drive.

The very next rung, which would have set the STOP bit to False, has not executed when the whole Output.Command word was copied out to the communications subsystem.

So the output word includes both the .START and the .STOP bit as true.

In the A-B world, STOP commands always win. It's that way on terminal strips, and over networks, and in every other instance where both Start and Stop can be present at the same time.

The classic indication of this network problem is when an operator tells you "I've got to punch the Start button several times before it takes effect". You can even see that in the habits of operators hammering on a Start button even long after the problem has been solved.

But I'm talking about holding the start command active the entire time you want the drive to run. So even if the drive saw the start and stop bits at the same time for one scan, it would see only the start command the following scan, and would take off running with no issues (except for a one-scan delay), right?

I'm asking seriously because that's how I've done it in the past.
 
Last edited:
In general, an A-B drive needs to see the START command go through a False-> True transition when the STOP command is currently False.

Dropping the STOP command one I/O scan later is not equivalent because there is no transition of the START command.

The ordinary "if not START then STOP" logic worked fine on old PLC-5 and SLC-500 systems that use synchronous I/O updates, and it will work most of the time on a Logix system that uses asynchronous I/O, like over EtherNet/IP. If your motors start infrequently, and your PLC program scan time is relatively long compared to the I/O update, then you might never experience a suppressed Start command.

I don't know for sure if that's what's happening in the system that started this thread, but I've experienced it (and done in-depth analysis) and I'm confident in my descriptions.
 
CV4.png


You guys guessed this one EXACTLY
 
In general, an A-B drive needs to see the START command go through a False-> True transition when the STOP command is currently False.

Dropping the STOP command one I/O scan later is not equivalent because there is no transition of the START command.

The ordinary "if not START then STOP" logic worked fine on old PLC-5 and SLC-500 systems that use synchronous I/O updates, and it will work most of the time on a Logix system that uses asynchronous I/O, like over EtherNet/IP. If your motors start infrequently, and your PLC program scan time is relatively long compared to the I/O update, then you might never experience a suppressed Start command.

I don't know for sure if that's what's happening in the system that started this thread, but I've experienced it (and done in-depth analysis) and I'm confident in my descriptions.

Thanks for the explanation- I hadn't thought about it requiring that extra transition. I'll test it out the next chance I get.
 
The GSV is probably a *better* way of detecting comms failure, but the disadvantage of that is that you can't do it within an AOI, because you have to point it to the ethernet object directly. Since I like to have everything to do with controlling and monitoring the drive packed into one AOI and tied up with a nice ribbon and a bow, I figured my way is the next best thing.

You can actually point the GSV properly when it inside an AOI. I learned this at this years Rockwell Automation on the Move.

What you do is is declare an "InOut" tag of data type "MODULE" in the AOI (for example, "set_ModulePath"). Inside the AOI set up your GSV with the "Instance Name" of "set_ModulePath" (or whatever your InOut tag was named). When calling the AOI you just point drive to that tag (use the device name).
 

Similar Topics

I had to replace 3 PowerFlex 40 multi-drives that each had 3 PF4M daisy chained off the DSI port. The PF40s had comm-e cards installed for...
Replies
9
Views
2,356
Bear with me for a moment. So an issue came up this morning, one of our pumps wasn't running. I plug into the processor (5069 ver 31), the...
Replies
5
Views
3,923
Good Morning , I just recently did a project with several PowerFlex 525 drives. I just recently started getting a F 73 Fault ( EN Net Loss...
Replies
24
Views
23,920
Are the N files in the 525 the same as the 40p for ethernet? (E-Comm card) I have used 40P with Micrologix 1400 Messaging but don't see the N...
Replies
0
Views
52
Hey all, I am currently working on a depalletizer for a customer and we are doing a hoist upgrade. This is a SLC500 processor and the drives are...
Replies
6
Views
182
Back
Top Bottom