Multiple "Display" information Clones and large CPU usage.

[danny_t]

Hi All,

This is not totally a DQMH question, but it relates to a situation with a DQMH solution. 

I have a test system where I have multiple DQMH clones that display front panel measurements and readings to the user for different test fixtures. Only one clone is visible to the user at a time, though all are loaded into memory and running. I allow the user to select which one to view and it is shown loaded into a main subpanel. I am wondering if I should use Defer Panel Update on the clone modules that are not loaded in the subpanel to save them running their user threads, or is it the case that because their front panels as not being shown their user threads do not run?

Also if Defer Updates is used, but information is still being pumped into the clone, ie broadcast events still occurring, what happens when the Defer is removed? does the last broadcast event data get shown or is the a backlog of data to display ?

Each clone is registered for a number of broadcasts so I am not over keen on  the idea of unregistering and registering again each time, the user switches view.

cheers 

Danny

[Darren · Accepted solution]

Defer Panel Updates is only going to prevent the editor from drawing a visible panel. If there is no panel visible, the property has no effect. And it has no effect on the processing of events.

[danny_t]

Thank you Darren, I assumed that might be the case, good to get it confirmed 

[danny_t]

I think I realised something I was doing incorrectly with the broadcasting of my sensor values.

In my sensor reading module I read all the lines of a Analogue Card, map the lines to desired Clones instances and first of a separate broadcast for each instance so I send 10 broadcasts each with data for 1 clone.

This means each clone needs to relieves 9 pointless broadcasts they have to decide to ignore and not process. I’m not sure how costly a broadcast is but I’m thinking this is  not a good way to go and would be better to map data to clone instance and send a single broadcast with all the data and let each clone pick out its own data. 

so 

10 broadcasts small data package v 1 broadcast larger data package ( thought still quite small).

any comments please

cheers 

Danny

[Taggart]

I like it! 

Create a map where the key is the module ID and just send that. Let each module lookup its own data.

[joerg.hampel]

A single broadcast might also increase readability?

[danny_t]

So I thought I might update this in case its useful to anybody else as it turns out I was looking at wrong location for my issue, i was nothing directly to do with the number of broadcasts sent.

I did change my system to Broadcast a single message on each sensor data update to ALL clones, as a LabVIEW MAP, and then let each clone just unpack the data relevant to them, so there were no thrown away broadcasts.  This reduced the number of broadcasts from 10 per 10mSec to 1 per 10mSecs and as I did this over a number of different sensor types, analogue, digital there was a significant reduction in the number of broadcasts in the system.

Very interestingly, this had very little effect, I think this is quite a positive statement for DQMH and many broadcasts  but didn't help my problem.

My issue was that I had significantly underestimated the CPU cost of reading local variables.

I occasionally use locals variables, normally with no issues, but they did in this case. This simple "bad" decision completely hamstrung my system design. Very simple and quick to fix once I figure out the real issue.

I had some Indicators which also acted as flags things like Test Station Id, Test Bay Number.  these were written only once when the DQMH clone module read its configuration from an INI file. These values were key in each clone deciding if a broadcast message was targeted for it or not, so for every broadcast message the clone was registered for it would do a read on these local variables to say is this for me.

Instead of passing these two values to the MHL via a configure queue message and holding them in a MHL Data cluster shift register arrangement, I was lazy and though, Id just read the values as Locals as I was only reading them so no race condition type risks. A simple change to hold these same values in a shift register cluster and the problem disappeared. I did when writing the initial code thing I should do it that way but stupidly though "nagh" 🙄.

Quick question for @Darren please, when you read a FP indicator or local variable of that indicator, does read occur and cost, thread switching to UI thread, even if that Panel is not visible ?

[Darren]

I wonder if this is because when DQMH panels are "closed" (like with the Hide Panel request), they're actually open, but in "Hidden" state. In which case you might have UI thread issues. I'd be curious if you added some code in the DQMH module to actually close the panel (via the FP.Close method) before you start updating the local variable, if the problem goes away.

Also, you mentioned the indicator only had a few flags that it was storing... I'm just clarifying that the local read/write doesn't contain a huge amount of data, as the memory allocation could slow things down independent of any UI thread + panel open/close issues.

Finally, I'd be curious if you replaced the local with a global (whose panel is never shown), if the problem still persists.

[danny_t]

If I get time I shall go back in my git repo to where the issue was and shall try a global rather than local, plus I can try FP.Close as well.  

It was purely a CPU issue for me not memory, and there was only two string indicators per Clone I was reading but I was reading them VERY often 🤣.

Basically I was doing this in all the clones in any registered broadcast event structures.

Now I have an internal private Event that I use to populate a data cluster for the event structure 

and do this in the registered broadcast event structures.

In a simulation / test mode, it reduced the CPU load from 60% to around 12% leaving plenty of headroom for the functionality I still need to implement