Lookout 6.1 Modbus.cbx object- is 3/3/07 latest version?

[sjviking]

One of my clients is upgrading from Lookout 5.1 to 6.1. We are getting "Response too Short" errors on the Modbus statistics screen. The old Lookout 5.1 system has no errors, using Modbus.cbx dated 5/16/03. Both versions have the Serial Port Receive gap set for 1000 bytes to eliminate "Garbled Message" errors.

I would like to have the latest version of the Modbus.cbx object for both Lookout 5.1 and 6.1.

Thank you.

[Ryan.S]

It is the lastest version of Modbus.cbx. Actually we didn't do big changes to the modbus driver.

What's the percentage of the Response too short error?

Make a diagnostic file. Option->Serial Ports, select the COM port you use, check "Diagnostic file settings", input the file name such as d:\log.txt, then Accept. I'd like to have a look at the communication.

Check the Modbus object settings, including the receive timeout.

The receive gap you set is more than enough. Actually I think 50 or 100 is enough.

You can try the 5.1 modbus.cbx in Lookout 6.1. First you need to backup the 6.1 modbus.cbx, changing its name to modbus.cbx.bak. Then copy 5.1 modbus.cbx to 6.1 folder. Restart Lookout. Check if the problem still exists. If there is no problem then, it is the modbus.cbx's problem.

Btw, did your client have modbus.ini in 5.1 system? If yes, please also copy this file to 6.1 folder.

[rfoote]

Maybe I should try that...

[Ryan.S]

rfoote,

Generally we don't suggest to use different version of .cbx file. Most of 5.1 cbx files can be used in 6.1, if it is not modified much. I suggest sjviking to try it since he said 5.1 had no problem but 6.1 has. This will not be a solution, but it will help us to verify the problem. 

But I remember you said that you met your problem also in 5.1 system?

[rfoote]

Ryan

Actually, we didn't see the problem on the 5.1 system. We saw it when we upgraded them to 6.0.2,

[Ryan.S]

okay. If the problem only exists in Lookout 6.0.2, I will focus on the changes we made from 5.1 to 6.0.

[sjviking]

Hi Ryan:

Modbus object configuration parameters are:
115200,N,8,1
POLL RATE: 0:40
Retry attempts: 10
Receive Timeout: 5000 mS
Advanced Options: (Defaults):
   Read Coils: 2000
   Read DIs: 2000
   Read Holding registers: 125
   Read Input registers: 125
   Force coils: 800
   Preset registers: 100
   Immediately write outputs
   Skip every 4 poll requests after communication failure.

I am reluctant to use the Lookout 5.1 Modbus.cbx object in Lookout 6.1 because of the way it performs in Lookout 5. With Lookout 5.1, if I set the serial port receive gap shorter than 1000 bytes, the Modbus "Garbled Message" errors accumulate to the point where all serial communications fail. Clicking Modbus comm. Stats "RESET" will not re-establish communications. I have to physically disconnect the serial port cable and reconnect it before Lookout will communicate with the RTU again. The same thing happened when I tried to use Lookout 6.1 on a brand new Dell PC with onboard serial ports.

There is no Modbus.ini file on the Lookout 5.1 PC.

The RTU is an Industrial Control Links (ICL) Model 4300, and uses a fully buffered UART for its PC serial port. A PC serial port Receive gap of 1000 Bytes corresponds to a response delay from the RTU of about 87mS at 115KBaud: 115200 bits/sec = 11520 bytes/sec = 87microsec/byte, and 1000 bytes = 0.087 sec
The RTU has 6 serial ports operating simultaneously, and is executing data acquisition and control logic for a city water system. It is reasonable to expect an 87mS response delay to Lookout data polls.

Attached is part of a one-day log of serial data transactions for the new Lookout 6.1 PC. The first part of the log is with the serial port receive gap set at 20 bytes. I have annotated the place in the log (16:04) where the Modbus communications failed. This failure was preceded by several repeated requests for holding register data from the RTU, all with the same time stamp. The only way to re-establish Modbus comms was to reset Modbus and momentarily disconnect the serial cable. The Receive gap was then set to 1000 bytes.

There were 57 "Response too short" messages after the Receive gap was increased.

We are running the SCADA system on the Lookout 5.1 software until these problems can be resolved.

Thanks for looking into this!

John Nourse  

[Ryan.S]

Hi John,

The receive gap is okay. I didn't know your baud rate is 115200, I assumed it is 9600...

I want to confirm something with you first.
From the txt file, the actuall poll rate on this port is about 12~13 seconds, so the poll rate you set seems less than 10 seconds, but not the 00:40 you said. This is weird.
At 16:04:00, you see that the [01][03][20][6B][00][01][FE][16] is sent out and no response, then it is sent out again immediately. I want to know if it is sent repeatedly for 10 times and then waits for some time before it repeats 10 times again. As you set retry attempts=10, it should retry for 10 times and skip the next 4 poll.
Did you receive "no response" or "garbled reponse"? What I don't understand is that if you got garbled response error, the received data frame should be logged. But in the txt file, there is nothing... Here I think has something wrong.

Then, let's see the response too short error. Could you point out the time when you got the error? Tell me a timestamp, you can get it from the Alarm Window, or query in MAX. I want to check the data frame it got when you saw the error.
But actually I think it the "response too short" error may not affect the whole process. After Lookout gets this error, it will retry the same address immediately. If it gets correct data next time, it's okay. So, it's possible that the process is still working fine with the too short errors.
The receive gap you set is only 0.08 second, maybe the remote device occasionally fails to meet the gap time. From your description in txt file, you got 7 errors in 12 hours. The error percentage is less than 0.01%. I think it is acceptable. What do you think?

Message Edited by Ryan.S on 09-16-2008 04:54 AM

[sjviking]

Hi Ryan:

Adjusting the poll interval does not seem to have any effect on the polling cycle.

Before I increased the receive gap to 1000 characters, the Modbus statistics showed rapidly increasing "Garbled" rather than "No Response" error counts.   I don't know why the errors are not being logged.

I checked MAX alarms and events, with no filtering, but only two "No response from Modbus Secondary" alarms were registered. These occured whenever I connected the serial cable. No other errors were registered.

I don't care if errors are generated, as long as there are automatic retries and recovery.  I simply don't trust the Modbus driver, which has misbehaved in all versions of Lookout I have used. In Lookout 4.5, Modbus errors would halt the entire Lookout process. I had to create a separate process just for Modbus, and automatically stop then restart that process if Modbus errors exceeded a maximum value! In Lookout 5.1 and 6.1 the Lookout process doesn't halt on Modbus errors, but data communications don't always recover, and manual intervention is required. This is not a good situation for an unmanned SCADA facility!

Possibly the Modbus driver is retrying without waiting long enough for a reply, causing more errors, and overrunning a buffer, or branching to code that locks up the object. I think someone needs to look at the code for the Modbus.cbx object.

Thanks...John

[sjviking]

Hi Ryan:

One thing I forgot to mention about the Modbus driver in Lookout 6.1 is: If I make any edits to the Modbus configuration, such as changing the number of registers polled, or the comm port number, and close the configuration window, Modbus communications stops working properly. When I re-open the Modbus configuration window, I find that the baud rate has been changed! When I correct the baud rate and close the window, Modbus communications starts OK.

Please add this to the list of bugs to be corrected.

Thanks...John.