Communicator using 100% CPU

[inpelsa]

Hi!

I have this problem on 2 different computers (was win2003 and now Win7, both virtualized through) every few days on the win2003, ever few hours on the win7.

Communicator is configured to use a virtual serial COM port with Lantronix Software pointing to a lantronix RS485-Ethernet converter over a wireless connection.

I have been using this software/hardware for several years working perfectly over wire connection. Wireless is just a testing environment.

I do not expect a loss-less connection, just… communicator not taking over the CPU.

Any clue?

[Mikhail]

Hello,

communicator not taking over the CPU.

Sorry, I didn’t catch what the error is?

[inpelsa]

Communicator usually uses very little CPU, but seems it tries to open the serial port too aggressively (through it has a 10 seconds delay)

Any idea to debug this?

[Mikhail]

Please, post a part of the communication line log when this situation occurs.
If you stop communication line (from context menu), CPU load become low?

[inpelsa]

“El nombre de red especificado ya no está disponible.” = Specified network host is not available

2016-04-27 16:03:21 Communication session with the Device 41 "Regulador Trafo-A", type: KpModbus, address: 1
Request element group "TempActual"
2016-04-27 16:03:21 Error communicating with the device: Error writing data: El nombre de red especificado ya no está disponible.

2016-04-27 16:03:21 Communication session with the Device 42 "Regulador Trafo-B", type: KpModbus, address: 2
Request element group "TempActual"
2016-04-27 16:03:21 Error communicating with the device: Error writing data: El nombre de red especificado ya no está disponible.

2016-04-27 16:03:36 Communication session with the Device 41 "Regulador Trafo-A", type: KpModbus, address: 1
Request element group "TempActual"
2016-04-27 16:03:36 Error communicating with the device: Error writing data: El nombre de red especificado ya no está disponible.

2016-04-27 16:03:36 Communication session with the Device 42 "Regulador Trafo-B", type: KpModbus, address: 2
Request element group "TempActual"
2016-04-27 16:03:36 Error communicating with the device: Error writing data: El nombre de red especificado ya no está disponible.

2016-04-27 16:03:51 Communication session with the Device 41 "Regulador Trafo-A", type: KpModbus, address: 1
Request element group "TempActual"
2016-04-27 16:03:51 Error communicating with the device: Error writing data: El nombre de red especificado ya no está disponible.

2016-04-27 16:03:51 Communication session with the Device 42 "Regulador Trafo-B", type: KpModbus, address: 2
Request element group "TempActual"
2016-04-27 16:03:51 Error communicating with the device: Error writing data: El nombre de red especificado ya no está disponible.

Stop communication line: Yes, it becomes low.

I could understand that sometimes it can fail, but is not acceptable to eat 100% CPU in case it could not connect/transfer data to COM port.

On the virtual serial port monitor software I can see Communicator is non-stop querying for COM status:

0000797 00:02:07.33643 Com4   192.168.5.32    10001  WaitOnMask      Pending                   
0000798 00:02:07.33641 Com4   192.168.5.32    10001  GetCommStatus   Success                   Err 0 WaitImm 0 InQue 0 OutQue 40 EOF 40 Hold 0x0

[Mikhail]

Unfortunately, write method is very simple:

        public override void Write(byte[] buffer, int offset, int count, 
            CommUtils.ProtocolLogFormats logFormat, out string logText)
        {
            try
            {
                SerialPort.DiscardInBuffer();
                SerialPort.DiscardOutBuffer();

                try
                {
                    SerialPort.Write(buffer, offset, count);
                    logText = BuildWriteLogText(buffer, offset, count, logFormat);
                }
                catch (TimeoutException ex)
                {
                    logText = CommPhrases.WriteDataError + ": " + ex.Message;
                }
            }
            catch (Exception ex)
            {
                throw new InvalidOperationException(CommPhrases.WriteDataError + ": " + ex.Message, ex);
            }
        }

It drops on SerialPort.Write, where SerialPort is standard .NET class.
Probably serial port driver causes CPU load.
Does your converter support direct connection as TCP client or TCP server without virtual port?
For instance, Moxa NPort converter works correctly if connection is lost.

[Mikhail]

I have an idea:
set Delay after request cycle parameter of the communication line to 100
Please write about the result

[inpelsa]

> (through it has a 10 seconds delay (10000 ms))

It’s already done, that’s what is weird!

[inpelsa]

Yes, direct TCP connection is available, but let’s see if we can fix this for other people.

code is simple… that can mean code is too simple and we are not taking care of some situation (I.E.: OutQueue=40… buffer filled? port not ready?)

Maybe opening/closing port each time is required (aka freeing port) could be a good idea.

[Mikhail]

Without a delay Communicator tries to write in the loop. So CPU become loaded.
I will add the fix in the core of Communicator.

Does the connection repair automatically or you need to restart Communicator?

[Mikhail]

As I realized the most fast communication if UDP is used directly for a serial converter without virtual port and C:\SCADA is ignored by anti-virus system.

[inpelsa]

Small delay or system.doevents() or port checking will help on this 🙂

Shouldn’t apply delay in case of any error too?

>I will add the fix in the core of Communicator.
Where can I get it?

OK, I will switch to UDP on the production server, but I just fetch data every minute, comm speed is not a problem, cpu hog… as always it is.

[Mikhail]

Shouldn’t apply delay in case of any error too?

I think that you did is enough.

Where can I get it?

It will be included in the next version. In case we found the workaround I think you shouldn’t update Communicator. But if you wish, I can send it by email.

[inpelsa]

Please send it to me, I can not apply none of the solutions at this time and still happens.

Please consider about uploading any updates of any type to a public location so others in the community can get them.

Good and fast job!!

[Mikhail]

It’s already done, that’s what is weird!

Did you mean that Delay after request cycle parameter solves the problem?

[Author]

Posts