New CL5380 Controller with New I/O mapping question

dev67

Member
Join Date
Jun 2016
Location
Michigan
Posts
19
Hey all! Before I jump in I just want to say this community is amazing! I haven't been at this whole Controls thing very long and this forum has been a huge help in my education in the field. Searching Google with the "site: plctalk.net" prefix is now second nature to me. So thank you all for sharing your knowledge 👨🏻‍🏫

So onto it then.

I'm prepping an old program for a machine that will be using the 5069-L3ERM controller and found that the I/O mapping is totally different now. I switched back and forth between the regular data vs packed data trying to move all of my inputs into an INT in the simplest way possible.

This is the best I've been able to come up with so far, but I know there has to be a better way.

zE06VEC.png


Also, when it comes to throwing a fault, what is your favorite method with the new format? Our company was using a masked move to put a zero into the faulted input and throw an HMI fault. Once I learn a better way to move all these bits into an INT I'm sure I can use our old method for this. I'm curious as to the flavor of everyone's method on this.

I got a lot of great info from Geospark on this thread concerning this stuff too. http://www.plctalk.net/qanda/showthread.php?t=117803&page=2. Still curious about what those "Uncertain" bits are for though. As well as all those diagnostic bits and others that aren't my actual inputs. If anyone knows where to find a manual that describes them it'd be much appreciated.
 
Not sure what you mean by regular data vs packed data. Your screenshot of the IO mapping looks fine though.

When you add a module to your RSLogix program, you can go to Controller Tags, find the module (for example Local:1:I) and expand it to view exactly what data is available. The user manuals for each module/PLC card should have details on exactly what data (diagnostic bits, etc) are available. Here is an example:

https://literature.rockwellautomation.com/idc/groups/literature/documents/um/1769-um002_-en-p.pdf

Hope this helps.
 
If I understand correctly, you used to use a simple COP to transfer 16 inputs into a 16-bit INT data type, which you were able to do because the older processors had all of the input data stored in a single INT. e.g. Local:1:I.Data was an INT, with Local:1:I.Data.0 through Local:1:I.Data.15 representing 16 inputs. You could then copy this INT to your own INT called, say "Slot_1_Input" where now Slot_1_Input.0 through Slot_1_Input.15 represented your 16 mapped inputs.

Now you've found that the I/O data from the new 5069 series compact logix is not packed nicely into a single INT, but rather spread across multiple status tags, so you can't find a neat way to copy all the inputs into one INT tag, and have had to revert to individual XIC-OTE style mapping, as shown above. Am I right so far?

If so, sorry, I have no ideas! I for one prefer to map that way anyway, because it's so much easier to read, easier to commission, easier to troubleshoot, easier to modify, etc etc. I have all of the mapping automated using excel, so it only takes me half an hour to generate an I/O map for a few hundred I/O, and then I have a very user-friendly I/O mapping routine to play with when I get to site to commission.
 
A_G said:
Not sure what you mean by regular data vs packed data...

If you care to, have a read of the linked thread above. In there I briefly outline the difference between these two newer Data Formats for the newer 5069 I/O modules and also how the module-defined data types differ between the two.

A_G said:
...When you add a module to your RSLogix program, you can go to Controller Tags, find the module (for example Local:1:I) and expand it to view exactly what data is available. The user manuals for each module/PLC card should have details on exactly what data (diagnostic bits, etc) are available. Here is an example:

https://literature.rockwellautomation.com/idc/groups/literature/documents/um/1769-um002_-en-p.pdf...

Although I know you are just providing a general example, that document is specific to the older 1769 Compact I/O analog modules. The OP is not necessarily asking about adding traditional I/O modules to a traditional Logix platform. They are specifically asking about adding the newer 5069 I/O modules to a newer 5069 Logix controller and how they have noticed how different they are...

dev67 said:
...found that the I/O mapping is totally different now...

These 5069 I/O modules are quite different to what we have been traditionally using across the older Logix platforms and their module-defined data is handled in an especially unique manner. As I explained in that other thread, the 5069 I/O data points are no longer stored as individual BOOL members within an INT or DINT member of the module-defined data type. In fact, for the standard "Data" Format, the individual point data is one of three BOOL members within a sub-data type within the module-defined data type (shown in other thread). The other two BOOLS being the point specific Fault and Uncertain status members for the point.

If we change to the optional "Packed Data" Format, the two status members are removed. In fact the actual sub-data type is removed. The individual point BOOL members are then moved up a level within the module-defined data type and grouped together in numerical ascending order. However, the points are still only represented by individual BOOL members within the module-defined data type. They are not collectively represented as in grouped within an INT or DINT member.

(Since noticed your post ASF - read on or view linked thread for solution, if you like, even if you may never use it)...

This new and optional method of representing 5069 I/O point data poses a problem where a user wants to use traditional methods of I/O mapping or referencing at the word level (INT or DINT). However, using the more concise and efficient Packed Data Format, we can then use the Copy (COP) instruction to copy the module data to a user-defined 1-dimensional DINT array with two members (DINT[0], DINT[1]). The DINT[1] member of the array will then contain the point data for the module in the more traditional word format. This get around is also mentioned in that other thread and a technote on the subject is linked.

dev67 said:
...Still curious about what those "Uncertain" bits are for though. As well as all those diagnostic bits and others that aren't my actual inputs...

I didn't have time to go further into the subject on the day in that other thread, and seeing as the OP, nor anyone else, made no further reply to either acknowledge the info or ask further questions, I didn't bother coming back to expand on the "other" specific BOOL members. Something I was hoping to do though should someone eventually ask...

The 5069 Compact I/O modules incorporate a feature which allows us to monitor the quality of the channel or point data being returned to the controller. Data quality represents accuracy. There are levels of data quality reported via certain module input tags -

.Fault - This tag indicates that the reported channel or point data is inaccurate and cannot be trusted for use in the application. If the tag is set to "1", you cannot trust the data being reported. You should troubleshoot the module to correct the cause of the inaccuracy.

Typical causes of inaccurate data may include -

Channel is disabled
Open Wire (input modules)
No Load (output modules)
Underrange/Overrange
Short Circuit

Once an inaccurate condition is removed the .Fault bit automatically resets to "0".

.Uncertain - This tag indicates that the reported channel or point data may be inaccurate but the degree of inaccuracy is unknown. If the tag is set to "1", the data may be inaccurate. You should troubleshoot the module to discover what degree of inaccuracy exists.

Typical causes of uncertain data may include -

Data signal slightly outside the channel operating range
The channel is slightly over temperature
Invalid sensor offset value
Calibration fault on the channel
Calibration is in process on the channel

For analog I/O modules, active calibration on one channel can cause simultaneous indication of Uncertain data quality on other module channels within the same group. A channel under calibration will slow its Notch Filter down to 5hz and set its .Uncertain bit to "1". Because analog channel groups share the same AD converter, the slowing of the sampling rate for the single channel under calibration (5hz) will affect the AD conversion for the entire group i.e. all channels experience a slower sampling rate. Therefore, for analog groups, once one channel is under calibration, all channels within the group will set their .Uncertain bits to "1" until the calibration is complete. Once complete, all .Uncertain bits are automatically reset to "0".

For more critical process applications we can monitor these tags in the project to help ensure that the application is operating as expected with accurate channel data.

Also...

DiagnosticActive - Indicates if any diagnostics are active or if the prognostics threshold is reached.

DiagnosticSequenceCount - A counter that increments whenever a diagnostic condition is detected or reset. The counter is a rolling counter that skips "0" on rollover at "255".

And others...

dev67 said:
...If anyone knows where to find a manual that describes them it'd be much appreciated.

While I'm spouting on all "expert" like, I just wanted to give a quick flavour of some of these particular module status bits here on the Forum. These descriptions are of course available within the 5069 Compact I/O manuals...

5000 Series Digital I/O Modules in Logix5000...

5000 Series Analog I/O Modules in Logix5000...

Regards,
George
 
What I’ve done in the (recent) past is created an AOP that takes the bits of an INT and tie them to the specific data points that represent either input or output channels. You could do that in the ladder routine, but I do it with the AOP to keep the main ladder routine cleaner. It was a bit of a learning curve when I first setup a 5069 but like anything else once you get to know it, it will become second nature.
 
AOP = Add-On Profile. I think you mean AOI = Add-On Instruction?

But you've reminded me of something else to do with I/O mapping alternatives...

Out of the handful of available 5069 I/O modules, there are four specific modules that do not support the Packed Data Format which allows us to use the COP instruction to group the point data. As an additional get around, Rockwell have provided specific AOIs on the Sample Code Library which do similar to what you have described, Firejo.

The following technote is the same one I linked in the original thread on this topic and contains both the COP method and a link to the Sample Code Library for their AOI options...

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

G.
 
So I wound up writing a small AOI for this. See below.

HOAlh22.png
JlP67eK.png


Thanks Geospark for the more in depth look at those other bits. Do you think my AOI here is okay with each channel being conditioned with those fault and uncertainty bits? Do you have any experience with watching those actually trigger and go high? I don't want to make my inputs unreliable if the uncertainty bit happens to flicker on every other signal, but on the other hand if the signal really is unreliable I don't want a false positive. I'm thinking I should add separate faults for these, although our company never has in the past. They've only thrown faults and process stoppers directly off of the connection_fault bit, never the uncertainty bit.

Also, I think I need to set up a false routine to move 0 into my INTs just in case. Sometimes we condition those rungs, and move 0's in some cases.

What do you think?
 
AOP = Add-On Profile. I think you mean AOI = Add-On Instruction?

But you've reminded me of something else to do with I/O mapping alternatives...

Out of the handful of available 5069 I/O modules, there are four specific modules that do not support the Packed Data Format which allows us to use the COP instruction to group the point data. As an additional get around, Rockwell have provided specific AOIs on the Sample Code Library which do similar to what you have described, Firejo.

The following technote is the same one I linked in the original thread on this topic and contains both the COP method and a link to the Sample Code Library for their AOI options...

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

G.

Good catch. Yes I mean AOI. There is still a lot of information that I need to get caught up on but being less busy after AF didn't really happen as I had expected. Maybe next year :ROFLMAO:
 

Similar Topics

Hello everyone, I'm working on a project that involves controlling an array of nozzles within a CNC environment, where the nozzles travel along a...
Replies
5
Views
128
I have 9 field devices, three METSEPM5110 power meters and six ACE949-2 rs285 interface modules. I want to read this Modbus rtu data through rs485...
Replies
8
Views
269
Hi, One of my customers has an old fabric tensile testing machine. The IC # AD7501KN of its controller has malfunctioned. This IC is related to...
Replies
1
Views
62
Does anyone know of a way to detect if someone is online with the controller in ControlLogix (from logic) I'm thinking that maybe there is a CIP...
Replies
7
Views
293
Hello everyone, I am currently working on a project that uses a Rockwell L33ER controller and the FTV Studio V13 as Supervisory computer...
Replies
0
Views
84
Back
Top Bottom