The new Logix platform

In this case, "not directly compatible" means "has a different I/O bus connector".

The 5069 bus is based on gigabit Ethernet.
The 1769 bus goes back to the mid-2000's and is based on SPI.
The 1734 bus is CANBus, running DeviceNet at double speed with some extra adjacent-module features.

CompactLogix 5380 controllers can use them all, but the older platforms need to connect via EtherNet/IP network adapters, not plug directly into the backplane.

Every design decision is a trade-off between modern features and performance and compatibility with old technologies and installed base of product.

I disagree very strongly with the idea that "Rockwell isn't good at compatibility" when I can connect an 8-bit 120V AC I/O module built in 1978 into a network adapter that links to a modern ControlLogix 1756-L83E controller.

Exactly. Thanks for clarifying, Ken. I was on my way to it, but got called away. :)
 
I disagree very strongly with the idea that "Rockwell isn't good at compatibility" when I can connect an 8-bit 120V AC I/O module built in 1978 into a network adapter that links to a modern ControlLogix 1756-L83E controller.

The operative words being "network adapter" when other brands don't make you buy them...
Another interesting aspect is when they simply kill off a product family and have no way to maintain the system other than replace everything but the power supply and backplane. Meanwhile, other brands have the same protocol and bus supported since mid 90's to today... no adapters needed.
 
Where did you encounter an incompatibility with 1734-AENT adapters ?

The 1734 POINT platform is specifically called out as supported over EtherNet/IP in the 5380 CompactLogix Controller Specifications / Technical Data document on Page 17.

Were you using an early build, or is there a specific firmware revision issue that isn't called out in the technical data document ?

So the other day (I swear to God people, it was just the other day (musical pun)) I needed to run a quick test on one of our 1734 modules and I had an L306 sitting on my bench so I opened the program that was in it (off line) and tried attaching a 1734-AENT module to one of the Ethernet ports. All of the 1734 communications adapters were grayed out so I jumped online (I almost sent you a text) and started digging. I found the same document that Jordan posted clips from. I've not looked at it any further other than to quickly try again this morning (after reading your post) and now they are all available (boy you've got some pull within Rockwell). Now I'm going to have to make it work!
 
Ok so this time I'm able to configure and connect a 1734-AENT (with a 1734sc-IF4U) and it works just fine. I have no idea why I couldn't do that last week nor do I fully understand what the Rockwell statement talking about it not being compatible is all about. So I formally rescind my previous statement about the 1734-AENT cont being compatible with the new Logix platform.
 
JordanCClark said:
Firejo said:
Something else I discovered, the new Logix platform isn't compatible with 1734-AENT modules. That one is a little narrow sighted in my view (pardon the pun).

From technote 772353:
The 1769 Compact I/O family is not directly compatible with the 5380 controller but can be used along with a 1769-AENTR Ethernet adapter.

The 1734 Point I/O family is not directly compatible with the 5380 controller but can be used along with a 1734-AENT or 1734-AENTR Ethernet adapters

Firejo said:
...nor do I fully understand what the Rockwell statement talking about it not being compatible is all about...

I thought Ken had made it clear?...

Ken Roach said:
In this case, "not directly compatible" means "has a different I/O bus connector"....CompactLogix 5380 controllers can use them all, but the older platforms need to connect via EtherNet/IP network adapters, not plug directly into the backplane.

If I may put it another way?...

The somewhat older 1769 I/O modules, and the 1734 I/O modules, are physically "not directly compatible" to be used as Local I/O attached to the backplane of any of the newer 5069 family of controllers. You cannot physically plug a 1769 or 1734 I/O module onto the side of any 5069 controller as the architectures are dissimilar. The limitation is just referring to a physical Local I/O restriction.

Using 1769 or 1734 I/O for Distributed I/O communicating with a 5069 controller is of course perfectly valid, as stated. You can also communicate from a 5069 controller in a distributed fashion to a 1747-AENTR and 1746 I/O modules.

Firejo said:
...the “path” structure is different (although I don’t know details)...

I've posted this here before...

MSG Instruction Communication Path (5069 controllers)

Let me know if there is anything further you'd like to know on the path structure.

Firejo said:
...the I/O structure has changed...

Yes, indeed it has. Unfortunately I'm heading home now for the weekend so I don't have anywhere near the time I'd prefer to give this, as it is an important change to know about, but I will give you this much...

The 5069 I/O modules use a newer data structure for their module-defined data types -

For the old Logix data type, for example using a 16 point input module, the module-defined data type is simply made up of 1 DINT Fault member and 1 INT Data member, representing the 16 input points.

As we know, each input point in the INT (or DINT for 32 point) is addressable in programming using the .0, .1, delimiter (Local:1:I.Data.0, Local:1:I.Data.1).

For an equivalent 5069 16 point module-defined data type, the structure now contains more module information and more point information -

(I'll explain "Data" format in a minute)

Example 16 point input module using default "Data" format:

Module level data -

RunMode - BOOL
ConnectionFaulted - BOOL
Diagnostics Active - BOOL
DiagnosticsSequenceCount - SINT

Point level data -

Pt00 CHANNEL_DI:I:0
- Data - BOOL
- Fault - BOOL
- Uncertain - BOOL
Pt01 CHANNEL_DI:I:0
- Data - BOOL
- Fault - BOOL
- Uncertain - BOOL
Pt02 CHANNEL_DI:I:0
- Data - BOOL
- Fault - BOOL
- Uncertain - BOOL
...
...
Pt15 CHANNEL_DI:I:0
- Data - BOOL
- Fault - BOOL
- Uncertain - BOOL

So the data for each point, in this example, is now contained in the module-defined data type, within a sub data type - CHANNEL_DI:I:0. So for Pt00, for instance, instead of referencing the data for the point using a ".0" delimiter, we now reference it using a ".data" delimiter and to point to the correct input the ".data" delimiter is preceded by the point number "Pt00" -

Local:1:I.Pt00.Data

So the point number (Ptxx) now becomes the distinguishing element of the full input address.

Furthermore, within the Module Profile for the 5069 I/O modules, there is the option to change the module's Data Format from the default "Data" to "Packed Data". This reduces the overall size of the default module-defined data type by removing the excess point information -

Example 16 point input module using "Packed Data" format:

Module level data -

RunMode - BOOL
ConnectionFaulted - BOOL
Diagnostics Active - BOOL
DiagnosticsSequenceCount - SINT

Point level data -

Local:x:I.Pt00Data - BOOL
Local:x:I.Pt01Data - BOOL
Local:x:I.Pt02Data - BOOL
...
...
Local:x:I.Pt15Data - BOOL

So using "Packed Data", the sub data type CHANNEL_DI:I:0 is removed and the input points are simply represented by BOOL members at the higher level within the module-defined data type. So now for Pt00, instead of referencing the data for the point using the ".data" delimiter, we now reference it using a higher level ".Pt00Data" delimiter -

Local:x:I.Pt00Data

Which is one less delimiter than normal. If the per point information is not required then the Packed Data format is more efficient.

One downside to these newer module-defined data type structures is the loss of the ability to reference a module's data at the word level. You can no longer directly reference an INT or DINT value to monitor a complete module's point status as the new structures no longer support this data congregation.

But there is a workaround. Using Packed Data format, the module's data, as a whole, may be copied (using the COP instruction) to a destination array, of which a member will contain the module's data. This mapped data can then be programatically referenced as a whole or individually within the project...

790954 - Invalid data type error when using 5069 I/O modules
Access Level: Everyone

As concise as I could be!

You might not like it any better, but I hope that helps explain it a bit better?

5069%20IO%20Data%20Format.jpg


Regards,
George
 
Last edited:

Similar Topics

Hello Everyone! Need help with this... I have a controllogix plc 5571 which has just a USB port on it. I wish to read the data from this plc...
Replies
2
Views
2,359
I sifted through a few old threads on this subject, but most seemed to be troubleshooting specifics. I am sure I could google several sources for...
Replies
12
Views
3,337
I am getting ready to load RS Logix 500 on a laptop with RS Logix 5000 installed. During setup , I was asked about installing FactoryTalk Service...
Replies
3
Views
4,872
Good Evening , A few months ago I upgraded my RS Logix 5000 , and my service platform became corrupt . Has this happened to any of you ? I...
Replies
4
Views
3,848
Hi all, Has anyone had experience or success even with connecting some discrete remote IO to a Micrologix (1100 or 1400)? From looking at...
Replies
14
Views
8,037
Back
Top Bottom