SLC - Using an output instruction to fire an input

Processor: 1747-L553B/C
Software: RSLogix 500 Pro v7.3

Ladder Rung Example:
----| B3:0/0 |-------( I:2.0/0 )---

Question!
Now, barring a long explanation of why I need this done, under what conditions would the above logic actually work? Is it even possible to "fire" an input, as it were, using ladder logic, if I have "disabled" that specific slot under the I/O tab of Processor Status (in Logix)?

Unless there's a way to use logic to turn on a ".Force" bit I don't know about...

I guess that's like two questions.

I recall seeing this once in someone else's program. It should *work* then again, there's absolutely no reason to do this I can think of unless, of course, the person have no idea what he/she is doing.

Your rung will change the state of the memory location for I:2.0/0.

It will remain in that state* until after the program scan and will be updated during the I/O scan, at which time it may change again, depending on the real world condition associated with that address.

*unless there is an instruction that forces an I/O update mid-scan...search your prgram for any IIM instructions

Paul

Hmm. That is tentatively good news. Thank you!

If you disable the physical I/O in the configuration, then it should work as expected. We do this occasionally in our office to simulate I/O.

Yeah, that's the effect I'm shooting for. It's easier to dry run the system if I can just simulate a few inputs, as opposed to changing the main routine.

IMHO this is bad practice. Use internal bits (i.e. B3:0/0) for this testing. Its to easy to forget and leave one of those testing rungs in.

Some programmers map all inputs to "B" data files anyway then use the binary bits for there program. For testing you can then just disable the mapping during the testing and toggle the bits as needed. When done enable the mapping.

I agree with Mickey. Perhaps you should take a look at using Debug files and the RSEmulate 500 software for testing. This is precisely what you use it for.

But if you must, then as suggested, go into the Processor Status and disable the slot for the input module. This will prevent the I/O update from changing your Input data.

OG

harryting said:

I recall seeing this once in someone else's program. It should *work* then again, there's absolutely no reason to do this I can think of unless, of course, the person have no idea what he/she is doing.

Click to expand...

I have seen it done on a Siemens PLC to override an input, to either force on or off (old S5 could not force), used very infrequently to overcome a hardware failure to enable the rest of the logic to work.

With Siemens its easy as the I/O is updated only between scans, with AB it would be difficult as you do not know when the I/O will be updated in relation to the scan.

PeterW said:

With Siemens its easy as the I/O is updated only between scans, with AB it would be difficult as you do not know when the I/O will be updated in relation to the scan.

Click to expand...

From the catalog number the OP gave us he has a SLC5/05, the input update happens at the start of the scan just like the Siemens above. Your statement would be true if he had the ControLogix or CompactLogix platform.

ah well, not memorised the catalogue numbers yet, there's still hope then

Mickey said:

IMHO this is bad practice. Use internal bits (i.e. B3:0/0) for this testing. Its to easy to forget and leave one of those testing rungs in.

Some programmers map all inputs to "B" data files anyway then use the binary bits for there program. For testing you can then just disable the mapping during the testing and toggle the bits as needed. When done enable the mapping.

Click to expand...

That is my standard way of doing simulation in a ControlLogix, but I have other reasons to map I/O in a ControlLogix.

If you can get the end user to agree to mapping the I/O in a SLC system, then I agree that is an elegant way to do simulation. The problem is that the end users I work with see little benefit after the system is installed. All the benefit is to the programmer for simulation, they get left with an extra layer of addresses. They would prefer a simpler program style that uses real I/O addresses.

Disabling the I/O and adding simulation logic in a separate program file is a good method for SLC. The simulation technique doesn't dictate the programming style. "Forgetting" to delete the simulation program file is not an issue. I certainly would not recommend scattering simulation logic throughout the program.

OperaGhost said:

I agree with Mickey. Perhaps you should take a look at using Debug files and the RSEmulate 500 software for testing. This is precisely what you use it for.

Click to expand...

RSEmulate500 has its place. It's on my machine and I use it to debug sections of logic. But it has a lot of limitations too. Messaging, PID, HMI comms, all these things either don't work at all or are more complicated to simulate than they are to do with a real processor. I once did accumulated runtime based lead-lag on a cooling tower with three two-speed fans, emulator was great for that.