Messaging to Powerflex 4m over Ethernet

[Controls Tech]

Hello guys its me again, I have finally found time to finally get back to messing around with my "test bench" and I want to use messaging to read/write parameters to my powerflex 4m over Ethernet if possible. I am using the 22-xcomm-DC base with a 22-comm-e module installed I am able to see the drive in linx and CCW. All I am really looking to do with the drive is ramp the motor up and down from a Panel View 600. The manual for the 22-comm-e only provides programming examples for the PF 70s and the only "stuff" I see in the powerflex 4m manual is for Modbus. . Any pointers or tip would be greatly appreciated. I would upload the file but I keep getting invalid file. Its a .RSS

 

[Ken Roach]

To attach a PLC program file, just ZIP it.

I presume there's a MicroLogix 1400 or 1100 controller involved ? Or are you trying to go direct from a PanelView (Plus or Standard ?) to the PowerFlex 4M ?

The 20-COMM-E manual will have PowerFlex 7-series information. Make sure you have the 22-COMM-E manual.

It's definitely do-able to message to the drive from an Ethernet-equipped MicroLogix. There are examples in the Knowledgebase too.

 

[Controls Tech]

Hello Ken, Yes I am using a Micrologix 1400 1766-L-32 bxb that has a built in Ethernet port, I would like to message from the ladder logic, and just ramp the drive up/down from the panel view plus 600. Attached is a part of the program that I have already written with controls from switches/buttons hard wired and from the panel view. The message instructions in the lower rungs was my attempt to communicate with the drive. The drive IP address is 198.162.1.8. Does it seem like I am on the write track? Trying to solve the message instruction is more difficult than I thought. Since I posted this I have "cleaned up" my message and Routing files.

 

[Controls Tech]

Here is a version that I have been working on, didn't work, but that is what practice is for think I am starting to understand how the message instruction works a bit more.

 

[Geospark]

Explicit Messaging is Non Deterministic...

...messing around with my "test bench" and I want to use messaging to read/write parameters to my powerflex 4m over Ethernet if possible. All I am really looking to do with the drive is ramp the motor up and down from a Panel View 600...Any pointers or tip would be greatly appreciated...

As you appear to be at the learning stage, and even though you are only attempting this on a "test bench", I feel it important to point out to you the limitations and potential risks involved in what you are trying to achieve, should it be implemented in a real world application.

These limitations may not necessarily be an issue for every application, but more, that you should be aware of them when considering using this method of drive control for certain applications. A Risk Assessment should always be performed and include these limitations when identifying potential risks, should control of the process be lost.

I would urge you to read this technote which highlights the limitations that need to be considered and also provides details on how to configure such a setup...

52205 - PowerFlex Drives: Controlling via EtherNet/IP from MicroLogix, SLC, PLC5, CLX V15 and below
Access Level: Everyone

We would always at a minimum advise that users implement hard wired start/stop control to the drive and only use Explicit messaging for changes to the Speed Reference and to read feedback data. But your own assessment should best decide what level of Explicit control would be safe to use, or not.

"Ramp" would suggest modulation of the drive output i.e. Loop Control. This would be another level of speed control beyond merely changing the Speed Reference, say before starting, and would also not be recommended here using Explicit messaging. But perhaps by "ramp" you just meant manually changing the Speed Reference on the fly?

Regards,
George

 

[Controls Tech]

Yes, that is what I meant by "ramp" changing the speed on the fly. I have the program written with hard connections, so that I can start/stop the drive with hardwired buttons, change direction with a hardwired 3 position switch and I can also do this with the panel view plus, I am just practicing messaging between devices.

 

[Geospark]

Yep. That all sounds good to me.

Forgive me if all that was clear in your attached project file but I am not in a position to view your logic right now.

I know you are only practicing, and were probably not considering using this anytime soon in the real world, but the learning stage, especially, is when I feel it's best to point these things out so you don't pick up bad habits. But you look like your down the right path so far.

Is the technote of any use to you regarding the configuration and sequencing of the MSG instructions?

G.

 

[Controls Tech]

Yes that tech notes is a good example, thanks, looked at this document, while I was trying to program mine. One of the things that I am not sure took was entering 5 into N20:0. But I did not get any COMM error. But don't really have a start/ stop programmed thru the comm port either.

 

[rupej]

Sorry, I don't have access to that technote right now, but what is the safety concern with using MSG instructions to control a drive for start/stop?

I've done it and while clunky, it seems safe to me. If the drive doesn't receive a message within the timeframe that you specify, it faults. I've tested that and it works as intended.

 

[Geospark]

...If the drive doesn't receive a message within the timeframe that you specify, it faults...

This is the key factor here...

When asserting Start/Stop commands, using Explicit messaging, you must initialize the communications adapter's timeout value before issuing any commands, each and every time. This is because the default value is "0" which effectively disables the timeout i.e. no commands will be accepted by the adapter. However, in setting this value, you must allow a minimum ammount of time for the program to scan, enable, queue, buffer and transmit the MSG instruction's data, or error after the MSG instruction's own timeout.

Due to the inherent delays in using MSG instructions, which must go through the above process within the program's scan time, the recommended value of 5 - 20 seconds should be set for the communications adapter's timeout value. That is 5 seconds minimum. This is recommended so as to avoid nuiscance timeouts which can often occur when using synchronous communication methods.

In cases where there is a larger program with a somewhat slower scan time, or a lot of messaging is used, or both, then a user may have to increase the minimum 5 seconds considerably higher to avoid nuiscance timeouts.

In all cases, other factors are determining what timeout value needs to be used. This may be fine for many applications. However, for some applications, this order of timeout may be unacceptable. Unacceptable from either a control point of view, or a safety point of view, or both.

For instance, if asserting a Stop to a drive and a 5 second timeout, or greater, has been set in the adapter, and the MSG instruction errors; then this delay in waiting for the drive to fault and react may take too long for some applications and cause damage and/or create a hazard.

If a risk assessment required a timely and controlled Stop, using a deterministically failsafe method, then Explicit messaging would not be permitted. Implicit control of the drive would be required. This would involve using a Logix 5000 processor and having the drive within the I/O configuration and under the control of a Scanner. The connection to the drive would be configured to fault on loss of communications. The watchdog timeout value for this connection would be in the order of 100 milliseconds. Neither the program's logic nor the program's scan time is affecting this watchdog. It is fixed, determinate and failsafe.

It really is down to the level of assessed risk involved in an application should control over the drive be lost.

Regards,
George