high speed counter

What will hapen if we connect a high speed input to a normal digital input of a PLC?
What is the significance of the high speed input?

Normal digital inputs are read by the processor and made available to the ladder program normally once per program scan. (There can be exceptions to this, but this is usually true.)

Therefore the any input that changes faster than the program can be updated is not going to have the change of state seen by the logic.

The minimum time depends on the time of the program scan, and the repsonse time of the PLC input. In general this time is likely to be anywhere between 20 -200msec.

A high speed input is connected directly to a hardware counter in the processor and counts inputs independently of the logic scan. Usually these counters will accept pulse trains in the range 20-100kHz.

If you need to respond rapidly to a single event pulse, then neither of these methods will works, and other special techniques, usually very specific to the PLC will need to be used.

To further explain:

If you have a 1000 pulses per revolution encoder connecetecd to your input, and it's turning at 1000 rpm, then its putting out at a rate of 16,666 pulses per second. Now let's say your program has a scan rate of 8 ms per scan. 8 ms scan time = 125 program scans per second.
As you can see the puls train rate of the encoder is much higher than the ability of the program to count every pulse. Therefore the program cant count the pulse train.

As Phillip indicated, the high speed counter inputs are a seperate and independent hardware device that does the counting, then provides the counted value to the program logic.

Mike

Thanks a lot, both of you!

High speed input

Hi
in addition to what mentioned above i want to clearify that always the high speed inputs is dedicated to high speed counters in the PLC once you select the high speed counter in your program the dedicated inputs will be attached automatically to this counter.in this case you can't use this inputs at all in your program(don't write it)
and if you make a mistake and you write it in your program it will not be executed as a logic.
The high speed inputs is treated as interupts and updated regardless the scan time.
if you don't use the high speed counter in your program you can use the high speed inputs as a normal dohital inputs in your program.
THX

srirajas,
You have got your by-the-book answers already, and maybe that is what you are looking for. There is another case not covered yet. That is where you are out in the country, hours or days away from the nearest distributor, and all you have on your PLC are normal inputs, but you find that you have one encoder input that is runnning just slightly faster than the normal PLC input can count. The plant is ready to run, except for this, and everyone including the President of the Company down to the janitor, are standing around, waiting for you to get it fixed. If this or something similar is the case you had in mind, then here is what you can do:

(1) Connect the encoder or other high speed input to a normal input.

(2) Then compare the counts seen by the PLC to the actual counts sent out. For example, if your encoder sends out 100 counts, but the PLC only sees 80 of them, then you need to multiply your input by 100/80, or 1.25, like this: Count = Input X 1.25.

This will get you in the ballpark, and will work for some applications but not for others, but in a desperate situation, what else can you do? Am I the only old **** here who has had to make do with what I had avaliable in the field? Let's hear about some other jury-rigged fixes.

i disagree

Lancie1
I disagree with you,As well as the encoder connected to a normal input it will not treated as a fast input.so it will depend on the scan time which is not constant in each cycle hence if the actual count from the encoder is 100 pulse, the plc will see it 80 in one cycle ,88 in the second .75 in the third an so on so it is impossible to correct the reading by multiplying in a constant factor.
thx

Hesham,
I did say that my "fix" will not work in all cases. It is something to use when there is no other path. It has been my experience that the scan time does not vary as much as you say. It depends on how many sub-routine jumps are being done. If it is a straight-thru program, executing one rung after another, with no outside calls and interrupts, then what will make it run faster or slower? The only other thing I can say is that for the times I have had to use it, it worked! Have you ever tried to use this method, or are you speaking hypothetically (from a make-believe situation)? I will tell you right here that I don't put much stock in make-believe. What cranks my tractor is the down-in-the-dirt, nitty-gritty, ever-day real world.

Lancie1,

I grew up under the wings of the likes of you. One old guy's name was Edger. We called him EE-Gads. You always could tell when EE-Gads preceded you on a job due to the fact that the machine room looked like something from a "mad scientest" movie like Dr. Frankenstine's labatory.

It seems like the "never leave it down" guys are all but gone now. Their legeacy is quickly becoming a distant faded memory to a few of us middle age guys, and only a myth to the younger croud. The sad thing is many of these new guys will drive 50 miles back to the shop to pick up a blocking diode, passing 10 Radio Shacks on the way.

To be honest with you I like your "fix". It may be ok for speed feedback but positioning is another story.

Just make sure that someday you get back to that job with a counter module....

Mike