I have experienced a problem, where OPC-UA state was faulted.
My only guess is the lack of system memory. Could it be?
Java was using quite much of RAM.
Also my Designer have been opened for a couple of weeks without restart.
Can’t say for sure without seeing your logs.
How can I extract logs for a specific date and time period?
On the console page of the gateway you can click ‘export logs’ and send them to us. There’s not really an easy way to go back into history to a specific timestamp in the console.
OPC-UA faulted on another server.
Screenshots and log is attached.
UA server error message.txt (3.53 KB)
The same happened just now on completely different server.
I have attached log file.
The same happened on this machine exactly 2 weeks ago.
Also I don’t know if it is related, it seem to happen when Java use of RAM has reached amount of 1,5GB.
OPCUA Faulted.txt (3.64 KB)
logs.bin.gz (843 KB)
It looks like you are running out of memory. It’s almost certainly a leak in the COM module or related to all the OPC-COM errors in the console.
What version of Ignition is this?
Can you go through your scan classes and remove all the bad items that are constantly being resubscribed (look at the messages in the console, they tell you which logger to turn to DEBUG to see status codes).
Both machines run Ignition version 7.6.7 (b2014082615) | 32-bit
I will do so, thank you.
Gateway just crashed with no obvious reason.
I was just editing UDT tags and Gateway stopped.
I am attaching LOG file to this reply.
Could you please look at LOG file, maybe you could determine what has happened?
logs.bin.gz (783 KB)
If I gather correctly from the logs, you have about 152 scan classes, correct? How are these scan classes defined? Are they all driven? Are they all similar? Is the tag provider internal or external?
I would really like to try to narrow down why they are constantly changing. My guess is that they are driven and the tag qualities may be going in and out. I’m not sure that this is the cause of your issues, but it could definitely be adding strain to the system.
Also, you could go to the install directory, go to “logs”, zip the wrapper.logs files, and post them here or email support? Those files might contain additional messages about why the system crashed.
That’s correct, those scanclasses are driven by tags getting values through UDP (OPC-UA/Devices/UDP Driver). Different UDP port for every station telling scanclass when to go to the fast rate. It happens by event from controller, otherwise it waits for 400 seconds. After 400 seconds all scanclasses go to the fast rate. I have attached screenshots. Scanclasses provider is [default], so it’s internal.
OPC Data Mode is Subscribed for OPC-DA COM Connection devices and
Read for Modbus TCP devices. I we assign Subscribed for Modbus TCP devices, after tag read session tags qualities go bad for some reason.
For OPC Com devices we are using 3rd party OPC server and Modbus TCP devices are defined under OPC-UA/Devices. Devices are using 3G connection.
We are using the same scanclass/connection system on other servers, which are running without a problem, but there are only OPC COM devices in use, not Modbus TCP like in this server.
I am attaching log file as well.
wrapper2.zip (1.52 MB)
wrapper.zip (1.2 MB)
I have upgraded OPC Core components, Java and Ignition to x64 version and gave to Ignition 3GB of memory through ignition.cfg.
It seemed that lack of memory was the issue.
Now it seem to work much better, but maybe it’s too early to tell yet.
Am I right, or maybe you were able to identify some other problems?
That could be the case, but I would like you to also keep an eye on the memory used by the actual java process, in the windows task manager.
We’ve seen memory issues with the Read mode where Ignition will report a stable amount of usage, but the actual java process continues to grow.
If you observe that, try using the version of the module attached to this file. It has an updated version of the underlying library, and has fixed the memory leak issue for some customers. It has been generally stable, but we had one customer that had different stability issues because of it.
OpcCom-module.modl (1.67 MB)
Is this suitable for x64 version?
Yes, 64 bit is fine.
The thing is, we don’t use Read mode for OPC Com devices, it’s Subscribed.
Now java.exe memory usage grows every day.
We use Read mode for Modbus TCP devices. If we assign Subscribed for Modbus TCP devices, after tag read session (when scanclass goes to fast rate) tags qualities go bad for couple seconds for some reason.
Modbus TCP devices are defined under OPC-UA/Devices. Devices are using 3G connection.
We would gladly use Subscribed for Modbus TCP devices as well to reduce system load.
Could you please help to understand, why Modbus TCP tags qualities go bad for couple seconds when scanclass goes to fast rate? And how to solve this?
I have found last years post with the same problems we have described:
inductiveautomation.com/forum/v … b54#p46616
There you attached updated OPC-UA-module.modl for version 7.7.1 and said that it “might be backported to 7.6”. And we have version 7.6.7.
Could you please tell, has it been backported to 7.6? Maybe it could help us.