carroll arbogast
Member
- Join Date
- May 2005
- Posts
- 2
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
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