JeremyM,
Okay. I understand where you are coming from, and you are right to consider the Connections count, but I still feel you may be missing my basic point.
I'm only pointing this out to you because I notice how you are thinking about this in a certain way, when it is not as cut-and-dry as you appear to think it is...
JeremyM said:
...I did mis-write my question - probably better to use "CompactLogix"...
That would be the same difference my friend...
Whether you used "1769", "CompactLogix", or "1769 CompactLogix", etc., the possibility that it may not be a CompactLogix, at all, still remains.
It would be more correct to have simply asked...
"Which
controller is deployed?"
The core misconception I feel you may have here is that you are thinking that because the EtherNet/IP distributed I/O is intended to be of the 1769 CompactLogix family then the owner controller must automatically be of the same 1769 CompactLogix family. It does not automatically mean that.
So my point is that you, if knowing better, should not automatically assume it to be a CompactLogix controller, at all. Even though, and as I said I would also have guessed, it is highly likely that it may be.
Rock bottom point...
EtherNet/IP is an open standard. Realize that there are other controllers which may communicate with a 1769-AENTR over EtherNet/IP, other than the same 1769 family controllers.
Also, while I'm being my usual picky self...
"How many and what kind of
remote I/O are planned?
Notice how I used the term "distributed I/O" above?...
For Allen Bradley/Rockwell, where one is not specifically dealing with "remote I/O", I would always refer to it as "distributed I/O", simply because remote I/O is a very specific type of legacy I/O for this brand. Because we know this is intended to be a non-local EtherNet/IP I/O rack, it would more correctly be referred to as distributed I/O, rather than remote I/O.
So it would have been more correct to have asked...
"How many and what kind of
distributed I/O are planned?"
Again, I'm being quite picky here, I know. But I always try to correct what I perceive to be a misconception or a misuse of certain specific terms.
Recently I've mentioned as such for the "slight" misuse of the the terms "multistate indicator", the abbreviated "RSLinx", and would you know, the incorrect term of "1769-L4x" instead of "1768-L4x", which of course I was guilty of above.
That is just to point out that it is in my nature to try to correct these subtle mistakes, when and where I see them, even when they are my own, in the interest of education, more so than trying to be a "know-it-all", of which I am most certainly not.
In other words, please do not take the above the wrong way. It is intended to be constructive criticism.
On the point of Connections...
The 1769-AENTR adapter has a limit of 96 TCP/IP Connections, or physical devices that can be connected to it's Ethernet port. This should be more than sufficient for most applications.
Note: You can configure the adapter to communicate with one controller using an exclusive Owner Connection, or Listen Only Connection, depending on the I/O modules used. You cannot use both together. So only one controller can communicate with the adapter using Class 1 Connections at any given time. If another controller requires the same I/O data then you would have to use the Produce/Consume model or implement Explicit Class 3 Messaging. This is only important if you are adding an 1769 EtherNet/IP distributed I/O rack to a busy network that requires the simultaneous distribution of the multicast I/O data to more than one controller.
The limit on the maximum number of I/O modules under the adapter is 30 across 3 racks. This is because the adapter has a limit of 30 Class 1 CIP Connections. This facilitates the use of up to 30 Direct Connections from the controller to the individual I/O modules.
You cannot use a Rack Optimized Connection from the controller to this adapter for all 30 I/O modules. You must use separate Direct Connections.
The adapter also supports up to 32 Class 3 Explicit Messages to the I/O modules.
It also has an I/O packet rate of 10,000 pps (packets per second)
NetNathan,
This adapter "should" be more than capable, Connection-wise, at your end. But as we don't know the intended controller to be used on the customer's side, the controller's TCP/IP and CIP Connection limits or currently available Connections "could" have a bearing on the success or failure of this project, as JeremyM so rightly points out.
Whether you feel that this is important to you or you see it as being their problem, is up to you, but if you want the project to go smoothly, I would advise you to take it into consideration.
Regards,
George
