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?
Regards,
George