Forum Home › Forums › Communicating with Devices › Modbus › Communicator using 100% CPU
- This topic has 21 replies, 2 voices, and was last updated 7 years, 11 months ago by Mikhail.
-
AuthorPosts
-
April 27, 2016 at 9:29 am #1025inpelsaParticipant
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?
April 27, 2016 at 9:40 am #1027MikhailModeratorHello,
communicator not taking over the CPU.
Sorry, I didn’t catch what the error is?
April 27, 2016 at 9:50 am #1028inpelsaParticipantCommunicator 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?
April 27, 2016 at 1:18 pm #1029MikhailModeratorPlease, post a part of the communication line log when this situation occurs.
If you stop communication line (from context menu), CPU load become low?April 27, 2016 at 2:15 pm #1032inpelsaParticipant“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
April 27, 2016 at 2:58 pm #1033MikhailModeratorUnfortunately, 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.April 27, 2016 at 3:01 pm #1035MikhailModeratorI have an idea:
set Delay after request cycle parameter of the communication line to 100
Please write about the resultApril 27, 2016 at 3:04 pm #1036inpelsaParticipant> (through it has a 10 seconds delay (10000 ms))
It’s already done, that’s what is weird!
April 27, 2016 at 3:10 pm #1037inpelsaParticipantYes, 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.
April 27, 2016 at 3:15 pm #1038MikhailModeratorWithout 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?
April 27, 2016 at 3:20 pm #1039MikhailModeratorAs 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.
April 27, 2016 at 3:50 pm #1040inpelsaParticipantSmall 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.
April 27, 2016 at 4:17 pm #1041MikhailModeratorShouldn’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.
April 27, 2016 at 4:26 pm #1043inpelsaParticipantPlease 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!!
April 28, 2016 at 6:23 am #1050MikhailModeratorIt’s already done, that’s what is weird!
Did you mean that Delay after request cycle parameter solves the problem?
-
AuthorPosts
- You must be logged in to reply to this topic.