better output mapping technique

unsaint32 · Nov 30, 2015

Let's say my PLC has a 32 terminal output card called Local:3.O.Data.

Which of the two options below is a better way to map the output? Or is there a better way?

OPTION1)
Creating an alias DINT tag named "LO-03" aliasing it to Local:3.O.Data.

OPTION2)
Creating a DINT tag named "Local03_Outputs" then
COP(Local:3:O.Data, Local03_Outputs,32)

rdrast · Nov 30, 2015

Personally, I create a unique alias for every individual input/output. A bit more work, but then they at least have descriptive names.

briancr · Nov 30, 2015

+1 rdrast

jdbrandt · Nov 30, 2015

unsaint32 said:
Let's say my PLC has a 32 terminal output card called Local:3.O.Data.

Which of the two options below is a better way to map the output? Or is there a better way?

OPTION1)
Creating an alias DINT tag named "LO-03" aliasing it to Local:3.O.Data.

OPTION2)
Creating a DINT tag named "Local03_Outputs" then
COP(Local:3:O.Data, Local03_Outputs,32)

The real answer is "it depends".

If you do option 1, there is no dependency on Routine scanning, since there is no program action required for the alias to be active.

If you do option 2, your data is dependent upon the timing of the execution of the COP instruction.

All of this is on the assumption that the PLC application logic, be it ladder, statement, or whatever, is creating output-type instructions to your Aliased tagname, and not directly to the hardware-assigned tag name.

RET · Nov 30, 2015

Personally, I prefer to have a separate routine that maps the output command to the actual output tag. To me, that makes it easier to find outputs and trace the back through the logic as well as trouble shoot and commission.

RonJohn · Nov 30, 2015

unsaint32 said:
OPTION2)
Creating a DINT tag named "Local03_Outputs" then
COP(Local:3:O.Data, Local03_Outputs,32)

FYI: if you decide to go with option 2, I believe that your COP instruction should have a length of 1, not 32, since the destination is a DINT and not a BOOL.

DBLD99 · Nov 30, 2015

+1 RET

If you use aliasing you won't be able to change an input or output online. Which is an issue for us, So we use a IO Mapping routine that way if an input or output burns up you can easily remap the input without downloading on a running plant.

Also makes it easier you if use UDT's you can map the IO bit directly to the UDT member without using another tag.

MrAnonEMoose · Nov 30, 2015

Where I'm from, every instrument has an ISA-like tag eg. 41_PIT_4112, 30_FV_0161 etc.
An add-on instructions processes the data from an analog input card point (scaling, etc) for each tag. The same thing happens with the outputs.

unsaint32 · Nov 30, 2015

DBLD99 said:
+1 RET

If you use aliasing you won't be able to change an input or output online. Which is an issue for us, So we use a IO Mapping routine that way if an input or output burns up you can easily remap the input without downloading on a running plant.

Also makes it easier you if use UDT's you can map the IO bit directly to the UDT member without using another tag.

A novice question for you.... I thought using UDT for IO mapping means using COP or CPS instruction, rather than creating a separate IO Mapping routine.

unsaint32 · Nov 30, 2015

DBLD99 said:
+1 RET

If you use aliasing you won't be able to change an input or output online. Which is an issue for us, So we use a IO Mapping routine that way if an input or output burns up you can easily remap the input without downloading on a running plant.

Also makes it easier you if use UDT's you can map the IO bit directly to the UDT member without using another tag.

After doing some thinking, I realized I really don't have to use the CPS or COP. I can just create a UDT then simply use those in the mapping routine. That makes sense. Thanks.

JeremyM · Nov 30, 2015

What, no one else likes finding undocumented B00, B01, B02, etc. (or direct-mapped I/O) in a modern ControlLogix system?

+1 to aliasing.

JeremyM · Nov 30, 2015

DBLD99 said:
+1 RET

If you use aliasing you won't be able to change an input or output online. Which is an issue for us, So we use a IO Mapping routine that way if an input or output burns up you can easily remap the input without downloading on a running plant.

Also makes it easier you if use UDT's you can map the IO bit directly to the UDT member without using another tag.

I am able to do so. Just create a new tag aliased to the same I/O, adjust your program's references accordingly, delete the old.

Unless, of course, there's a vague client *cough* FT trash *cough* out there using the original tag.

better output mapping technique

unsaint32

Member

rdrast

Lifetime Supporting Member

briancr

Member

jdbrandt

Lifetime Supporting Member

RET

Member

RonJohn

Lifetime Supporting Member

DBLD99

Member

MrAnonEMoose

Member

unsaint32

Member

unsaint32

Member

JeremyM

Lifetime Supporting Member

JeremyM

Lifetime Supporting Member

Similar Topics