PowerFlex 525 Comm Loss detection.

Sparkyman1

Member
Join Date
Apr 2017
Location
Minnesota
Posts
54
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?
 
Take a look at using a GSV.

Class Name: "Module"
Instance Name: Your device
Attribute Name: "EntryStatus"


From the help:
EntryStatus


INT


GSV


Specifies the current state of the specified map entry. The lower 12 bits should be masked when performing a comparison operation. Only bits 12...15 are valid.

Value
Meaning

16#0000
Standby: the controller is powering up.

16#1000
Faulted: any of the MODULE object’s connections to the associated module fail. This value should not be used to determine if the module failed because the MODULE object leaves this state periodically when trying to reconnect to the module. Instead, test for Running state (16#4000). Check for FaultCode not equal to 0 to determine if a module is faulted. When Faulted, the FaultCode and FaultInfo attributes are valid until the fault condition is corrected.

16#2000
Validating: the MODULE object is verifying MODULE object integrity prior to establishing connections to the module.

16#3000
Connecting: the MODULE object is initiating connections to the module.

16#4000
Running: all connections to the module are established and data is successfully transferring.

16#5000
Shutting down: the MODULE object is in the process of shutting down all connections to the module.

16#6000
Inhibited: the MODULE object is inhibited (the inhibit bit in the Mode attribute is set).

16#7000
Waiting: the parent MODULE object upon which this MODULE object depends is not running

16#9000
FirmwareUpdating: Firmware supervisor is attempting to flash the module.

16#A000
Configuring: Controller is downloading configuration to the module. Either ?forward open? or (ADC) download occur during this state.
 
I completely understand what your telling me, all except for the "16#"
I'm not sure if i'm looking as ASCII characters, octal, or hexadecimal..

Take a look at using a GSV.

Class Name: "Module"
Instance Name: Your device
Attribute Name: "EntryStatus"


From the help:
EntryStatus


INT


GSV


Specifies the current state of the specified map entry. The lower 12 bits should be masked when performing a comparison operation. Only bits 12...15 are valid.

Value
Meaning

16#0000
Standby: the controller is powering up.

16#1000
Faulted: any of the MODULE object’s connections to the associated module fail. This value should not be used to determine if the module failed because the MODULE object leaves this state periodically when trying to reconnect to the module. Instead, test for Running state (16#4000). Check for FaultCode not equal to 0 to determine if a module is faulted. When Faulted, the FaultCode and FaultInfo attributes are valid until the fault condition is corrected.

16#2000
Validating: the MODULE object is verifying MODULE object integrity prior to establishing connections to the module.

16#3000
Connecting: the MODULE object is initiating connections to the module.

16#4000
Running: all connections to the module are established and data is successfully transferring.

16#5000
Shutting down: the MODULE object is in the process of shutting down all connections to the module.

16#6000
Inhibited: the MODULE object is inhibited (the inhibit bit in the Mode attribute is set).

16#7000
Waiting: the parent MODULE object upon which this MODULE object depends is not running

16#9000
FirmwareUpdating: Firmware supervisor is attempting to flash the module.

16#A000
Configuring: Controller is downloading configuration to the module. Either ?forward open? or (ADC) download occur during this state.
 
Basically, the GSV is going to return a DINT that is formatted in hexadecimal.

If, as part of the tag properties, you change the Style to "Hex" (bottom of the tag properties window) it will make a lot more sense.

You can then just do some pretty easy "EQU" comparisons to the result.

For example if "ResultTag" == "16#4000" (you can use the "16#..." prefix to a number to specify it as hexadecimal instead of decimal) then the device is running. If it's something else, it's not working properly.

These are the same values that are returned on the device properties screens (when you right-click, Properties on the device in the explorer tree).
 
My advice would be to set up the device GSV, create a destination tag that is formatted as hexadecimal and plug in and unplug the Ethernet cable and watch what the value returns as. It should make sense then. You can continuously scan the GSV so it's pretty easy (don't need a rising edge). You may want to poll the device intermittently (use the .DN bit of a timer) at some point in the future to reduce things that the processor is doing but that's up to you.
 
That example is exactly how I do it. It's an example of the general GSV usage described in the Major, Minor and I/O Faults Programming Manual:

http://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm014_-en-p.pdf

With regard to the "drives not starting when they are supposed to"; take a close look at the logic and figure out when you're holding the STOP bit true.

The classic method of "If START is not asserted then assert STOP" always has the risk that the Output connection will grab the state of both bits exactly at the instant between the rung or line that controls the START and the one that controls the STOP. That will send both START and STOP true at the same time, which causes the drive to ignore START.

I handle this by only asserting STOP when the drive is still Active. That way it's always False when the logic comes around to start the drive again.
 
I didn’t write the program, but I’ll defiantly look through it and figure out the sequence of commands.

Is it possible that the problem situation that Your describing would only present it self on an exremely rare basis?
 
I handle this by only asserting STOP when the drive is still Active. That way it's always False when the logic comes around to start the drive again.

So you assert the stop bit before you turn off the start bit, and then you turn off the stop bit before asserting the start bit?
 
Last edited:
The simultaneous START + STOP bit issue tends to appear infrequently. Not only does the I/O connection RPI timer have to expire between scans of those two specific lines of the program, but also the drive has to be commanded to start to expose the conflict.

The goal is to have the .START bit true only until the drive confirms it is running by setting the .ACTIVE bit true.

Likewise, we set the .STOP bit true only until the drive confirms is has stopped running by setting the .ACTIVE bit false.

StartStop.PNG
 
The simultaneous START + STOP bit issue tends to appear infrequently. Not only does the I/O connection RPI timer have to expire between scans of those two specific lines of the program, but also the drive has to be commanded to start to expose the conflict.

The goal is to have the .START bit true only until the drive confirms it is running by setting the .ACTIVE bit true.

Likewise, we set the .STOP bit true only until the drive confirms is has stopped running by setting the .ACTIVE bit false.

Thanks for clearing that up for me, I'm really surprised to hear that the drive is fine with not having an active start bit while its running. I assume that it will stop on its own if it looses communication with the controller, or else you would never be able to stop the drive.
 
The simultaneous START + STOP bit issue tends to appear infrequently. Not only does the I/O connection RPI timer have to expire between scans of those two specific lines of the program, but also the drive has to be commanded to start to expose the conflict.

The goal is to have the .START bit true only until the drive confirms it is running by setting the .ACTIVE bit true.

Likewise, we set the .STOP bit true only until the drive confirms is has stopped running by setting the .ACTIVE bit false.
Anything wrong with just holding the start command active always when you want the drive to run, and then holding stop whenever start is not on? Seems like that would also fix the "no start" issue and also take two fewer bits in the logic.
 
Anything wrong with just holding the start command active always when you want the drive to run, and then holding stop whenever start is not on? Seems like that would also fix the "no start" issue and also take two fewer bits in the logic.

I think what your describing is exactly what he was saying should be avoided, if you did that its possible that drive read info after the start bit turns on, but before the stop bit gets turned off, even if its the very next line of code.
 

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,358
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,925
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
56
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
186
Back
Top Bottom