Is it possible to write a "1" into an input image table location? No input card installed. Wondering how to turn on an input bit using logic (without forcing). I only want to write to a single location.

You can use the force function in either a SLC or PLC to force the input address on. In a PLC5 I think you can just punch a one in the data table and it will stay there as long as there isn't a card installed.

In a SLC, the processor will fault if the configured card is absent. I don't know of a way around this.

In a SLC you can use an input address in an OTE or OTL instruction. I don't know about the PLC5.

Our distinguished colleague Ron Beaufort teaches this exercise in his PLC bootcamp to illustrate the fact that a PLC COPIES the inputs into an input image table. Then it solves the logic. Then it COPIES the output image table to the outputs. The input image table is NOT the actual inputs, its a read/write memory location that is updated with a copy of the actual inputs in between the scans. So if you write a 1 to a bit in the input image table on the first rung of the program, logic will solve as though the input was on, even if is is not actually on.

"Forcing" is a temporary override in memory of an Input data element or override of the logic program's result of an Output data element. It's a very specific thing and can only be done by the controller's operating system under instructions from the editing software. Forces can be globally turned on and off, and globally removed with the push of a button.

I had not considered putting an "overwrite" routine in the first program subroutine. It wouldn't work when interrupts or immediate input instructions were present, but it's a very clever technique.

If you didn't put the "override" routine in the first program subroutine, you'd have the input bits at different states at different times in the program, which would be troublesome.

I'll take back my assertion "but not by application logic" above, as it is demonstrably incorrect. Back to bootcamp for me.

Ken's right, we are not writing to the force table here, but if you don't have any IIMs then this method will work - as long as you are clear on exactly what it happening and make sure your program and subroutines are constructed accordingly.

The IO module must be configured, and unless you set the status bit the program will fault if the module is actually missing as already mentioned above.

Well, may be I missused the word "Forcing" in the context in which I needed to accomplish my task.

Basically, I want to be able to write a one or a zero in to an input image table location using logic.

Following OkiePC's example, I used an OTE instruction to turn on an input bit in the I/O image table. This was the first line in my main program. However, it keeps toggling on/of without holding a steady state of "ON" or a 1. I even tried adding an OTE latch instruction, but did not help the cause. Even tried the instruction at multiple locations (beg. and at end of Main routine) w/o any sucess. By the way, I am trying this with a PLC 5/40.

Is it actually toggling on and off in your program scan, or are you just seeing it toggle in Logix500? You computer reads the IO image table asynchronous to the progam scan, so the bit could still be on for the full portion of the progam solving part of the scan. Try this

Just a Warning - The input image in a controllogix 5000 is updated independant of the PLC scan (ie between one rung and the next)

PS I have sucessfully used simulation code in SLC500 where the simulation code changed the I table based on the O table using timers and basic logic - Great for testing the program and HMI in the office before turning up on site.

standard disclaimer: first of all let me say that I always feel slightly “uncomfortable” whenever I use Phil’s excellent forum to discuss the PLC training that I do - because I’m sure that there are some who consider any comments that I make to be “advertising” ... on the other hand, occasionally my PLC courses do get mentioned, and in many of those situations I feel that I should make SOME type of personal response ... I can assure you that my feelings will NOT be hurt if Phil decides to edit (or even completely remove) anything that follows ...

also ... I’ve been out of touch for a few days of vacation in Florida which is why I haven’t already responded to the questions posed in this thread ...

also ... the material that I’m posting here pertains to the Allen-Bradley PLC-5, SLC, and MicroLogix platforms ... specifically, it does NOT apply to the ControlLogix or CompactLogix platforms (for the reasons that MichaelG correctly pointed out in post #14) ...

from skyfox:

Quote:

Well, may be I missused the word "Forcing" in the context in which I needed to accomplish my task.

yes, your original terminology could be causing some of the confusion ... just to nail this idea down, my PLC classes generally last for five days ... I usually don’t let the students “force” anything until at least Wednesday or sometimes Thursday ... the reason is that until they understand EXACTLY how the PLC processor’s “scan sequence” works, the “force” feature can be quite confusing ...

personally I use the term “hijacking” for the operation that you’re looking for in this thread ... specifically, we can use a simple OTE rung to “hijack” the 1-or-0 status of any INPUT bit during the execution of the ladder logic rungs ... more specifically, we can MAKE the processor interpret the status of that “hijacked” input bit as either a 1 condition or as a 0 condition throughout the REST of the ladder logic rungs - REGARDLESS of the actual on/off condition of the field device itself ...

Quote:

Basically, I want to be able to write a one or a zero in to an input image table location using logic.

that’s not a problem ... in fact, I use exactly the same approach VERY often when I need to demonstrate to a customer how his program will react to a certain input - even when my lab equipment isn’t set up to duplicate the exact addresses of his input devices ...

here’s a quick example ... suppose that a customer has a rung which uses the field address I:014/12 for a start button ... I don’t normally have my lab equipment set up to duplicate that specific address - so I just drop in a temporary rung to “hijack” the status of that input bit ... to keep things neat and clean I usually put this new rung in a TEMPORARY subroutine file ... the customer doesn’t even need to see this part of the setup ... but now when I turn my lab’s simulator module switch (I:000/0) on and off, I can easily change the status of the original bit ... just make sure that your JSR rungs are set up so that you jump into the “hijack” routine BEFORE you jump into the original file ... or if you want to keep things simple, skip the “subroutine” idea and just put the “hijack” rung in the same program file as the original rung ... but again, be sure that the “hijack” rung is scanned BEFORE the original rung - or else the whole idea won’t work ...

and yes, I know how “weird” it looks to “control” an INPUT device with an OUTPUT instruction ... but it works - and it’s VERY educational ...

and now the puppet dances ... all we have to do is pull the (simulator) strings ...

and since “forces” were mentioned too, click herefor an interesting post which pits the brutal power of the mighty FORCE against the wimpy little OTE instruction ... guess who wins? ...

Quote:

Following OkiePC's example, I used an OTE instruction to turn on an input bit in the I/O image table. This was the first line in my main program. However, it keeps toggling on/of without holding a steady state of "ON" or a 1. ... By the way, I am trying this with a PLC 5/40.

probably what confused you here was that the status of the bit on the RSLogix5 display screen appeared to keep toggling on and off ... the “PLC-5/40” is REALLY important ...

secret handshake #1: with the PLC-5 platform (and RSLogix5) the screen “communicates” with the processor at RANDOM times during the ladder execution sequence ... so SOMETIMES the status of the “hijacked” bit might look ON - but SOMETIMES the status might look OFF ... but if you really understand how the rungs are scanned (their order of execution) then you can accurately forecast how the ladder logic will interpret the status of the “hijacked” bit - regardless of what you see on the display screen ...

secret handshake #2: with the SLC and MicroLogix platforms (and RSLogix500) the screen usually “communicates” with the processor at the VERY END of the ladder execution sequence ... so the status of the “hijacked” bit will NOT usually appear to “toggle” on the screen the way you witnessed ... and once again, if you really understand how the rungs are scanned (their order of execution) then you can accurately forecast how the ladder logic will interpret the status of the “hijacked” bit - regardless of what you see on the display screen ...

actually this “you-can’t-always-trust-the-screen” lesson is always a critical part of the classes that I teach ... some students have a LOT of trouble “unlearning” some of the misconceptions that they’ve picked up “along the way” ... usually their biggest problem is pure old-fashioned stubbornness ... “but I’ve THOUGHT it for so long that it MUST be right” ... sorry ... that approach doesn’t always work ...

Quote:

Perfect. It wasn't toggling. I was wrong! At least now I can setup a test routine just to toggle the bit's I need without modifying the existing logic.

This has been very educational and I appreciate the help I've gotten from all of you. Back to the boot camp post..........

and it looks like it’s all been taken care of ...

finally ... I do NOT recommend using this “hijacking” approach as a regular programming technique ... this will confuse the daylights out of a LOT of people - even some who have been successfully writing PLC programs for years ... it’s just too doggone WEIRD! ... but ... it really DOES have a lot of uses for demonstration and training purposes ... and (as long as SAFETY permits) it can sometimes come in handy for a TEMPORARY “quick-fix” to replace one field device with another ... again, I do NOT recommend it - I’m just trying to make you aware of what will happen IF (big IF) the “hijack” situation ever does arise ...

and REALLY finally ... thanks to Alaric for the kind compliments - and for the link in post #10 ... if anyone has any additional questions along these lines after reading that particular “epic” then please post again ... I’ll be glad to try to nail things down ... just between you and me, these particular ideas are ABSOLUTELY CRUCIAL to fully understanding PLCs and they are well worth the time it takes to master them ...