RSLogix 500 - I/O mapping question

toads

Member
Join Date
Sep 2019
Location
Terra Firma
Posts
4
Hi all,

I'm using a Micrologix 1400 PLC. I have 8 physical DI's, 4 DO, 4 AI's that will be radio transmitted to a DCS Master. The DCS is a Bailey - and accepts data only in Words.

So, the I/O will need to be packed into 16 bit registers and then transmitted.

I'm new to RSLogix 500, i've figured that the Input register is where I add info about my physical DI, F8-Float is my AI, Oo - Outputs etc etc.

To put these into a word then, do I use the MOV command?
source = DI/AI/etc
Dest = N7 ?

Or what is the best way to do this?

Appreciate any help
 
What are your intentions on handling the AI's? Are you going to send as REALS (2 words) or as Words with implied decimals?

Assuming you want to use REALS, then the COP command is the one to use,
COP F8:0 Destination N7:10 Length 2.
This will populate N7:10 & 11, so the next COP would be to N7:12, the BAILEY system will have to put the 2 words back together.

OR you could multiply F8:0 x 10 to N:10, as long as you are less than 32767, then on the Bailey Side, multiply by 0.1 to get one decimal.


For the IO just MOV the INput OUTput Words to N7:0
 
I'm treating all Inputs from analog and digital the same. Digitals are in bits - taking up Word N7:0
Analogs are words each.

Does look ok?

plc.jpg
 
Why not just use an MOV or COP command
I:0 to N7:0 it will move all the bits in 1 command
and it works for both Digital and Analog inputs
 
A "Word" of Caution...

toads said:
Hi all,

I'm using a Micrologix 1400 PLC. I have 8 physical DI's, 4 DO, 4 AI's that will be radio transmitted to a DCS Master. The DCS is a Bailey - and accepts data only in Words.

So, the I/O will need to be packed into 16 bit registers and then transmitted.

I'm new to RSLogix 500, i've figured that the Input register is where I add info about my physical DI, F8-Float is my AI, Oo - Outputs etc etc....

Hi & Welcome to the Forum!

Seeing as you've mentioned being new to the RSLogix 500 software environment, and hence I assume you may also be new to the controllers that are programmed using this software? -

I notice you have made the assignment "LAD 2 - DIGITALS" and "LAD 3 - ANALOGS", which is fine in itself. However, you should be aware that "LAD 2", is a default ladder routine which is predefined whenever you create a new project in RSLogix 500. As LAD 2 is special, it is always automatically executed (logic is scanned) when the controller is in Run Mode. You may have already noticed LAD 2 was already there when you first created the project?

You may then create further user-defined ladder routines according to the program structure you wish to use. So "LAD 3 - ANALOGS" was then user-defined to handle your AI data. All fine so far. However, LAD 3, or subsequent user-defined ladder routines, are not automatically scanned when the controller is in Run Mode. You must execute a specific instruction in the special LAD 2 routine for each subsequent ladder routine that has been user-defined in the program (standard program type).

To execute LAD 3, you must place a "JSR" instruction (Jump to Subroutine) on a rung in LAD 2. Within this instruction you will assign the number "3" for the the "U:" operand, which denotes ladder routine "3". Where you place this JSR rung in LAD 2 determines the order in which the logic for your entire program is executed.

Example: If you place the JSR instruction on LAD 2: Rung 0000 then when the controller goes to Run Mode it will start executing at LAD 2: Rung 0000 and immediately jump to LAD 3: Rung 0000 and execute your AI logic. Once the execution reaches the END instruction in LAD 3 it will automatically return to LAD 2 and carry on executing at Rung 0001 and then execute your DI logic. When the END instruction is reached for LAD 2, the scan cycle will begin executing at LAD 2: Rung 0000 once again, and so on.

If you do not have a LAD 3 JSR, and have not actually run this program yet in the controller then you may not yet have noticed your LAD 3 routine will not execute. If you already have a JSR instruction in LAD 2, which is pointing at LAD 3, then of course, ignore my fundamental lesson and my apologies if I have incorrectly assumed you were unaware of the need to use the JSR instruction.

toads said:
...To put these into a word then, do I use the MOV command?
source = DI/AI/etc
Dest = N7
?

Or what is the best way to do this?

Appreciate any help

Ken Moore said:
...For the IO just MOV the INput OUTput Words to N7:0

GaryS said:
Why not just use an MOV or COP command
I:0 to N7:0 it will move all the bits in 1 command
and it works for both Digital and Analog inputs

Folks,

Just a "word" of caution here as you all appear to be looking at the same solution for the digital inputs...

Remember, these are embedded digital inputs we are dealing with here (or a digital input card if using expansion on the MicroLogix 1400). It may not be so much a "complete" user-defined word of data that needs to be mapped to another user-defined word of data. As these are actual digital inputs, which do indeed use certain "module-defined" sequential addressing (Example: I:0/0 - I:0/15), we must consider that, for this particular application, only the first 8 of the digital inputs appear to be required to be mapped for transmission to the DCS.

If we execute mapping using a MOV, for instance, of I:0.0 (16-bit word of digital input data) to N7:0 (16-bit word of user data), then bits N7:0/0 - N7:0/7 will be correctly populated with the input data required for those first 8 digital inputs. However, N7:0/8 - N7:0/15 will also be populated with digital input data for inputs I:0/8 - I:0/15. This data may not be required, and by including it in the mapping when transmitting the entire N7:0 16-bit word to the DCS, it "may" corrupt the intended data value, or it may of course not. It depends on how the digital input data is parsed out of the transmitted word. If only the bits required are parsed out and the "other" data ignored, then perhaps that is fine. Also, if only the first 8 digital inputs are used for this application and the remainder are spare, then the spare digital inputs may normally have a value of "0", so again, perhaps nothing to worry about. But what if some of the spare inputs were to be used in the future, and it then does matter that their now changing values start having an impact on the N7:0 word value being sent to the DCS? Just something to be wary of, that's all.

Another possible solution I could suggest is to Mask Move the first 8 digital input registers, ignoring the values of the remaining input registers -

MVM instruction (Masked Move):

Source: I:0.0 (16-bit input word)
Mask: N7:50 (user-defined mask word - constant value = 255)
Dest: N7:0 (user-defined data word - to store mapped data)

Using a Masked Move (MVM) instruction, we can filter out whichever data bits we do not want to pass through the mask to the destination. By setting the example N7:50 mask word to a constant value of 255, we are turning on the first 8 bits in the filter for the MVM instruction. In binary, N7:50 looks like this:

bit 15>0000000011111111<bit 0

Example MVM in binary where all 16 digital inputs are used and have various Boolean values:

_Source:I:0.0 = bit 15>11101100 10101101<bit 0 / ignore last 8 inputs / move first 8 inputs
Mask:N7:50 = bit 15>0000000011111111<bit 0 / pass first 8 inputs only
_Dest:N7:0 = bit 15>0000000010101101<bit 0 / only first 8 inputs passed from source

Of course, if it is your intention that the entire I:0.0 word of digital input data be mapped to the DCS, forevermore, then yes, by all means map the full input word to the integer register and again, just ignore me (note: there are actually 20 digital inputs available - the 4 others beyond the 16 we've mentioned are module-defined at I:0/16 - I:0/19 in the next word).

Cleverness aside - as best practice, I would follow the rule of thumb of only mapping the required data and not involve other address registers, even if they may not be having a negative impact on the end result. It's just cleaner and neater programming, and less confusing, in my opinion. Often, the best way to achieve this is actually the "brute force" rung-by-rung method you are already implementing.

Ken's good advice on handling the Float (REAL) data needs little adding to so I won't get "too" involved here, but one thing I do notice though, if I may, is that in your N7 file you have assigned each mapped analog value to a single 16-bit integer...

Example:
FIT23276_MBUS = N7:1
AIT23277_MBUS = N7:2
...and so on.

If the analog values you are mapping are originally stored in Float (Floating decimal point) registers, which are 32-bit registers, then "ideally" you will require 2 consecutive 16-bit integers in order to map these 32-bit values, as Ken is pointing out to you. "Ideally", as it may not be essential you do so here. More on that in a minute.

Ideal example:
FIT23276_MBUS = N7:1 & N7:2
AIT23277_MBUS = N7:3 & N7:4
...and so on.

You can, as I'm sure you are aware, increase the number of elements for the N7 data file from 10 to say 20 elements (words) and you would then have enough integers to expand the assignment.

Why "ideally"? - You cannot move (convert) a Float value to a single integer value indefinitely. Integers may only store whole numbers between -32,768 & +32,767. If a Float value exceeds these boundaries while converting to a single integer then the processor will fault and flag a "Math Overflow Trap" (S:5/0).

As you appear to be working with flow rates and speeds, etc., it may be possible that your expected real time values will not exceed +32,767, for example, and converting Floats to single integers will be just fine. But just in case it may not be fine, you are now a little more informed.

Remember...

MOV instructions convert dissimilar data types between Source and Destination
COP instructions simply copy the bit-pattern from Source to Destination

So what Ken is advising is you COP the Floats to 2 x integers which simply copies the bit-pattern for the 32-bit register into 2 consecutive 16-bit registers in a raw format, so to speak. The values now stored in the individual integers are more or less meaningless in this format. When the DCS pulls in the 2 integers, it will need to be able to convert the 2 raw integers back into a meaningful 32-bit Floating point data value. This is usually achievable on most DCS systems but may involve both word swapping and data conversion, depending on whether the system is Big-endian or Little-endian.

Also note that by converting a Floating point value, which may contain a fractional portion (Example: 32,500.561) to a single integer which only stores whole numbers, there will always be rounding applied (example rounds up to 32,501). Depending on the level of accuracy required for your application, this may also be worth considering.

Regards,
George
 
Last edited:
Thanks Geospark, i've taken that onboard. It's also made everything a lot more simple.
See attached my new program code:

My only question is - regarding Analog Output mapped through Modbus to AO. I have just used the MOV function. Is this correct?

FhWHXer.jpg
 
Last edited:
toads said:
Thanks Geospark, i've taken that onboard. It's also made everything a lot more simple.
See attached my new program code...

Looks better. If you are happy with the structure of your program and your scaled values, etc., I won't question or guide you any further on that.

toads said:
...My only question is - regarding Analog Output mapped through Modbus to AO. I have just used the MOV function. Is this correct?

If we recall your opening post...

toads said:
...I have 8 physical DI's, 4 DO, 4 AI's that will be radio transmitted to a DCS Master...

...i've figured that the Input register is where I add info about my physical DI, F8-Float is my AI, Oo - Outputs...

...you had not originally mentioned having any "AO" to deal with here? You had only mentioned knowing that the "Oo" are your outputs.

Are you now saying you have analog outputs being used on this controller going directly to field devices? And that their values are coming in through Modbus from the DCS, or somewhere?

If so, then as you may be aware, there are 2 analog outputs available on the controller. You have mapped (MOV) N7:5 and N7:6 to O:0.1 and O:0.2 respectively. These are not the correct Output words.

Analog Output Channel 0 = Output Word 4 - O:0.4
Analog Output Channel 1 = Output Word 5 - O:0.5

If you do not have any physical analog output devices connected to these channels, then you should not need to map from the N7:x registers to the physical output (O:0.x) addresses just to get the data "out" of the controller. The N7:x registers should be directly usable when parameterizing your communications programming, which I assume is using messaging (MSG) configured for Modbus?

If I've got your intentions mixed up a bit here then please do explain as clearly as you can.

Regards,
George
 
Last edited:
Yep sorry, I missed that in my opening post. I have 2 x AO's. These are coming from the DCS via modbus.

I have now moved those into the correct Output Word. My question is, what difference does it make moving O:0.1 and O:0.2 to O:0.4 and O:0.5 ?

You're a legend Geospark, thanks.
 
IO, IO, it's off to work we go...

toads said:
Yep sorry, I missed that in my opening post. I have 2 x AO's. These are coming from the DCS via modbus....I have now moved those into the correct Output Word...

OK, that's fine my friend.

toads said:
...My question is, what difference does it make moving O:0.1 and O:0.2 to O:0.4 and O:0.5 ?

All the difference in the world.

Short answer - because those addresses have been pre-defined by the manufacturer for these two specific analog outputs.

Less shorter answer - the different model MicroLogix 1400 controllers come with different base configurations for the embedded I/O points. All models support 32 discrete I/O points (20 inputs/12 outputs) but vary in the types of I/O provided (DC, AC, fast, normal, relay). Some models provide additional analog I/O (4 inputs/2 outputs). Because the embedded I/O density can vary, the maximum number of Data File elements (words) required for the base I/O is default present in all MicroLogix 1400 projects we create, whether or not it is required. For the Input Data File this is 8 words (0-7) and for the Output Data File this is 6 words (0-5). When we select/configure/read in the Base Type of the model that we are using, the pre-defined words in the Data Files are automatically updated to reflect the I/O that is available. For an analog base, the Input Data File will update with words 4-7 pre-defined for analog input channels 0-3, respectively. The Output Data File will update with words 4 and 5 pre-defined for analog outputs 0 and 1, respectively. You cannot change this assignment. It is locked by the manufacturer.

Let's find out if your project currently knows whether the controller base you are using supports analog I/O or not?...

Open your Input Data File and expand the window out to the right so you can fully read the descriptions for all the words. Every I:0.x word should likely have at least the following description...

Bul.1766 MicroLogix 1400 Series B

However, if your base is configured as an analog base then words I:0.4 - I:0.7 should also be appended as follows...

I:0.4 - Bul.1766 MicroLogix 1400 Series B-Analog Inp 0
I:0.5 - Bul.1766 MicroLogix 1400 Series B-Analog Inp 1
I:0.6 - Bul.1766 MicroLogix 1400 Series B-Analog Inp 2
I:0.7 - Bul.1766 MicroLogix 1400 Series B-Analog Inp 3

Likewise, the Output Data File should have the following for O:0.4 and O:0.5

O:0.4 - Bul.1766 MicroLogix 1400 Series B-Analog Out 0
O:0.5 - Bul.1766 MicroLogix 1400 Series B-Analog Out 1

Example: (Please ignore the addressing for the 32 point expansion input module for now)
ML1400-Analog%20Base.jpg


If the appended analog channel descriptions are not present, then currently the selected base in the project is most likely at the default of "Any Discrete Base" under the IO Configuration...

ML1400-Default%20Base.jpg


If at default, change it to "Any Analog Base", or to whichever model base you are using, if you happen to know it (Example: 1766-L32BXBA). Apply this change and the Data Files will update with the analog channel descriptions. This base selection will usually sort itself out when you are actually connected to and downloading or uploading to the controller. But by setting the base type manually in advance, a user will then know which pre-defined addresses are related to the analog I/O when programming. Especially for a novice who, without the descriptions, may not know off by heart which addresses relate to the analog I/O.

Moving on...

One of the reasons I had asked you if you were OK with your scaled analog input values was because I had noticed the input addresses you had assigned as the Input operand on your SCP instructions...

From your last screenshot, I can see I:0.1, I:0.2, I:0.3, I:1.1

I don't know if you have actually put your logic "to work" yet (I'm assuming not?), so it's very possibly you do not realize that at program execution, you will most likely not see what you are expecting, or perhaps worse, something might happen in the "real world" that you definitely were not expecting?

From the above, we now know that the proper addresses for the 4 analog input channels are as follows...

I:0.4 - Analog Input Channel 0
I:0.5 - Analog Input Channel 1
I:0.6 - Analog Input Channel 2
I:0.7 - Analog Input Channel 3

These are the pre-defined Data File addresses that you must use to read the analog input values from and scale to your N7 Modbus registers.

Just to point this out...

If we look at the IO configuration screenshot above, we can see that the MicroLogix 1400 is designated as Slot "0" within the "chassis". Even though this controller type is generally described as being an integrated PLC system i.e. has embedded I/O, communications, etc., it also supports expansion I/O modules and so it may also be classed as somewhat of a modular PLC system i.e. slot based chassis system with separate modules for processor, expansion I/O, communications, etc. As the controller is designated as being in Slot 0 of the chassis, the embedded input and output Data File addresses are also designated as being in Slot 0. We can see this from both Data Files in the first screenshot above.

You can now focus on the 32 point expansion input module...

If we note in the example IO Configuration above that there is also a 32 point expansion input module (1762-IQ32T). This module is positioned and connected directly to the right of the controller base and so it is automatically designated as being in Slot 1. Therefore, the input Data File will designate both 16-bit word addresses for the 32 input points as being in Slot 1.

We can clearly see that this first expansion input module, which has 32 points, is being automatically designated the word addresses I:1.0 and I:1.1 in the input Data File. The next module that would be added to the right would automatically be designated as Slot 2, and so on up to the maximum 7 expansion modules support by the MicroLogix 1400 controller.

Of the input addresses you selected for your SCP instructions...

I:0.1
I:0.2
I:0.3
I:1.1

...and starting at the bottom...

Word address I:1.1 is designated as the second half of the Slot 1 expansion input module (inputs 16 - 31). This would or could never be an embedded analog input address. As you have this word address available in your project, do you by chance have one or more expansion modules added to this controller project? If so, does it or they exist in the real world? If so, then depending on the module type and its usage, the word value of the data in this address could be anything. Certainly not the analog value you would be expecting, I'm sure? This word address being incorrectly assigned as an analog input to the SCP could result in at least erroneous data, or at worst erroneous data which could render something in the real world as uncontrollable. However, I am also considering that you "might" have an analog input module added in Slot 1?

Next...

I:0.2 and I:0.3:- These again are not designated analog input word addresses but are the least likely to cause more than blank or erroneous data as they are not used.

Lastly...

Word address I:0.1 - First off, word address I:0.0 stores the first 16 discrete embedded inputs (I:0/0 - I:0/15). Then, word address I:0.1 stores the last four of the 20 discrete embedded inputs (I:0/16 - I:0/19) with the remainder of the word unused (I:0/20 - I:0/31). So, once again, this word address could potential have a value based on the usage of the discrete inputs and if incorrectly used in an SCP instruction, as an assumed analog input, it could also result in undesired effects.

Just some things for you to consider and change if my assessment of your project, at the time of those screenshots, is correct.

Seeing as you are relatively new to RSLogix 500 programming, the following is just a fundamental guide on some of the addressing syntax used as I often see folks mixed up between the representation of a word address and a bit address...

Example:
I:0.0 = Word address
I:0/0 = bit address

The obvious difference is the "." and the "/"...

For the word addressing...

Example: I:0.0
I = Input address
: = Slot delimiter
0 = Slot number
. = Word delimiter
0 = Word number

This is Word 0 in Slot 0 of the Input Data File

For the bit addressing...

Example: I:0/0
I = Input address
: = Slot delimiter
0 = Slot number
/ = Bit delimiter
0 - Bit number

This is Bit 0 in Slot 0 of the Input Data File

You may also see, for example, the same input bit address including the Word number...

Example: I:0.0/0
I = Input address
: = Slot delimiter
0 = Slot number
. = Word delimiter
0 = Word number
/ = Bit delimiter
0 - Bit number

This is Bit 0 in Word 0 in Slot 0 of the Input Data File

Questions?...👨🏻‍🏫

Code:
Please hold the right scroll arrow down 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 HeHe, what are you doing all the way over here silly?
 
Last edited:

Similar Topics

Hello, Haven't been on in a while. I need to generate a bit level pdf of the I/O for RSLogix 500. I can generate a report but it just shows the...
Replies
1
Views
110
I would like to copy register N61:131 thru N61:147 into ST252:0 I keep failing What happens is I copy into ST252:0,1, 2 etc. What am i missing...
Replies
18
Views
482
I'm trying to fix a mess of code on an older machine that's running a Micrologix 1400 and an RS232 ASCII barcode scanner. The previous guy had...
Replies
3
Views
304
I'm not super familiar with the Micrologix line of processors, but I am pretty familiar with RSLogix 500. I'm trying to simply copy a string to...
Replies
4
Views
258
I have been using RSLogix 500 version 9 for a long time now. I am about to need to move to something else Rockwell related to cover the...
Replies
8
Views
907
Back
Top Bottom