I started getting this error after the update (8.1.17 to 8.1.25)
Unexpected error initializing redundancy session. Will try again in 1 minute.
com.inductiveautomation.metro.api.ex.TimeoutExpiredException: TimeoutExpiredException[queueId=service_GatewayRedundancyService, targetIntent=_services.invoke_|2, msgData=com.inductiveautomation.ignition.gateway.redundancy.services.GatewayRedundancyService#registerPeerNode([class com.inductiveautomation.metro.api.ServerId, class com.inductiveautomation.ignition.gateway.cluster.NodeInfo])]
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
spam every minute only on redundant gateway. We are on version 1607 of Windows with most recent updates.
Ignition is running as a service and, in this case, we are requesting %TEMP% as the location to move the files. Because your Ignition service is running as a User, that is the location it is being stored at. If it were run as a System service, it would likely be stored in c:\Windows\temp. While not wrong, we do have a temp directory within the Ignition install that we should be targeting (and will be making a change for).
I am guessing that AppLocker is preventing DLLs from being loaded from that directory and us making that change will potentially resolve this issue. If we can get this change into a nightly release would it be possible to see if it resolves the issue by installing just the new module?
Us changing where the temp directory is located should hopefully resolve the issue you are seeing with the module loading. It would make sense based on everything I am reading about .dll placement and settings that can be applied.
For the other error, it looks like it is occurring when it is attempting to process the initial connection. We don't think that it should have anything to do with the 61850 module, as this would cause the peer incompatible status that you also mentioned seeing, but seeing that a connection was successful seems like there might be disconnects occurring. When you removed the module, did the com.inductiveautomation.metro.api.ex.TimeoutExpiredException error stop occurring?
@malone46844, I moved your post into this existing thread, because it's almost certainly the same root cause. If you're able to help Garth work identify what's different between your system and our test systems, it would be greatly appreciated - even if not, you can be assured we're aware of the issue and working on a fix.
If you are seeing the dependent library error when Ignition attempts to load the 61850 driver, the fix is going to be to download and install the latest Microsoft Visual C++ Redistributable package:
The Triangle Microworks library that we leverage has dependancies on items included in that package. Uninstalling the module is also an option if you don't have a need for it.
We are looking into what can be done to prevent this requirement, but that is the current solution. We appreciate your help in letting us know and providing information to help assist in troubleshooting the issue.
Edit: The following KB article has been posted about this issue: