Problem Rosemont DP Sensor

I apologize, the red line on the chart is the one that is drifting is P-High Sensor and should be label as such, and not P-Low

Hard to keep straight with interruptions and time constraints for post editing.

Are these instruments powered from the same supply? If not... I would start there and get them on the same supply.

Buss type system (Hart gateway)

Yes, both are powered by the same power supply. And each are grounded together and not to the panel. Yesterday, one of the techs check the integrity of the wiring and did not find anything.

Thanks for the response.

The DP computation looks way off, regardless of which sensor may be drifting.

if there is a computation error, there would be a consistency..... instead it would drift up,...... hold,..... and the drift down until it reach it original readings.... or at least close to it. Very unreliable and no pattern. With no abrupt, which could indicate a grounding issue. That is the unsettling part.

Is the shielding in the cabling going to these units the same on a well behaving setup when compared to the one setup not working properly?

Possible thermal differences between a good running column to the bad one?

Is the rate of drift linear?

Is the shielding in the cabling going to these units the same on a well behaving setup when compared to the one setup not working properly?

yes, And it worked flawlessly for a year, we looked if we did any changes that was near the cabling lines, if we had installed anything that would give interference, but no.

Is the rate of drift linear?

No real pattern, in time or rise.... it does look like it would begin to level off, and run steady (though incorrect) and then drop down.

whats running on the lines 4-20 mA (which is set high[4] and low[20]mA) analog signal or ethernet?

I don't quite follow, What do you mean, 'what's running on the 4-20mA'?

The DP uses analog 4-20mA or digital? You have a not so cost efficient set up.

Usually intrument in this type of application is like below (Hi & Lo integrated in one transducer) Or why not thi set up?

You have a not so cost efficient set up.

On looking at it as a simplified layout, I would agree.

Unfortunately on a more detail process it's not. This is a reaction column, things are dynamically happening inside.

We arrived to this through trial and experience, (no, I'm not going to say trial and error because that's what we expected) . And due to the complexity, I just listed our tests.

So, in more detail.....

This process is set up as an interface, we have 3 different types of media being entered here that is not all soluble (tar/water mix as well as a product) the tar water is more of an emulsion. And each is of a different mass. so its possible that things will drop out and stratification can happen here. The product is the lightest, so that is on the top.

As its sitting in the column, some of the tar of the tar/water mix will drop out. When it drops out, the tar goes to the bottom of the tank (BELOW P-High). The tar and water is mixed through turbulators prior to entering the tank.

One will think That's a problem, sure its difficult, but not a problem, we base the numbers off empirical data from the past.

We use these sensors configuration and set-up to give use an approximation of what's happening in the column.

With this data, we found we started having trouble to take it off line. and run tests on it.

Now to simplify it, we needed static test, We use Just Water.

No mixtures so nothing is dropping out of the mixtures.

That's why you may think its not efficient, you only see the static tests, so there is a reason for it, I just felt that I'd post the results of just water, and if there are members here sharp enough to see the inefficiencies of the set-up, and there are, such as yourself, then I'd explain further out of being considerate to this community.

And because of the dynamic process, we do need the 4-20 mA sensors and not a discreet sensors for automation purposes.

But I didn't want the distraction of the actually dynamic process, so I posted the simplified version using just the water.

I hope this helps to explain the reasoning behind it.

To me it looks like there is an additive offset present in the signal.

Food for thought stimulation and consideration: (All are rhetorical.)

Has the system been loop tuned recently?

If so; Are you certain the current PID values are correct?

Are all configuration parameters correct? (Scaling? Range? Engineering Units? Zero?)

Does the sensor have a local display readout?

If so, does the local display indication match the broadcast DATA?

If there is no local display; Have you attached directly to the sensor with a HART monitor and verified the broadcast comm. values match the local sensor readout values?

If they do not match, communications are suspect.

If all of the above is good:

1) Have you used an oscilloscope to evaluate the sensor power supply and feedback signals for AC noise impingement?

2) Has any new equipment and/or instrumentation been added to the loop or in the general area?

3) Are there any direct immersion heaters or other equipment immediate to the affected sensor that may have an electrical ground or short?

4) Has there been any recent programming changes made to the HART system?

5) Has there been any new lighting, RF, VHF, UHF, RADAR, SONAR, or other broadcasting systems installed in the general area?

6) Is there any welding going on in the general area?

7) Has there been any new flow monitoring equipment installed on any of the feed lines to the tank? (DOPPLER? Magnetic?)

8) Any new chemical additives or chemical composition changes to the stored fluid?

Hope this helps. Good luck!

I thought it was a math era as well, the data as how it was told to me, is done internal on the sensor. And the sensor outputs the signal to be accessed and read. Its no going into the PLC, but straight into our historian.

Hey, rhetoric or not, I'm open for suggestion or thoughts.

Has the system been loop tuned recently?

That specific I'd have to run that past our electrical tech. I did asked if it was set-up correctly/calibrated... the answer was yes.

Yes, We manually filled the tank and we did take a manual measurement, and it was correct. we left the tank sit, and it begins to drift.

If so, does the local display indication match the broadcast DATA?

Yes, we hooked up a lap top to the sensor, and it matches the the broadcast data.. Good question, it would rule out the data line.

1) Have you used an oscilloscope to evaluate the sensor power supply and feedback signals for AC noise impingement?

No, but that may be on the list.

2) Has any new equipment and/or instrumentation been added to the loop or in the general area?

No, but, what started it out, on our historian, the data should an abrupt drop in tank level a few weeks back. We thought at first that there may have been a power outage. We asked around, and there wasn't. We are still looking into what cause that, and see if there is a connection.

3) Are there any direct immersion heaters or other equipment immediate to the affected sensor that may have an electrical ground or short?

No, but, when we were running another tank level test, I was going to see if there were any stray voltage,.... I brought it up to our Electrical Engineers, our equipment is well grounded (Due to our environment)

4) Has there been any recent programming changes made to the HART system?

No, Just got a call from the Rep that was suppose to arrive this afternoon, he has the flu. We were going to record all week end with a static level in the tank, and see if there is a pattern on Monday.

5) Has there been any new lighting, RF, VHF, UHF, RADAR, SONAR, or other broadcasting systems installed in the general area?

No

6) Is there any welding going on in the general area?

Our maintenance Shop is in the area, I'm looking at the records to see if there were any welding and the like going on at 3:30 AM when the first incident occurred.

7) Has there been any new flow monitoring equipment installed on any of the feed lines to the tank? (DOPPLER? Magnetic?)

No

8) Any new chemical additives or chemical composition changes to the stored fluid?

No,

Thanks for the input, we are going to revisit some of the items again to see if we missed anything.

Thanks,

You are most welcome.

Another item to look at is the possibility that there is a duplicate address and/or DATA tag circulating in the system.

If you are using IP protocol communications I would suggest using a laptop or the server for instituting a continuous pinging of the device IP address and observing the feedback for change or differences in device location and/or differences in the message response delay.

The same would be applicable in pinging the ECN or MAC address or DATA tag in a DCS or PLC based system.

I have chased similar DATA display issues only to discover someone "fat-fingered" an address and the DATA logger or HMI server was combining both signals on-screen and in the historian file(s).

I have found duplicate ECN and MAC addresses in different/multiple devices straight out of the box from the factory.

It could also be a polling table timing conflict or a device on the network could be broadcasting too much or out of sequence. Have you looked at the number of collisions occurring on the network?

If fiber-optics: Have you checked the db losses? Signal quality from the device as well as the overall system? (Dirty or loose fiber connection? Laser optic degradation due to age or damage?)

Does the communications cable from the device to the server/Historian node run through open tray or conduit?

If in open tray: Has any new cables been pulled into the same tray(s) at any point along the cable route? (Possible induction or cable shield damage?) Possible chemical or heat damage to cable?

If in conduit: Any physical damage to the conduit along the route? Water or chemical inside the conduit?

Corroded or loose instrument/device cable connections?

Just talked to our EE, the communications on the Rosemont is wireless.

We only use it for monitoring by personal to make sure that there is something happening in the column. kinda as a backup system for quality. The process itself is more of a timing where the inlet and outlet flows are the ones monitored and controlled

On our polling table, The time is 30 seconds, I'll confirm that... (Normally the data is every 5 seconds, because that's how we started out when we develop processes around here for trouble shooting and it because a standard)

I believe what I'm going to do, is reviewed the new info we have at the company, as well as what was brought up here. I'll repost it in a format in one area.

Gives me a change to review it also.

Thanks.

With RF communications there is a high probability the issue is being caused by bandwidth and/or frequency impingement from another RF source such as another RF device such as cell phones, door openers, overhead lighting ballasts, or anything operating within the frequency range of the device in question.

You might want to consider using a frequency analyzer to monitor the device broadcast channel for unwanted noise.

It is very common for RF equipment frequencies to overlap from one manufacturer's equipment to another especially in the 5.8KZ range.

We have to run all of our RF above 9KZ in order to stop issues caused by frequency bleed-over from wireless printers, cell phones, Bluetooth, and other Wi-Fi devices.

Even at the higher frequencies we have device frequencies from time to time drift out of range and cause severe issues.

That's interesting, I'll have to compile the information see what we have here.

I like to add on all of our none critical devices we go wireless, for nonessential info and security. None of our wireless gets connected to the PLC.

I will firstly say that I know SFA about these units and my suggestion is likely way off, but is it possible that sludge in the bottom of the tank is causing your problem?

No, the tank was drained and we have been testing it with water. We are leaving it sit over the weekend, with water, and Monday we will look at the data to see what or if there is a pattern.

I never rate threads, but this thread rates 5 stars because it is an excellent example of a well stated question from one professional to his contemporaries and their response to try and help.

I wish more threads were like this. Good work.

Ahem...hardly ever.

--W.S. Gilbert

Up till now.

Thanks Lyn.

As a layperson looking in from the outside.

You stated that the reactor has a water jacket.

If the sensors are piezoelectric is it possible that changes in the water temperature flowing in the jacket would change the output signal of the sensor by changing the resistivity of the piezoelectric material used in the sensor? Or changing the output voltage by changing the thermal stress due to the coefficient of thermal expansion of the piezoelectric face of the sensor?

Why only one sensor could be affected:

Is it possible that the relative change in resistance due to a change in temperature of the piezoelectric material could be proportional to the "stress" on the piezoelectric sensor?

Where is the water intake in relation to the two sensors? Would this be a factor in Jacket temperature at the two different locations? If the water intake is nearer to the HP sensor than the LP sensor then the water and jacket temperature would not have time to stabilize at the location of the HP sensor. Did the problem evolve with the change in season? That is, would the intake water temperature be different now than lets say - Mid-August?

Do you have the capability of monitoring jacket temperature at both sensors?

Do you have the capability of bumping water intake temperature up against pressure sensor signal?

Is there any reason the same effect would not occur with a Hook (spring loaded) sensor; especially given the coefficient of thermal expansion of the spring?

Problem with that is, after a year of no issues, what changed.

delete

Well how we added the water for the test there is a 'tee' valve above the discharge pump below the tank. (Between the pump and tank, which I did not show)

During process, the inlet is on the side wall, I can get dimensional relationship on Monday.

The product is tar/water, which is mixed by an inline turbulator.

Yes we can and do monitor the outside jacket temp. As said in earlier post. The temp is within operating range of the sensor.

Is the jacket water temperature monitored at both sensor locations or just a single location with that info fed to both sensors? If it is monitored at a single location what would be the effect if there was a different temperature at the two sensors?

Not on a recirculation jacket.

Very, very interesting thread. Pertinent data is very well presented.

I assume that this is an interface measurement, given that the diagram shows a fixed level with the low side elevated well below the vapor area.

If the High side was stuck at a fixed value, then it could be stuck in loop test mode, but the high value slowly tracks the pressure change at about 20% of the real change, ruling out stuck-in-loop-test.

What could possibly cause high side low measurement error, a failure to accurately measure an increasing head pressure only 20% of the increase seen by the low side?

If the High sensing element were blocked by ice, gel or solidified sludge, particularly with a trapped gas bubble, then the sensing diaphragm could fail to see the full impact of pressure changes. But you've pulled and inspected the sensing element.

Since the transmitters are flange mounted, it isn't likely that there is an isolation valve or a manifold valve that could block pressure to the High unit, is it?

There's no public document that I can find that tells what the communication is between the Low and High ERS transmitters, but the manual is explicit about a twisted pair shielding and cable shielding, a maximum of 150 feet of cable length and a maximum capacitance value. And there's a note about an IS barrier being limited to 1mH of inductance. Those warnings sound like precautions for a digital protocol, not an analog output from the low to high unit.

And if that's the case, the high side likely does the arithmetic, P high minus P low.

That says that the High unit is a direct measurement of pressure; the High pressure value is not 'communicated'. If the communications were dicey, an error would likely show up on the Low unit's value, since its values are the ones sent over the communication link.

Which says to me that either the High pressure has to be blocked or the high unit is just failing to measure its applied pressure under the process conditions.

I like the idea of swapping the high and Low units. Be sure to re-identified each unit for its correct module assignment (high or low).

And let us know what the results are.

The problem with that is, only the lower sensor (P-High) is drifting, the upper sensor is relative constant level (P-Low) if the level changes the DP between the two (P-Low, P-high) because the distance between both are constant. Both should also change, only the P-high changes.

Try to transfer input of DP to different receiving module.

This will have no effect we are getting the information right from the sensor. We even hooked our lap top directly to the sensor.

Is there a change in temperature or specific gravity in the liquid?

Rosemont makes excellent instruments.

The drift seems to be upward in a non linear fashion.

If the instrument is good,and I suspect it is ,the problem has to be external to the instrument.

Two instruments with same problem?Not likely.

A leaking outer or inner conductor on the wiring can cause drift.

Have your electrician do a megger test on the cable.

A nick on the outer insulation could cause such a drift.

A DVOM does not have enough voltage to detect a "wet ground",not enough to ionize the moisture,even in diode test mode.

I once used a Fluke to test for ground on a system and it showed nothing.

An older engineer with an analog Triplett 310 meter tested it and it showed up as grounded.

I was surprised that the old analog meter could detect a problem when my new (at the time) Fluke 8060 could not.

I found a 310 on a surplus site and I keep it in my go bag,along with my Fluke 27,just in case.

The liquid (in process is tar/water) mix, but since the problem, we have been only running water. With the water jacket recirculating at about 50c and off.

No, it will drift up hold, then also drift down. We have a huge sampling rates tat is put into our historian.

I agree, not likely but possible... Rosemont is sending the first one back which they found no problem with.???

A leaking conductor, i brought up about stray voltage... Our electrical engineer says highly unlikely... But that is still in the table.

We well be having our techs put a merger on the cabling again on Monday. (That would be a double check)

A nick in the insulation is possible,

Interesting about the analog meter.

Excellent response, I'll try to answer what I can, and find out an post later when I have the info..

I saw that in the table to, I had to delete some before posted it, I'll look into it, (I didn't get much sleep the night before, because of work :-/ ) so, I'll look into it, we did check the DP between the too, and the math was correct,... It could and most like be human error. (Me when I posted it) As I'm hoping this issue is also just human error..

And give a full report Monday, or Tuesday. (The controls guy is on vacation Monday, but said he'd come in.

Yes, the original was shipped last week and we will be installing .

We pulled the sensor twice, one to inspect the membrane, the second time to ensure the Teflon gasket was not impeding the membrane. (We actually enlarged the ID of the gasket to ensure it was no where close to the membrane .

As I mentioned before. We connect our laptop directly to the sensor, and it does match the historian sampling..

On temperature, I beleive that there is silicon behind the membrane and we talked about the temperature having a effect, but the temperature is within it limits to the sensor..

I talked to the tech yesterday, that there is a lot of data the are not put into the historian, he was going to get that Friday, and we'll look at it on Monday or Tuesday..

On a different note, we or I had what turned out to be an issue with a controls issue on a different process line and I brought it up to our controls department, when I asked if it could be a controls issue, I was assured it wasn't, I asked a few more times to others in our controls dept. and was assured it's not a controls issue..

I'm sure they talked to each other that I was fishing for blame, but far from it. Just looking for a solution and directly challenging. That it may have only appeared that way..

And because they are professions, I accepted it, though reluctantly only to turn out it was a controls issue after all ;) . So I can't rule anything out. Someone could have did a mistake included myself. And I feel the problem is so out in the open we can't see it..

I'll get back with the other possibilities you mentioned..

Thanks again for you efforts.