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 28th, 2017, 01:44 PM   #16
Aardwizz
Member
United Kingdom

Aardwizz is offline
 
Aardwizz's Avatar
 
Join Date: Dec 2017
Location: Swindon
Posts: 206
That's why I said, "kind of".

I've only used Inputs and Outputs with Phase programs, not normal ones. I never could figure out a use for them. Unless I missed something big (possible), you can't call a program like you do a routine, passing parameters with a JSR (except in an Event Task, and using Public tags).

How does using Input and Output parameters solve the I/O scan synchronization issue? If the input tag is just an alias to Local:3:I.Data.5, doesn't its "bit bucket" get read every time it is referenced, and thus change when the I/O point changes, which may be intra-scan?

Or is that a fundamental difference between "Input" and "Local" ?
  Reply With Quote
Old December 28th, 2017, 04:59 PM   #17
Operaghost
Member
United States

Operaghost is offline
 
Operaghost's Avatar
 
Join Date: Apr 2002
Location: Seattle, WA USA
Posts: 2,562
Input parameters are only updated at the beginning of the scan. Output parameters are updated at the end of the scan. Input parameters cannot change state in the middle of the scan whereas aliases are updated immediately.

And parameters are accessible outside of the program where they are defined unlike local (program) tags.

OG
  Reply With Quote
Old December 28th, 2017, 05:31 PM   #18
Aardwizz
Member
United Kingdom

Aardwizz is offline
 
Aardwizz's Avatar
 
Join Date: Dec 2017
Location: Swindon
Posts: 206
Interesting. My "new thing learned" for the day. Thanks, OG.

So moving the Alias tags from the Controller scope to a program ("IO") makes them only updated once per scan (of that Program in that Task)? And they'd be referencable anywhere (as "\IO.aliastagname")?

I'm not entirely sure how useful that would be, but then, I'm big on UDTs and AOIs, so I wind up "mapping" everything into those structures anyway, and so don't care if they're asynchronous or not; the I/O address is only used once in the program.

But I'll keep thinking about this, to see if there's a nifty way of exploiting this.

Again, thanks.
  Reply With Quote
Old December 28th, 2017, 11:49 PM   #19
RET
Member
United States

RET is offline
 
Join Date: Feb 2015
Location: Houston, TX
Posts: 224
Quote:
Originally Posted by rdrast View Post
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.
No, genius. You map i/o values to logical tags in a "mapping" program to logically named tags, and use those throughout the program.

If you ever have to move the i/o point, say for a bad channel, or whatever, if you use an alias, you're stuck. If you use simple mapping, it's no problem.

And if you ever use aliases in program for me, you'll be fired and blacklisted.
__________________
This statement is false.

Last edited by RET; December 28th, 2017 at 11:51 PM.
  Reply With Quote
Old December 29th, 2017, 08:54 AM   #20
Aardwizz
Member
United Kingdom

Aardwizz is offline
 
Aardwizz's Avatar
 
Join Date: Dec 2017
Location: Swindon
Posts: 206
Quote:
Originally Posted by RET View Post
And if you ever use aliases in program for me, you'll be fired and blacklisted.
Which is your right, just like if you were ever work for me, and don't program as I say -- which may include aliasing -- you would be let go. "He who pays the bills makes the rules."

Aliases are like hammers: they're tools. Faced with a nail, I'll use a hammer. Faced with a screw, I will not. To me, saying "no aliasing" is as idiotic as saying "always alias".

Or "always map", for that matter. The whole asynchronous thing is way over-hyped. 99% of the time, it doesn't matter. We tend to naturally buffer our inputs anyway: putting photoeyes behind On-timers and Off-timers, to ensure that they are actually seeing something, for example.

Output coils are only used once (without error, anyway), so don't need to be mapped.

HMI communication has ALWAYS been asynchronous to scan, and it bit me once -- once -- on a PLC-5 application. Once I understood what was going on, I rewrote the code so that it didn't matter. But we don't worry about buffering our HMI addresses, do we? Even if the same bit might be referenced in multiple places in the code? Not that I've seen, anyway.
  Reply With Quote
Old December 29th, 2017, 09:58 AM   #21
Paully's5.0
Lifetime Supporting Member
United States

Paully's5.0 is offline
 
Join Date: Jan 2006
Location: WI
Posts: 2,060
Quote:
Originally Posted by Aardwizz View Post
But we don't worry about buffering our HMI addresses, do we? Even if the same bit might be referenced in multiple places in the code? Not that I've seen, anyway.
Completely agree with your tool analogy, all tools in the chest are useful given their purpose. Usually it comes down to understanding, application and value add.

We might worry about efficient communications to/from the HMI (assuming Ethernet). Pack the HMI data into an array for communications purposes. Using this as an example highlights advantages of aliasing, mapping and HMI comms in respective areas.

A base array Digital_Inputs that might communicate to the HMI:

Code:
Local:1:I.1 --> Mapped to: Digital_Inputs[0] --> Alias of "DoorOpenProx" 
Local:1:I.2 --> Mapped to: Digital_Inputs[1] --> Alias of "DoorClosedProx"
Local:1:I.3 --> Mapped to: Digital_Inputs[2] --> Alias of "DoorLocked"
.
.
.
Local:1:I.n --> Mapped to: Digital_Inputs[n] --> Alias of "SomeUsefulName"
HMI/SCADA references the array, PLC program references the alias to make it a bit more readable.

Like you, my IO naturally buffers itself due to the usage of AOIs for device control, but I still have routines to "map" the IO as inputs into the respective AOI, both for input and output areas. The advantage is that the hardware tree is irrelevant until you actually require it for commissioning, allowing you to test and develop on whatever equipment you have at your disposal. Aliasing an IO point in this example doesn't provide any additional value.

To expand a bit, the alias names in my example would actually be AOI names as the AOI would provide additional logic functionality for the IO device:

Code:
DoorOpenProx.Digital_Input (mapped physical IO point)
DoorOpenProx.Debounce_Timer
DoorOpenProx.Simulation_Mode
DoorOpenProx.Simulation_State
DoorOpenProx.State (based on debounce timer and simulation)
I find the alias to be more useful for the corresponding AOI reference rather than the physical IO itself.

I think aliasing gets a bit of a bad rap because many just think of IO aliasing rather than aliasing to make your program a bit more structured and refined. Aliasing a program tag to a controller tag can save quite a bit of time if you are replicating many identical programs (say for example tank farm application).
  Reply With Quote
Old December 29th, 2017, 01:33 PM   #22
NetNathan
Lifetime Supporting Member
United States

NetNathan is offline
 
Join Date: Nov 2011
Location: Corona, CA
Posts: 1,480
I worked on a job that they used aliasing to link to original IO logic.
Can you imagine trying to work with "%I0105" that is actually "%I0090"??? If you do not have original logic you are more lost.
It would have been way easier to have a section where %I0090 is mapped to %I00105, and actually use text for input address.
__________________
****Control Freak****
Net is where I be and Nathan is me.
  Reply With Quote
Old December 29th, 2017, 02:22 PM   #23
Aardwizz
Member
United Kingdom

Aardwizz is offline
 
Aardwizz's Avatar
 
Join Date: Dec 2017
Location: Swindon
Posts: 206
I tend not to use mapping routine (although I'm in the minority there). I prefer to have a "YV107" routine, that does "one stop shopping" for all thing related to valve 107 -- interlocks, I/O links, AOI call, equipment module interface, or anything else that relates to that control module.

I generally don't alias the I/O, and merely map the Local:I tag to the AOI element.
But in larger systems, where the code is outstripping the hardware design, I put in "placeholder tags" for where the I/O will go -- just stand-alone BOOLs that I'll reference (in a separate Program) by simulation logic. Depending on when the official I/O list (or rather, I/O address assignment) gets done, I'll replace the placeholder with the real I/O, or I'll do a partial tag import, and turn those "placeholders" into aliases.

The latter is faster, since it comes straight out of Excel; but the former doesn't have extra tags that serve little useful purpose in the PLC.

Time & money usually override Engineering Quality. They shouldn't, didn't used to, and it's getting worse every year, bit by byte. Like I said, "he who pays the bills makes the rules".

I'm counting the days until retirement.
  Reply With Quote
Old January 2nd, 2018, 03:25 PM   #24
CapinWinky
Member
United States

CapinWinky is offline
 
CapinWinky's Avatar
 
Join Date: Aug 2011
Location: Virginia
Posts: 510
I say map the point to a structure (UDT in Rockwell speak) and do any processing in the mapping (adjust for NC/NO, filtering logic, etc) so the point in your IO structure is useful as-is. I usually make a structure that goes something like IO.DIn.MyDigitalInputName or IO.AO.MyAnalogOutputName and the autocomplete makes things go very quickly as far as generating the actual logic.

Aliasing has a lot of negatives, probably the biggest being you can't even do it until you have all the hardware picked out. It's a concept specific to Rockwell and how IO works in Logix/Studio5k so the whole paradigm doesn't work on most other platforms, while mapping to a structure can be done in some fashion on every major platform. In the past, tracking down the original point through the alias was problematic (largely fixed in newer versions making it easy to tell where aliases point and jump right to the source). It's also disjointed, you can't put aliases in a structure, making organizing code difficult.

The big advantage to Aliasing is that it is easy to do in comparison to making and mapping a UDT. This has more to do with the UDT editor being total **** than anything else, but you definitely can knock out aliasing much faster.

Just an FYI:
Aliases are not pointers, it's basically just a big list of find and replace. Because of this, it actually uses less processor power than mapping to a UDT because the value is never moved to a new memory location. However, if this is a noticeable effect on your project's performance, you need a better PLC.
__________________
-----------------------------------------------------
Cycling power is a sign of weakness.
  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 SDOs configuration and Variable mapping of the parameters Sohaib28 LIVE PLC Questions And Answers 1 October 11th, 2015 09:18 AM
RSLogix 5000 Multiple Aliases to Same Tag davidc100 LIVE PLC Questions And Answers 10 May 27th, 2014 09: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 03:55 AM
EtherNet/IP - Modbus Mapping Configuration (GC-XPORT-EIP-MB) puisan77 LIVE PLC Questions And Answers 1 May 7th, 2010 12:44 AM


All times are GMT -5. The time now is 07:36 AM.


.