immediately write outputs - more on modbus plus performance

[frisk]

more on modbus plus performance

I have more dilemmas considering modbus plus. I'm trying to reduce the unnecessary traffic as much as possible, so I've unchecked "immediately write outputs" in advanced settings for modbus plus hoping that lookout will write to plc only when modbus object is polled. However, it seems that it doesn't happen that way, looks to me like lookout is writing to plc poll or no poll. I need to cut down the traffic because I have delay in system response and I'm considering lookout's share in it.

I have a feeling that making a system with deterministic response (which should be one of mb+ highlights) is quite cumbersome and sometimes impossible.

Can anyone comment on this issue and maybe share ideas for improving modbus response time? Is there anything about modbus plus and lookout on ni.com that I'm not aware of?

Darko

[Richard P.]

Hi Darko,

Lookout is event-driven. Any time a value is changed on the panel, this new value is sent to those items which are connected to it, and to the database as well. PLCs have poll rates, so if you can reduce the poll rates of any PLCs you can reduce network traffic. Because the timing is dependent on network activity, and on the way Windows divides CPU time between different programs and processes, Lookout is not more deterministic than other Windows software.

[Khalid]

By default, Lookout writes Outputs immediately (without waiting for the poll).  BUT, if you uncheck the "immediately write outputs" setting, it should write only when polled.  If it's not doing this, it's a bug -- can someone at NI verify this? 

Couple of things you can try for improving communication performance:

1. Make sure you're not writing outputs every-so-many polls (unless you really have to).  By default, Modbus Object writes the Outputs every 100th poll -- even if none of them have changed.  Use the Modbus INI settings to change this behaviour:

http://digital.ni.com/public.nsf/allkb/2E64D5CF87CA6A1086256BB30070DC1A

2. If you have some IO points which don't need to be read as fast as others, use a second Modbus object for these with a slower poll rate (but on the same address, etc.). 

3. Use an appropriate update deadband for your analog reads -- you can filter out "noise" from data this way.  Note that the IO are still read every poll, but aren't propagated to the rest of the system unless the deadband is surpassed.

Hope this helps,

-Khalid

[Richard P.]

Hi Khalid,

I checked into this and there are no reports filed of a bug with this. I think your other suggestions should produce some results. Thanks!

Richard

[JohnBishop]

Our company found a modbus performance issue a few years ago when we tried updating from lookout 3.8.  It seems that the modbus driver was re-written and has never been fixed since.  In all of our tests, the immediate writing of outputs was fine.  Every 100th scan, the poll writes all outputs to the modicon device causing a 5 -15 second delay during our tests.  This occured if we were using 10 outputs or 500.  National Instruments has been aware of this problem, and has said they would look into it and include a fix in the next release several times now (we are still using lookout 3.8 primarily).  Our workaround has been to disable the polled writes (settings for this are in the lookout.ini file) and manage our own forced polled writes if any issues arise with the state file.  I hope this helps.

[Richard P.]

Hi John,

Is the problem with the writing every 100 iterations of the poll as Khalid has commented on above, or is the problem that it takes too long?

Richard

[JohnBishop]

Yes there is a problem writing all outputs on every 100th scan.  I have not investigated in detail what is happening on the 100th scan, but lookout will lock up for 10-15 seconds while trying to write all outputs to a modicon device.  Our company worked around this, but we would like the default driver to perform the writes a little quicker.  I wrote my own driver to accomplish this every 200 scans, and have had no problems.  I assume lookout is reading the inputs while trying to write all the outputs, creating a nested loop of timeouts.  Personally I did not think this issue was too difficult to fix on a driver level.

[Richard P.]

Hi John,

This is also possible through the INI file, as in the KB linked to by Khalid.

Here is the section to add:

UpdateOutputs
UpdateOutputs=50

UpdateOutputs specifies how many poll requests pass before the driver rewrites all outputs to the device. For example, if UpdateOutputs equals 10, every tenth time the Modbus object receives a poll request, it writes all output values to the device. This ensures that the device is synchronized with Lookout. The default value is 100.

Please check into this if your driver causes you any difficulty.

Richard

[JohnBishop]

Richard,

That is exactly the problem.  One may reduce or increase the time for the driver to rewrite all the outputs, or simply disable rewriting all the outputs.  That does not change the fact that in Lookout 3.8 there was not a delay when rewriting all outputs to a modbus device.  Lookout 6.0, 6.01, 6.02 there is a significant delay rewriting all the outputs.  This delay is in the upwards of 10-15 seconds regardless of how many scans before this rewriting.  Even if I told the .ini file to update every 100000th scan, it will still lock up for 10-15 seconds on the 100000th scan using the default modbus driver.  The only way around not locking up for 10-15 seconds is to disable rewrites altogether.  When one disables the rewriting, all should be well until the state file corrupts.  Then, a problem starts.

[Richard P.]

Hi John,

If you can save a log from your serial port, during the 15 second delay. Then attach it here. we will take a look at it as nobody in R&D has heard of this. Serial protocols and TCP are inherently non-deterministic protocols (to comment on the orginating post from the other user) but we don't expect serial or TCP writes to take 15 seconds.

Please use a Lookout process that contains only this modbus object, so we konw the error is isolated to the object and its driver, and not the process file. Please attach the process file here as well (the .lks).