Hi Kevin,
I have observed that in the later versions of Ignition (7.7) , on expiry of trial period of 2 hours, the Ignition Gateway doesn’t respond to any external communication from OPC read/write or a TCP read/write thru our module. In fact our module hangs, i.e. it doesn’t come back to life after reset of Ignition’s trial period. We can’t even restart our module as on restart, Ignition will be waiting for some response from “localhost”! It gives some internal error after few mins! Our module then disappears from the installed module list and we can even reinstall our module as it again goes in wait mode from “localhost” and gives internal error page afetr some time!. We have to restart the GCU! In earlier versions of Ignition (7.6) our module used to continue to run even after expiry of the trial period of Ignition and communication with our models or OPC client used to run!
Has something changed in Ignition in later versions? How can we capture the trial period expiry event in our module and prevent such a dead lock situation!
Hi Kevin,
I am trying to make my modules which communicate with Ignition on tcp/ip sockets, robust under all condtions. In this regards I need clarification on how Ignition gateway server responds to following abnormal situations:
When trial period expires, does it stop responding to our read/write requests? ( I observe the older version 7.6 used to continue responding, but from 7.7 on wards , it seems to stop responding).
When we reset the trial period, what happens? Does it resume where it left communicating?
When server pc goes to sleep (hybernate) due to no activity or power off ? (The communication seems to work in the back ground, but I want a confirmation).
When its woken up from hybernate, does it start responding to queued requests? (As you know the OPC Server starts giving errors in log file, and we have to edit and save the server settings to stop these errors as you told me about it once).
If we restart ignition server or restart our module abruptly, will we get exception on our client module communicating on tcp socket?
I would appreciate your inputs on this to make my modules behave correctly under abnormal situations like these.
I'm not sure what exactly you're referring to that you think stops responding, but I think the answer is no. What happens on trial timeout varies by module. The drivers will start setting a bad quality on values they read before passing them on to the subscriptions, but that's about it.
Again pretty much varies by module. Since I don't know exactly what you're asking about, I'll just assume OPC/drivers again. All that happens is the driver modules stop setting bad quality. Communications never stopped.
If the server is truly sleeping or hibernating then all proccesses are suspended and no code is executing.
Sure, it should all just resume executing.
I assume when you say module you're talking about a module in Ignition. Your module gets notified that shutdown is happening. You need to do whatever it is you need to do to clean up here. Nothing is done for you. That includes closing any sockets or whatever else your module is using.
Hi Kevin thanks for your replies. Here are my comments to some of your answers:
I have Gateway module in Ignition to which I connect my external program using simple tcp/p socket giving read/write values to Ignition Tags. I send a read request from my external program to my module in ignition and wait for its response. Will I get the response to my read request to my module on ignition during trail period expiration mode? In Version 7.6 I used to continue getting response to tcp/ip read/write calls to my Ignition module even during trial period expiration mode. It was also updating Ignition data base even in trial period expiration mode. But version 7.7 on wards I am not sure how it will respond to read/write requests from external program on tcp/ip sockets. Even the OPC/UA client read requests give error under this mode (I guess that is perhaps due to driver setting staus bad). I am probing into it by trial and error, but I just want a confirmation on how it really works internally so that I can take meaures to handle the exceptions correctly.
I after doing a lot of trial and error I came to following observation/conclusions about my tcp/ip communication module, when the Ignition server goes to sleep mode (In real plant server should never sleep, but I am testing abnormal situations):
(To summarize the structure of my module, its a gateway hook module to be installed on Ignition server which reads/writes to Ignition tags based on commands received on a TCP/IP socket on a port from my external application on another computer.)
When every thing is normal, it works fine, the communication goes on smooth, but when Ignition server goes to sleep (by timeout or manually forced), then my external programs gives Socket time out exception on a read command, after 30 seconds after server sleep, which is as expected. Then I stop my external application and wake up ignition server, my gateway module on it hangs! When I try to restart my module on Ignition, it keeps waiting for a response from localhost forever! After a long wait it gives a server time out error on a new page. There is no way I can restart my module, except to restart the GCU ! Is there any way I can restart my module without restarting GCU? After restarting GCU, I am able to restart the communication module on gateway, but sometimes the module itself disappears from the module list and it has to be reinstalled!
Even if I have to restart my module after communication timer out its fine, but having to restart GCU is unacceptable! When does the restart of a module wait for a response from localhost and how to force start it? I am testing extreme conditions but there should be a way to recover from it, which is no happening.
Can you think of reasons for module restart waiting for localhost for long? Is it my shutdown/ strartup functions of my module that’s hanging up on some socket event? How to force stop?
Sorry for the rather long question, but I am getting stuck for the past two days with no solution or clues in sight. Will appreciate your comments on it asap. I need to list my modules in showcase asap, that why I am testing them thoroughly before that.
Have you tried to establish a baseline by removing your module from the gateway and verifying all Ignition services recover from a sleep event? If not, then you might want to figure out that problem first, though I don’t think sleeping is a reasonable expected behavior of Ignition.
If Ignition does go into and recover from sleeping properly by itself, you then know your problem is entirely within your module, since Ignition uses TCP/IP all over the place. Then you’ll need to add detailed logging (tracing) to your module’s communication code so you can see the chain of events in the wrapper log after you go into and recover from sleep. It sounds to me like you aren’t handling error codes or exceptions from your underlying network sockets. Sockets aren’t expected to stay open through sleep, though the sleeping code won’t discover that until it wakes.
Thanks for your comments. I did try various socket comfiguration options but all in vain. I tried setting setReuseAddress(true) option, tried making setSoTimeout(0) but has no effect. You are right, ignition gateway wakes up after a sleep mode restoring itself and every thing else back to normal, so it must be something to do with my modules. Even an OPC UA Client detects no response from Igntion OPC UA server in case of sleep or loss of connection, and go to sleep and wake up again once normalcy is restored. So I am trying to achieve the same thing in my module. Hope I find a solution, but I guess under normal circumstances , Ignition server will not hybernate or sleep any time! But we must safegaurd our models so that they always go to safe mode.
I will coninue my trails and errors approach of testing and fixing the problems. Hope i get a solution soon.
Hi,
So far I have come to the conclusion that there is an issue with version 7.7 (LTS version) of Ignition after it goes to sleep and wakes up after some time. The module signing , restart , the OPC UA server they all give problems after the Ignition wakes up from sleep. The module restart keeps waiting for some loclhost event and eventually it gives Internal Error screen! It never used to happen wtih version 7.6 , which used to work fine with our modules even after restart of a module.
Hi All,
I installed my module on Ignition 7.8.3 version. This seems to behave in a much predictable way on Ignition trial period expiry, server hybernate and wake up and restart of my module! However I installed Ignition 7.8.3’s 32 bit version on Windows 7 laptop, where as 7.7.8 was on 64 bit windows 10 laptop. I don’t know whether its an issue with ignition version 7.7.8 or its 64 bit version or Windows 10 OS or something else like hybernation settings on the two laptops! In 7.7.8 even OPC server used to start giving some errors in log file continuously after it wokeup from hybernate state, where as in 7.8.3 this doesn’t seem to happen! In real plant environment ofcourse the situaltion of hybernation/trial period expiration will not happen. I hope customers will use/upgrade to 7.8.? and use the latest version.
Jsu an observation I wanted to share with you all.