LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DQMH Local Instance Events disappear during execution?

Hey guys,

 

I have trouble with a problem which never occured before to me.

My problem is, that DQMH seems to lose the "Local Instance Events".

 

I have developed a data logger application using DQMH.

For the data logging, two instruments are measuring continuously.

For each device, there is a "Graph" module launched (cloneable). This module receives the measured data from the corresponding device and display it in chart. To reduce the needed performance, the chart is NOT updated after receiving the data. The chart will be automatically updated every 2s (time increased from 1s because of my issue). This update is done by sending a Request from the event structure timeout case which is inside a helper loop.

Everything works fine. But after 2 weeks, the chart will not be updated anymore. The Request VI inside the event structure reports:

Error Code: "403684" / Error Source: "Graph.lvlib:Module Not Running--error.vi:6400001<ERR> Not a single instance of "Graph" Module running. [...]

 

But this is strange. The two instances are still running. My application has the ability to check it by using the "List Instances.vi" of the module.

In addition, the front panel of the instances can be loaded into a sub panel. The module FPs shows the last executed messages and there I can see, the Graph instances still receive the data of the corresponding devices.

Also the data logging of the other file writing module works fine. So the application still works an do its job - excepting the updating of the chart.

 

This is the event structure inside the helper loop (The SubVI requests the chart update):

Ynot223_0-1715847345913.png

 

SubVI:

Ynot223_1-1715847442196.png

Inside this SubVI, I'm using the Request VI to generate an Event, which updates my chart.

As you can see, I also log the used Module ID to be sure, that this ID is not lost or anything else.

 

Request VI:

Ynot223_2-1715847532565.png

And here the error is generated. The "DQMH_NAN" detects, that there is no local instance event available (TRUE).

 

Obtain Request Events:

Ynot223_3-1715847651199.png

But why should the DQMH do such a "faulty behavior"?

It works for days and now it doesn't work anymore? I can't figure out why....

The only reason why this could happen (from my point of view), is using the module ID "-1", but according to my log, this doesn't happen.

 

Did anyone experience something like this?

 

Note:

- This error happens to both instances at the same time.

- Why I'm using a Request instead of simply using the Message Queue? This update request can be triggered by other functions of the Graph and contains a boolean parameter to initialize the graph for reasons. To make future parameter changes easier to handle, I have decided to use a Request. Using a directly Message Queue could solve my problem, but would not solve the root cause of this and I want to understand this.

 

 

LV 2022 Q3 32 bit

DQMH 7.0.1.1316

 

Log:

"Error" in MHL. Module: "Graph 2" Error: "TRUE" Error Code: "403684" Error Source: "Graph.lvlib:Module Not Running--error.vi:6400001<ERR> Not a single instance of "Graph" Module running. <b>Complete call chain:</b> Graph.lvlib:Module Not Running--error.vi:6400001 Graph.lvlib:Update Graph.vi:3310001 Graph.lvlib:UI-Input_Timeout-Graph-Update.vi Graph.lvlib:Main.vi:4140003 Graph.lvlib:Main.vi.ACBRProxyCaller.19100027 Additional Info: Given Module ID for Request: 2<DQMH>Helper Loop: UI Inputs</DQMH>"

 

 

Many thanks in advance

0 Kudos
Message 1 of 5
(236 Views)

I have the almost the same exact issue. Waiting to hear back from DQMH team!

In my case, data is passed into the graph instances via a request. My Local Instance Event is to bring up a dialog box for user to choose which signals to be displayed. After a while, I cannot bring up the dialog box by Local Instance Events. The graph is clearly refreshing based on the selection made before.

0 Kudos
Message 2 of 5
(127 Views)
0 Kudos
Message 3 of 5
(121 Views)

Thank you! Make sense, I thought it was some kind of refs leaks, just couldn't figure out where. Will give this a try.

0 Kudos
Message 4 of 5
(115 Views)

I also think the issue you are seeing is related to the memory leak mentioned upthread.

 

The workaround would be to add the Release Queue function in the Read SEQ.vi, as described in the post on the DQMH forum thread.

0 Kudos
Message 5 of 5
(93 Views)