Lookout Requires Restart On Serial Communications Failure

[Mike R]

The application is a Lookout 5.1 server process operating on a Windows XP touchscreen computer communicating through a VHF radio network connected via the serial port. When Lookout encounters a communications failure with a remote site, sometimes Lookout needs to be restarted to reinitate communications with the remote site again, even though the remote site is operating OK. The communications fail in Lookout locks up communications with that device and will not restart communicating until Lookout is rebooted (Or if in edit mode open and reclosing the Aquatrol driver object). The other sites continue to communicate OK. This issue is random in relation to frequency, time and sites in Lookout.

This same issue was previously posted in 02 and 03 but the thread seemed to end without a fix for Lookout only a suggestion that the user try a different serial port or changed the serial port or PC out. We have tried several RTS and CTS settings, different com ports on the PC and even replaced the PC. Issue still happens and is random sometimes within 48 hours sometimes all is OK for 3 weeks.

In the serial port log the last communication listed with the device is all that shows up no more attempts come from Lookout until reboot.

[GValdes]

Hello, Mike,

It is really strange that Lookout just locks the communication to your serial port. Do you know if it generates any alarms? The first thing that I will try (and it is also worth it) is to install the Lookout fixes. I will be more interested on the first link, since that takes cares of some DLLs and CBX objects.
Have you tried changing the baud rate? How about the radio modem connected to the serial port? I am just trying to isolate the problem the best possible. The last thing that I can recommend you is to create a switch and attach its value to the Poll data member of the Aquatrol object. So, when you see that the communication is halted, you can create a transition on the Poll data member to force the polling.

I hope this helps. Let me know if you have any other information that might be helpful.

Regards,

GValdes
Applications Engineer

[Mike R]

Thank you for the reply. Yes I will upgrade with the latest patches and updates, I probably should have tried this first.

I left out this info: One local site is connected along with the radio modem through an RS-232 splitter, when communications fails both the local site and remote sites connected through the modem stop as well. The baud rate and port settings are 1200,8,N,1 and are limited to this by the field hardware. The POLL RATE data memeber is set up for 30 second interval and the POLL data member is blank.

I am not sure that Lookout is locking up the PC's serial port or if the lookout driver or serial port OBJECT in Lookout is locking up. In an attempt to duplicate the issue I tried both removing the serial cable from the PC until all sites time out into data fail and I modified comm. settings in the individual driver objects to create individual data fails and when these items where returned to normal so did communications to all sites without a need to restart.

The switch connected to the POLL data member is a good idea...I have tried this, as well as a POT connected to the POLL RATE data member that changed these data member values on data fail with no success.

When the communications locks up the only way I have found to re-initiate it is to reboot, and as soon as Lookout restarts all communications with all remote sites is working good.

Another fix I have tried is using the Windows XP [SHUTDOWN -R -F] with the Lookout RUN command. Unfortunately this has not proven reliable, after the delay timer times out a quick flash of the DOS RUN command box appears on the screen then the unit only occasionally shuts down properly. Is there another way to shutdown or restart lookout on a comm. fail lockup within a single process?

Thank you for your help.
Mike R.

[JPhillips]

We had this problem quite frequently, and I believe it was due to a lot of garbled data coming through the communication port. I say this because about a year ago we installed new mds radio transceivers (all the same type as opposed to 3 different types of transceivers) and since then we have not had a serial port lock up. The garbled data coming through the serial port was significantly reduced (like night and day).

Hope this helps

Jason Phillips

[khalidfaridi]

Hello Valdes,

I too am facing similar problem. I am dialling Mitubishi based RTUs to fetch data. If the RTU is busy (as it is required to dial out to HMI if under Alarm)the Nistcubishi CLM driver returns the "unexpected format error" and then no matter what it wouldn't return data unless either lookout is restarted or the driver object is reset by getting into its properties in Edit Mode.

Imagine, I have to dial 150 stations, perhaps create 150 such objects, and ask the operator to DO what?

Other way is I use ASCII object to dial out, but in this case I lose info for as long as someone doesn't reset the driver or lookout.

With ASCII object I haven't been successful to dial out. In one computer it works, in any other it doesn't. That leaves me with using Direct driver object to dial. I might decide to write some logic to read BusyTone. But the Mitsubishi object doesn't allow that.

This problem is reported from ver5.0 and 4.5, I am not sure about latest version, lets see. Any suggestions please

[Khalid]

---

@Mike R wrote:
Another fix I have tried is using the Windows XP [SHUTDOWN -R -F] with the Lookout RUN command. Unfortunately this has not proven reliable, after the delay timer times out a quick flash of the DOS RUN command box appears on the screen then the unit only occasionally shuts down properly. Is there another way to shutdown or restart lookout on a comm. fail lockup within a single process?
Mike R.

---

Hi Mike,

That's pretty drastic. Does re-loading of the process reset the object? If yes, then you can unload and reload the process this driver object is in using the Loader object. Ideally, you would put all your driver objects (and nothing else) in a single process, called the "Server." All your other stuff would be in a diffeent "Client" process.

Regards,

Khalid

[JMiller]

We've seen this problem as well communicating with Siemens 505 PLCs via radio modems. The only workaround we've been successful with is restarting the master.

[skibum019]

We also seem to have this problem. Ours though involves another layer, the NI RS485ENET-2/4 hardware. We have Mitsubishi PLC's distributed throughout our plant, and I am connecting to some of them using this hardware and the Mitsubishi RS-485 link module. All is fine and well until any errors occur and then a restart of the host computer is required to free up the "serial" ports again.