I/O Addressing

[Guest Electrode]

Have a Question about mapping on micrologix 1500. I have a program written by an outside source that has all the inputs showing up as binary numbers. Example: I:3/3 would actually be B17:3/3 in the program file. Description say it is a part present proximity for station 1. When I search my input image table the inputs for the expansion racks is not listed. The only listing I have is in Data File B17. Can this be crossed reference some how to show correct input addressing and why would this be configured this way. Elect.

[Chris Elston 79]

Can you register a user name on the board and then attach your program so we can look at it?

[gravitar 3]

So when you turn on I:3/3, you see B17:(whatever) go true? I can't think of ANY possibility other than a rung of code that has I:3/3 as a condition and in some way or another writes to the B17 address as the rung's output. Now.. If you're saying you turn on I:3/3, you see the corresponding light turn on on the card, but you do *NOT* see I:3/3 turn on in the input image table.. Umm. "There's the signpost up ahead.. Your next stop, The Twilight Zone!"

[Electrode 0]

Thanks for your reponse, I am totally confused here. I will have to attach the program in the morning I left it at work. Elect.

[Electrode 0]

What's crazy is the B bits are not used as aux bits, instead they are used proir to the output conditions. Example would be if I use xio in the start of the rung I don't I:0/1 instead I see B:17.0/1 which makes the rung true. I am not sure how this works and it's all new to me. Also there is no scanner module listed in the I/O config file. Thanks for your response, tomorrow I will post the file and we can look at it. I am sure it is something I overlooked or it is has a simple solution. Thanks Elect.

[jstolaruk 9]

Look for the following instructions: MOV I:0.0 B17:0 or COP I:0.0 B17:0 Basically some instruction that is copying the input image over to the binary file in a word/integer format. I've run into this at facilities that require all inputs and outputs to be mapped to binary files before using them.

[Wordman 0]

What would be the reasoning to do something like that. I've only done that with a Scanner's M Image table to cut down on scan time.

[Electrode 0]

Here is the File we are working on. The Lad File of interest are 15 thru 18 nest 1 - 4. Thanks Elect 2682_TOYOTABRACKET_RS_02_28_05_.RSS

[jstolaruk 9]

Check out the MVM instruction in file 13 rung 0. The input image from Input card slot 1 word 0 is copied to B16:0. The input image in B16 is cleared if there is not a fixture in the nest (b9:10/0). So any outputs in the ladder file 15 would likely be not executed. ladder files 16,17,18 are similar for each input word in slot 1. I've seen this before, its not uncommon, but its kind of clumsy to follow. Edited 7 Oct 2005 by jstolaruk

[Guest]

Greetings Electrode, regarding your specific question: some vendors do this to make the program code more "portable" ... basic idea: the programmer writes the program using nothing but interal (B) bits rather than using real-world inputs (I) and outputs (O) ... that way he doesn't have to worry about exactly what type of input and output modules will eventually be used - or about how they will eventually be arranged in the chassis ... time marches on ... eventually the electrician guys get through wiring up the machinery and installing the I/O modules ... they give the final list to the programmer - who just adds a few rungs (like your MVM rungs) to "map" the inputs and outputs to the already existing internal bits ... now everything is ready to go ... plus ... suppose that down the road someone (another customer perhaps) decides to use an SLC platform rather than a MicroLogix platform ... the already existing program code is already set to go ... just remap the real-world I/O to the internal bits ... note: personally I don't like this approach ... it usually just makes things harder for the maintenance guys to troubleshoot ... but many vendors like it - and use it ... incidentally, RSLogix has many "Search and Replace" tools that could make the same types of operations almost painless ...

[jstolaruk 9]

On another note, if I remember correctly the older Panelviews were unable to access the I/O image tables directly so that resulted in the programmer coping the images into binary or integer files so that the Panelview could display them. Edited 7 Oct 2005 by jstolaruk

[Guest HalBishop]

Intouch I/O servers were not able to access SLC I/O data tables. (they like octal not decimal). This is why we used this "bit cache" to allow the I/O server to monitor real world status. Edited 7 Oct 2005 by HalBishop

[Electrode 0]

Thanks Guys for your help, It makes a lot more sense now that you guys explained why this is done. I can now see the benefit of mapping it this way from the programing end. but I also agree with you Ron that it will cause maintenance more work in troubleshooting and equipment downtime. You guy are awesome! Thanks again for clearing this up for me. Have a Great Weekend. Elect.