Ran out of nodes on 1769-L16 Controller

Sydneyguy

Member
Join Date
Jun 2019
Location
Sydney
Posts
39
Hi All,
Got a project which has specifically called for a L16 compact logix, to control 11 motors, all using the E300 module. All was well and good until I realized I well and truly ran out of ethernet IP nodes.
Now I just want to clarify my options.
This project is being sent to some remote part of australia, so the ability to adjust overload settings over ethernet is ideal. (This strikes out the E200 option).
Am I able to configure one ethernet IP module, configure the device and then remove it from the project? does it need to be apart of the project to operate properly?

Could I set up one module in the IO tree and then cycle its IP address and parameters cyclic to effectively poll all nodes?

How would I go about this if I wanted to do produced and consumed via the MSG command? (Would this even work?)

Look forward for any pointers here

Cheers
 
From memory you could probably rig some hard wiring to run the E300... but I'd request a different PLC that can have all the nodes. Did the E300 ever get its network issue fixed, I think 3ish years ago we'd have them drop and come back up almost immediately. This usually threw a communication fault and would shut down the systems (by design).

Also, this type of designing goes against the whole 80% full rule in most new installs you need 20% expansion possibilities. (What are they going to do if they want more IO? Message a different PLC on the network? I've seen that "resourcefulness" done so many times, and is sometimes a pain in the *** to fix later on. Then again, potentially not your problem.)
 
The only option you have is to upgrade the processor
I ran into that same problem some time back
it will drop communications to a node at random you will not know witch until it happens
and reboot

Also a heads up your programming computer will take up 2 nodes
 
Cake & "Eth" it?...

Sydneyguy said:
...Got a project which has specifically called for a L16 compact logix, to control 11 motors, all using the E300 module...

Specifically why? It does not fit the bill, in my opinion?

Sydneyguy said:
...I thought I may be able to use the E300 as a standalone once configured because you can configure its operation if comms fails etc..

That depends on how you wish to "use" the E300 relays?...

The E300 Electronic Overload Relay supports up to 54 Operating Modes which can be broken down into different categories. To decide which category to use you have to know what it is you wish to use them for.

For instance, do you want an active overload mode where it trips a motor starter or do you want a passive overload mode just to monitor a motor for current or power consumption, etc.?

That's just 2 brief examples.

Other questions that will help determine which mode you require...

Do you require network control of any trip/control/normal output relays?

Will you be using the E300 Operator Station?

Or do you wish to use the E300 Local I/O?

Are they intended to just provide overload control or full starter control (reversing/non-reversing, 2-speed starter, Star/Delta starter, etc.)?

And on, and on...

See E300 User Manual - Chapter 4 Operating Modes

To give you an example of a basic Overload Mode which would not require Network control, you could use Operating Mode "Overload (Local I/O)". Here you can use the E300 digital I/O to control the motor starter for trip/reset. There is no requirement for the E300 to be added to the I/O Configuration and so it would not use up a precious Node out of the 4 Node limit for the L16ER. This would give you a "standalone" option, or as Rockwell refers to it - a "non-networked" option. However, also using the above Local I/O Mode, you could indeed have them on the network and control/monitor other features of these electronic overload relays. Options abound here.

To parameterize non-networked E300 overload relays, you can use the Add-On Profile (AOP) in Studio 5000, even if not intending to leave them in the I/O tree. On a Node limited controller you can drop them in one at a time to configure (as you've suggested). Or, you can configure them via their embedded webpage. You can also use an optional E300 Diagnostics Station instead of software.

Sydneyguy said:
...the ability to adjust overload settings over ethernet is ideal. (This strikes out the E200 option)...

Even though we know that you can use the E300 in a non-networked configuration, if you feel that Ethernet connectivity is a must for this application, even if just for remote access/configuration/monitoring of the E300 overload relays, then you will have to consider upgrading the specified controller model to at least an L27ERM (16 Nodes). However, I would recommend at minimum an L30ER (16 Nodes), or my GGG (George's General Goto) L33ER (32 Nodes).

While the E300 does support CIP messaging, I just would not go there, to be honest. I would highly recommend using a suitable controller and the intended integration method for these devices (EtherNet/IP/AOP/IO Tree).
But if you must, or wish to consider it, see Appendix B - Common Industrial Protocol (CIP) Objects in the above same manual.

Fro me, specifying 11 x EtherNet/IP based E300 Electronic Overload Relays along with a 4 Node max. L16ER controller, does not compute here.

Leaving the CIP option aside...

You either want them on the network proper - must upgrade controller

Or...

You want them non-networked - use 4 node controller but no Ethernet access

You cannot have your cake & "Eth" it? If you do add a pinch of "CIP" though, then indigestion is highly likely.

Regards,
George
 
Last edited:
GaryS said:
The only option you have is to upgrade the processor...

It's not the only option, but is the one I would recommend.

GaryS said:
...I ran into that same problem some time back
it will drop communications to a node at random you will not know witch until it happens
and reboot

Also a heads up your programming computer will take up 2 nodes

Once again (on this Forum), I will state that the above is not true. We have discussed this before and while neither side has definitively proved it to be, or not to be, the case, there have been strong arguments and real world cases provided which have found it not to be true.

Workstation, or programming computers use a small amount of controller Connections, out of which an L16ER has 256, for example. That is not Nodes, that is Connections. The software limits a project, with this controller specified, to 4 Ethernet Nodes in the I/O Configuration. Whichever 4 Node devices are added, they will use a certain amount of these 256 controller Connections. But they will not use anywhere near all of them. Therefore, this limit of 4 Nodes restricts the amount of controller Connections used for Implicit I/O and so prevents Implicit I/O Connection saturation for the controller. Something the older CompactLogix controllers suffered greatly from. The remainder of the 256 Connections left after the 4 Node devices have been added should, in most to all cases, provide more than sufficient Connections for non I/O communications, such as HMI/SCADA, workstation computers, barcode scanners, weighers, unconnected messages, and so on.

One programming computer connecting to, or being left connected to these newer Node limited and expanded Connection controllers, will not cause drops in communications. If that is happening then there is something else wrong.

For perspective, I've stated this before and will so again here...

The L16ER, being designed with just a 4 Ethernet Node limit for smaller applications, does not loose 2 of those Nodes just by connecting a programming workstation. At the design level that would make little to no sense, if you think about it logically? On a running system, half its I/O Ethernet capacity would be consumed (or stolen?) just by connecting to it?

With respect, that would be nonsense.

I will wait, patiently, for someone to post up an example in the future where one of these controllers has had its Connection limit maxed out. Not that it's impossible, but it is just so much less likely now.

Regards,
George
 
Last edited:
^ Not to mention messages are typically (and by default) set up to be unconnected, so the connection it consumes is opened and then closed when the message is done.
 
Just for the record the information I posted came from a conversation I had with rockwell on just that problem if memory serves it was an L16 and it was limited to 6 nodes we added another drive and started seeing the problems
we were dropping network devices at random I called
the infrmation was as I stated and they indicated they the programmer pc uses 2 nodes
i thnk its RSLinx and RSLinx Enterprise both are running on the pc when you are connected
 
JeremyM said:
..Not to mention messages are typically (and by default) set up to be unconnected, so the connection it consumes is opened and then closed when the message is done.

Geospark said:
...provide more than sufficient Connections for non I/O communications, such as HMI/SCADA, workstation computers, barcode scanners, weighers, unconnected messages, and so on.

Yes, that is why I specifically stated unconnected messages, as they will use and drop Connections on the fly. If a message is connected, and using an RPI, then it will constantly consume a Connection. But still, several connected messages could in theory be executing on these controllers without ever maxing out the total Connections available.

G.
 
Nodes are not consumed "on the fly"...

GaryS said:
Just for the record the information I posted came from a conversation I had with rockwell on just that problem...

Yes, before I posted I had specifically recalled that you had originally learned this information from a Rockwell representative. I cannot speak for that individual, nor do I want to appear to doubt their knowledge on the subject. However, I do think it is possible that they did not fully understand the newly introduced feature of counting Ethernet Nodes for a controller as opposed to the older method of counting Connections. I have also had several encounters with Rockwell Support Engineers where, when I felt I knew better, I have had to correct them on small but important interpretations of product functionality. One elementary example in recent times was an issue with an SLC Typed Read message which was timing out to another controller. They started by asking how was the Write message configured in the other controller, to which I of course replied there is none. They then said that was my problem. I then said could I please speak to an experienced SLC Support Engineer?...but of course I also went on to explain their misunderstanding of how it should work.

I have also previously, and today, considered the possibility that what they had said, and what you believed them to have said, may not be exactly the same thing?

GaryS said:
...if memory serves it was an L16 and it was limited to 6 nodes we added another drive and started seeing the problems...we were dropping network devices at random I called...

If you were trying to add 6 Nodes to an L16ER then you would certainly be seeing problems. I think I mentioned the Node limit of "4" for the L16ER at least half a dozen times in my previous posts here? The software would not allow you to compile a 6 Node L16ER project and download. Your troublesome project could only have been at maximum a 4 Node L16ER. If you physically provisioned more Ethernet I/O devices onto the network, like Ethernet drives, without them being allowed in the project and hence the controller not knowing about them, then there are scenarios which could have caused interference with the existing valid configuration. But we won't go into that cold case here.

GaryS said:
...the infrmation was as I stated and they indicated they the programmer pc uses 2 nodes...

Again, I believe strongly that this is incorrect. Connections, perhaps? But not Nodes.

GaryS said:
...i thnk its RSLinx and RSLinx Enterprise both are running on the pc when you are connected...

You also originally stated this and it is also incorrect. When you connect to a Logix 5000 controller you are using an RSLinx Classic communications driver. RSLinx Enterprise (now FactoryTalk Linx) is primarily used for HMI communications, be it from a computer "Station" based application to a controller, or from a physical HMI terminal to a controller. It may also be used for communicating with any FactoryTalk Live Data capable device or application. RSLinx Enterprise will not establish a connection with a controller simultaneously with an attempt to go online with RSLinx Classic. They are totally independent.

If you happened, for instance, to have a FactoryTalk View ME Station application running on the workstation computer, then RSLinx Enterprise could possibly be communicating with the controller. However, even if both were running and simultaneously connected to the same 4 Node controller, they would only be using controller Connections, and not any of the Node count.

To clarify this further...

The controller knows nothing about "Nodes" or how many are allowed, used or remaining. All it knows is "Connections" and how many are allowed, used or remaining. If a 4 Node limit is used up, all the controller sees is how many Connections have been consumed. If other non I/O devices are also using Connections then all it sees is the total Connections in use and what is remaining. It will keep opening Connections to devices, of all types, until it has no more.

The Node limit feature and restriction is entirely in the software on your computer. This just prevents us from compiling and downloading a project with too many I/O devices added to the I/O tree, which could consume too many of the available Connections, and leave very few or not enough Connections for non I/O devices which may be added now or in the future.

Another point, which hopefully sets aside the notion of communications software on our computers decreasing this Node count...

As the Node limit is only in the software, the Node limit verification is done at compile time and before downloading and running the project on the controller. It is not checked at any other time. Therefore, an "after the fact" attempt to connect to a running controller from RSLinx Anything cannot and will not have any effect on a virtual Node count that is only performed when a project is being compiled for download i.e. Nodes are not consumed "on the fly".

When the project is being compiled, any connected device that is not added to the I/O Configuration (workstation computer) will not go against the Node count. If you are compiling an otherwise valid L16ER project, and there are 4 Nodes added, then you may proceed to download. Nothing on a running controller can change this at a later point.

Nodes are "virtual" within the programming software and used to limit how many Connections will be used for I/O devices when the controller is running.

Connections are "real" within the controller and they will be consumed by both the devices (Nodes) added to the I/O Configuration and the devices not added to the I/O Configuration, up to the total Connections for the controller.

GaryS said:
...programming computer will take up 2 nodes...the programmer pc uses 2 nodes...

So again, the Node limit is only verified when a project is being compiled, and never when we make a connection from a workstation computer. They cannot use or take up 2 Nodes.

Interestingly, I found your very first statement on the above and you had actually said this...

GaryS said:
...Don't forget the programming PC uses 2 connections, RSLinx Classic and RSLinx Enterprise...

You said "connections"?

But then went on to state this, 2 posts later...

GaryS said:
...Check the manual the L16 only supports 4 nodes and the PC will use 2 of those.
what will happen is the L16 will start dropping connections different devices at different time it will drive you nuts

you should make another processor for this project....

Whatever about Rockwell, you appeared to be confusing or interchangeably using both terms as though meaning the same thing?

In all your statements I've read, if we substitute "nodes" with "connections" then they tend to make a little more sense?

Original thread for reference...

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

Regards,
George
 
Last edited:
You are in the PLC business because your time is valuable, and a reliable system is valuable. Doing junk like "oh we specified the wrong hardware, let's spend a few days blue-tacking a bit of cardboard to the side" is not the industry you are in. Flag up that someone made a mistake, lesson learnt, someone in the project pipeline takes a hit, start a new project tomorrow.

Take home: blue-tacking cardboard to the side of an underspec'd PLC is not how you grow as an engineer.
 
Just to add to George's comments...

I had a project with 4 E/IP nodes in the tree on an L16.

Had no issues with S5K connected via a laptop and a separate NUC concurrently connected with Ignition SCADA.

The issue as this topic discusses only came when I tried to add a 5th E/IP object to the IO tree, exceeding the limit of 4 on an L16...
 

Similar Topics

This forum post I found seemed to reference the same issue, and if posts were still allowed on that thread, I might make an account there to post...
Replies
7
Views
5,651
Hi Can anyone please explain how Gefran TC 1200 works for Cool /Heat. We have plastics extruder which needs 120c. The fan should come on when...
Replies
0
Views
957
I have a few open slots left for my ControlLogix Boot Camp training class October 29th through November 2nd in Charleston, S.C. one of which was...
Replies
0
Views
1,695
Good Afternoon , Took notice the price really jumped on Panelview Plus 6's . A .MER runtime that was running on a Panelview Plus 6 will run...
Replies
5
Views
4,404
Hello every one I am facing with problem with Omron CJ Series Analog I/O module MAD42. The 'RUN' LED is Lit and the 'ERC' LED is also Lit. I am...
Replies
2
Views
1,334
Back
Top Bottom