PLCnext on LinkedInPLCnext on Instagram  PLCnext on YouTube Github PLCnext CommunityStore PLCnext Community

  1. peterdallmann
  2. PLCnext Engineer
  3. Friday, 28 February 2020

I have a problem with the OPC UA server in the AXC F2152 with PLCNext Engineer 2020.LTS.01 / FW 2020.LTS.01.

1) Communication is dropped by the AXC F2152 for around 1500ms

2) Variables are shown as TRUE in the HMI (TP3185 W) even they are not TRUE in the PLC

3) Do to the communication drop, variable of type BOOL are set to FALSE, even if set retentive in the controller

I have checked the settings for the timeout in Visu+ and also in the controller - there should be no drop of communication.

A log with wireshark has shown the same issue, the OPC UA server drop's the communication for periods of 1500ms. There is no fixed interval when the communication drops, can be a day, can be an hour.

 

Any ideas what the issue could be?

 

Peter Paul

Oliver PLCnext Team Accepted Answer Pending Moderation
0
Votes
Undo

Hello Peter,
we will have to look into it.
So far this looks like it is application specific,

1.) could happen if the CPU load is high or due to network traffic . I will ivestigate.

2.) I have never seen that.
Is it a latche able variable?
If you connect with a ua expert or something the variable is still shown as Active even thou it is off?

This might be related to the Visu+ Project.
Please forward the effected part of the Project. (see email for upload link)

3.)
I did not see this behavior before
I will have to investigate.
Please attach the wireshark logs. I would like to see the details of the connection loss. Terminated or timeout ect...

kind regards,
Oliver

Phoenix Contact Electronics Headquarter - PLCnext Runtime Product Management and Support

  1. more than a month ago
  2. PLCnext Engineer
  3. # 1
peterdallmann Accepted Answer Pending Moderation
1
Votes
Undo

Update:

I have been working with Oliver on this issue for some time now. And we both came to the conclusion that there maybe is an issue in the OPC_UA client of Visu+.

To confirm this, I have been replacing the PxC HMI (TP 3185 W) with an HMI from a different supplier that also uses OPC_UA as communication platform - no problems so far.

I also have setup a test with two PLC's. The AXC F 2152 as master and an Siemens ET200SP CPU as a slave. There are also no issues to report.

This would confirm, that there is an issues with the OPC_UA client in Visu+.

  1. more than a month ago
  2. PLCnext Engineer
  3. # 2
voltaing Accepted Answer Pending Moderation
0
Votes
Undo

Thanks for sharing the information.

I have very similar problemas with Visu+ in a large SCADA.. do you know if there is another way to communicate to PLCNext with Visu+?? (hope not to do a Modbus TCP server because I have around 2000 tags ?)

peterdallmann Accepted Answer Pending Moderation
0
Votes
Undo

Hi Voltaing,

I would like to give you a short update on the OPC_UA issue:

After 1½ years there has been some development in the case. In the past few days I was in contact with Phoenix Contact for a specific project that has been my nightmare for the last 1½ years.

I have send the Visu+ project and PLCNext Engineer project to Phoenix with all the logs and fault information. Those have been forwarded to the developer of Visu+ and hopefully we will have some response in the near future.

The project in question is small in size but still Visu+ should do what it adverticed.

One of the main issue I have seen, is a problem that we have seen in the OPC_DA communication as well:

When importing variables in to Visu+ directly from the controller (OPC_UA / OPC_DA) or offline from the PLC project (OPC_DA in PCWorx); all variables get an Read / Write attribute assigned in Visu+. This has given us problems before when using OPC_DA communication. I don't know if this is a timing factor of the polling between OPC server and client or some other aspects. But it does mess up the communication. most common is the miss representation of variable states: fx the PLC variable is FALSE and in VISU+ runtime the same variable is TRUE.

A possible workaround is the set the correct attributes for each variable in Visu+ -> OPC_UA session. Read or Write. The problem becomes acute again if you have numerus variables that have to be read/write - setpoints as an example. Here I have seen an issue when you reach around 35 - 40 variables.

But all this has been handed over to Phoenix now and I do have a good feeling about my contact with in Phoenix. For the first time I feel that the issue has been taken seriously. So we can only hope that we get an feedback soon.

Especially since I have a existing system that has to be converted from an RFC 470 to an RFC 4072S to the end of the year. There Visu+ has 16000 TAGs.

As a note to Phoenix: Please work on your support! At the moment we don't have it and that makes it difficult to use or promote your product.

 

Peter Paul

voltaing Accepted Answer Pending Moderation
0
Votes
Undo

Thanks Peter for your reply. I would try the solution mentioned and give some feedback.

Hope our friends in Phoenix Contact take a place in this issue and give us a official answer.

peterdallmann Accepted Answer Pending Moderation
1
Votes
Undo

Hi Voltaing,

I know that they work on it - that is the best I can tell you at the moment.

What I don't understand is the late reaction to the problem and the fact, that the OPC_UA function is promoted as working. I think it is misleading and only generates more issues for us users.

The worst case here would be, that we look for something other.

But at the moment, I still hope that Phoenix will fix the problem at some time.

That will not help me in the short run: our client has demanded that we pull the Phoenix system and replace it with a different PLC system. He can't and will no longer wait for a solution from Phoenix.

Is a bit sad, because the PLC side is working well. Just not the SCADA application.

 

Peter Paul

voltaing Accepted Answer Pending Moderation
1
Votes
Undo

Really sad Peter... Hope not get to that point with my client.

peterdallmann Accepted Answer Pending Moderation
0
Votes
Undo

Hi Voltaing,

As an update:

Phoenix and the developer for Visu+ are working on the issue. It has also been expanded to include the Engineer side as well.

Did my tip give you any results? I would like to hear what you can find. Would maybe give PxC some more infos on where to look.

Lets see what they can find. For my project in question, well, there is no other way for me to go.

Over the weekend I have re-programmed the complete project and will during the week change the PLC. I may even get a working VPN connection in this way. The last fix for it on the AXC F 2152 works, as long as the distance isn't to long.

Don't ask me why, but around 250km physical distance is the limit before the VPN connection to the PLC is unusable.

Peter Paul

  1. one week ago
  2. PLCnext Engineer
  3. # 8
Martin PLCnext Team Accepted Answer Pending Moderation
0
Votes
Undo

After investigations here, the problem described in the original post does not seem to be caused by a fault in the embedded OPC UA server, or in anything related to PLCnext Technology.

Based on the current status, the team responsible for Visu+ (including the OPC UA Client) is working hard to find a solution to the described behaviour.

With this in mind, and considering that this is a forum for PLCnext Technology, the appropriate support channel for this issue is now via your local Phoenix Contact subsidiary.

They should already be aware of this but, for their reference, the internal case number for this issue is 00128237.

~ Martin.

Phoenix Contact Electronics Headquarters - PLCnext Runtime Product Management and Support

  1. one week ago
  2. PLCnext Engineer
  3. # 9
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.