PF 40 and 22-Comm-D

sportster

Member
Join Date
Mar 2005
Location
WI
Posts
113
Hey,

I have an application that was done using a PF 700 drive on a high speed conveyor (2500 fpm). This conveyor is used to "throw" product through a set of blades to cut the product into french fry like sticks. This drive was set up on DeviceNet using data links (20-Comm-D) to give feedback on amperage and torque. These values were used to determine if the conveyor was getting overloaded with product. This would happen when the blades got dirty and/or plugged up. Once the drive started pulling high amps; the conveyor was stopped so the blades could be cleaned out. Everything worked great.

Now the client has changed out the PF 700 for a PF 40. They did this because they don't want to have to stock another different drive and they already have a ton of the PF 40's around. The problem is that the PF 40 doesn't support data links (22-Comm-D). I can get the data I need (amperage and torque) using explicit messaging, but how fast can I execute the message instructions? I need the data within about 100 ms maximum. Or is there another way to get the data I need without the messaging? I have read the manual on the 22-Comm-D, but it doesn't give any other options.

I have two weeks before the equipment goes "live"; but would like to get this figured out in case I need them to switch back to the PF 700, or figure something else out. Thanks in advance.

Patrick
 
I certainly don't agree with your management's decision-making, but that's why we're Engineers, isn't it ?

Which parameter numbers are you trying to get from the drive ? There might be a way to get them in a group.

What's the controller and DeviceNet scanner type ?

You can execute DeviceNet explicit messages as fast as they can complete and report their completion back to the controller interface. The biggest delay, I suspect, is going to be in the DeviceNet to DSI conversion inside the 22-COMM-D.
 
Ken,

From the PF 40 manual, I am looking for parameters d003 and d029.

Processor is a 1756-L61 with a 1756-DNB (firmware 6.2).

Thanks,
Patrick
 
Just go back to the 7 series.

The E-Comm connection to the PF40 messaging is fast enough that 100 mS is reasonable, but a devicenet connection with ANYTHING else on it might be barking up the wrong tree.
 
Crocrop,

Yeah that's what I'm worried about too. There are four other PF 40 drives on this network, but they don't run anything as critical (just conveyors on/off). Still they are there. And there are three Alphagear linear actuators on the network as well. Those are critical because if they don't move within the alloted time... things will go bang. Maybe Ken will come back with a solution still using the PF 40.

Thanks,
Patrick
 
Well, I discussed the problem with the local support office and they seem to think that it should work fine with the PF 40. The only thing they were worried about was if/when more devices were added to the network that it may get overloaded. There is no indication at this point that there will be anything else added to this network, but around here the only constant is that things will change. I guess I will have to discuss this with the client add try to convince them to go back to the PF 700. If not, I guess the PF 40 will get the nod.

Thanks again,
Patrick
 
Because the values you want aren't in adjacent parameters, there's no sense trying to manipulate the PCCC object to get them as a group. We'll just send two messages.

The good news is that you can't actually "overload" a DeviceNet. DeviceNet networks can run at 100% utilitzation without losing any data. You might not get the performance you want, but you never lose data.

And explicit messages have lower priority than I/O messages, so the most you can delay an individual I/O message is by an 8-byte frame.

I found a PowerFlex 40 demo in my office. I'll see if I have enough gear to hook it up and time the explicit messages.
 
I set up a little network polling just two devices, an E3 overload and the PowerFlex 40.

I tested triggering one message after the other as well as triggering both at the same time. I used a rententive timer in RSLogix 5000 to measure the interval between each message being Enabled and being Done (the .EN and .DN bits) and measured between 27 and 44 milliseconds each. These values varied.

I also tried triggering both messages at the same time, and the completion time for one jumped to about 55-66 milliseconds, and to the other stayed at 27-33 milliseconds. It could be either one that got the long interval, which suggests that the drive only processes one message at a time and the other one just had to wait (which makes sense).

So, a sub-100-millisecond messaging technique for these drives is theoretically possible. Only testing on your particular system can tell for certain how fast you are able to get data via messaging.
 
I put the DNet traffic analyzer to use to learn more.

With just those two devices being polled, running the network at 125 kb/s with a default 10 ms interscan delay, the average network utilization is just 13.4 %, peak 14.6 %.

When messaging is enabled and triggers both messages every 100 milliseconds, the average network utilization is 15.2 % and the peak is 18.52 %.

The protocol analyzer confirms that each explicit message takes about 20 to 22 milliseconds before the 22-COMM-D responds. The next message is sent 3 to 5 milliseconds later, with the same response delay from the drive.
 
Here's the DeviceNet Protocol Analyzer screenshot, showing the explicit message traffic in purple:

DNet_PF40.GIF
 
Ken,

Very cool. That is excellent. I think I will start out at 150 - 200 ms and work down from there and see how far it will go. If I can get to 100 or below that will be cool. If not, maybe the PF 700 will go back in. When I get back from the job around Jan 25 I could post the results if you would like.

Thanks again,
Patrick
 
The last post from me on this... I gotta get some other stuff done, but this is fun.

I increased the network data rate to 500 kb/s and now the polling traffic takes only 3.36% of network bandwidth average, 3.66 % maximum. Adding messaging increases this to 4.12 % average and 4.63% maximum.

But it still takes about 20 to 22 milliseconds for the drive to respond to each explicit message request. This confirms my expectation that the longest delay in the system is in the 22-COMM-D to DSI protocol conversion and drive response.
 
Okay, this is really the last.

I replaced the PowerFlex 40 and 22-COMM-D with a PowerFlex 70 and 20-COMM-D and redirected the MSG instructions to the new node number of the PF70.

The PowerFlex 70 took between 15 and 30 milliseconds to respond to the same Parameter reads.

So the real advantage to the PF70/700 in this application is the ability to use DataLinks to put this data into the I/O exchange, not any important speed advantage of the 20-COMM-D for explicit messaging.
 
Ken,

Just to try to get one more post from you...

What type of device/software are you using to analyze DeviceNet when doing this testing? I have a NetAlert DeviceNet meter that checks a lot of stuff (voltages, grounding, frame rates, and bandwidth). I used this meter to get a basic network baseline when the equipment was originally installed last June. Just wondering what other people use, I guess.

Thanks again,
Patrick

Edit: I type wwwaaaaaayyyyy to slow to keep up with you. Thanks for all your help. This is great stuff to learn and know.
 
That screenshot is from the DeviceNet Traffic Analyzer, a little-known A-B utility. It's bundled with the ControlNet traffic analyzer as part number 9220-WINTA for about $1000.

These programs only work with the 1784-PCD and -PCID(S) and 1784-PCC interface cards.

There are free "lite" versions of the analyzers that disable many of the analysis features (like triggers and filters) but can be used for simple traffic captures.

I use the DNet Traffic Analyzer as well as the NetMeter to do baseline studies of networks when they are installed. The NetMeter gets me the physical and electrical information, and I can get performance and throughput information from the DNet Traffic Analyzer.

It's neat to be able to prove the data exchange speed on the network and compare that to customer expectations. I also frequently use it to illustrate the decrease in network utilization when Change-of-State connections are used instead of Polled connections.

It's also very valuable when troubleshooting third-party integration and messaging issues, and for examining messaging performance for controller-based messages.
 

Similar Topics

After updating a panel, I inherited another PLC for my "learning lab". It's a Modicon TSX Micro. I've not worked with a Modicon PLC yet, so I...
Replies
1
Views
83
Guys need a bit of help getting the instance correct for a 22comme with a PF40P. Trying to get 2 things first is the drive current amp draw...
Replies
1
Views
67
I have 3 new PowerFlex 7000 VFD's. Rockwell was out to do some checking before startup. These are part of a larger electrical project. I gave the...
Replies
7
Views
272
Hello everyone, I'm seeking advice from those familiar with working on Siemens Relay 7SR11 for communication via 61850. Currently, we have...
Replies
0
Views
1,092
Hi all, This is my first post; I am new to PLC Controls stuff and English is not my native language, so I apologize in advance if something is...
Replies
4
Views
490
Back
Top Bottom