Lookout 6.0.2 modbus rtu problem?

[Ryan.S]

Hi Roger,

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

[all]

RefreshOutputs=0

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.

[rfoote]

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.

Thanks again

Roger.

[Ryan.S]

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.

[rfoote]

Ryan I mean after exiting and relaunching Lookout, but we can also disable polling as we have a switch object anded to the sequencer output that is connected to the Poll datamember. After relaunching Lookout, polling will start and continue normally. Turning the switch off for the site that is refreshing too long lets the other sites return to a normal polling cycle and turning the switch back on lets the offending modbus object return to normal polling. It appears that Lookout is having problems keeping the serial port secured, but that's just a guess. In any case, the new modbus fix does keep these issues from bringing the system down. From what you said in your last post, turning off refresh outputs doesn't sound like a good idea. Thanks again Roger

[rfoote]

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

[rfoote]

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.