Today is...
Saturday, November 17, 2018
Welcome to, the global online
community of automation professionals.
Featured Video...
Featured Video
Watch an animation of a conveyor stacking operation demonstrating the use of a move on a gear command.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Temperature Probe Spikes in DCS
Compressor temp probe spikes noticed only in DCS not in system

In one of our compressor in Syn gas train, one of the temp probe on the active thrust bearing had spikes from 61 to 93DegC on two occasions which was captured in DCS. But when I checked in System1, no spikes were noticed. To ensure I have enabled 1 sec data collection, the result is same.

Two days back we had the similar spiking (95 to 123DegC). This time on one of the radial bearing temperature and again observed only in DCS, not in System 1 trend. On both occasions, other pairing probe trend is normal. No abnormal changes in process parameters, radial vibrations, and axial displacement trends are normal.

We have frequent loss of communication with 3500 rack, possibly due to card problems (seen as blank in the trend). I would like to know, is the communication loss and spike (only in DCS) has any relation?

Bearing temps are not likely to "spike" due to actual temperature changes, especially if nothing extraordinary is occurring.

Temperature values frequently have a low scale or high scale burn-out or failsafe value setting, and it's common to see that when a sensor is disconnected because disconnection is a fault/bur-out/failsafe condition. But burn-out is full scale up value or full scale down value; it is not a 32 degree or 28 degree difference. So what you're seeing is probably not a momentary burn-out/failsafe indication.

The general rule of industrial digital communications is that data that has errors is thrown out; it is not 'reported', instead a comm error is reported. Hence one typically rarely, if ever, receives incorrect data values created during digital communications. It theoretically can happen (the error checking CRC algorithm has some probability of passing an error), but I can't recall ever having traced a bad value to bad comm.

Your "communications loss" is a reflection of such - you're not getting lots of bad data, you're not getting any data at all. Somewhere there's an error log that is filling or full of reported errors.

A temporary spike error could be due to a flaky analog input on the input side or a flaky AO on the field side. I have seen the A/D in an AI temporarily lose a bit that should be set or have a bit set that shouldn't be. The field AO failures have typically not been temporary errors, but obvious, continuous errors. The couple of times I've seen an AI fault, it was associated with equipment that had been over heated.