Time input must be on

How long does a input have to be on to be recognized by the SLC PLC
is there a minimum at all or am i worring to much

A SLC generally has a minimum on time of 3ms for a DC input or about 18ms for an AC input.
Check the specs for you input card.

SeanLee said:

How long does a input have to be on to be recognized by the SLC PLC
is there a minimum at all or am i worring to much

Click to expand...

There should be a response time indicated in the specifications for the input module. A DC module would usually have a response OFF to ON <15ms. AC inputs might be a little longer ~30ms. Check your manual.

First I will say I dont have a clue

PLEASE CORRECT ME IF WRONG. The response time is the time it takes for the input to ....I dont want to say turn on...be available for the process may be a better term..BUT...doesnt scan time have a bearing how long an input must be "available"? Technically it isnt "ON" until its scanned...correct?

Example: Input is activated, 15ms later its available to program...program scan is past that point in ladder, scan is 50ms. Wouldnt that mean the input has to be active for approximately the next 50ms?

This is how I determined it to be but please correct me if I am wrong. I think I have dealt with issue along these lines.

Rule of thumb

Rule: Input must be on at least twice as long as the scan time.

In Ron's example of 50ms, I would not try and use an input signal that is less than 100ms long.

Were this can get you into trouble is trying to count pulses with a standard input card.

yes, as Ron and Ken said ... not only does the internal circuitry of the module have to react to the input signal, but the processor has to have time to “see” the input and update the ON/OFF status of a bit on the input table ...



so the “reaction time” of the module has a lot to do with it ... but so does the length of the processor’s scan time ...



specifically, it’s entirely possible to have the processor “miss” seeing a change in the status of an input which is only ON (or OFF) for a very brief time ... and the longer the scan time, then the worse the problem can become ...



as a practical note: some applications may benefit from the use of one or more judiciously placed IIMs (Immediate Input with Mask - for SLC-500) or IINs (Immediate Input - for PLC-5) ...

I've never had an issue with this, but I thought the response time was the time it took for the signal to reach the image register, which would then be held & picked up by the next scan. So if you had a scan of 100ms and the off to on response time is 15ms then it would be seen by the next scan only as the image is cleard at the end of each scan.

That's my understanding of it. Maybe one of the forum members who work for the manufactures can verify or correct me.

There are two components to take into consideration.

First there is the filter time of the input module. That's the time that the signal must be in the ON state before the input module will report it to the PLC as being ON.

Second is the time between updates from the module to the PLC. In conventional input modules this is roughly equal to the PLC's overall scan time. If the PLC has a scan time of 25 milliseconds, that means that once in that 25 millisecond period the PLC gets around to asking the input module to report the status of its inputs.

An exception to that would be an input module with interrupt capabilities. In that case, as soon as the module recognized that the input was ON, it would send the interrupt signal to the PLC. The PLC would then suspend execution of whatever it was doing (solving ladder logic for example) and read the status of the input.

Another exception would be the execution of an "Immediate I/O" function in ladder logic. When the PLC executes one of those, it reads all or some of the inputs as directed by the function.

and it can get even weirder ... here’s an interesting little experiment for an Allen-Bradley PLC-5 ...



suppose that we take a 16-point input module and jumper all 16 input terminals together ... then we tie the one resulting input wire to one single pushbutton ...



then we enter this “test” program into a SPARE processor ... do not try this with a production machine ... the program is designed to cause a fault ...








note: if you want to try this with an SLC-500 processor, the RSLogix500 software probably won’t let you enter the Jump to a non-existent label ... so try “Latching” bit S:5/0 to cause an “on-demand” fault ...



so once everything is ready and the stage is set, go ahead and push the button ... what do you expect to see? ... all 16 inputs turned ON at one time? ... should be, right? ... because every single one of them is tied to all of the others - and they are all controlled by the same single button, right? ... so then all 16 bits in N7:0 should be set to ones, right? ... go ahead - try it ... then reset the fault and try it a few more times ... I think you’ll find the random nature of this beast to be quite interesting ...



luckily most programmers never have to worry about this type of “input-by-input” timing issue ... but in some rare “fast acting - timing critical” situations this can turn into a very ugly experience ... so just what type of application is our friend SeanLee working on anyway? ...

Very intersting Ron. It makes sense, but I had never given it any thought.

You might try this for a SLC, and it won't fault the processor.

Greetings Alaric,



yes, the “non-faulting” idea that you suggested is a perfectly good one - and could also be used (with an ONS) for the PLC-5 processors ... the major reason that I generally use the “fault-the-processor-to-snapshot-the-data” approach is that usually I’m demonstrating this concept to people who are highly skeptical of the results ... they often get the idea that I’ve got something “up my sleeve” when I just use the One-Shot approach ... somehow they are more easily convinced when I kill the processor and then show them the stored data ...

Thanks for the info

i am seting up a rain gauge that measures to the 100th of an inch
it tells the PLC every 100th so if there is a hard rain i am worried about it not registering

My calculations may be wrong but a hard rain would be 5-6 inches an hour (of course your application may differ). If so then it should increase around .150 per sec which should allow a fairly close update.

If you are worried about getting a stable reading then I suggest you set up a FIFO and average the reading over time. Say once a second unload the oldest value from the queue and insert the newest value. Then average the queue contents.

I cant imagine an app where an instantaneous real time reading of rain fall is needed, so would a five second lag be a real problem so long as it gave a stable reading?