We are looking to implement a tier component for file send and receive management in rs232.
Gurux.serial is on the table and being analyzed. As our application will be constantly listening to incoming files in reception I wanted to know the implementation that you recommend in this case. The application could be listening on hundreds of COM port. And manage multiple simultaneous file receptions.
Using ondatareceive seems like a good solution, but how does it handle threads? Does it open one thread at each current reception on each port?
Do you know of users who use gurux serial at this intensity without encountering performance issues?
Yes, there is one listening thread for each port. You didn't tell are you using Java or C# version, but our clients are using TCP/IP connections to simulate thousands of meters. An idea with serial and network media is the same. Performance is always an issue. It depends from the how many serial port instances you have and how much data you are receiving and send in one frame. Baudrate also effects.
I can't say anything sure. You need to make a small test and check it by your self.
I started testing the gurux.serial solution on the .net platform. The provided test project works perfectly
(one COM port)
Unfortunately when I push a little further the tests I find that after opening 10 ports after a few seconds,
up to 2 minutes I have an exception :
System.ObjectDisposedException
HResult=0x80131622
Message=Le handle sécurisé a été fermé
Source=mscorlib
StackTrace:
at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success)
at System.StubHelpers.StubHelpers.SafeHandleAddRef(SafeHandle pHandle, Boolean& success)
at Microsoft.Win32.UnsafeNativeMethods.GetOverlappedResult(SafeFileHandle hFile, NativeOverlapped* lpOverlapped, Int32& lpNumberOfBytesTransferred, Boolean bWait)
at System.IO.Ports.SerialStream.EventLoopRunner.WaitForCommEvent()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
Yet I'm only opening port, I overload events onerror (), onreceive (). But no other action, neither closing
of port, nor sending of character on the line, I do not trigger reception.
The COM port used are virtual COM created with VSPE.
I have provided you my very simplified test project by mail since the zip file is not autorized on post.
Do you see something that I have not implemented correctly?
I took a little time to try to add COM ports to the test application you are providing. All goes well and I do not see the same problem as my test project.
So I compared and your sample is a Winform project unlike mine which is a WPF project.
So I docked in a winform application my library using your gxserial component that is not functional when opening 10 COM ports in my first wpf application. In this configuration everything is fine.
So here's my observation, without knowing more, gxserial looks incompatible with use in a WPF application.
We have used the serial port in WPF projects. I made a small test app and I was able to communicate with one serial port, but that is real serial port, not a virtual one. Can you connect one serial port when using WPF? I'm not sure are you using WPF in your first post.
Yes we test gxserial in a new wpf projet. One (virtual) port is working, open 10 (virtual) port raise an error in a few seconds. Same source code work with a new winform project. (open 10 virtual port)
I have send you my wpf projet to your mail yesterday.
I just found your email from the spam folder. It'll take a while, but I added this to the work queue. We'll create 10 virtual ports and check what happens.
We could find where the problem came from on a wpf application. We must be on different declaration of gurux.serial for each opened port.
We have no longer problem with the use of a Gurux.serial array.
It's good news.
However during our tests to validate if the library will support a lot of simultaneous connections and read / write we noticed one thing.
Even with a single COM port, even without the onDataReveive event, we see a very high CPU usage when we send contantly characters to be readed by a gurux.serial opened port. We were able to see that by raising the ReceivedBytesThreshold property it was decreasing synonymous but that if a packet was not this size the event OnReceived was not launched.
Do you have an implementation tip for not having this CPU usage? The test sample has the same result.
(We are on C#, tested on a WPF 32 and 64bits and tested on winform 32 and 64 bits with same result)
In the current implementation, OnReceived is called every time when there is a data on the serial port buffer. If you set Eop, it'll wait until End Of Packet char is received before packet it sent.
Hi Nicolas,
Hi Nicolas,
Yes, there is one listening thread for each port. You didn't tell are you using Java or C# version, but our clients are using TCP/IP connections to simulate thousands of meters. An idea with serial and network media is the same. Performance is always an issue. It depends from the how many serial port instances you have and how much data you are receiving and send in one frame. Baudrate also effects.
I can't say anything sure. You need to make a small test and check it by your self.
BR,
Mikko
Thanks for your quick reply
Thanks for your quick reply Mikko.
Sorry, we are on a wpf .net C# application.
Our application will have to open simultaneously and leave open a hundred of COM port (Production machines are on the other side)
Several COM ports will send and receive files simultaneously. We expect a high margin of 10 to 20% simultaneous transfers of all connected machines.
I will, as you suggest, try to reproduce this with virtual ports. To see how gurux.serial behaves in such a situation.
Regards,
Nicolas.
Hi Nicolas,
Hi Nicolas,
Thanks from this info. I know that you can create hundreds of instances from serial port and it should work if you have enough PCU and memory.
BR,
Mikko
Hi Mikko,
Hi Mikko,
I started testing the gurux.serial solution on the .net platform. The provided test project works perfectly
(one COM port)
Unfortunately when I push a little further the tests I find that after opening 10 ports after a few seconds,
up to 2 minutes I have an exception :
System.ObjectDisposedException
HResult=0x80131622
Message=Le handle sécurisé a été fermé
Source=mscorlib
StackTrace:
at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success)
at System.StubHelpers.StubHelpers.SafeHandleAddRef(SafeHandle pHandle, Boolean& success)
at Microsoft.Win32.UnsafeNativeMethods.GetOverlappedResult(SafeFileHandle hFile, NativeOverlapped* lpOverlapped, Int32& lpNumberOfBytesTransferred, Boolean bWait)
at System.IO.Ports.SerialStream.EventLoopRunner.WaitForCommEvent()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
Yet I'm only opening port, I overload events onerror (), onreceive (). But no other action, neither closing
of port, nor sending of character on the line, I do not trigger reception.
The COM port used are virtual COM created with VSPE.
I have provided you my very simplified test project by mail since the zip file is not autorized on post.
Do you see something that I have not implemented correctly?
Thank you in advance for your help.
Best regards,
Nicolas.
Hello Mikko,
Hello Mikko,
I took a little time to try to add COM ports to the test application you are providing. All goes well and I do not see the same problem as my test project.
So I compared and your sample is a Winform project unlike mine which is a WPF project.
So I docked in a winform application my library using your gxserial component that is not functional when opening 10 COM ports in my first wpf application. In this configuration everything is fine.
So here's my observation, without knowing more, gxserial looks incompatible with use in a WPF application.
Do you have any experience on this?
Thanks for your help.
Regards,
Nicolas.
Hi Nicolas,
Hi Nicolas,
We have used the serial port in WPF projects. I made a small test app and I was able to communicate with one serial port, but that is real serial port, not a virtual one. Can you connect one serial port when using WPF? I'm not sure are you using WPF in your first post.
BR,
Mikko
Hello Mikko,
Hello Mikko,
Thanks for your quick reply.
Yes we test gxserial in a new wpf projet. One (virtual) port is working, open 10 (virtual) port raise an error in a few seconds. Same source code work with a new winform project. (open 10 virtual port)
I have send you my wpf projet to your mail yesterday.
Regards,
Nicolas.
Hi,
Hi,
I just found your email from the spam folder. It'll take a while, but I added this to the work queue. We'll create 10 virtual ports and check what happens.
BR,
Mikko
Ok thank you Mikko.
Ok thank you Mikko.
I will meanwhile continu my validation tests on a winform project.
Bye.
Nicolas.
Hi,
Hi,
We could find where the problem came from on a wpf application. We must be on different declaration of gurux.serial for each opened port.
We have no longer problem with the use of a Gurux.serial array.
It's good news.
However during our tests to validate if the library will support a lot of simultaneous connections and read / write we noticed one thing.
Even with a single COM port, even without the onDataReveive event, we see a very high CPU usage when we send contantly characters to be readed by a gurux.serial opened port. We were able to see that by raising the ReceivedBytesThreshold property it was decreasing synonymous but that if a packet was not this size the event OnReceived was not launched.
Do you have an implementation tip for not having this CPU usage? The test sample has the same result.
(We are on C#, tested on a WPF 32 and 64bits and tested on winform 32 and 64 bits with same result)
Thanks for your help.
Regards,
Nicolas.
Hi,
Hi,
Try to set Eop to 0x7e.
serial.Eop = (byte)0x7e;
In the current implementation, OnReceived is called every time when there is a data on the serial port buffer. If you set Eop, it'll wait until End Of Packet char is received before packet it sent.
BR,
Mikko