DQMH Tester UI Getting un responsive

[Altira]

Hi

I have a project where i have made 2 different modules , one is generator and second is for display

In generator im planing to generate some data

Project looks like this

I have created a request to the data generator module called Start_Gen, and Stop Acq

basically start gen will start generating and stop gen will stop, this is controlled by a flag in MHL

On the message handling loop, i have enqueue a set a cases, so that all the cases are enqueued and the Message handling loop will process all cases

which looks like this

Create task and apply sampling are blank cases for me

Read data case is like this

when stop generation event happens, the generation flag goes false and Read_data case is not enqueued

I just need my MHL to contentiously come to read data until the generation flag is False, and broadcast data when ever read case is executed

but now on the tester, when i test, everything works fine, but when i try to stop the code, tester stops responding

am i doing something wrong? i have also observed that, without broadcast data, my tester is responding well  and no issues,

when i add the broadcast data, tester hangup after start button

i have attached my code

[Ludwig72]

Hi @Altira,

I am not surprised that it doesn't work. If you push a new task into the MHL every cycle, the loop will always be busy. Actually, the MHL should always be ready for requests. Depending on how long a read process takes, the next tasks line up behind.

This is a case where I would typically use a helper loop. This can also be event driven. But the only events that exist are start, stop and exit. The read operation can run as a timeout event. This way the loop would always be ready to process the incoming commands.

Ludwig

[Ludwig72]

I modified your example - have fun.

Btw. the second issue that I identified was the broadcast load of the tester. It wasn't able to react because of the mass of incoming messages. Never use broadcasts without any timing...

[drjdpowell]

I dropped a 1 ms Wait in your  "Read_Data" case, and that was enough to make your code work (by stopping it produce broadcasts faster than they could be handled).

I measured and your code was generating more than 60,000 broadcasts per second, which is far too fast.

[Ludwig72]

---

@drjdpowell wrote:

I measured and your code was generating more than 60,000 broadcasts per second, which is far too fast.

---

😅

[joerg.hampel]

Thanks for using DQMH, Altira, and thanks everybody for chiming in and lending a hand.

Enqueuing messages inside the MHL (sometimes called "self-enqueuing") can lead to various problems as you have no control over what else is happening in your module, if somebody else sends requests etc. If you can avoid enqueuing messages from within the MHL case structure, that usually leads to a more robust design. Sam Taggart's Simple DQMH Dos and Don'ts article gives some insight into this and other good practices.

One way to work around the need for self-enqueuing is to create a helper loop which takes care of the periodic actions (and more). More details about helper loops can be found in this blog post about helper loops. 

[Altira]

Hi i was also expecting the same and now im planing to implement a helper loop, and i would be a string based state machine for further molecularity

but still the large amount of data transfer and how its achievable from module to module is not addressed

[Altira]

Hi im very much aware that it generates a large amount of user events in this scenario, but in my case i need to pump considerable amount of data from one module to another

I could see that broadcast is nothing but a user event coupled with data, so every broadcast would load the UI thread

is there any other mechanism inbuilt in DQMH where i can send data from one module to another like a stream?

[Ludwig72]

You are free to use any mechanism that fits your requirements. In this case you can for example pass a reference to a stream as argument for a start request or other way around as argument inside the reply.

[drjdpowell]

The problem in your example code isn't User Events, as they are fast (and don't require the UI thread at all).  The problem is in the tester, where you continually concatenate an ever-growing text string, as that is very slow.  No streaming method will help you go fast if you have slow code at the end of the stream.