Upgrade from v398g version

[Igor]

I have application what working fine with v398g build.
Program read and write tags only when it necessary and time between operation could be 10-20 minutes.
With v398g version everithing working good, but with later version start working corectly read and write tags
as it has to be, but after ~1 minute with no reading or writing tags it crashes with message:
"
file: EthernetIPforPLCSLCMicroCom.vb
Code Row: Return DLL(MyDLLInstance).ExecutePCCC(pccc, TNS, MyObjectID)
Message: An exception of type 'System.IndexOutOfRangeException' occurred in MfgControl.AdvancedHMI.Drivers.dll but was not handled in user code
"

[Archie]

Is this version 3.98m?

[Igor]

It starts with v398j and still with v398m

[Archie]

See if the change at the end of this post does anything

http://advancedhmi.com/forum/index.php?topic=779.0

[Igor]

I tried to change code, but it didn't work

My Processor type: MicroLogix1400
I'm using direct reading/writing thru driver to manipulate the values in PLC
...
Value = EthernetIPforPLCSLCMicroCom1.Read(TagName,QTY)
EthernetIPforPLCSLCMicroCom1.Write(TagName,Value)
...
to minimize network communication and processor load (it run on a small tablet)
if I switch to read tags each sec. everything working correctly a long time with no problem,
but app has many forms to fit in small screen size and regular reading slowed it alot.
Problem appears only when reading attempt longer than ~1 minute

[Archie]

Problem appears only when reading attempt longer than ~1 minute

It sounds like the problem is in the timeout period for the connection. Those values were changed in version 3.98j

I will do some testing to see if I can reproduce it.

[Igor]

I set
...
EthernetIPforPLCSLCMicroCom1.CloseConnection()
...
after last reading and now it works )))) even if time between readings more than 1 minute

[Archie]

This is what I think is happening.....

When creating a CIP connection, there is a timeout period set. After the timeout period with no activity, the PLC will drop the connection. The communication driver must also drop it's connection, so it knows it must open a new connection for more communication.

It sounds like the PLC is dropping connection faster than the communication driver is timing out and dropping its connection. They are essentially out of sync. The driver should drops it connection first. When you call CloseConnection, you are essentially forcing it to close, so the timeouts do not need to do anything, therefore making the driver close its connection first.

[Igor]

I agree.
Thank You for helping me alot
and for all your great work!