Sign in to follow this  
Followers 0
mmd604

addressing inputs outputs

5 posts in this topic

I am curious I have a question I was looking at a program and the inputs and outputs  each had theyre own subroutine and the input subroutine had the inputs on one subroutine connected to a alias tag and then the outputs had the same the alias connected to the outputs.  What is the benefit if any to doing this?

Edited by mmd604

Share this post


Link to post
Share on other sites

I assume from what you describe you were looking at a ControlLogix or CompactLogix program.

The reason for coding this way has to do with how PLCs process data.

I present an oversimplified explanation below:

In the "early days" the PLC5 and SLC500 were "single-thread" processors and processed as described below:

1)  Read Inputs into Data Table

2)  Solve Logic reading and writing to the Data Table as needed

3)  Write Data Table to the Outputs

4)  Process Networked Communications

5)   Return to Step 1

The ControlLogix and CompactLogix PLCs are "multi-thread" processors and process as described below:

Thread 1

1)  Read Inputs into Data Table

2)  Write Data Table to Outputs

Thread 2

1)  Solve Logic reading and writing to Data Table as needed

2)  Process Networked Communications

As a result an input can be on at one rung and off at the next, making for unpredictable logic.

The use of alias in the logic routines and the way they are read and written makes the newer processor behave like the older one.

Share this post


Link to post
Share on other sites

Adding to Bob description, aliasing of inputs and outputs helps latter when an input or output point fails on a module.  You have a spare and can make one change to the alias and not affect any other logic.

Share this post


Link to post
Share on other sites

Adding more:  The modern Logix family supports up to 32 tasks (threads) with explicit prioritization, so some threads might interrupt others based on timing demands.

Share this post


Link to post
Share on other sites
14 hours ago, mmd604 said:

I am curious I have a question I was looking at a program and the inputs and outputs  each had theyre own subroutine and the input subroutine had the inputs on one subroutine connected to a alias tag and then the outputs had the same the alias connected to the outputs.  What is the benefit if any to doing this?

mapping I/O to intermediate data set adds to code length and consumes more memory but it also allows several possible advantages even on a single thread PLC. here are some ideas worth considering: 

1. Imagine world where things are done by teams. you are doing programming (and maybe working remotely) and someone else is doing panel wiring. so you may not have access to the real hardware or maybe you only have the PLC CPU but not rest of the I/O or fieldbus etc. then you can still easily write your code without consideration of the IO architecture, type or order of I/O modules etc. the mapping to physical I/O is simple step that can be done later on to work on whatever hardware is actually used. 

2. signal names can be more descriptive or easier to use. 

3. Imagine one of PLC inputs or outputs is failing and you do not have a replacement module at hand but there is a spare (unused) input or output point. of course you can move the I/O wire to that spare I/O point and make change in code. but if the address of that signal is used in 50 places in program, you would need to search and replace it in 50 places. this can be time consuming, error prone, and makes revisions/program comparisons more difficult. but if you are using intermediate variable, you just need to make program change in one one place. guess which option is preferable when production team is breathing down your neck? And what if this change only need to be temporary and will need to revert back but - you are still developing/testing and making other changes in your PLC programs? reverting things in one place is easy but comparison or in depth search/replace can be very time consuming and error prone. 

4. Imagine if one of the signals needs some conditioning (delay, inversion, debouncing, etc.). if that was a hardcoded I/O address used in 50 places in your program, you would have real mess on your hands. 

5. your code is a certain "black box" of certain functionality. you spend time developing and debugging it... imagine client decides that they already have plenty powerful PLC that controls entire plant and that same PLC will be used to run several of your "black boxes", you will just need to use different I/O, some of the I/O is local, some is remote. if your code is not using hardcoded I/O addresses, it is easy to create multiple instances of it and complete the task in no time.

etc. 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0