Mapping Inputs in Logix5000

Bering C Sparky

Lifetime Supporting Member
Join Date
Mar 2014
Location
Bering Sea, Alaska
Posts
1,117
Hello,
Just starting to learn the Logix5000 platform. (for those who have not seen my previous post)

What I have read says that the Logix5000 platform is Asynchronous and you should map your "Real" inputs onto seperate rungs at the beginning of your program and assign a "Internal" coil for each of them. Then use these internal coils as the inputs in your program.

I follow the logic in this but have a couple of questions.

1) Are most of you following this layout when you program in Logix5000?

2) The controller I am using has embedded High Speed Counters, would these also be considered inputs, same as say a DI and should you map these to internal coils also. Or because they are high speed this would not be a good thing to do?

(I will only be using each HSC input one time (in one place) in my program so it should not affect me one way or the other but I was just curious as to what would be the norm or correct)

3) When mapping out the inputs should you go ahead and map out all the inputs, even ones that you will not be using and just label them as spare so they are in the program and ready to be used when needed.
The processor will have to scan all of these each time, even though you are not using them. That seems a bit wasteful but this is what they have done in the example I am looking at.
Whats your opinion on this.

(My program will be relativly small so it probably will not affect me either way, again I am just curious as to what would be the norm or correct)

Thanks,
BCS
 
To me it is not a waste of time. It is time consuming but in the end it will save you time. If one of your inputs or outputs go bad it is a easy swap if you map your i/o. Make a alias tag configuration routine. Set your spares as dints. It also gives you a good troubleshooting ladder to check all your i/o.
 
Most of the time scan order doesn't matter, so the only time I map an IO point to another bit is when scan order matters.

Ultimately, it is up to you how you want to do it.

I do recommend using aliases to the IO module addresses, and name the alias something meaningful. Aliases are easy to retarget if the IO point changes later. I usually use the instrument tagname and a description, for example, FS506_TankLevel.
 
Thanks for the reply's,

When I read that you should map the Inputs it seemed a bit different from from what I have seen in the 500 platform. So just wanted to see what others are acutally doing.

(I know 5000 is different than 500, just trying to figure out what the differences and similarities are)

The Artical I am reading does say to just use alias for the outputs.

Here is a link to what I am looking at. Check it out when you have time and give your opinion on if it is on the mark or a load of Hooey.

http://www.contactandcoil.com/rslogix-5000-tutorial/

I am just reading what I can at the moment, playing around making a sample program to get used to the 5000 format and asking questions as I come to them before I start putting together my actual project.

Thanks all for your valuable input.
BCS
 
Aliasing is suggested a lot but there is a downside. Modifying the aliased I/O requires a download so it is not a simple remap. The majority of our customers run 24/7 and there is no time to stop a process for a download. It is for this reason that we avoid using aliases.

We do map I/O in separate routines without aliasing.
 
I do the same thing. Makes it really easy to reassign an input/output if it's ever required due to a faulty point (or because I made a mistake!), and makes doing your I/O checks dead easy.

Also, it's a great starting point for someone troubleshooting if they're unfamiliar with your code or just not very experienced with PLC's in general. If their motor won't start, and all they know is the output number, they just have to go to the digital outputs routine, which is all in card/numerical order, and scroll down to their output. From there they can cross reference backward as far as they need to to work out what's holding up their output.
 
Right on, I can see where that would be usefull.

Dont take this the wrong way, I am only asking questions to learn, but would'nt you be able to see the same thing in the Controller Tags / Monitor Tags.
All the I/O is listed in order there and you can see the value for each input and output there?

What stuck with me as a good reason to map the Inputs were these paragraphs from the link I provided earlier.

<H2>Understanding Asynchronous I/O
It’s important that you understand the difference between synchronous and asynchronous I/O in PLCs. If you come from the SLC 500 or PLC/5 world, you’ll be used to synchronous I/O, and that made your life a bit easier. In the PLC/3 world, I/O was asynchronous, and in a move that surprised many programmers, the ControlLogix/CompactLogix platform uses asynchronous I/O as well.
In a SLC 500, the PLC “scanned” the inputs by reading the state of the hardware and storing them in memory. Then it solved the logic. Then it “scanned” the outputs by copying the output coils to the actual hardware outputs. The important thing to realize is that the state of an input could never change during the logic solve. That meant you could write things like this:
Async-Example.png

…and you could be certain that Output 1 and Output 2 would never be on at the same time. However, with asynchronous I/O, our assumptions are wrong. Both Output 1 and Output 2 could be on during the same scan, or off during the same scan if Input 1 changes state between the time that it solves the first rung and it solves the second rung. Rare, but possible, and it leads to bugs that are intermittent and very hard to find, especially in logic that deals with critical timing, like data collection or communication logic.
</H2>


Those of you who do map your I/O would you also do this for the High Speed Counter Inputs?

What about analog? (not trying to be a Knowledgeable Donkey)
You cant really map analog to a coil.
Do you just Alias the analog or leave it as is?

I was kind of hoping that there would be some continuity and standard to how this platform is programed, but as if ofter the case, it seems there are many flavors to suit many different taste.

Thanks,
BCS
 
Aliasing is suggested a lot but there is a downside. Modifying the aliased I/O requires a download so it is not a simple remap. The majority of our customers run 24/7 and there is no time to stop a process for a download. It is for this reason that we avoid using aliases.

We do map I/O in separate routines without aliasing.

No, actually, no download required. EDIT the aliased tag, maybe put DEL in front of it's name. Define a new alias tag with the new physical address, delete the instruction with the tag marked DEL, assemble edits, then delete the old tag completely from the tag browser.
Of course, this implies that you only have a single point where you map the physical I/O to internal memory.

----------------

All that aside, I always map all of my tags on Logix platforms. For several reasons:
1) I can develop all of my logic before I know what the physical I/O will be.
2) I can run the program on a processor, with no I/O attached.
3) I can develop all HMI's live to the I/O Less processor.
4) I can write a test routine to simulate running the physical I/O.
5) I can assign the physical I/O on commissioning one at a time as they are verified.

All of my programs have routines for "Scan_Physical_Inputs" and "Update_Physical_Outputs". All mapping happens there. For simulation purposes, I add in "Scan_Inputs_Test" and "Update_Outputs_Test", which I can toggle to with a single bit to simulate whatever without the physical I/O in place.
 
BCS ...

no one is trying to intentionally mislead you – but not everyone here is talking about exactly the same thing ...

personally I draw a distinction between the terms "mapping" – and "buffering" – and even "packing" – which we haven't gotten around to yet ...

moving right along ...

if ALL that you want to do is to prevent the ASYNCHRONOUS scan demon from messing with the status of your input bits DURING the execution of the ladder logic, then "BUFFERING" the inputs (as opposed to "MAPPING" them) might be worth considering ... a demonstration of "buffering" (based on your examples) is attached ...

personally, I do NOT think that this "buffering" approach (or "mapping" either for that matter) is necessary for MOST programs – although in a few rare cases of HIGH-SPEED operations it might indeed be the solution to a very tricky troubleshooting or debugging problem ...

I can tell you that I used to see these techniques used in a lot of the programs sent in by my students’ companies ... nowadays – not so much ...

I think that the main reason that it used to be so popular was because the programmers were unfamiliar – and therefore afraid – of the asynchronous scan cycle ... to some guy who’s been programming PLC-5 and SLC-500 platforms for many years, this "weirdo" way of doing things with the ControlLogix and CompactLogix scan cycle was uncharted territory ... the "buffering" that I’ve demonstrated is ONE way to make the scary new asynchronous scan "behave itself" – and act like ladder logic did back in the good-old days ...

right or wrong – useful or not – that was the general perception which led to "buffering" – and to the similar "mapping" ideas that you’ve been discussing ...

so ...

the idea of "mapping" the inputs (and/or outputs) DOES have its advantages – and those advantages are what’s generally been discussed so far in this thread ...

and specifically, ONE of the advantages of "mapping" is to keep the asynchronous scan from fiddling around with the one/zero status of your input signals while the ladder logic is being executed ...

but ...

if ALL that you want to do is to simply keep the asynchronous demons at bay, then some programmers would use (and recommend) the "buffering" technique that I’ve attached – instead of the rung-by-rung "mapping" that’s been discussed so far ...

I’ll be honest ... most of the programs that I come across these days (and I see a LOT of programs) do NOT worry about "mapping" or about "buffering" ... once people get used to the asynchronous scan thing, they just seem to quit worrying about it and get on with their lives ...

consider this ...

when Bubba the operator mashes the Start button – does it really matter whether the processor runs through an "extra" scan cycle or two before the pump actually comes on? ... in most cases, the difference between the new asynchronous scan cycle – and the good old fashioned plain vanilla synchronous scan cycle – doesn’t amount to a hill of beans ...

BUT ... here’s a warning ...

in some high speed cases – it certainly COULD matter – so you definitely need to be aware of it ... but frankly, if I were you, I’d quit worrying about "mapping" and "buffering" for the immediate future ... you’ve got a LOT of other subjects to dig into ... you can always come back later and take another dose of this particular medicine ...

but then again – since we’re already talking about asynchronous scans ...

going deeper (much deeper) into this subject – you might want to take a quick look at the following link ... it doesn’t really have anything to do with the asynchronous scan’s effect on Input and Output signals – but I think that you’ll find it interesting ...

preview of the basic idea ... the systems that you’re working with are capable of changing data values right smack-dab in the middle of a math instruction ...

http://www.plctalk.net/qanda/showthread.php?p=376167&postcount=61

oh, and incidentally – to answer one of your specific questions - you could use the MOV command to "map" an analog input - if you so desired ...

party on ...

.
 
Last edited:
No, actually, no download required. EDIT the aliased tag, maybe put DEL in front of it's name. Define a new alias tag with the new physical address, delete the instruction with the tag marked DEL, assemble edits, then delete the old tag completely from the tag browser.
Of course, this implies that you only have a single point where you map the physical I/O to internal memory.

This is a work around. Yes you can rename, recreate, replace, and delete. We do this when we have a customer who insists on using aliasing. If HMI(s) are accessing this tag, now you can not rename without shutting down HMI(s). In my opinion, all of this hoopjumping is not worth aliasing to I/O.
 
Hi Ron,
Once again thank you for your input and time.

First let me say, I never thought anyone was trying to mislead me. It is just simply human nature that we tend to do things differently from one another. Thats what sets us apart from the animal kingdom - free will and a large brain. (and a set of thumbs of course)

I have already started mapping my Inputs in my test program so I will just keep going with that for the time being.

One question no one has touched yet is about the HSC can this high speed input be mapped to a internal coil?

Is the internal coil able to keep up with the speed of the HSC?

My guess would be yes it is, (but this is only a guess)
(the acc on a counter is controlled internally and it counts accurately,)
I will try it in my program today and see, but if anyone want to shed light on the answer for my piece of mind that would be great.

I know my questions are very elementary compaired to 99% being asked on the forum, but if I knew the answer I would not be asking the question.
I will get on a higher level with you guys one day. (God Willing)

I have been wanting to take your class on 5000 for some time now but dates dont work out. Looks like April or May might be my next shot when I have some time off.

Thanks again for sharing your knowledge and experience with me.

BCS
 
Last edited:

Similar Topics

We have an input map that executes at the top of every scan. In most cases we are using the MOV instruction to copy the input data into a human...
Replies
7
Views
2,198
Hi, I trying to figure, how to map local inputs to an array. I've attaches some images; the FROM image has the the local inputs (from 0 to 5...
Replies
9
Views
2,770
I have 3 racks and 15 Input Digital cards. Im Mapping Digital Inputs to the memory and memory to variable I map them like this : %I0.2.0 ---...
Replies
1
Views
2,451
Hi everyone, Kind of new at this, so we recently upgraded our 1769-l32e to the newer 5069-L320erm, i converted the file over and Verify the...
Replies
8
Views
361
Hello Guys I have an 1756-L73S Controller with a Fanuc Robot mapped as follows: - In 1756-EN2TR Slot 2 the Fanuc Robot is defined as an...
Replies
5
Views
189
Back
Top Bottom