RSLogix 5000, Input Mapping

When programming in RSLogix 5000, I usually map all my inputs to bits to be used in the program. Since the IO is updated separate from the program scan, it could lead to Inputs or Outputs changing mid scan, and could cause unexpected or undesirable results with the logic.

The downside of this, is that you can not force the IO from the point of use in the program.

Unless I am mistaken, A tag aliased to an input is updated at the same time as the actual input, right? Not once per scan like a mapped bit in the logic would be?

Is there a way to make a non-aliased tag force-able?

What are you trying to do exactly?

If your force your physical (unbuffered IO), the buffered IO will get the "force" on the next scan of the PLC. So by forcing the physical IO you essentially are forcing the buffered IO. Granted, you have to navigate to the buffer logic to do so, which I assume is the hassle.

Personally I never use forces, all of my IO has a corresponding AOI for the device type (prox switch, valve, motor, level transmitter...etc). The AOI contains simulation logic, essentially a branch around the physical IO input to allows me to use the "toggle bit" option to mimic an IO force on/off.

I only use forces for testing purposes. Or temporary troubleshooting.

I map my inputs to bits to be used to remove the issues that can arise from Asynchronous IO scans in the 5000 family compared to the 500 family.

If I use a input address in a piece of logic, I can test/troubleshoot right from that point of use. If I use a mapped bit, it cannot be forced directly, and you have to navigate in the program to the real input address to force it.

Example of Mapped input:

XIC Local:1:I.Data.0 OTE INPUT[1].0

So Local:1:I.Data.0 can be forced On/Off where ever it is used. But INPUT[1].0 cannot be forced On/Off. I guess I could look into making a Mapping AOI that would allow simluations, but I would still need to navigate to the corresponding simulation bit to turn it on/off, instead of the "Input" bit being used in the program, right?

If you are just testing, don't call the JSR for the input mapping logic then you can just toggle the INPUT[1].0 bit.

If you are doing a combination of testing using the real world IO for feedback and forcing/simulating IO, then you have a bit more of a hassle on your hands. I suppose you could just delete the IO you wish to "toggle" from the input mapping, do your testing then put the logic back.

For me, most of my applications involve an HMI, so I can activate simulation mode for individual devices, and manipulate the on/off status from there as I test.

So, to answer your questions.

Tharon said:

......A tag aliased to an input is updated at the same time as the actual input, right?

Click to expand...

Correct

Tharon said:

Not once per scan like a mapped bit in the logic would be?

Click to expand...

Correct

Tharon said:

Is there a way to make a non-aliased tag force-able?

Click to expand...

No

OG

Tharon said:

When programming in RSLogix 5000, I usually map all my inputs to bits to be used in the program. Since the IO is updated separate from the program scan, it could lead to Inputs or Outputs changing mid scan, and could cause unexpected or undesirable results with the logic.

The downside of this, is that you can not force the IO from the point of use in the program.

Unless I am mistaken, A tag aliased to an input is updated at the same time as the actual input, right? Not once per scan like a mapped bit in the logic would be?

Is there a way to make a non-aliased tag force-able?

Click to expand...

Just a point of clarification...
An alias isn't really a tag at all. It's just an alternate name for the very same memory location. It's purely for the benefit of humans and doesn't really exist in the compiled code. So, it's not that it is updated at the same time as the base tag, it is the same tag.

I've changed my methods to suit the ControlLogix platform. I mostly use forces now during IO checkout and commissioning and still not all that often. There are usually better ways to accomplish temporary or troubleshooting tasks than what I can do on a SLC500 or a PLC5. If you use PlantPax, the maintenance mode gives you all sorts of ways to temporarily bypass malfunctioning hardware.

mellis said:

Just a point of clarification...
An alias isn't really a tag at all. It's just an alternate name for the very same memory location. It's purely for the benefit of humans and doesn't really exist in the compiled code. So, it's not that it is updated at the same time as the base tag, it is the same tag.

Click to expand...

To further clarify the bolded points above, an Alias tag IS a tag in the database, just like any other. The only difference with an alias tag is that it contains no data, just references the data contained in the base tag. You can "invalidate" an alias tag by deleting the base tag to which it refers, so it is not "the same tag", but a completely different one.

Referencing the alias tag of an I/O point will not "synchronise" your I/O to the controller scan cycle.

One way I've seen to overcome the asynchronous inputs is to handle every single one of them with a "debounce" subroutine or AOI, so that the physical input is only ever addressed once in the code. Many inputs needed debouncing anyway, so this was considered to be a workable solution, debouncing with a preset time of zero for inputs that didn't need it. Of course, forcing the inputs will also be effective