Phoenix Contact communication problems

Dear readers


We are having a problem with the communication between a MassFlow meter and the HART-module of our phoenix plc.

The plc is a ILC 170 ETH 2TX, the massflow meter is a yokogawa rotamass RCCT38-AV0M05S. The meter functions correctly (we can follow its function on a screen that is part of the meter).
Here is the problem, the communication functions normally except for uncontrolled time-outs. We have no idea what could cause these time-outs. Is this a softwareproblem with the plc or a cummunicatonproblem of the HART-module?

Can anyone help us?

TIA
Giete

What HART module are you using?

baranyk said:

what hart module are you using?

Click to expand...

ib il ai 4/ef

And the timeouts are appearing as part of the PLC program?

No, the data should be refreshed every 0.5 seconds constantly. But it stops for about 3 to 4 seconds at random moments and then it restarts on its own. The problem is that this messes up our results.
The dropouts happen at random moments, but when it does happen, it has 2 to 5 dropouts in a row. followed by a long time without problems.

Where are they appearing? Via the screen on the instrument, or from the PLC to another connection?

We can see the dropouts happen on our computerscreen in the debugger of PCWorx and our HMI. There is also a screen on the massflowmeter, we checked this screen already and the massflow is not the problem. It's data is absolutely correct.
So, the massflow sends its data for sure. But for some reason there are dropouts when the data is recived by the plc

Could you send me a screenshot of your local control program?

Have you contacted your local technical support?

I'm not at work. I will send you a screenshot first ting in the morning. Local support is not really helpful, we are a small company and well.. They are not helping. So we are trying hard to solve the problem ourselves.

A screenshot is out of the question.. My supervisor won't let me take one. Sorry, I still hope you can help us.

Here is what we have done so far; We made sure that our datalines were protected against magnetic influences. We also made sure that we could rule out ground-loops. This improved the situation slightly.

We can now (wit almost complete certainty) say that something goes wrong in the HART-module. But we have no clue what.. Can you point us in the good direction? Maybe you know how to test some things to rule everything out until we have the problem? In the meantime we will look up what we can and try to resolve this problem ourselves.

Giete said:

ib il ai 4/ef

Click to expand...

I made a little mistake in the serial number. The module we are currently using is the IB IL AI 2-HART (-PAC)

Giete said:

A screenshot is out of the question.. My supervisor won't let me take one. Sorry, I still hope you can help us.

Here is what we have done so far; We made sure that our datalines were protected against magnetic influences. We also made sure that we could rule out ground-loops. This improved the situation slightly.

We can now (wit almost complete certainty) say that something goes wrong in the HART-module. But we have no clue what.. Can you point us in the good direction? Maybe you know how to test some things to rule everything out until we have the problem? In the meantime we will look up what we can and try to resolve this problem ourselves.

Click to expand...

Hey no worries, I understand.

Is there a diagnostics output on the function block you're using?

The Functionblock used to read in the hart module is called 'Hart_multidrop_v**'. In this Fucntion block there are two possible errors; wErrorClass and wErrorCode.

There is a errorcode generated during the dropouts. The only problem is that I have trouble finding how I can read the specific code. I'm currently trying to solve this issue because I think that the code could help us in the process of finding the problem.

Any idea how I could read the errorcode?

Right click on the function block and read the help file... alternatively, check to see if the library came with any documentation. The error codes should be in there.

Oke, I did whay you told me. I think we are on to something. The errorcode that is generated is a wErrorClass code. The code is FFFF(hex). That is the only code explained in the errorcode library. The explanation says:

"Internal error, e.g. device does not exist any longer in operation. Therefore wait for "xActivate" and "xPollmodeActivate" = FALSE"

I found out that the program contains a small FBD that puts "xActivate" and "xPollmodeActivate" on FALSE and then back on TRUE in case of an error. I think this is the reason that the dropouts all last very short. The program repairs itself.

When xActivate and xPollmodeActivate are put on FALSE and back on TRUE the function block 'HART_MULTIDROP...' starts looking for divices en restarts reading its values.

The fact that the program repaires itself is good but there is data lost in the process of selfrepair so we have to find out what causes these dropouts. Thats the only way to assure that our programs will work perfect.

Do you have any idea what could cause this error? I'm going to try to look it up myself but your input is very welcome