On that ag system, I set the serial port connected to the radios this way:
Receive gap 200
I set the PollRate on the radio sites this way:
PollRate 0:12 (12 seconds)
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:
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.
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).
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...
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.
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.
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.
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.
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.