Only 4 Ethernet/IP Nodes on a CompactLogix 1769-L16ER-BB1b ?

but the Both RSLinx Classic and RSLinx Enterprise on the PC will be a node each. both are required to get online and program the Processor.

Click to expand...

Another incorrect statement: RSLinx Enterprise is not required to program the processor. Rslogix 5000 uses RSlinx Classic only.

The only reason that computer or HMI will be counted as a node is if you add it into the I/O tree that should not be done anyway.

The whole idea of the newly structured Ethernet Node counting system and increase in Connections for the newer Logix controllers was to make it simpler to configure and to eliminate the possibility of running out of Connections too quickly as a project grows. This happens all too often with the older CompactLogix controllers.

For the older Ethernet CompactLogix controllers (L32E and L35E) they are very restricted. They only support a maximum of 32 CIP Connections. Imagine how quickly some I/O Nodes, which can use double figure Connection counts, will eat up Connections on these controllers.

Also, this limit of 32 is further restricted by the RPI set per Connection. The higher the RPI the lower the supported maximum CIP Connections becomes. For high speed applications, this can absolutely murder the limit. If you have 2 Connections set to 2ms RPI each, then those 2 CIP Connection are all that are allowed for the controller. This would leave nothing for RSLinx Classic communications, a HMI, or the like.

However, if all Connections are set to 35ms RPI or higher, then the full 32 CIP Connections will be available. But with these controllers you always have to be careful to leave enough spare Connections for programming workstations and HMI. Each RSLinx Classic driver instance uses 1 Connection (not Node). Each PanelView HMI can use up to 5 Connections (not Nodes).

The new CompactLogix controllers now have Ethernet Node limits, which does somewhat restrict the number of devices you can add to the I/O tree, but this is relative to the controllers intended application market. They now restrict the number of Nodes allowed, in the software, so as not to saturate the specific controller with I/O Connections. This leaves plenty of overhead with the remaining Connections for non I/O tree devices. i.e. There should be plenty of Connections to go around for "non I/O" communications, such as RSLinx Classic.

Ethernet Nodes and devices using Connections are one and the same. They all use Connections. The difference now being that they have a much greater overall Connection count available to them (256), compared to their previous counterparts (32). This allows a much larger scope for new and temporary devices to be simultaneously provisioned onto the controller's network.

The feature, of restricting Ethernet Nodes per controller, is basically one intended to limit, or reserve, a portion of the overall Connections for I/O communications. The Node limit, while fixed, does not dictate the final CIP Connections used for all of the I/O Node devices added to the I/O tree. The type of devices added will determine this.

Example:

If we add 3 PowerFlex 40 drives as Nodes to an L16ER I/O tree, using 22-COMM-E adapters, they can use up to 16 CIP Connections each. So that's a possible 48 CIP Connections in total.

If we add a 1734-AENTR as a 4th Node, it can use up to 20 CIP Connections.

So now, for the 4 allowed Nodes, we have a potential 68 CIP Connections used off the total of 256 for the controller, leaving 188 Connections free for non I/O devices. This should be more than adequate for most applications.

It is all about counting Connections at the end of the day. Ethernet "Nodes" is just a new buzzword for the limitation in Logix Designer for the I/O Configuration in these controllers. Once there are plenty of Connections available, then using RSLinx Classic, Explicit Messaging, HMI communications, peripheral devices such as barcode readers and printers, should not be such an issue, as it was in the past.

Rockwell Automation said:

IMPORTANT - With the increased abilities of the CompactLogix 5370 controllers, where it should no longer be of concern, it is still recommended that the control system limits should still be checked and verified for each specific application.

Click to expand...

What they are basically saying here is that once you have selected the correct controller for your application, and because they are now much more capable, you should not have to worry about Connections any time soon.

If your selected controller's I/O Node count seems "tight" then you move up in specification.

Another improvement made on the new CompactLogix controllers over the old is the maximum Packet Rate for the Ethernet port. The old controllers can achieve up to 4000 PPS (Packets Per Second) whereas the new can achieve up to 6000 PPS. Also, for Unconnected Messages, the old allow 32 across the backplane and 32 out to the Ethernet network. The new allow a total of 400 for everything.

GaryS,

I'm always open to learning new things and I do not presume to know everything on a given subject, but I am seriously doubting the advice given by Rockwell here as being credible?

Perhaps the Support Engineer was misinformed or something, I don't know?

I'm still open to being further enlightened here, but so far I cannot see that...

...the Ethernet Node count...

...which is only based on the devices added to the I/O tree...

...of which a "computer", "RSLinx Classic" or "RSLinx Enterprise" are not...

...can be reduced by 2 Nodes...

...on a controller spec'd for 4 Nodes...

...that is half gone already...

...just by communicating from RSLinx Whatever...

Why would they only spec it for 4 Nodes if such a trivial thing can eat up half its available Nodes before you even start to build the I/O Configuration?

Also, this Node limitation is in the software, not the controller's firmware. When you try to Verify or Download a project with an exceeded I/O Node count it will error with...

The maximum number of nodes on the local Ethernet port has been exceeded - reduce the number of Ethernet nodes

When a valid project is downloaded to the controller and running, all the controller knows about is Connections. It is not counting Nodes. This is purely done back in the software before the Download. Regardless of whether in the I/O tree or not, the Controller keeps opening Connection requests until it has no more. If the limit is exceeded then the controller will not be able to open any more requested Connections until some are freed up.

With so many Connections now available to the new Logix controllers, and with the added restriction on the amount of devices that can be added to the I/O tree, preventing the Connection total from being I/O saturated, there should be more than enough Connections to go around, if you have selected the right controller for the job.

What ever was wrong in your case above (you didn't say how you fixed it?), I would be very surprised if it had anything do with a programming workstation using up "Nodes".

Regards,
George

Hi



"Interesting to note the new PanelView 5500 terminals and how they can be added to the I/O tree. I just mentioned the new HMI Button Control (HMIBC) instruction in another thread last week. You add the PanelView to the I/O tree in order to have a monitored connection so the instruction can reset the program tag should the connection become unreliable."

Grorge I saw this at the automation fair and did a lab on it. The new panel view looks very or should I say will be very good as I believe it's not there yet
The lab actually used the hmibc instruction and it's also used for quicker activation of the code due to the hmi been in the project tree

As for the number of connections and the l32 I found out the hard way and learned about connections, up to that point I must admit I did not even know there was a limit as low as that

Donnchadh

I've got an L16 in the field with 4 ethernet nodes, and I've never had any problems with it going online or dropping connections. And I'd know about it if it did, because it's the central data collection point serving critical data up to three production lines. Unfortunately, not everything Tech Support tells you can be taken as gospel.

ASF said:

...Unfortunately, not everything Tech Support tells you can be taken as gospel.

Click to expand...

Well, there is also the possibility that what was said, and what was thought to have been said, are not always one and the same.

For those interested...

In addition, I Just wanted to add an explanation here as to why and how a PanelView HMI may use up to 5 Connections to a Logix controller...

For a FactoryTalk View Studio ME Runtime application each Display creates 1 OPC Group. An OPC Group is just a way to organize the data for a Display so it can be accessed more easily by a controller for read/write operations through the OPC Server i.e. RSLinx Enterprise.

Only one OPC Group is active at any given time for the current Display that is on scan.

Depending on the volume of tag data on scan with the controller the current Display's OPC Group may create one or more Optimized packets, which will be approximately 500 bytes each. For each Optimized packet the OPC Server (RSLinx Enterprise) will open one CIP Connection with the controller.

However, the number of simultaneous Connections allowed for an OPC Group at any one time is limited to no more than 4 read Connections and 1 write Connection per Logix controller. The bias is toward reads as that is the primary operation on most HMI; reading data from a controller to be displayed.

If you have more than 4 Optimized packets on the current Display, RSLinx Enterprise will combine several Optimized packets on the same Connection.

So what does that really mean?...

Example:

Display with 200 tag "Connections" assigned to read data from the controller and 10 tag "Connections" assigned to write data to the controller.

When the Display is active its OPC Group will automatically start to build the first Optimized packet of tag data, to be read form the controller, until it reaches the 500 byte limit.

Note: The amount of tag data included in an Optimized packet will vary depending on the tag data type. String and Numeric data will of course use up more memory than Boolean.

Once built this Optimized packet will then open the first CIP Connection to the controller to read in the data. The second Optimized packet is then built and when ready it will open a second CIP Connection to the controller, and so on until each of the first 4 Optimized packets for read tag data have opened 4 individual CIP Connections to the controller. The limit of 4 simultaneous read Connections to the controller has now been reached.

But, as there is 200 tag "Connections" for this Display, there is still tag data left to be read in for the Display...

Any subsequent Optimized packets for read tag data, after the limit of 4 read Connections has been reached, will now start to be combined into those already established 4 CIP Connections with the controller. This will continue until all the read tag data has been Optimized into packets and read in across the 4 open Connections.

This pattern of creating the packets and reading in the data will continue on a cyclical basis, based on the Tag Update rate for the individual Display.

If a write operation is performed, such as a Button Object being press or a Numeric Entry Object being used, then a data packet will be built to write the data to the controller. This will not necessarily be an Optimized packet because only a single data point is being written. So there is no consolidation of data for more than one tag into an Optimized packet of 500 bytes. So a smaller non Optimized packet is created. This packet, once built, will open the one and only allowed write Connection to the controller.

The write CIP Connection is established as soon as the next Tag Update cycle commences for the Display.

Once any or all of the 4 read Connections have been established, or the 1 write Connection, they will not be closed again, as long as the HMI and the controller maintain good communications. If one or the other device goes off the network, or times out, then the established Connections will be torn down.

If you have a very simple application with just a small amount of tag data to be read into a Display, then the chances are that only 1 or 2 of the allowed 4 read Connections will be open at any given time. There is less tag data being transmitted and less Connections to cycle through and service. So the application will run more efficiently.

For larger applications with hundreds of tags on scan per Display, the 4 available read Connections must be used to facilitate all of the data. Besides having to service the maximum 4 Connections, there will be an increased payload per Connection, which will increase the packets per second loading on the network. This can burden the devices somewhat more and a noticeable increase in the refresh rate of tag data on the Display may be experienced. A rule of thumb is 200+tags on one Display will start to markedly increase the CPU loading for the terminal.

Newer PanelView terminals are combating this issue with greater memory and better CPUs.

So from the above, Rockwell advises that a general consideration be made that any PanelView HMI, communicating with a Logix controller, will potentially use up 5 Connections of the controllers overall Connection count.

For this reason, they advise that not more than 5 PanelView Plus HMI be communicating with a Logix controller at any one time. This limits the controller's HMI Connection loading to 25 CIP Connections.

Now some do add more, many more, as some controllers do have plenty of Connections. Whether it impacts on performance or not can depend on many factors, not just including the above.

Again, with the newer Logix controllers and the newer PanelView terminals, that advise may very well be revised upward in the not too distant future.

Regards,
George

I decided to use the 1769-L18ER-BB1B ( 8 nodes ) instead of the
1769-L16ER-BB1B ( 4 nodes ).

You "nodes" it makes sense!