Indirectly Addressing New CompactLogix I/O

Anyway to indirectly address I/O based on slot # instead of having to first map each point to a secondary tag? Prefer to be able to address based on both slot and point but not sure if either is possible with the new platform.

For example, can this be indirectly addressed

Local:8:O.Pt00.Data

as

Local:INDEX:O.Pt00.Data?


INDEX is a tag in this case that will hold the value of slot # being addressed. The above method does not work. Is there another way to do this? Perhaps I am not using the correct syntax. I am open to either a ladder or a structured text based solution while not having to map values first to a secondary tag. There are 14 slots involved and mapping each individual data point to another Tag first each and every scan before they can be indirectly addressed, does not seem like an efficient way to do do things.


As an alternate, can the "Local:8:O.Pt00.Data" be copied over to another Int tag to include all 16 data points? That is ultimately what I am wanting to do.


Thanks.

Some advice here: http://www.plctalk.net/qanda/showthread.php?t=121838&highlight=indirect+IO

skyfox said:

As an alternate, can the "Local:8:O.Pt00.Data" be copied over to another Int tag to include all 16 data points? That is ultimately what I am wanting to do.


Thanks.

Click to expand...

Use an ALIAS tag (e.g. Slot_8) to Local:8:O.Pt00.Data

Then Slot_8.0 thru to Slot_8.15 would address Local:8:O.Pt00.Data.0 thru to Local:8:O.Pt00.Data.15

this may be helpful

https://rockwellautomation.custhelp.com/app/answers/detail/a_id/790954

Which CompactLogix? 1769's and 5069's have different file structures and the I/O addressing is different.

Thank you all for your help.





Daba

Can you explain how this works? Unless I misunderstood your explanation it seems that Aliasing method results in a single bool tag that just points to a single I/O point.

Unless you meant...

Create a INT Tag Named "SLOT_X" and then alias each bit to a data point as in;

SLOT_X.0 to Data Point 0
SLOT_X.1 to Data Point 1
...
...

SLOT_X.15 to Data Point 15

Etc., Etc. That is a lot of work. Specially when working with large number of I/O points points.

Thanks again.

Cheers.

Hi Firejo,


Local:8:O.Pt00.Data is the new 5069 platform.

Hi JZerb,

That looks like my only option short of individually mapping each point to an integer tag. This really sucks. Wish AB hadn't done that. They just complicated array operations, masked moves, masked compares etc., when using INT or DINT tags with I/O points mapped to them with a single copy or a move instruction that represented all of the I/O points in a given card.

Thanks again for that link.


Cheers.

You may also read the following previous information I provided for another member, and also the linked thread within the first post, where I detailed the makup and options we might have when working with this newer I/O platform and its data types. The same technote that is linked here is also linked in the original thread...

New CL5380 Controller with New I/O mapping question

For 5069 I/O modules that support the Packed Data format option, and in keeping with much of the advice given there and here, you can copy the data as a whole to an array structure, which will then contain within the array the module data point values in the traditional word format.

For 5069 I/O modules that do not support the Packed Data format, we have the alternative AOI method, either provided by Rockwell, or user-created, which does similar in presenting the data in a more user friendly way.

My gut feeling on this new and wonderful "Module Data Quality Reporting" feature is that the majority of us won't require or use it, and the same majority of us will bemoan the fact that they did away with a very fundamental and useful data structure, which we now, the majority of us, must circumvent using additional time, thinking and resources.

My gut is also whispering that, in all probability, the possibly young go getter software and hardware feature developers at Rockwell are becoming more and more "not" ex Field Engineers with a few years experience at the coal face?

This feature, and its implementation's trade-off, is akin to upgrading the Engine Control Unit in a car to give more diagnostics, while at the same time telling the driver that the mileage readout is now expressed in Scientific Notation. It's not too difficult to convert the data to the format we better understand, but it is distracting for long enough to take our eyes off the priority.

Regards,
George

Geospark said:

My gut is also whispering that, in all probability, the possibly young go getter software and hardware feature developers at Rockwell are becoming more and more "not" ex Field Engineers with a few years experience at the coal face?

George

Click to expand...

Truer words have never been spoken.

This was another arrogant slap in the face type of a dictated change by ROCKWELL without any consideration to their user base.


Thank you for your help. Much appreciated.


Best regards.

daba said:

Use an ALIAS tag (e.g. Slot_8) to Local:8:O.Pt00.Data

Then Slot_8.0 thru to Slot_8.15 would address Local:8:O.Pt00.Data.0 thru to Local:8:O.Pt00.Data.15

Click to expand...

I was actually gonna call you out for aliasing an IO tag but this actually makes sense

Hi diat150,

Originally Posted by daba
Use an ALIAS tag (e.g. Slot_8) to Local:8:O.Pt00.Data

Then Slot_8.0 thru to Slot_8.15 would address Local:8:O.Pt00.Data.0 thru to Local:8:O.Pt00.Data.15

Click to expand...

diat150 said:

I was actually gonna call you out for aliasing an IO tag but this actually makes sense

Click to expand...

Curious. Why would aliasing an I/O tag be a bad thing? I would think that would help with network latency when communicating with non AB HMI's (or even with native HMI's for that matter) where resolving "LS1" aliased to "Local:8:O.Pt00.Data" would be much faster than trying to resolve Local:8:O.Pt00.Data. Actually some of our customers dictate that all module I/O tags to be aliased before they are used in logic.

i.e.

IO_InLS01 Alias for Local:6:I.Pt09.Data

IO_OutAV01 Alias for Local:8:O.Pt00.Data

etc., etc.

I am interested in knowing why that would be frowned upon? Also, unfortunately, the method that Daba described does not work. It still points to a single bool tag and does not result in an Integer that is holding all 16 module points. Also there is a slight error in the format in his reply as there is no ".xx" after the Data. As in...

Local:8:O.Pt00.Data.0 - is incorrect
Local:8:O.Pt00.Data - Is the correct format.

Cheers

I see programmers alias individual io points on say a digital input card then reuse them in the logic. Now if you have a point go bad on a card that has spares, you cant re-alias an individual point online, so you have to go thru a bunch of hoops to swap a point without bringing the PLC down.


I dont know anyone that reads the actual physical IO. Typically I create a mapping routine where I just map the physical IO to a coil via an xio or xic

diat150 said:

I see programmers alias individual io points on say a digital input card then reuse them in the logic. Now if you have a point go bad on a card that has spares, you cant re-alias an individual point online, so you have to go thru a bunch of hoops to swap a point without bringing the PLC down.


I dont know anyone that reads the actual physical IO. Typically I create a mapping routine where I just map the physical IO to a coil via an xio or xic

Click to expand...

Hi diat150,

Now I see what you mean. However, this practice of re-assignment of I/O may be OK with one of a kind or mom and pop type of operation. But if it is a customer with 100's of identical systems and these systems are spread around the globe at different manufacturing facilities and if one facility changes software that was once universal because of a single failed I/O point in a card, that would be a disastrous practice and go against the philosophy of copy exact among their global manufacturing operations. So while it does have it's place in some applications, it should not be something that should necessarily be frowned upon.

Just my 2 cents.


Cheers.

skyfox said:

Hi diat150,

Now I see what you mean. However, this practice of re-assignment of I/O may be OK with one of a kind or mom and pop type of operation. But if it is a customer with 100's of identical systems and these systems are spread around the globe at different manufacturing facilities and if one facility changes software that was once universal because of a single failed I/O point in a card, that would be a disastrous practice and go against the philosophy of copy exact among their global manufacturing operations. So while it does have it's place in some applications, it should not be something that should necessarily be frowned upon.

Just my 2 cents.


Cheers.

Click to expand...

Yeah I can see that point. I mostly deal with Oil and Gas so very few sites are the same. Also you wouldnt want to have production down waiting for a card that may or may not be available immediately.



regardless, aliasing the IO wont stop someone from changing the IO, it is just a major annoyance.