Message Setup? Allen Bradley Contol Logix

[mellis]

I don't see why, but READ actually takes twice longer and uses 4 packets instead of just 2 for a WRITE.

READ:
Request ->
DATA <-
Rec ACK ->
ACK <-

Write:
Data ->
ACK <-

Contr_Conn,

Can you point me to some documentation that supports this? I seem to remember a discussion a while back that came to the exact opposite conclusion. (I did a search and couldn't find the thread.)

Thanks,

 

[Contr_Conn]

Contr_Conn,
Can you point me to some documentation that supports this? I seem to remember a discussion a while back that came to the exact opposite conclusion. (I did a search and couldn't find the thread.)
Thanks,

I don't have anythig to prove it, I just happen to know this

You can do ethreal traffic capture and see really how many packets takes to do read and write.
I am pretty sure that read takes twice longer than write.

 

[PhilipW]

I am not going to argue Contr_Conns point, as I suspect he is right, but there is a more important criterion about whether to use a Read or a Write. Put simple the MSG instruction needs an event to trigger it. It could be a simple periodic timer, or an actual logical event, but whichever, that event will be defined in one of the processors, and thus it makes sense to have the MSG located in that processor too.

In the case the event and the data needing to be moved are in the same CPU then the MSG will be a WRITE, and the case they are in opposite CPU's...it will need to be a READ.

 

[akreel]

What usually happens is you type the path as Contr_Conn has shown, and as soon as you accept it, RSLogix replaces the first two elements with the Name of the ethernet card in the I/O config. This is confusing because it looks like you have an odd number of parameters when they should be in pairs.

One more reason to NOT put the ethernet card in the I/O config if it's not being used for I/O. If you don't give it a name, RSLogix can't substitute in your path.

That's probably what I'm doing differently. I am using the module name.

 

[Contr_Conn]

That's probably what I'm doing differently. I am using the module name.

Not just you, a lot of people do this.
Technically if you put a communication module in I/O configuration,
you are establishing connection between processor and comm module.

With large systems where every connection counts, it actually waste
of connections and communication resources to keep connection open.

In some cases like DHRIO module with no RIO channels,
you will see error, because processor can'r find a place to make connection.

Also it is a common misconception, that you have to have communication
module in I/O config to connect HMI and computers.

This is not true, I/O configuration has nothing to do with unscheduled comms
and will not increase performance.

Changing subject a little, for ControlLogix platform you should definately look at Produced/Consumed model:
- No extra ladder involved.
- All comms will be performed by the I/O processor compare
to MSG processed by the main processor
(except Compact and Flex processors).
- All data exchange will be done at specific time interval.

 

[akreel]

Changing subject a little, for ControlLogix platform you should definately look at Produced/Consumed model

Thanks!

I'll look into taking the ENET modules out of the I/O config.

We decided against produced/consumed tags because the idea of data constantly screaming "I'm ready," "I'm here," "Don't you want me?" didn't sit well with us. We can disable MSG instructions as necessary. Our bandwidth utilization is really good, though. So the idea has come back up from time to time.

AK

 

[PhilipW]

I pretty much use Producer/Consumer tags for all interprocessor comms that I want to run on a periodic basis.

One way of looking at is that by scheduling the data transfer you have deterministically allocated bandwidth to that transfer and it will happen like clockwork with no further coding or error handling required.

 

[pater01]

Message setup

I want to Thank you guys for your support, I completed this project today around 4:00pm. It was a challenge that I enjoyed, if it where not for the challenges in the controls field I would not enjoy the work I do. If I can help you in any way let me know, I've learned alot about messaging in Allen Bradley Control Logics and Compact Logics lately. Thanks again

 

[automatic]

In addition you need to make sure both controllers are on the same subnet

Does this apply to 1734 point I/O on 1734-AENT modules? From reading the module's manual, it looks like the I/O can be on different subnets than the ENBT.

Also, is anyone aware of having issues with VLANs? I am not very familiar with it, and we are getting yellow traingles on Point I/O that's on a same VLAN subnet. There is a router in the VLAN subnet that connects different switches and you can ping the Point I/O module and pull up its webpage (green blinking network status light).

 

[Contr_Conn]

I/O will not work with routers or on the different subnet.

Ethernet/IP specification requires that multicast packet have TTL=1 (time to leave). This packet will not go through the router.

 

[automatic]

Page 3-2 of the 1734-AENT module (1734-um011_-en-p.pdf) shows a router between 2 networks.

Does this mean, the AENT has a TTL of more than 1, but ENBT does not? Since all of them use the same Ethernet/IP protocol, I do not see why it will be different.

Thanks!

 

[Contr_Conn]

I don't see anything on the page 3-2
http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1734-um011_-en-p.pdf


But if you see it someplace -this is a mistake.
Can you post a screeshot?

TTL=1 is mandatory for all Ethernet/IP devices.
See Section 3 of Ethernet/IP spec.

In any case you don't want TTL>1 because it will flood your network with multicast traffic!

 

[automatic]

Section 3, in pages 3-4, 3-5 and 3-6 it talks about coneecting two networks via routers.

 

[Contr_Conn]

Section 3, in pages 3-4, 3-5 and 3-6 it talks about coneecting two networks via routers.

These pages give you basic IP/Subnet/gateway information.
Nothing said that you can control I/O.
These examples are in every Ethernet manual from AB.
Please read the text, not just look at these pictures.

Chapter 4 is the example and all devices are on the same subnet.

This is pointles discussion: Ethernet/IP I/O will not work with a router.
This is a Ethernet I/P open specification.
A-B will not break spec they wrote.

 

[automatic]

These pages give you basic IP/Subnet/gateway information.
Nothing said that you can control I/O.
These examples are in every Ethernet manual from AB.
Please read the text, not just look at these pictures.

Chapter 4 is the example and all devices are on the same subnet.

This is pointles discussion: Ethernet/IP I/O will not work with a router.
This is a Ethernet I/P open specification.
A-B will not break spec they wrote.

Nothing said that it cannot control I/O. Why include this network subnets with router in it when its clearly not usable with the product and create confusion. Atleast add a sentence in there that says its a general configuration and routers will not forward Ethernet IP packets.
I did read the text.
I was never disputing your point, but just the user manual.
Thanks for your inputs! Pointless maybe, but extremely helpful discussion to atleast me.