ChartDirector Support - View Thread 1643150036

Multithread - RealTimeMultiThread & RealTimeViewPort - .NET/C#

Posted by William on Jan-26-2022 06:33

Hi Peter Kwan, hi all,

I wanted to use preferably RealTimeViewPort for a project of datalogger (ViewPort also offers the multithread feature if I am not mistaken).
What I want to understand as I can't find examples with this and not finding any PDF reference manual, is to know in which part of the ViewPort project I need to insert the data collector : In DoubleBufferedQueue.cs? In Program.cs? In RandomWalk.cs? or in the form source code frmrealtimeviewport.cs?
I would proceed like this :
The data collection would be performed over TCP with the "Nuget" SimpleTCP which means that I will define the reception of data with the following line :
private void Server_DataReceived(object sender, SimpleTCP.Message e).
and call the SimpleTCP with the line
using SimpleTCP;

For the moment, it is all in the frmrealtimeviewport.cs file and it really does not look like it is multithread as the longer the app runs, the bigger the interval between two samples. So if I have to use this data reception code in one of the other file, how would I render available the data acquired to the frmrealtimeviewport.cs file? Even a simple example would help a lot. Thanks.

Re: Multithread - RealTimeMultiThread & RealTimeViewPort - .NET/C#

Posted by Peter Kwan on Jan-26-2022 13:04

Hi William.

Initially, when a program starts up, it has a single thread. It is the thread that runs the GUI. You can create additional threads if necessary. In the multi-threading sample code, it starts an additional thread to run the data generator, which is just a random series generator.

In your own code, the "data generator" is your SimpleTCP. If SimpleTCP supports multi-threading, you can certainly run it in another thread. In the SimpleTCP Github page, it mentions "multi-threading" in its "TO DO" list. It seems to suggest SimpleTCP does not support multi-threading or it has not been tested for multi-threading.

In any case, the data in the RealTimeViewPort sample code is fed in the "onData" method. You mentioned SimpleTCP will call Server_DataReceived to deliver the data. In the Server_DataReceived, your code can receive the data, and call onData to pass the data to the charting code.

Regards
Peter Kwan

Re: Multithread - RealTimeMultiThread & RealTimeViewPort - .NET/C#

Posted by William on Jan-27-2022 09:22

Thank you Peter,

Peter Kwan wrote:
In your own code, the "data generator" is your SimpleTCP. If SimpleTCP supports multi-threading, you can certainly run it in another thread. In the SimpleTCP Github page, it mentions "multi-threading" in its "TO DO" list. It seems to suggest SimpleTCP does not support multi-threading or it has not been tested for multi-threading.

I didn't pay attention to this. I can't even find this info but I trust you. Well, my client app does not use this SimpleTCP thing. I would only use SimpleTCP as I need to transfer data from the client app to the server app, which should be the realtimeviewport. It appears that the client app, if I try to send as many data as I can from this client app to another external server app, Wireshark tells me that the time elapsed between 2 frames is almost 20us which is not bad even if a bit still a bit limiting and each frame is made of 90 bytes so I would have 220ns for each byte (28ns per bit) just to summarize but I imagine the encapsulation by the protocol will make the whole frame somehow bigger. In this case, the client+server apps never conflicts and the datareceived buffer always gets empty apparently. If I use millisecond timers in this client app, I have a timing between frames of any multiple of 15~16ms. There will probably be some error from the management of the timer interrupts but there is nothing I can do about this and in any case, I am not supposed to use it.

With the SimpleTCP Nuget, the issue is that it seems the buffer has difficulties to get empty and the size of the frames vary according to the capacity of the Nuget to empty this buffer. I can have intervals lower than 10ms between packets but if the speed it too high, I will have cumulated messages in one single packet and at some point, crashes on the line. At least, it is what happens when I use the SimpleTCP nuget from the frmrealtimeviewport.cs file and it will probably badly impact the reception of the TCP frames. SimpleTCP is not the worse obstacle for the moment and I would like to focus more on the right place to put the TCP data reception thread. You said replacing the random generator by the reception and processing of TCP data could render the overall process more efficient and faster?

Peter Kwan wrote:

Initially, when a program starts up, it has a single thread. It is the thread that runs the GUI. You can create additional threads if necessary.

...

In any case, the data in the RealTimeViewPort sample code is fed in the "onData" method. You mentioned SimpleTCP will call Server_DataReceived to deliver the data. In the Server_DataReceived, your code can receive the data, and call onData to pass the data to the charting code.

I have to do some more investigation around this. Now, I got myself a breakout board with the FT232H that can allow me to tie up or down GPIOs and it is very nice if I want to measure the timing to process some lines of the code or entire sections, with the use of an oscilloscope. I should send you some screenshots with comments, the next time I operate with this.

Peter Kwan wrote:
In the multi-threading sample code, it starts an additional thread to run the data generator, which is just a random series generator.

Yes. It seems this random number generator can generate sample at a very high resolution. That is why I wanted to replace this thread by mine with the reception and processing of data from TCP.

Thanks again,

William

Re: Multithread - RealTimeMultiThread & RealTimeViewPort - .NET/C#

Posted by Peter Kwan on Jan-31-2022 03:33

Hi William,

For the SimpleTCP multi-threading, I check again and I found that there are more than one SimpleTCP in Github. The one that does not support multi-threading is a different SimpleTCP. The SimpleTCP you are using may support multithreading. You may try to launch it in another thread to see if it works.

The normal way to obtain the timestamp is to obtain it from the source, that is, your client should send the timestamps and the data values to your server. In this way, the timestamps will be correct regardless of network delay or delay caused by the OS overhead, or other programs in your machine that slows down the machine or network.

If the client cannot include any kind of timing information, and you can only generate the timestamp on the server side, then your code should generate it immediately when you receive the data. Because Windows is not a real-time operating system, and the default time slot on Windows is 1/60 second (around 16ms), you can expect error of similar magnitude for server based timestamp. If you can write low level code, you may consider to increase your thread priority to make it respond faster. Note that if your thread hangs or is busy all the time, it can hang your machine if it has the high priority, because nothing else can run.

Regards
Peter Kwan