Showing results for 
Search instead for 
Did you mean: 

Lookout 6.0.2 modbus rtu problem?

Go to solution



On that ag system, I set the serial port connected to the radios this way:


Receive gap 200

RTS 100

CTS 100


I set the PollRate on the radio sites this way:


PollRate 0:12 (12 seconds)

Retries 2

Timeout 1000msec


A complete poll at the largest of the radio sites takes 8.8 seconds aprox, so that leaves 3 seconds aprox for Lookout to do housekeeping/database tasks.


The hardwired serial port:

Receive gap 200


The hardwired modbus object:


PollRate 0:08

Retries 2

Timeout 1000 msec


That site takes 5.5 seconds for a complete poll, leaving 2.5 seconds of idle time.


After 6 hours everything looked 100% good.


However, this morning I was informed that polling had failed and Lookout was only polling 1 site again. This time there were overflows.

I am headed out to the site this morning and will post the results if it is early enough (it is a 5 hour round trip drive).


I hope we can find out why Lookout is breaking down. It seems that no matter how we set up comms, it just keeps failing.




Roger Foote

0 Kudos
Message 41 of 89

Almost forgot...

There were no com fail pages.

0 Kudos
Message 42 of 89

rfoote:  When the comm stops working on our systems, usually 2 or more sites have the update member as false.  We added a timer that watches for more than 1 non-updated site (minus commfails!).  This timer activates an alarm that notifies the operators.


seudo:  (((member1.update+member2.update +member3.update)-30)-(member1.commfail+member2.update+member3.update))>1

description:  add all the updates, subtract from total sites (30 in this case) then subtract actuall commfails, if more than 1 because its a single comm link, start a timer (1-2 total poll cycles).


Good luck



Mike Crabtree - Lead Developer
Destek of Nevada, Inc. / Digital Telemetry Systems, Inc.
(866) 964-6948 / (760) 247-9512
0 Kudos
Message 43 of 89



Yeah, I did something similar using on delays fired by the update datamember per RK Domer.

Ended up replacing modbus.cbx with v5.1. I guess we will see if it chokes now...

0 Kudos
Message 44 of 89

At 3AM Sunday morning Lookout polling failed again. This time the modbus update member assumedly stopped firing the on-delay timers I installed, we will look further today while there.


I wrote a sequencer object to replace the PollRate timing and will install that today so that no 2 modbus objects can be active at one time.

Only other thing I casn think of is incompatability with the new MOBO, an INtel "Classic Series" with a Core2 Duo. These new MOBOS have no RS232 ports, not even internally

so we are using a Digi USB>RS232 adapter.


Thinking of uninstalling and reinstalling Lookout while I am there. Been a long weekend.



0 Kudos
Message 45 of 89

We have used a USB>RS232 with success for many years, granted not with modbus.

 Mileage may vary of course 🙂

 We are using PCI>Serial cards for our new systems.



Mike Crabtree - Lead Developer
Destek of Nevada, Inc. / Digital Telemetry Systems, Inc.
(866) 964-6948 / (760) 247-9512
0 Kudos
Message 46 of 89

System collapsed again last night. After I created a sequencer to fire modbus objects. Worked fine until late.

One behavior I see that makes the situation worse is that when Lookout loses comms with a SCADA Pack and comms return, Lookout polls that device between 12 and 14 complete cycles before returning to the other sites. The sequencer just goes through it's steps and never gets away from the site that just restored comms until 75-91 frames.


So that buffer issue is not helped by using a sequencer.



Why does Lookout poll dozens of complete polls after comms have been restored? I see no good reason for that behavior since it creates chaos in the polling cycle.

The sites that get ignored back up into the buffer and it all breaks down. Any ideas welcome!


Btw, my polling steps are 30 seconds long now and still having the problem.


I am headed down there again today, another free service call.



0 Kudos
Message 47 of 89
Did you calculate the cycles by the received frames or get it from the diagnostic file?
I tested your process here again with the comms failure. It's the second process you uploaded. After the comms on one site failed and then returned, I saw that it did get more than 75 frames . I looked into the diagnostic file and found that it did a lot of write functions. All the 75 response frames were in one poll, and most of them were the write function. After the comms returned, the modbus object restarted the communication and wrote the current value of all output items to the device one by one besides the reading. So, is this the same issue you saw? Maybe the 75-91 frames you saw were not multiple polls, but only one. Since it's wireless, 75 frames might take much time to finish, but it is expected.
After the 75 frames received, did the process continue to run and poll other sites correctly? This is what I want to confirm.
So, could you set up the diagnostic file? It can tell us what happened, if it polls for once or multiple times.
I will continue the test, hope to figure out something.
Message Edited by Ryan.S on 09-16-2008 01:22 AM
Ryan Shi
National Instruments
0 Kudos
Message 48 of 89


The remotes always do the streaming thing when comms are restored and that is not new. The old system did that as well.

What is different is that there are times when Lookout never comes off of the site being polled for times ranging from 8 minuted to several hours.


What we did yesterday was to build a new, different PC with a PCI serial port card. I haven't heard back from them yet.


One note is that when a SCADAPack ;polls another SCADAPack we don't see this behavior. In that case, when comms are interrupted and then restored polling just picks up again.



0 Kudos
Message 49 of 89

Things are worse, much worse.

Relaunched Lookout and the first site has been polling ever since with lots of errors, when I hung up with the manager it was at 2,400 polls and never went to the other sites.


Another note, the alarms stayed on the alarm window after relaunch even before any polling happened. IIRC, that is different, since alarms are cleared on launch. Is that correct?


Is there a problem with these "Classic" MOBOs using Core2 Duos? We never saw this until the original Intel 945 died and we replaced it with this.


We ditched the USB>Serial and went with the same model PCI card that was in it originally.

Rebooted all the modems and PLCs.

Rebooted the PC (cold start)


I am running low on ideas now. It had crossed my mind to move my work computer over there (a 2003 Dell 2350) and see if we still have issues.  

0 Kudos
Message 50 of 89