1746-HSCE2 error in counter value

[carroll arbogast]

I have been seeing an interesting phenomenon (bug?) regarding the counter value of an 1746-HSCE2 and am hoping that someone out here is familiar with it and can offer a solution. A simplified description of my application follows:

I am using a SLC 5/05 with an HSCE2, a 16 point dc input module, and two 8 point output modules. The HSCE2 is configured for 2 counters with X1 quadrature. I am using the first counter which is connected to a 1000 cpr encoder. The encoder is associated with a rotary device that produces an output signal at a certain point in the rotation. The output signal is also supplied to the PLC via a 1746 DC Input Module.

I am using the PLC to record the encoder value at which the input transitions from low to high. My goal is to characterize the variance in the signal timing by building a 1000 bin histogram of transitions versus encoder positions.

For each scan, I look at the input: if it has changed from a 0 to a 1, then the current encoder counter is used as an index into the histogram and that location is incremented by 1. I run this program until I have accumulated a few millions of points. This typically takes less than 24 hours (depending on the speed of the rotary device). The program works quite well - the histogram usually shows a profile of the transition with a spread of about 10 - 20 counts.

The problem is that the histogram shows a few outliers, on the order of 1 per million data points. An examination of the encoder count values associated with these outliers shows that in each case, the least significant 4 bits of the value is 1111. I determined that this is caused by a rollover error between the least significant nibble and the next nibble. I suspect that there is a problem with the method used to perform the input scan - for example the scan may be reading the counter a nibbles at a time during which time the nibbles are asynchronously updating (many firmware programmers will be familiar with this problem).

Thanks for bearing with me this far! At this point, my questions are:
1) Has anyone encountered this type of problem with Allen Bradley input modules and can shed some light on the cause?
2) Am I barking up the wrong tree?
3) Any suggestions for a solution?

Thanks,
Carroll Arbogast

 

[carroll arbogast]

More info

I have noticed that the erroneous values will the LSBs set to 1111 when the HSCE2 is counting *up*, but when counting down (reverse direction of rotation) the LSBs of erroneous values are 0000.

This strengthens the case that there is either a problem in the HSCE2 or in the backplane scan. I have 3 identical systems, and they all show the same symptom.

The encoder is rated to 200 Khz, but it is actually running at about (180 rpm / 60 spm) * 1000 cpr = 3 Khz. This is well within the spec of the HSCE2 (1 MHz). The signals look fine on an oscilloscope.

I am considering replacing the SLC 5/05 with a spare SLC 5/03 as an experiment. I don't really know how the backplane scan works, but I am speculating that there is firmware on the cpu module that performs it - perhaps the 5/03 firmware does not have this problem?

Any comments, suggestions, or proposed experiments will be appreciated!

Thanks,
Carroll

 

[oddsocks]

HSCE 2 error

I also suspect card firmware.
configured as Quad (AB) & 2 pulse (A only) counters
AB counter resets to Zero while counting up.

I know Z1 external reset has no effect.
I know initialise sequence occurs only once.
Output words are then only used to reset to zero.
Reset signal is only active while slide on home switch.

so why does spurious count reset occur 1 in 10 cycles.
3 Cycles/min of 16,000 pulse count in 2S of tape length.

Suspect this card has beaten many Engineers.

regards Dr. Joe

 

[oddsocks]

Integration of Rate value

in the absence of a fix for HSCE2 card.

try integrating rate value.
may not be as accurate - as the absolute pulse count.
but reliability will be better.
if sample rate is 5Hz can only loose small qty of pulses.

Worth a try.