HART compatible Sensor successfully transmitting data to one RTU, but not another RTU

[Luke01011]

I'm not actually in front of the equipment yet, but this is the information that I have been given by a client:

------------

Data from HART compatible Endress & Hauser Analyzer over Modbus TCP has successfully been read by Kingfisher CP-12 RTU's for many years, with apparently a HART board being added to the RTU to allow the data transfer. Client wanted different RTU in one spot - a Kingfisher CP-35. The same E&H sensor is being used in the same way for this new RTU, but after a short period of successful transmission on powerup, then the comms fails and takes a number of seconds to come back again, then the process repeats.

------------

Manufacturer of Kingfisher RTU's is Ovarro, and upon relaying the above information to them, they are trying to say that it's a sensor issue, despite using the sensor successfully CP12 RTU's for many years.

Sorry if description is vague. My plan would be maybe to use wireshark and look at the captures from CP-12 RTUs, and then look at the captures from CP-35, and see what is different.

Please let me know if by small chance anyone might have experience with something similar, or any ideas?

Thank you very much

Ovarro Kinfisher RTUs, stats for both, by selecting 'variant': https://ovarro.com/en/global/soluti...rtus-from-ovarro/2/kingfisher/kingfisherplus/

Page mentioning HART protocol for these RTUs: https://www.maximation.biz/wp-content/uploads/2017/08/KingfisherPLUS.pdf

CP-12: https://www.ebay.com.au/itm/272191048793

CP-35: https://isagraf.ru/images/industry_avt/soft/isagraf/kingfisher-plus-cp35_04.pdf

 

[danw]

Which comm fails after a short period?


Whatever the RTU is talking to over Ethernet? which loses all channels



The E&H field device comm talking HART to the RTU? which loses the E&H data

 

[danw]

If the issue is the E&H comm on its input channel to the RTU,


1. Is the 4-20mA signal coming through OK?


2. Some field instrument have a HART feature called "burst mode", that, if implemented on that device, can be enabled or disabled.
I suspect that Burst mode can disrupt a HART master (in the RTU AI) that is not expecting burst mode transmissions.



3. There is HART 'pass through' mode that is used by Asset Management software for configuration and troubleshooting.


But I suspect this is not a pass-through app, but that the RTU HART card is picking off HART variables for tags, that are then available via the higher level comm, RTU-to-whatever. That means that the RTU AI card has to know what to do to get the data that has to be configured.



At a minimum the RTU card has to poll the correct HART address/node ID in the transmitter.