So here's my situation, I have been tasked with modifying the logic to mimic a button press in the PLC.
You want an in-PLC emulator of some or all of the process. That is a great way to test things out. I, and I am sure many others, do this or something similar all the time.
I have two identical machines however one has a CLX PLC and one has a SLC, on the CLX side it's a no brainer because mapping was used, so my button press logic will just go in parallel with the physical input. On the SLC side that's not the case.
There is a reason the CLX program is like that: I/O is asynchronous, which means I:0.0/1 (or its equivalent in CLX, Local:I...) can change at any time, even during the program scan. I find it kind of funny that this asynchronous "feature" of CLX is most often the first thing overridden by an input map routine when writing a new program.
The physical input is used in over 20+ places. Rather than have to branch around each physical input I believe I have found a workaround and wanted to get advise before putting this in production. I have tested this on a micrologix. The rung has I:0/0 as an XIC bit and an OTE coil, I then branch around the XIC with another XIC using my binary bit. In testing, pressing the button turns on the input and releasing the button turns it back off and turning on the binary bit also turns on that input, turning off the binary bit turns off the input. It seems to work just fine but is it legal?
Define "legal."
It takes advantage of how the PLC actually works, so it's definitely a hack, but I still say it is legal. @Ron Beaufort's
bootcamp videos use that same technique to make the point that the user's PLC program does not read
external physical inputs and write
external physical outputs
directly, rather the program directly reads and writes bits in PLC
internal memory that the PLC operating system connect to the
external physical IO.
Can I get myself into a situation where this will come back to bite me?
I assume that is a rhetorical question
.
The most important thing is to add a clear and concise comment to such a rung.
Another thing to consider is whether or not you should ensure the PLC outputs are in a safe state if the Emulate_Mode bit (see next section) is actively overriding the inputs. If you are only trying to override this one input in the actual process, then that is on you; but if this is part of a full blown process emulation (see next section), then it might be wise to ensure an accidental trip of this override bit never effects chaos on the actual process.
For me, and probably many others, yes. In fact, it is often the reason for having an otherwise unnecessary input mapping routine in synchronous PLCs like SLC, MicroLogix, etc., which routines are often required for operational reasons in asynchronous PLCs like CLX.
Also note that doing this is roughly equivalent to using a "Force."
Note that more generally you could do
XIC B3:99/15 MOV B3:0.0 I:0.0
to have that emulate mode bit (B3:99/15) trigger emulating a full word's worth of input memory locations from that B3:0.0 word via a single rung; I did something very similar recently, and also added code to emulate the process i.e. to have the bits of word B3:0.0, and thus I:0.0, driven by logic that simulated the process, so could I test my process-controlling logic without the physical process.
The code shown in Post #1 assumes the normal situation in mimic/emulator mode is that the input value is 0; that may not be the actual case. So I would add another global bit called EMULATE_MODE, which chooses which source to use to write the input value used downstream of this rung.
