Lookout tiway object commfail stuck

[christeb]

  I have three Lookout 5.1 stations monitoring seven Siemens model 555 PLCs over ethernet. We had a serious power issue Sunday, and an eventual blackout for several hours. The Lookout stations came back up, but can only monitor six of the PLCs now. It seems that the Tiway object commfail is stuck. If I create another Tiway PLC object in my application, and modify an object to look at the PLC through this new Tiway object, it works. The network is fully functional. I can monitor this PLC with programming software over the ethernet connection. I can ping the PLC. I have installed my archived Lookout application on a laptop, connected to the network, and it works just like the rest of the stations (it can see all of the PLCs but the one). I created a new application on my laptop to monitor one point on this PLC, and it functions fine. It seems that Lookout is somehow stuck in the mode that the communications has failed, but since several stations all have the same problem, it must be that Lookout is monitoring some commfail bit in the PLC that hasn't been reset. I can't power down this PLC until our next shutdown, and re-addressing all of the objects to my new Tiway object would be a lot of work. Plus this might happen again in the future, and I'd like to have a solution for this issue. Any idea what bit that the Lookout Tiway object monitors? Any suggestions?

[Ryan.S]

As you said you can successfully communicate with it by creating a new object, I think there is an simple way to have a try that you edit the property of the object, change some parameters and then apply. It might work again.

If they are only run-time servers, try to close Lookout application and open it again from the .lks file.  Make it recompile.

[christeb]

  I tried to edit the property of an object, and this didn't work. The only thing that has worked so far is to create a new driver, and point the object at the new driver (which proves the communications work). 

  I tried recompiling the lks file. I tried using newer version 6.0 from my laptop. I tried modifying the tiway driver to use the RS232 port on the PLC using a cable connected to the com port on my laptop. I tried replacing all of the tiway driver text in the source file with a new name (using Word). Nothing has worked. I have over 1200 instances of this driver name in the program, so I don't want to manually reconfigure all of the locations.

  I set up a duplicate test PLC in my ofice that I can communicate with over ethernet or the com port, using my archived PLC program and any of the above test scenarios. But the archived PLC program from the on-line PLC won't work in my test setup. I've narrowed the problem down to something in the PLC that Lookout doesn't like, but still don't know what actually caused the problem. We've never had a corrupted program before where only one thing would give us a problem, and everything else in this system is working properly. Plus I can communicate online with this PLC through the ethernet port using Softshop, and through the com port using Tisoft. I now know at least downloading our archived PLC program will correct this problem, but I'll have to wait for a shutdown.

  If you come up with any more ideas, I'll try them. Thanks.

[christeb]

  For anyone that is interested, I have discovered the problem. Somehow the PLC memory configuration got changed to a smaller value (I suspect by a maintenance technician during the shutdown weekend). The Lookout configuration was monitoring some memory locations that no longer existed in the PLC, so it displayed "communication error". That's why I could configure a second Tiway driver and make some objects work by using this driver. The particular objects that I randomely selected to modify didn't use the higher memory addresses, so they would work.