lookout modbus plus performance

[steatar]

I'm running 9 Schneider Electric PLCs Compact 265 connected to Lookout v5 PC via modbus plus. I have cyclic stalls of transport, each 50 secs or so, which last for 3 or even more seconds. I've tried all the settings there are on modbus object in Lookout, but with no success, only different graph shapes in performance monitor (you can have a look at graphs at the end of mail). Even single PLC on network (with others shut down) freezes the communication for more then second, which is unacceptable since I need to refresh my data at least each 350ms.

I've considered 3 things:

1. PLC underperforms

I've checked scan time in PLCs, they're all running smooth with scan time under 90ms. This time doesn't increase even during modbus peaks, I've reduced watchdog to 100ms and it never triggered. Looks to me like plc has more than enough time for modbus, so plc should not be the problem.

2. PC underperforms

Hardly a problem, PC running under 5% most of the time, never goes over 50% no matter what I do.

3. modbus underperforms

Statistics show no garbled or timed out frames on any plc, so wiring should be fine.

PLC uses 130 registers of memory (type 4 – holding register). With all registers back to back (no slack between registers), this should mean that all the memory can be transferred in 2 frames. This also means total data load per sec should be

9 plcs * 3 refreshes * 130 reg * 2 bytes = 7030 bytes.

Even with overhead included, this is so little compared to theoretical 120 kbytes modbus plus should be able to perform, so nothing else for me to do but scratch my head.

I've checked Lookout source for any loops which could initiate some read or write at 50sec cycle, but there's nothing even close anywhere in program.

Am I missing something? Can anyone tell me why modbus freezes my system?

Bye everyone,

Darko

SVETLOST TEATAR

 

[Jeff M]

Hi Darko,

Sounds like you have been very thorough in narrowing down the problem.  I'm not sure what could be the cause of this.  Has this application always shown this behavior?  Or was the application developed in stages, in which maybe it functioned correctly when it was smaller or communicating with fewer PLC's?

My suggestion would be to narrow this down even further to testing the modbus object performance on a smaller scale.  As a test, perhaps try to save the process as a new name, and remove all functionality except for communication with 1 or 2 PLC's and see how the performance changes (i.e. if the 3 second delay is still present). 

Regards,

Jeff M.

Applications Engineering, National Instruments

[frisk]

Hi Jeff,

I'll answer question by question:
1.
Has this application always shown this behavior? 

Yes.

2.
Or was the application developed in stages, in which maybe it functioned correctly when it was smaller or communicating with fewer PLC's?
No, I've never had properly functioning version.

3.
My suggestion would be to narrow this down even further to testing the modbus object performance on a smaller scale.  As a test, perhaps try to save the process as a new name, and remove all functionality except for communication with 1 or 2 PLC's and see how the performance changes (i.e. if the 3 second delay is still present).

Did that. I removed most of the program from PLC, but the peak remains unchanged, which leads me to conclusion that the problem must be in lookout. If I use only one PLC, the graph remains the same.

Looks to me like Lookout is reading all the PLC memory at peak times. I don't see no configurable param in modbus object for this, nor I see modbus transfer trigerred by "my" action in scada. Back to square one, I don't know where to look.

Any other suggestions is welcome.

Thanks,

Darko

[Larson E Fraud]

I also have a performance problem with Modbus object communicating with a PLC (Control Microsystems SCADAPACK).
If one looks closely at the Lookout documentation "Modbus Configuration Dialog Example", the example shows a poll rate
of "0:01". The documentation states that this is polling everty TENTH OF A SECOND!
I made the mistake of assuming it was polling every second. I have never seen a time value specified this way.
In the next few days, I will confirm if the documentation is true.

Kalle Leppik
NIELSEN SYSTEMS
819 827 3971 (TEL)
kleppik@ieee.org

[Larson E Fraud]

Darko,

  The problem may well be your PC. Microsoft Windows operating systems are not real-time OS. I have run into
the problem where a time critical task needed to be done every 70 ms. My application would perform properly
for 30 sec and then hang. The Windows OS (NT, 2000, XP) simply pre-empts you application and goes off
and performs an OS task (flushing disk buffers or whatever). I do know that Microsoft did have a real-time version
of NT. Not sure if Microsoft has real-time version of XP.

Kalle Leppik

[Khalid]

Hmmm..  I always thought "0:01" was every second. 

-Khalid

[erblock]

Do your Schneider PLC's have an adjustable "communications window" setting?  How about memory and disk write out performance on the PC?  Do you have access to a dual CPU PC to see if things improve?

Just hunting....

Ed

Oh, and 0:01 is definitely one second in Lookout

Message Edited by erblock on 08-28-2005 03:03 AM

[frisk]

Hello,

It’s been a while since I last checked the forum, but in the meanwhile I’ve resolve the problem.

The solution lies in modbus.ini and the way modbus object communicates with modbus secondary, an issue not properly covered by help and ni.com. Unless defined otherwise in modbus.ini, modbus object will refresh all of the configured memory points in your plc each 50 or so polls (I can’t remember which is the default value). This can be a problem if the number of memory points is large, because it congests modbus and creates performance stalls.

You can read more about this here: Lookout Driver Objects - Custom INI File Settings (http://zone.ni.com/devzone/conceptd.nsf/webmain/E54F75254BBE772786256CFC00700B5F).

Thanks everybody for joining in.

Bye,

Darko