Controllogix/Controlnet NUT/RPI Question

[tmeyer 0]

A customer has a network consisting of a 1756-CNB/D residing in controllogix 17 slot rack with 1756-L62 PLC. The 1756-CNB is connected to a 1734-ACNR with 5 - 1734-232ASC/C ASCII modules (Rack A), and another 1734-ACNR with 1 - 1734-232ASC/C ASCII module (Rack B). The NUT for this network is 5ms and the RPI for all the ASCII modules was 50ms. I was having trouble getting a barcode fast enough from the Rack B (higher conveyor speed than at Rack A's barcode scanners). I lowered the RPI for the Rack B ASCII module from 50ms to 10 ms, rescheduled the network (saved file) and the problem was solved. Then I went back to try to lower the RPI's for Rack A's modules to 10ms just for consistency sake, and could not save the controlnet file. I had to put Rack A's modules back to 50ms and it saved just fine. In reviewing how the RPI and NUT work in scheduling data transmissions, I cannot see a problem with all have a 10ms RPI (total 6 modules). Each ASCII module was configured for 54 Input bytes, and 20 output bytes. From what I can see, the network should have been able to transmitt 2479 bytes of data per a 5 ms NUT. I have to add to this network another 1734 rack (with 3 ASCII modules) plus a 7 slot rack (with a 1756-IA16 input module and a 1756-DNB devicenet module). If anyone has any insights into why lowering the RPI's to 10ms didn't work, I would greatly appreciate it. Thanks, Tony

[Keith Menges 0]

I don't have the information in front of me right now to really look this up, but this might send you in the right direction. As you have seen you have the data bit speed to support what you are trying to do. However, CNet with not allow an unlimited number of connections per NUT. If you have six devices with a 10msec RPI running on a network with a 5msec NUT, CNet need to schedule three connections in a single NUT to get that to go through. That may be where you are getting stuck. Try to set your per module RPI to 6 times your NUT. In your case this would be 30msec. That should be OK. Keith

[tmeyer 0]

Thanks for the reply Keith. It took some hunting, but I found some info on the number of connections per nut for a 1756-CNB. According to the chart, a 5ms nut should allow 11 connections per nut. I also saw that the maximum amount of data that any node can transmit in a scheduled communication is about 477 bytes (521 minus 44 overhead). Each ASCII module should have been transmitting no more than a 100 bytes so I'm still stumped. Thanks, Tony

[Money4Nothing 0]

I didn't do the math to see if your numbers were correct, but off the top of my head, you might want to check your overhead time slice to make sure its not too high. I'm not sure how much unscheduled communication you have, but if its over 40% you may be in a bit of trouble. Go to Controller Properties\Advanced. Also keep in mind that your RPIs should all be binary multiple of your NUT. For a 5ms NUT, your RPIs should only be 10, 20, 40, 80, 160ms...etc. Any other amount is a waste of time. When I have time I'll do a little more digging if no one else has come up with anything. Good Luck! $ Edited 2 May 2006 by Money4Nothing

[tmeyer 0]

Thanks for the reply $ The overhead time slice is set at 40%. There is a Cimplicity application accessing the PLC data for a HMI and product destination responses. We are not sending messages to the Cimplicity; the Cimplicity is looking at and writing tags in the PLC for HMI, barcode info, and real time destination responses over ethernet. I assume this is all considered unscheduled communications? Do these communications affect the Controlnet network scheduling? Is there a way to schedule the controlnet network offline with RSNetworx to verify that it will schedule online? Tony

[Money4Nothing 0]

I don't know what Cimplicity is, but if it's communication path to the PLC is bridged from Ethernet through ControlNet, then its definitely going to affect the scheduling. How is it looking at the PLC tags? Apparently your Controller is acting as a server to Cimplicity, and I'm not sure how that kind of communication is managed by ControlNet or by the controller. The communication with your 1723-232ASC devices is scheduled communication. If you lower your timeslice to 30%, you'll probably see an increase in speed there. Good Luck $

[BobLfoot 302]

You find that Cimplicity is a GE product If I remeber correctly and is similiar in function to Wonderware or RSView.

[Money4Nothing 0]

I'm retarded....I even went to a demo class on Cimplicity once, but I totally forgot about it! Thanks Bob $

[Smoke 0]

This is Cimplicity HMI, not to be confused with Cimplicity ME now called Proficy ME

[BobLfoot 302]

No problem Money4nothing. Always glad to help - we all have senior moments after all.

[Money4Nothing 0]

I'm only 29, how many senior moments am I allowed before I'm labeled "senile"? $

[tmeyer 0]

Thanks for the input. I added the new chassis and the 1734-ACNR to the network this weekend and had no problem with the scheduling of the controlnet network. But had the *?!%*%# time getting the 1734-ACNR to see that it had 3 ASCII modules in the rack. After about an hour of frustration trying to get Rsnetworx to set the rack size (you know...the software to configure the network!), I found that you have to tell the 1734-ACNR what its rack size is, through the RSLogix5000 software. There is a "Chasis Size" tab in the modules properties with a button to "Set Chassis Size in Module". After I did that everything was good. Anyone know the logic for this? Doesn't seem right that I couldn't set the rack size with RSNetworx. Thanks again for all the help, I definately know more about controlnet and its scheduling now. Tony

[Money4Nothing 0]

Yea I had the exact same experience the first time I used an ASCII module with a 1734-ACNR. It took me about an hour as well to figure it out I don't know the exact reason behind it, but I'm sure its probably a good one. $