Controllogix message length?

In a very large controllogix setup, we are sending and receiving ethernet messages from various other PLCs around the plant. I would say that there are about 25 to 30 PLCs involved total. All of the message instructions are set up in the Controllogix and most of the messages are sending or receiving 5-10 elements of data, so they are not very large. However, recently I have come across the need to "read" about 300 elements from a particular PLC. It would be a situation where I would only need to do it about once a day. Is it a problem trying to do this since the message length is so long or not? The PLC that I would need to read from is a SLC 5/03 that is set up on a NET ENI. Again, the message instructions are set up in the Controllogix. I assume that since all of the data will not fit into one data file in the SLC (too long) that I will have to use 2 message blocks in the CLX...one reading from the first data file in the SLC (say N7) and the second from another (say N10)?

Any thoughts on how to do this better?

Not sure about you question but i do see that you are doing reads and writes. I would do reads only. Much less tasking and easier to troubleshoot.

far less problems sticking to reads only.

I believe you are correct in wanting/needing to split your read from the 5/03 into two reads. IIRC you can only read the 256 words from the file at a time.

You will have no problems with your ControlLogix reading whole files from the SLC.

Ethernet "packet" lengths are around 500 bytes each, so large blocks of data are transferred in multiple packets, each .DN bit indicating successful completion of the data. If you are reading 2 files due to the data size, then make sure both messages give the .DN bit so that you have a complete data-set

Where you may come unstuck is in the number of connections used. For messages that occur infrequently (say greater than a couple of seconds), then uncheck the "Cache Connection" box in the message configuration. The messages will execute slightly slower, as the two machines have to create a connection before the data-transfer is performed, then release it again afterwards, but for infrequent messages this won't be an issue.

The Plc Kid said:

Not sure about you question but i do see that you are doing reads and writes. I would do reads only. Much less tasking and easier to troubleshoot.

far less problems sticking to reads only.

Click to expand...

In my setup, both read and writes are both REQUIRED...no way around it. Besides, if proper documenting is done, troubleshooting is a breeze anyways.


Daba, just out of curiosity, unchecking the cache connections box...does that help with network load since the connection is not held all the time?

daba said:

You will have no problems with your ControlLogix reading whole files from the SLC.

Ethernet "packet" lengths are around 500 bytes each, so large blocks of data are transferred in multiple packets, each .DN bit indicating successful completion of the data. If you are reading 2 files due to the data size, then make sure both messages give the .DN bit so that you have a complete data-set

Where you may come unstuck is in the number of connections used. For messages that occur infrequently (say greater than a couple of seconds), then uncheck the "Cache Connection" box in the message configuration. The messages will execute slightly slower, as the two machines have to create a connection before the data-transfer is performed, then release it again afterwards, but for infrequent messages this won't be an issue.

Click to expand...

I would be very cautious about this. I have not used the NET-ENI in this way but I think that the bottleneck will be the RS232 connection to the SLC. I do not think that this will allow you to read 300 values in one go unless they are Booleans packed into words.

Andy is right. The NET-ENI will bottle neck your comms if you are reading lots of data.

I set up a DDE link to a 5/04 through a NET-ENI and tried to read lots of data with a hot link. Many of the elements I needed to read were barcodes stored as ST (string) elements. Once I had more than about 40 string elements configured, it stopped working. I ended up using VBA to control the reads and did them in blocks of 32, with a couple seconds delay between reads.

So, be prepared to use more than two messages, and be aware that your online comms might get really slow during the messages. Since you're doing this once daily, you should still be able to get it done, provided you have enough connections available. Note that all the messages between the two devices will share the same connection.

A NET ENI is limited to 3 connections this connection info can be read in a web browser if you type the NET ENI ethernet address into address bar.

I think it might depend on the series and/or firmware revision. I have a series C and a series D, and I know my series D supports a max of 6 connections, max of 4 in either direction. You get 2 dedicated incoming, 2 dedicated outgoing and 2 that can be either incoming or outgoing.

My series C doesn't have that info on it's webpage...no diagnostics tab.

You're already on the right track using two SLC Typed Read messages to read two Data Files from the SLC-5/03.

The ControlLogix hides some of the complexity of PCCC and DF1 messaging from you. A single Typed Read transaction can only handle up to 244 bytes of data, so if you request more than 122 Integers from an SLC, the ControlLogix breaks it up into two or more separate transactions and delivers a /DN bit at the application level when both are complete.

Don't sweat the TCP Connections or CIP Connections as long as you don't have more than three other controllers trying to send messages to this SLC-5/03 at the same time.

In SLC-500 controllers each Data File can be 256 elements in length, and you can enable a feature called "Enable Indexing Across Files" in the Compiler settings for the controller. This allows you to use Indexed addressing across data file boundaries without faulting the controller. What I'm not sure about is if the feature also allows you to read past the end of the data file in the same way.

It can't hurt to try !