Hello,
after two years of trouble-free operation, the PMT50 power panel exhibited a strange behavior once. The OPCUAConnectionOK channel remains TRUE, but all other channels are inactive. There is no diagnostic information indicating a problem, yet values such as temperatures and ModuleID drop to zero.
The only way to restore communication is to reboot the device; there appears to be no other method to restart the communication.
The panel acts as an OPC UA server, while the PLC reads from and writes to the channels as a client. An application OPC UA connection is also established, but it exhibits the same behavior—method calls end with an error.
Has anybody experienced this behavior before?
Does anybody know whether the node quality or node error ID is evaluated? If so, then OPCUAConnectionOK should not be considered TRUE in this situation.
When OPCUAConnectionOK = True, the server is started, and UA communication with the server works.
More information about errors on the UA interface can be found in the Communication logbook. I would expect something like a subscription error or something similar.
Hi Jaroslav,
the problem is that I need to detect a channel malfunction (e.g., poor node quality or a node error) in my application, and there is no diagnostic tool available except checking it in parallel through an my OPC client application subscription.
Once the problem is detected, I need a way to restart the connection automatically. However, all of the required functionality appears to be internal.
Yes, I can restart the communication manually by switching it OFF and ON again, but that is not a real solution.
I need a way to detect the problem and recover from it automatically.
Hi Corne,I forgot to mention that the logger does not show any misbehavior. I have attached the connectivity log.
The problem was detected on 23/06/2026 at around 14:30, but I don’t know when it actually started. Afterwards, I connected via Site Manager and tried to restart it at around 17:45.
The Connectivity log shows 14 OPC UA connection lost (3 on today) and 3 OPC UA connection failed errors.
I can’t correlate yet why these errors are coming.
Could you supply all logbooks, so that there is more information available like downloads or warmstarts?
Otherwise I would expect external influences like bad cable, emc-problems.
Is the PMT50 directly conneced to the PLC or is there a switch or hub used?
Is the PLC a X90 cpu?
Hi Corne,
in the attachment, you can find the complete logger. Logger_26_06_2026_01.logpkg (7.0 MB)
Yes, there are devices between the PLC and the panel, but I suppose that any connection issues would affect the entire connection, not just individual nodes.
On Friday, I was on site at the machine and tried to test and reproduce this behavior. During all my tests, the nodes lost connection at the same time as the OPCUAConnectionOK channel. However, these tests were performed after the image and hardware update, but there are no indications in the revision information that any changes were made to node quality processing and IO capabilities.
There is a C80 on the other side. The PMT50 was selected because of the challenging environment.
The plc time is sometimes set by the NTP-Client.
Does the PMT50 also use the same NTP-server for getting the same time?
Do you use the latest firmware for the PMT50.
There seem to be al lot of OPC Client disconnects done in the PLC, where the server is the PMT50 device. Why so many ?
Hi Corne,
yes, both the PLC and the panel are synchronized with the same NTP server.
When the incident occurred, the old Linux image (v1.6) and hardware update (v1.1) were installed. Those were the current versions three years ago when the machine was commissioned. Now, they are updated to latest.
I’m not sure why. My OPC UA client has subscriptions to several variables, and sometimes it sets the buzzer and display brightness via methods with parameters, depending on the application’s needs. However, I’m not sure whether calling those methods creates a log entry.
Sorry,
those connections and disconnections were all carried out during our serviceman’s visits as part of several updates and the subsequent monitoring period.
Michal Malek