You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old December 26th, 2017, 10:12 AM   #1
rootcon
Lifetime Supporting Member
United States

rootcon is offline
 
Join Date: Aug 2011
Location: Western Mass
Posts: 15
Mapping vs Aliasing

Out of curiosity should you Map bits and words or Alias where it could go either way? I'm using RSLogix 5000.
Example:

--|\|--------------------( )---|
Start ...... .......Running
..... .... Local:1:O.Data.0


or



---| |--------------------( )---|
Running Local:1:O.Data.0
  Reply With Quote
Old December 26th, 2017, 10:57 AM   #2
Paully's5.0
Lifetime Supporting Member
United States

Paully's5.0 is offline
 
Join Date: Jan 2006
Location: WI
Posts: 1,961
Plenty of threads on this, so do a search if you haven't already.

From a functionality standpoint, generally speaking either method will work. It usually comes down to preference, how the development process is for someone, possibly some considerations due to the asynchronous IO update of a Logix controller.

I always map, advantages:

1 - Software development can begin if the IO List/Electrical design isn't finalized
2 - I can use SoftLogix for development testing '
3 - I derive additional functionality of an input/output within an AOI. So the result of my AOI is my preferred logic control rather than direct IO.
4 - I have some automated tools that will map my finalized IO list to my previously mentioned AOIs which make mapping IO logic easy.

EDIT: To Add...
I just went through a project where we updated someone else's system (it was a mess). Everything was aliased IO OR, direct IO in the logic. As a result, you cannot do any bench/simulation testing without the physical IO!!!! Took a few days to remove the aliased/direct IO references back to an AOI reference so I could create a simulation environment. With all the changes being made to both the electrical design and the customers process requirements, mapping IO is a clear advantage.

Last edited by Paully's5.0; December 26th, 2017 at 11:01 AM.
  Reply With Quote
Old December 26th, 2017, 05:21 PM   #3
RET
Member
United States

RET is offline
 
Join Date: Feb 2015
Location: Houston, TX
Posts: 223
If you don’t want someone cursing your name in the future, don’t use aliases. They about the worst thing you can use as a programmer. If you need i/o updates faster than a program scan rate then you shouldn’t be using a PLC.
__________________
This statement is false.
  Reply With Quote
Old December 26th, 2017, 08:06 PM   #4
Aardwizz
Member
United Kingdom

Aardwizz is offline
 
Aardwizz's Avatar
 
Join Date: Dec 2017
Location: Swindon
Posts: 37
Quote:
Originally Posted by RET View Post
If you donít want someone cursing your name in the future, donít use aliases. They about the worst thing you can use as a programmer.

I disagree. Aliases are the greatest thing in the PLC since sliced bread (although what sliced bread is dong in a PLC, I can't say.)

Granted, there isn't much value in creating an alias for an I/O point that'll probably just be referenced once in the program anyway. You do better by annotating the I/O point rather creating an alias to help give the point context. But then again, prior to v24, annotation wasn't stored in the PLC, but aliases were. Instead of cursing you, people would bless you if they needed to upload from the PLC and didn't have the original file.

The more complex your program, however, the more useful aliases become.

For example, in building an AOI, I'll create a Local DINT "HMI_CMDs", and have Input BOOLs "ManStart", "ManStop", "GoToAuto", "GoToMan" which are aliases to unique bits in the DINT. Similarly, I'll create "InOff" InHand" , "InAuto", BOOL aliases to bist 0,1, & 2 a "ModeStatus" DINT.

In doing so, what I've now done is recreated what we used to do in the PLC-5 & SLC: manipulate bits at the word level. If I MOV a 1 into ModeStatus, I automatically have set "InHand" and reset "InOff" and "InAuto". No need for convoluted sealing coils, or Latch/Unlatch instructions. The HMI has an easier time animating off of the single tag ModeStatus, while ladder in the PLC is referring to bits.

The HMI sets all the command bits, and the PLC resets them all after 1 scan with a simple, single XOR + MOV instruction.

Anytime I have an array of anything, I can know that I haven't fat-fingered the array pointer ( [2] when I meant [3] ) by creating a meaningful name for that one element in the array via alias, and then programming using the name instead of the array.

Another useful trick: Say I have two identical line, Line1 & Line2. I'll create two separate Programs, and have identical local aliases pointing to different controller-scoped tags. (I.e., in Line1 I'll have an alias "FeedValve" pointing to YV101, in Line 2 "FeedValve" will be aliased to YV201).

Now I program Line 1 using the alias name. When I'm done, I copy the whole code to the Line 2 program, and I'm done. No search/replace or anything. Because every rung refers to a local tag, there is no conflict, even though the names are the same. But because the aliases are different, different devices are used by the different code.

When I make changes to one program, I can just copy the whole shebang back on top of the other, without having to check for which lines changed and which didn't.

The way I use them, aliases cut down on the number of dumb mistakes that I'm capable of making (leaving me free to make more creative mistakes.)


Quote:
Originally Posted by RET View Post
If you need i/o updates faster than a program scan rate then you shouldnít be using a PLC.
Huh? I/O scanning rates have nothing to do with aliasing. I/O mapping is often used because the I/O scans (and HMI communication, for that matter) happens OUTSIDE of ControlLogix program scans, and some code can suffer if both -| |- and -|/|- are true on the same logic scan.

That's not to say that your statement is incorrect: there are things out there that perform I/O scans faster than a PLC does, and every situation needs the appropriate application. Your statement appears to me to be a non-sequitur.
  Reply With Quote
Old December 27th, 2017, 03:44 AM   #5
rdrast
Lifetime Supporting Member
United States

rdrast is offline
 
rdrast's Avatar
 
Join Date: Apr 2003
Location: South Carolina Lowcountry
Posts: 5,106
Quote:
Originally Posted by RET View Post
If you don’t want someone cursing your name in the future, don’t use aliases. They about the worst thing you can use as a programmer. If you need i/o updates faster than a program scan rate then you shouldn’t be using a PLC.
Exactly how do you back that up?
I'll go the other way. If you deliver a system to me, with raw IO addresses scattered throughout the program, you can take it back and forget getting paid.

Aliases are descriptive.
Aliases can be relatively easily re-assigned if IO has to change for any reason.
Aliases have absolutely 0 performance penalty.
Aliases need be done once, reducing the chance of programming errors.

But, you know better. Okay.
__________________
------------------------------------
How to ask questions the SMART Way!

Look First, Ask Second!

  Reply With Quote
Old December 27th, 2017, 07:33 PM   #6
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 4,100
Quote:
Originally Posted by Paully's5.0 View Post
EDIT: To Add...
I just went through a project where we updated someone else's system (it was a mess). Everything was aliased IO OR, direct IO in the logic. As a result, you cannot do any bench/simulation testing without the physical IO!!!!
Yes you can, you just "inhibit" the connections to the I/O modules (they don't need to be there), and let your simulation package read & write the I/O tags, or the aliases. I do this all the time when testing applications.

As regards the pros & cons for "mapping"....

+ It effectively synchronises the I/O to the program scan.
+ It is easy to change an I/O point with an online edit.
- You miss the benefit of fast I/O updates, which might be critical in high-speed motion control, or even flow-meter pulse counting.

I would suggest that it's not a case of "all or nothing", go ahead and "map" your "standard" I/O, and alias anything that needs a faster response than one Continuous Task scan rate. Don't forget that you can trigger EVENT tasks from change of state of inputs. Those inputs, if "mapped", lose their credibility
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
nil illegitimi carborundem


  Reply With Quote
Old December 27th, 2017, 09:04 PM   #7
Aardwizz
Member
United Kingdom

Aardwizz is offline
 
Aardwizz's Avatar
 
Join Date: Dec 2017
Location: Swindon
Posts: 37
RE: the OP's question as to whether it is better to use an alias or mapping:

(1) They are not mutually exclusive.
(2) In the example of the two rungs of logic, neither is particularly helpful., as "Running" is not terribly descriptive
(3) While one can create a bunch of stand-alone tags (Motor1_Running, Motor1_StartPB, Motor1_StopPB, etc.), IMO, it is better to make a UDT or AOI, with .Running, .StartPB, etc being elements of the one Motor1 tag.

Doing this somewhat ends the debate of the OP's question, because (as has been much groused about over the years) a sub-element of a tag cannot be an alias to a different tag. Thus to use UDTs / AOIs, one inherently maps.

Whether one maps via raw address or alias of raw address is up to the programmer's style and taste. Having an alias adds more "clutter" to the Tag folder; but it allows for a quick search if you're only interested in monitoring the point, without having to find the code where the mapping takes place to see the raw signal.

Flip a coin. If you find yourself hoping for a particular outcome while the coin is in the air, go with that. Otherwise, wait for the all-knowing coin to tell you what to do.
  Reply With Quote
Old December 27th, 2017, 09:27 PM   #8
Paully's5.0
Lifetime Supporting Member
United States

Paully's5.0 is offline
 
Join Date: Jan 2006
Location: WI
Posts: 1,961
Quote:
Originally Posted by daba View Post
Yes you can, you just "inhibit" the connections to the I/O modules (they don't need to be there), and let your simulation package read & write the I/O tags, or the aliases. I do this all the time when testing applications.
Assuming you have the correct physical controller to run the logic. RSEmulate has it's flaws.
  Reply With Quote
Old December 28th, 2017, 07:10 AM   #9
daba
Lifetime Supporting Member + Moderator
United Kingdom

daba is offline
 
daba's Avatar
 
Join Date: Jul 2004
Location: uk
Posts: 4,100
Quote:
Originally Posted by Paully's5.0 View Post
Assuming you have the correct physical controller to run the logic. RSEmulate has it's flaws.
Which is why we always bought whatever controller, chassis, and powers supply that were going to be used on the final installations. Many of our clients insisted on it for their Simulation Testing and F.A.T.

In the early days we looked at RSEmulate, but discovered that it isn't even an emulator - it doesn't "emulate" a hardware controller at all.

In those days, pre-AOIs, we had standard software subroutines for our plant item handlers. We would JSR the subroutine, passing into it the plant item UDT (e.g. VA123), then the open and closed feedback inputs. These would be "mapped" into the plant item UDT by the corresponding SBR of the subroutines.

When we ran this on RSEmulate, it didn't work, and I discovered that RSEmulate passes JSR parameters in Reverse Order !!

When I brought this up with RA, I got the response "RSEmulate is a cut-down version of SoftLogix, and the developers of SoftLogix were not given a specification to work to, so were not wrong". Go figure.....

The net result of this was that we would have had so many changes to make to the code after testing/simulation and FAT, to make it work in a controller, that our clients said it would invalidate the FAT. At that point we gave up with RSEmulate completely, and never even looked at it again

Quote:
Originally Posted by Paully's5.0 View Post
RSEmulate has it's flaws.
Like I said, its biggest flaw is that it is not an emulator for a controller....
__________________
___________________________
ControlLogix & SLC Training
a-b train ltd.
abtrain@tiscali.co.uk
www.abtrain.co.uk
tel: 07506 73 9999
nil illegitimi carborundem


  Reply With Quote
Old December 28th, 2017, 08:18 AM   #10
Paully's5.0
Lifetime Supporting Member
United States

Paully's5.0 is offline
 
Join Date: Jan 2006
Location: WI
Posts: 1,961
Quote:
Originally Posted by daba View Post
Which is why we always bought whatever controller, chassis, and powers supply that were going to be used on the final installations. Many of our clients insisted on it for their Simulation Testing and F.A.T.
There are many projects and situations where you simply don't have the hardware (existing system modifications for example) and have to make something work. A spare ControlLogix/CompactLogix or SoftLogix will do the trick but having direct IO references in the logic will cause you headaches should the IO tree get wiped due to a controller change so you can run it on your test hardware.

If you work in a plant, and have many types of controllers you probably don't have the same available at your desk for test purposes. If you work for an SI with 20-30 engineers you may have some in-house hardware available but availability is generally an issue.

Buy brand new hardware because you are supplying it, eat the warranty as it sits on your desk.

Lack of a good "simulation" platform from RA is my biggest gripe with them. SoftLogix needs to live on...
  Reply With Quote
Old December 28th, 2017, 10:47 AM   #11
jacoffey85
Member
United States

jacoffey85 is offline
 
Join Date: Nov 2016
Location: NC
Posts: 50
Out of curiosity, is it preferable to do one over the other depending on the controller type? My company does most of it's development in Siemens, but every now and then we'll have a customer that requests Allen Bradley. I've noticed that in Siemens, the developers stick with aliasing, but in the few AB projects I've worked on, all of the I/O is mapped out in a separate routine.
  Reply With Quote
Old December 28th, 2017, 11:25 AM   #12
Operaghost
Member
United States

Operaghost is offline
 
Operaghost's Avatar
 
Join Date: Apr 2002
Location: Seattle, WA USA
Posts: 2,536
I think for many it is force of habit to use mapping. You can map I/O with any PLC, where aliasing is something that not all support.

Out of curiosity, is anyone using input/output parameters as an alternative to aliases? It solves the I/O scan synchronization issue.

OG
  Reply With Quote
Old December 28th, 2017, 12:00 PM   #13
Aardwizz
Member
United Kingdom

Aardwizz is offline
 
Aardwizz's Avatar
 
Join Date: Dec 2017
Location: Swindon
Posts: 37
Quote:
Originally Posted by Operaghost View Post
Out of curiosity, is anyone using input/output parameters as an alternative to aliases? It solves the I/O scan synchronization issue.
Kind of. I create an AOI for a motor, and add the OUT and AUX as visible, required output & input parameters. Then I enter an unlinked alias for the fields in the AOI block.

In this way, I can develop while waiting for the I/O list to get finalized (the points are known, but they tend to move, as panels get shifted in the floor plan). I simulate using the unlinked alias names.

When the I/O list is ready, I import that from Excel. If it still changes, I import again.

If a device does not have a "required" component, (no. AUX, say), that "alias" tag will never get linked, and will serve a "dummy" tag to make the AOI happy. (There's a bit in the AOI to configure whether it has the feedback or not, of course. Or, I can just make the sim logic permanent for that point, always driving the AUX alias placeholder with the OUT).

But that's me. And I know that I'm not right in the head.
  Reply With Quote
Old December 28th, 2017, 12:37 PM   #14
Operaghost
Member
United States

Operaghost is offline
 
Operaghost's Avatar
 
Join Date: Apr 2002
Location: Seattle, WA USA
Posts: 2,536
What I was referring to is Parameters as in "Parameters and Local Tags". That feature was added in v24. Not, the parameters in an AOI.

OG
  Reply With Quote
Old December 28th, 2017, 01:19 PM   #15
diat150
Lifetime Supporting Member
United States

diat150 is offline
 
Join Date: Mar 2006
Location: Louisiana
Posts: 1,197
for IO I say mapping. Aliasing always causes issues when trying to swap IO points while making online edits. Mapping takes like 2 seconds.
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Canopen SDOís configuration and Variable mapping of the parameters Sohaib28 LIVE PLC Questions And Answers 1 October 11th, 2015 08:18 AM
RSLogix 5000 Multiple Aliases to Same Tag davidc100 LIVE PLC Questions And Answers 10 May 27th, 2014 08:04 PM
Creating Tags in Mapping showshocka LIVE PLC Questions And Answers 6 February 26th, 2013 03:33 PM
DNP3 Mapping: Should it be identical between SCADA and device? automan LIVE PLC Questions And Answers 0 September 21st, 2012 02:55 AM
EtherNet/IP - Modbus Mapping Configuration (GC-XPORT-EIP-MB) puisan77 LIVE PLC Questions And Answers 1 May 6th, 2010 11:44 PM


All times are GMT -5. The time now is 07:52 PM.


.