Restart module in a Script or in Command Line scripts

Looks like it has been asked twice now with no results or help, I am wondering if anyone has figured out an answer to either of these posts?

We have a scenario where the gateway comes online and sometimes the OPC server seems to fault out on powering up. We would like to check that status and restart the OPC module.

setSeverEnabled on false than true probably triggers a restart for that connection idk
(most other connection services have a similar function)
https://docs.inductiveautomation.com/display/DOC81/system.opc.setServerEnabled

That function controls Ignition’s connections to servers, not the native OPC server itself.

You are correct that is just for the connection and not the module it self. The issue happened again this morning which required a user to login into the plc and get the module restarted, kind of annoying problem a larger system issue I need to dig into.

Hm:/
You can run scripts in cmd with
https://docs.inductiveautomation.com/display/DOC81/system.util.execute
Maybe there is a way to restart the server through the command prompt

Ok so I guess that leads back to my original question can you restart a module with command line scripts? I know you can do this but how does it interact with a module?

Not an external script. A gateway scoped jython script can do it, if you go far enough under the hood, to the ModuleManager class’s restartModule() method.

You get the ModuleManager from the GatewayContext.

Any of this is utterly unsupported and the API can be changed at IA’s whim.

The OPC server itself doesn’t have any status that could be “faulted”.

Either an OPC connection is faulted for some reason, or the entire module failed to start. Can you confirm which it is, and if it’s somehow the whole module provide some logs from startup?

hmm what if you let the command prompt surf to the accept button to the correct module?
you’ll have to get the link for your own server tho as the numbers probably change depending on number of modules you have

I am thinking its failing to start outright? Here is the wrapper log I grabbed quick. wrapper.log.txt (864.9 KB)

Okay, I see… sometimes when the module starts up it fails to bind to the configured ports because they are still in use or being held onto by the OS… :thinking:

So little more transparency this is a Beckhoff unit. I am wondering for some reason if Twincat consumes that port on start up for its OPC server it has on another port and then creates like a race condition if its not released soon enough ignition will fail.

Maybe, I don’t have any experience with those. I feel like I’ve seen this once or twice before and it’s just a consequence of running on Windows and its mediocre TCP stack.

I’ll poke around and see if there’s anything different we can be doing on our side to help.

Ok so I gave the system a restart after disabling the twincat OPC start up and ignition came back on fine, so I am guess running the service with a delayed start up the race condition will be solved. such a interesting scenario