1769-L3xERMS controllers and nodes

g.mccormick

Lifetime Supporting Member
Join Date
Jul 2012
Location
IN
Posts
960
All,
I am attempting to spec a CompactLogix system with safety IO. I see that the 1768-L45S is destined to End of Life this July so I need to look at the 1769-L3xERMS series. The IO in use will be the 1734 Point GuardIO safety IO.
Questions:
1. Does each IO module consume 1 node? I believe that each module consumes some connections as the safety IO is not able to be configured as rack centric.
2. For the IO connections specified in the attached, what does that number mean? Is that number of remote io (1734 modules), number of what?

Untitled.png
 
for my understanding, for example if you use 1769-L30ERMS, you can have 16 Ethernet devices added to your controller Ethernet tree, the Ethernet devices can be drives and IO modules with safety or without safety (for example 1734 Point GuardIO) and many more. Each Ethernet device counts one Ethernet node.
For each IO module chassis (If you use 1734 Point GuardIO) you can add 8 local IO modules.
did that answer your question?
 
Last edited:
for my understanding, for example if you use 1769-L30ERMS, you can have 16 Ethernet devices added to your controller Ethernet tree, the Ethernet devices can be drives and IO modules with safety or without safety (for example 1734 Point GuardIO) and many more. Each Ethernet device counts one Ethernet node.
For each IO module chassis (If you use 1734 Point GuardIO) you can add 8 local IO modules.
did that answer your question?

If I would have a 1734-AENT with 5 1734-IB8S and 2 1734-OB8S mounted, how many nodes would I be using?
 
To go through the specs for the 1769-L30ERMS:
16 Ethernet Nodes means you can have 16 ethernet devices defined in your "tree". These can be VFD's, encoders, barcode scanners, or I/O racks. An I/O rack is just one node, regardless of whether it has 1 card on it or 50. The number of cards will affect the number or connections, but that's not the same as the number of nodes and is, for practical purposes in the case of your PLC selection, irrelevant.
I/O Capability Expansion of 8 means that you can add 8 1769 cards to the local rack (i.e. tacked onto the RHS of your processor). The usual restrictions regarding power supply distances etc apply.

When it comes to safety I/O, yes, you'll need to use a remote chassis for your safety I/O. There is no 1769 series safety I/O on the market. 1734 Point I/O is a common choice. So you'll add a 1734-AENT(R) to your ethernet tree; that will take up one of your 16 nodes (or 48 nodes, if you're using an L36). You can then put as many safety I/O modules on there as you like - it's still only one node.

The limitations you will face are in the arrangement of your 1734 chassis. There are two factors to consider; bus power and the number of CIP connections your AENT(R) can make to its I/O modules (note that this is completely separate from, and unrelated to, the number of connections you PLC can make. This is about how many cards your 1734-AENT(R) can talk to on it's local bus, not how many I/O racks your 1769-L30ERMS can talk to over ethernet).

First; bus power. Your 1734-AENT(R) can supply a certain amount of bus power. Each card on your rack draws an amount of bus power. Obviously, if the second number is bigger than the first number, you're going to have issues. The solution is pretty simple; once you have added so many cards that your AENT(R) is at its bus power limit, add a 1734-ED24DC to the chassis. This is a "bus power extension module" and does exactly what the name suggests - provides all the modules to its right with bus power once the AENT(R) has exhausted its resources. There's an RA technote (techconnect required) that will help you calculate your bus power requirements - note that the 1734-AENT, 1734-AENTR and 1734-EP24DC all have different amounts of available bus power. Alternatively, RA's free IAB software will let you create a mock-up of your rack and it will warn you if you exceed the allowable bus power and offer suggestions on how to reconfigure things.

The CIP connection limitation is a bit less, uh, straightforward. The newest 1734-AENT(R) modules support 5 rack optimized connections or 31 direct CIP connections if only standard modules are used. As soon as you put a safety card in the rack, that drops to 20 CIP connections. A 1734-OB8S uses two CIP connections - one for input data and one for output data. You need both input and output data on a 1734-OB8S - output data so you can turn the outputs on, and input data so you can monitor the card/outputs correctly to meet your required SIL/PL/whatever. The 1734-IB8S also uses two CIP connections by default. Input data to read the inputs (and also monitor the the card/input status for safety validity), and output data so you can use your test pulse outputs as standard/muting outputs. This means that, assuming there were only safety modules on your chassis, you could get a maximum of 10. However, if you don't need to use the test pulse outputs on the 1734-IB8S's in your program, you can set the output data to "none" for that card, and then the card only uses one CIP connection, meaning you could put 20 1734-IB8S's on your chassis. The test pulses still work inasmuchas they provide test pulse functionality for your safety inputs - you just can't use them as outputs any more. Which is a small trade off to make if you're looking at maxing out your I/O rack otherwise. Technotes 65912 and 553849 (techconnect required for both) go over this limitation, or again, IAB will warn you if your configuration exceeds the number of CIP connections available.
 
Last edited:
g.mccormick said:
If I would have a 1734-AENT with 5 1734-IB8S and 2 1734-OB8S mounted, how many nodes would I be using?

One Node.

Each Ethernet device, such as the 1734-AENT(R) adapter, added to the I/O Configuration in your project, will count as a Node used against the total Node count for the controller model you select.

While the adapter is an Ethernet device, the I/O modules under it are not. Therefore, only the distributed Ethernet adapter itself counts against the controller's Node count.

You seem to be aware of Connections, which is good, and So I wont go explaining those as distinct from Nodes...

EDIT - oh thanks A! I can go to bed early now! ...and you can go to work? :)

G.
 
Thanks all for the information. I've never worked with logix platform. I am not doing the controls directly, but specifing to contractors and verifying hardware etc. (I'd rather be actually doing the controls myself, but ...).

So I understand now that the 1734-AENT will consume 1 node regardless of number of modules connected. Each safety module seemingly will have its each connection or connections to the processor through the AENT.

Another question I have since I have some ears here, when setting up produced/consumed data tags, I'm guessing that the producer/consumer show up in the IO list and thus consume nodes.

Isn't Produced/Consumed messaging a fancy way of saying that you setup a message using implicit ethernetIP which is ethernetIP over UDP?

I have to specify and get different suppliers and contractors all sharing data amongst each other. Luckily they are all providing CompactLogix (5069 and 1769 series) processors.
 
See attached files

Number of CIP & TCP connections
SRC (DINT)=9 For used for NUmber of CIP connections
SRC_TCP (DINT)= 2 used for NUmber of TCP Connections.

DST (DINT) = Number of CIP Connections
Num_Conn_TCP (DINT)= number of TCP connections


I´ll be glad if somebody use it.

Path Config.JPG TCP Connections.JPG CIP Connections.JPG
 
If you need to consume a tag, the producing device needs to be in your ethernet tree, and will use one node. If you want to produce a tag for someone else to read, you just make the produced tag and you're done. You don't need to add the consumer to your ethernet tree, and even if 20 PLC's consume your produced tag, it will not use up any nodes on your PLC, only on the consuming PLC's.

Explicit messaging (using MSG instructions) is a scheduled and programmable transfer of a specific set of data from one device to another. It uses no "nodes" at either end.

Produced/consumed tags means that your consuming PLC treats the producing PLC as an I/O device. That is, it will establish a connection to it and cyclically request the I/O data at the specified RPI, just like any other physical I/O rack.

The two work quite differently and it's very much a "use the right tool for the job" question. Based on your description, if I were in your situation, I'd be 100% going down the produced/consumed tag path. Set up a UDT with enough data for all possible use cases, and share it with all of the suppliers. My standard comms UDT has two DINT's called BoolData (so I get 64 individual bits of BOOL data), 20 DINT's called IntData and 20 REAL's called RealData. Whatever I'm communicating with, this has always given me plenty of spare space for all the required data. Then you just tell each contractor which data you want them to map to which element of your UDT. Also, a tip - make the first element of the UDT a CONNECTION_STATUS data type, and then your connection status can be automatically monitored without the need for heartbeats and watchdog timers. You get two tags; ConnectionFaulted and RunMode, and even if both the producer and consumer are faulted, in program mode, or unable to communicate with one another these tags continue to update.
 
Thank you very much! I will specify a udt for my suppliers to adhere to and i will make it large enough to handle all needed data. Thanks!
 
This technote gives a very good breakdown of the ins and outs of Connection usage when using the Produce/Consume model...

56682 - Counting CIP Connections for Produced and Consumed tags in ControlLogix
Access Level: TechConnect

Just a general remark...

One thing I'm very wary of with the new Node limit on Logix 5000 controllers is that users may get hung up more on not reaching or exceeding the given controller's Node limit, while not so much considering the Connection count the Nodes will use.

It's important we don't loose sight of the fact that it is TCP/CIP Connections that are actually used at runtime, and that Nodes are a fictitious limit purely imposed within the offline project environment. Once you have selected a controller, with an adequate Node limit for your application, you should no longer really concern yourself, too much, with this limit.

Having said that, as the Connection limit is vastly increased for most all newer controllers, the Connection limit should also be of less concern. Still, it is the Connection usage at runtime that we should be more aware of, as we develop or expand these systems.

Regards,
George
 
Last edited:
A question on the Produced/Consumed data. Does the UDT have to be named the same at both ends, or just have the same structure? I assume it just has to be the same structre layout, and not actually nameed the same.

Example:

Supplier1.
UDT Name UDT1
Elements Real, BOOL.



Supplier2.
UDT Name : Prod_Con_UDT
Elements Real, Bool
 
UDTs must be identical to work in Produced/Consumed connections.

They must have the same UDT name, sub-element names, data types, data type sizes, and element order.
 
A question on the Produced/Consumed data. Does the UDT have to be named the same at both ends, or just have the same structure? I assume it just has to be the same structre layout, and not actually nameed the same.
Only data type must me exactly the same. Name can be different.
Producer for example can have tag named “ To_Controller_B” and consumer tag named “From_Controller_A”. In consumer tag properties, you will have to specify exact producer tag name “To_Controller_B” to link these.
 
UDTs must be identical to work in Produced/Consumed connections.

They must have the same UDT name, sub-element names, data types, data type sizes, and element order.

Only data type must me exactly the same. Name can be different.
Producer for example can have tag named “ To_Controller_B” and consumer tag named “From_Controller_A”. In consumer tag properties, you will have to specify exact producer tag name “To_Controller_B” to link these.
Anyone want to test it out and see who's right? :D
 

Similar Topics

Hi Guys, I have a 1769-L24-QBFCB1 that has the OK light flashing on the embedded counter module. The manual states it is a resettable fault, but...
Replies
0
Views
16
Hello all, and thank you in advance for any assistance you may be able to provide! This is my first post, so if I need to reformat or change...
Replies
0
Views
15
We are trying to poll data coming from a PLC for remote monitoring we have the IP address of the PLC and the default port number and the path is...
Replies
25
Views
418
My PLC is currently running the program and the process is still live. One of my 1769-if16C cards values are all frozen but the card is not...
Replies
1
Views
85
Hello Guys, I am using 1769-L36ERMS PLC by Rockwell which doesn't let me MOV or COP literal text into string datatype? i very well know the...
Replies
13
Views
350
Back
Top Bottom