I see. You configure connections on both modbus driver and the pot/switch.
It is expected that it polls 70 frames after a break in communications. Lookout is designed in this way that after a communication failure, the first poll will write all the outputs to modbus slave. Your process needs about 70 frames for each site to write all outputs. So I think it is expected behaviour.
You should see it receive 70 frames every 100 polls. Since you set the retry attempts to 10, it is possible that occasionally it takes more time to retry when communication has problem during the updating outputs.
Follow this KB to disable the "update outputs". http://digital.ni.com/public.nsf/allkb/2E64D5CF87CA6A1086256BB30070DC1A?OpenDocument
If you don't see modbus.ini in Lookout folder, just create one by yourself. Input
Another note, modbus protocol defines the function 15 and 16 to write multiple coils and registers. But write is different from read. Only if two or more coils or registers are contiguous, modbus will use thess functions. So, if you configure contiguous coils, to update them need less frame by function 15. Your process uses function 05 and 06 to write single coil and register one by one, this is why it needs 70 frames to update all outputs. Maybe this can be an improvement in the future.
For example, if you have connections on coil 100, 102, 104, 106, it needs four frames to update them. But if you configure 100, 101, 102, 103, it just needs one frame.
Hi Ryan, thanks for the response.
What you say makes sense. We can live with the refresh cycle now that the fix you provided keeps Lookout from going into an endless cycle even with 100% good comms.
We have seen instances where the refresh cycle goes longer than the normal 70 or so frames.
When this happens it is as if Lookout thinks there are comm problems, maybe it has trouble securing the sreial port sometimes? I say this because if I terminate comms at this point, everything gowes back to 100% good communications immediately. Still think there is a bug in there.
Are there any downsides to using a refresh=0 in the ini file? It would seem duplistic in my system.
I would like to have the outputs in contiguous blocks but I won't be able to do that. Certainly would be nice, but it would make troubleshooting the PLC code a nightmare.
How do you "terminate comms"?
Do you mean to disable the "refresh output" in ini file? If you set it to 0, it just stops refresh the outputs. All the output connections, like modbus.1 = switch1, will be updated only when you operate the switch/pot. Ideally it's enough. But it is possible that the value in PLC is not consistent with the one in Lookout occasionally.
We need a way to turn off the "Solved" icon!
Last night this system stopped polling on one of the RS485 ports that we are using. I have alarms tied to modbus update members.
We had "polling failure" alarms active for all sites except the other port on the same card.
We had some mssql errors in the winows event viewer when this happened.
It seems as though Lookout just lost connection with the one com port.
Going down to re-install Lookout and post any info later
One disturbing behavior we noticed is that Lookout is randomly changing setpoint values to maximum values on pump controls resulting in overflows. In one case we had 20,000 GPM running for 2 hours without alarms... It is important to note that this maximum value only exists in Lookout's pot object maximum value, not in the field device which can accept setpoints from 0- 65,535.
I did a complete remove/re-install and it runs flawlessly for around 30 hours and then starts having problems again.
I have not seen this before. Are there certain points/registers or random?
Again, none of our systems have exhibited this behavior.
I had not seen this before either. It is totally random.
Lookout is defaulting to maximum setpoints for whatever reason. 15 is the highest value in these pot objects and that is the value that we see when this happens.
I went through the PLC code to be certain that this can not be the field units, but there is no reference in any of the PLC code to any number other that raw data. Lookout is the only entity that can make that setting.
We had hardware HMI screens at the sites and we still saw the problem after those were disconnected as a troubleshooting step.
Maybe I should look at the datagood member and trend it? I suppose I should look at the CPU usage if and when we can catch it in the act so to speak.
I know you probably know this but, having been doing new PLC code for a project. Ensure that the numbers you are using and the correct type. BCD, Binary, Decimal, Hex, etc.
When developing the HMI the objects were set for decimal, but the PLC was using BCD.
Yup, I can verify format being correct... Plus if that was the case, I would have seen problems when the system was running in the shop.
Funny thing is that this system has been in service for years and we add a site every year. Well, the problems get worse with every site added like we are approaching some performance ceiling. Sure hope not, but someone alluded to just that being the case for them but more in the 1,000 I/O area. But that is most systems for those guys.
Having a hard time wrapping my head around why after a re-install the system would work flawlessly for 30 or more hours and then seem to start struggling to keep up.
Gettting dots instead of trend lines.
I will go out, diconnect lookout and do brutal communications tests thosands of times more dense than the modbus transactions between the main radio and the sites and those tests show 100% good transactions (no dropped frames)
then go back to Lookout and it will still be struggling.
Re did firmware on all radios and PLCs, performed feedline tests on all antennae, tested radio output power, recompiled all process files in lookout and trashed the database and started new ones, disconnected HMI screens, deleted connections to pots reading back from the registers in PLC, increased polling time to 1 minute and set Modbus to skip 2 poll requests after com fail.
I even put the V6.0.2 modbus.cbx back in the system but then Lookout would barely communicate at all so I put in Ryan's modbus fix back in and things went back to "normal" as in partially working.
Might still be a bug in modbus that our processes are stressing.
Starting to run out of things to try but I am going to put in yet another PC as soon as I get the optically isolated RS485 card for it.
Oh, yeah tried a dozen different serial cards and 3 different USB to Serial adapters. Always the same result though.