Very High Speed Counter Losing Pulses

[matt.norsask]

I've come across a new issue that has me stumped. We have a lumber sorting system that keeps timing using a 1771-VHSC and a 1000 pulse encoder. What started happening today is we are losing pulses. One full rotation is only giving us about 900 pulses, which throws our whole system out of time.

So I changed the encoder, which didn't fix the problem. I changed out the VHSC card, which also did not help. Nor did a new cable.

A little background information. We have the encoder count set to reset when you apply 24v to CH. 0 G. When I did this, the encoder count reset to 0, but that seems to be when we started losing pulses.

Any help would be very much appreciated!

 

[BryanG]

Are you using the encoder in Quadrature mode i.e. both pulse channels? I have experience of electrical interference on one or both channels causing a system to either loose counts or not count at all. And of course the other way is a bad mechanical connection between the system and the encoder.

 

[Bit_Bucket_07]

A little background information. We have the encoder count set to reset when you apply 24v to CH. 0 G. When I did this, the encoder count reset to 0, but that seems to be when we started losing pulses.

Was this a change that was made to the existing system, and did the problem only arise after making this change?

Is it possible that this reset pulse is too long in duration?

 

[robertmee]

Was this a change that was made to the existing system, and did the problem only arise after making this change?

Is it possible that this reset pulse is too long in duration?

That would depend on the mode you have the counter set up for. Check out page 1-8 of the manual. Depending on the mode, the gate reset will stop the counting. You need to make sure it's set for mode 4 for rising edge and to not pause counting. See below.

In mode 1, store/continue (1.4), the leading edge of a pulse input on
the gate/reset terminal will cause the current value in the counter to
be read and stored. The counter will continue counting. The stored
count will be available in the block transfer read file. The stored
count information will remain in the block transfer read file until it is
overwritten by new data.

In mode 2, store/wait/resume (1.5), the gate/reset terminal provides
the capability to inhibit counting when the gate/reset input is high.
Counting resumes when the input goes low. Mode 2 does not reset
the counter, although it does store the count value.

In mode 3, store-reset/wait/start (1.6), the rising edge of the pulse
on the gate/reset terminal causes the counter to stop counting, store
the current count value in the block transfer read file and reset the
count to zero. The counter does not count while the input pulse on
the gate/reset terminal remains high. Counting resumes from zero on
the falling edge of the pulse at the gate/reset terminal.

In mode 4, store-reset/start (1.7), on the rising edge of a pulse
input at the gate/reset terminal will cause the counter to store the
accumulated count value and will reset the counter to zero. The
counter continues counting, and the stored count is available in the
block transfer read file.

 

[matt.norsask]

Thank you for all the responses. I should have clarified. In order to reset the encoder count, we have to manually apply 24v to the gate terminal. It's not set to send a pulse automatically. So while the encoder is running normally it should never see a reset pulse.

Robertmee, your post was very enlightening for me! I did not realize we had those kind of customization options.

Bryan, the counter is configured for Encoder X1, but interference is something I will look into. Funny thing is, we've been running it fine for years the way it is. Now suddenly we started losing pulses. And the mechanical connection is good and solid! Always good to check though. I actually removed the encoder mechanically and spun it by hand. I would still only see about 900 of the 1000 pulses in the program

 

[John.S]

Hi,
Did you check power supply.
Take a scope and check the shape and value of the pulses.
This can give you clearity of what is going on.

Greetings John.

 

[BryanG]

You can try connecting the encoder direct at the panel to keep wires as short as possible. Then turn it by hand and see the results.

 

[ganutenator]

Sounds like everyone is on the right track here. If it used to work, and now it doesn't, it isn't a programming issue.

Now, to remove the variables.

 

[robertmee]

Sounds like everyone is on the right track here. If it used to work, and now it doesn't, it isn't a programming issue.

Now, to remove the variables.

Not so sure....It isn't clear what the OP meant by "When I did this, the encoder count reset to 0, but that seems to be when we started losing pulses." So, the reset seems to be causing the issue...what's not clear is whether this reset is a recent addition.

 

[BITS N BYTES]

Encoder Disc attachment to shaft inside encoder is loose.
Usually glued on with epoxy.
Replace the encoder!

 

[Doug-P]

Encoder Disc attachment to shaft inside encoder is loose.
Usually glued on with epoxy.
Replace the encoder!

Per initial post:

So I changed the encoder, which didn't fix the problem.

 

[Steve Bailey]

When you changed the VHSC module did you use the terminal strip from the new module or reuse the original one? If you used the original one it could be a bad connection between the terminal and the module or possibly a strand of wire from the pulse input making intermittent connection with the reset terminal.
Is anything in the program writing to the address of the module's accumulated count or to any of the control bits associated with it?

 

[Firejo]

You might have a drive and/or motor starting to fail. I’ve heard (via my providing tech support) of a VDF and/or motor that starts producing a large amount of noise on the AC lines which can act as antennas in that they “broadcast” the noise all over the place. It’s kinda like how you can hear a 60 cycle hum but it would be a much higher frequency. If the radiated energy is high enough it could be inducing the frequency onto the lines between the encoder and the PLC which would fill in some of the peaks and valleys reducing the count. Bit of a long shot but worth looking at (assuming you can’t find another cause).

 

[GaryS]

Just a thought
The problem starts after the reset try loading the rest input with a 22k ohm Resistor
The input may be floating high after the reset causing the counter to reset at odd times
I have found the not pulling the inputs down when not active can cause this type of problem