Conveying and Storing
the Pulse Count

This is probably the one area that gives most process control engineers a serious headache when it comes to radio telemetry. There are reasons for the headaches but a lack of knowing how to deal with them is the real cause of their despair.

The weakness in many radio telemetry systems is a simple one, reset the power and any accumulative pulse count is lost! This is seen by many as a totally unacceptable situation and even beats the problem of 'too few bits' hands down.

Too few bits, another main issue with process control people (although, as said, not as drastic as losing the count altogether). It raises its head whenever the accuracy of what is being measured is perceived as needing to be higher than actually required. This forces the pulse rate up which then fills up the counter quicker bringing on a roll-over faster.

Many counters were 8 bit (some still are) but not many have broken the 16 bit level either, this being directly attributed to MODBUS. No other reason! This means that a counter has a potential maximum count of 65535 before rolling over to zero. If a high pulse rate is fed into such a counter it does not take long before roll-over happens.

Adding more bits is not, in itself, a cure. Although the more sophisticated SCADA packages now allow the combination of two MODBUS words to form a 32 bit value every thing, from the physical input through to the SCADA, is doubled which includes all radio transmissions associated with the input. This also means double mapping on the radio system and is personally considered as 4 times the work!

The danger of having the count value stored in the telemetry module is it impairs maintenance. Power cycling to clear a fault has also the potential problem of clearing the count, and suddenly the person servicing the device is left with a choice of two evils. Further problems are found when the unit is exchanged for another. When the original is again put into service the count is at the value it was when taken out of service resulting in further maintenance to go and clear the count.

There is only one way of doing this correctly - "difference of count" addition. Simply put, when a count value is updated the SCADA package notices the difference, calculates the difference, and then adds this to a counter of the required bit-length. An example would be a counter is read at a figure of 100, the next time at 102. The difference is therefore 2 and this is added to the counter in the SCADA package. It is the rollover that fools a few people. During a roll-over the difference becomes a negative value. If the previous value was 65535 (16-bit) a singe pulse will cause this to become zero. The difference is therefore 0 - 65535 = -65535. What is done in this circumstance is a value of 2b (where b = number of bits) is added to the negative value, in this case 216=65536 so -65535+65536=1.

The only situation that needs to now be catered for is a reset. E.g. the count was sitting at 10213 and the following value was 0 this would put the difference at -10213. As it is a negative value 65536 is automatically added to it. This makes the reading 55343!? We know this cannot be the case. If it is tested that the maximum possible reading difference between any two updates is e.g. 10 then it can be safe to assume that should the difference be more than 20 (leaving some room for a little extra) then a reset has taken place and the difference must not be added (except do remember to update the reference value!). It may be safe to assume that the actual value of the counter be taken as the number of counts to add.

If we, for argument, stated that the next update value was 5 in our previous example then we could safely assume there was a reset and that 5 counts were done before an update sent. This way the count errors could be minimised as much as possible owing to resets that may or may not occur or be deemed necessary.

| | Ask a Question |