powerflex 525 with micro 1400 messaging
- Thread starter TyJ
- Start date
In the following manual there are examples that can help:
http://literature.rockwellautomation.com/idc/groups/literature/documents/um/520com-um001_-en-e.pdf
Hope it is helpful
In the manual for 20-comm-e adapter there are examples for the message structure for RSL500 for drives PF4-40. For 525 the message is the same , but you have to look for the EtherNet/IP object in the manual i sent in the previous message.
http://literature.rockwellautomation.com/idc/groups/literature/documents/um/20comm-um010_-en-p.pdf
http://literature.rockwellautomation.com/idc/groups/literature/documents/um/20comm-um010_-en-p.pdf
Ken Roach
Lifetime Supporting Member + Moderator
The reason there isn't much information there for SLC/MicroLogix is that controlling the speed or the stop/start control of a drive using anything but cyclic I/O connections from a ControlLogix or CompactLogix family controller is not a recommended method.
To my continuing frustration, though, a lot of people want to do it. And a lot of those folks are novice users of the MicroLogix or PowerFlex or of messaging logic.
I am personally reluctant to provide advice on the topic. I once wrote a very good PowerFlex 700 and SLC-5/05 control routine for a customer who had already installed the hardware and had used SLC-5/05 instead of ControlLogix, against my direct advice. As a condition of fixing his program, I made him promise not to build another one like it, because it was likely to have problems when the system was expanded in the future.
The program worked so well they made it their standard architecture. And yes, they have exactly the problems I predicted, but now they have them in sites all over the country.
Let's skip to the end and I can describe some of the things that go wrong:
1. The next design uses more drives and the logic isn't corrected to handle the message queue correctly, resulting in "hung up" messages and drive timeouts.
2. The wrong timer settings are put into the timer logic, resulting in heavy loads on the controller's network port and a slowdown of the HMI traffic, resulting in apparent degradation of the HMI performance, which folks proceed to waste a lot of time attempting to troubleshoot from the HMI side.
3. The control system gets connected to an enterprise network with multiple RSLinx/RSWho browsing sessions open on engineering workstations, which use up all the unused CIP connections for the controller. When a drive powers down, an RSLinx session grabs the last remaining CIP connection and when the drive powers back up, it can't connect over Ethernet to the MicroLogix.
None of those would happen with a ControlLogix, because they are built to do cyclic I/O connections as part of the Ethernet firmware, and all the connection establishment, timing, and management is done by the Ethernet module, not by the user logic.
TL;DR I am a grumpy old man.
To my continuing frustration, though, a lot of people want to do it. And a lot of those folks are novice users of the MicroLogix or PowerFlex or of messaging logic.
I am personally reluctant to provide advice on the topic. I once wrote a very good PowerFlex 700 and SLC-5/05 control routine for a customer who had already installed the hardware and had used SLC-5/05 instead of ControlLogix, against my direct advice. As a condition of fixing his program, I made him promise not to build another one like it, because it was likely to have problems when the system was expanded in the future.
The program worked so well they made it their standard architecture. And yes, they have exactly the problems I predicted, but now they have them in sites all over the country.
Let's skip to the end and I can describe some of the things that go wrong:
1. The next design uses more drives and the logic isn't corrected to handle the message queue correctly, resulting in "hung up" messages and drive timeouts.
2. The wrong timer settings are put into the timer logic, resulting in heavy loads on the controller's network port and a slowdown of the HMI traffic, resulting in apparent degradation of the HMI performance, which folks proceed to waste a lot of time attempting to troubleshoot from the HMI side.
3. The control system gets connected to an enterprise network with multiple RSLinx/RSWho browsing sessions open on engineering workstations, which use up all the unused CIP connections for the controller. When a drive powers down, an RSLinx session grabs the last remaining CIP connection and when the drive powers back up, it can't connect over Ethernet to the MicroLogix.
None of those would happen with a ControlLogix, because they are built to do cyclic I/O connections as part of the Ethernet firmware, and all the connection establishment, timing, and management is done by the Ethernet module, not by the user logic.
TL;DR I am a grumpy old man.
Ken Roach
Lifetime Supporting Member + Moderator
The good news is that Appendix C of that PowerFlex 525 comms manual shows that RA implemented the same PCCC object in the new drive as has existed in the older PowerFlex for a long time.
I strongly recommend that you hardwire the Start/Stop commands if you can. You can mask out the comms adapter from giving the drive all commands except Stop.
To summarize the logic examples you're going to find in the 20-COMM-E manual:
1. Write a nonzero value to N42:3 to set the command timeout.
2. Write a 3-word integer array to N41:0, Length 3.
N41:0 Command Word
N41:1 Not Used
N41:2 Reference Value
3. Keep writing that 3-word integer array to N41:0, Length 3 repeatedly, more frequently than the timeout value you wrote into N42:3.
4. If the N42:3 timeout value is zero, the N41:0 message will fail with an error. That's good, because you can use that error code (you'll have to experiment to figure out what it is) to determine when you need to send the N42:3 value again. The N42:3 timeout gets zeroed whenever the drive is power cycled.
I strongly recommend that you hardwire the Start/Stop commands if you can. You can mask out the comms adapter from giving the drive all commands except Stop.
To summarize the logic examples you're going to find in the 20-COMM-E manual:
1. Write a nonzero value to N42:3 to set the command timeout.
2. Write a 3-word integer array to N41:0, Length 3.
N41:0 Command Word
N41:1 Not Used
N41:2 Reference Value
3. Keep writing that 3-word integer array to N41:0, Length 3 repeatedly, more frequently than the timeout value you wrote into N42:3.
4. If the N42:3 timeout value is zero, the N41:0 message will fail with an error. That's good, because you can use that error code (you'll have to experiment to figure out what it is) to determine when you need to send the N42:3 value again. The N42:3 timeout gets zeroed whenever the drive is power cycled.
Last edited:
I know this thread is old but, Ken, are you saying that if you hard-wire the start and stop commands that you could use Ethernet just to monitor the drive status? I have a project with a MicroLogix 1400 and a Panelview Plus 700. I am trying to decide what drive to use for a conveyor that has a 1 HP motor. I would like to display some basic things such as the drive speed, current, and fault status on the PV. These would be read-only, no commands. It would be easier to use Ethernet than to wire that up.
Similar Topics
I am trying to communicate to a Powerflex 525 using a Micro 820 using a MSG instruction over Ethernet. I am using the position UDFB from the AB...
Hi to all. We need to change a bad powerFlex 525 to a new one. How do you save the configuration to install in the new one? Thank you all for...
Im trying to teach a couple of labs on VFDs at a community college. We have some motor control trainers with P525s and 3 phase motors from...
New to vfds. I put in parameters. IP, but I get ethernet flashing and link solid. What did I do wrong?
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...