random EHL/MHL transition failure?

[shuttlefan]

Strange thing I'm encountering.    As the code first start to run, everything is fine.
Here are the correct path as I'm statusing each step.  

Strangely, after some time, it appears as if the message enquing just stops working.  It gets to the EHL but never makes it to the MHL.
ADSSclient (singleton module) is just sitting idle most of the time, unless these two events needs to start.  

1/28/2025 10:39:27 PM;  DISPLAY UI;  Calling ADSS chg DS event

1/28/2025 10:39:27 PM;  ADSSClient 0;  ChgWorkingDS EHL

1/28/2025 10:39:43 PM;  ADSSClient -1;  EHL_chgWorkingMeaslist

1/28/2025 10:39:48 PM;  POLICY 1;  policy 1 heartbeat 129

Seems that something caused the module to be in a half dead state.

Any tips on what to look for?  any sort of self diagnostics?

[joerg.hampel]

I would recommend using our HSE Logger and placing log VIs in all the interesting places to monitor in real time how events propagate. It's most definitely what we would do internally at HSE.

[Ludwig72]

Now that you are still busy with the basics of DQMH, you should start thinking about booking a few days of coaching with your trusted NI partner. This will take you a big step forward.

[shuttlefan]

---

@Ludwig72 wrote:

Now that you are still busy with the basics of DQMH, you should start thinking about booking a few days of coaching with your trusted NI partner. This will take you a big step forward.

---

unfortunately, don't have that luxury at the moment.

[shuttlefan]

---

@joerg.hampel wrote:

I would recommend using our HSE Logger and placing log VIs in all the interesting places to monitor in real time how events propagate. It's most definitely what we would do internally at HSE.

---

Thanks, started process.

[shuttlefan]

I made a keep alive request that the module's helper loop calls every 7 seconds.
With no other input, the message queue part of the module just dies.  No errors reported.

1/31/2025 2:20:43 AM; ADSSClientQ 0; keepAlive
1/31/2025 2:20:43 AM; ADSSClientQ 0; KeepAlive MHL 855
1/31/2025 2:20:43 AM; ADSSClientQ 0; getEventCondLastUpdateTime
1/31/2025 2:20:50 AM; ADSSClientQ 0; keepAlive
1/31/2025 2:20:50 AM; ADSSClientQ 0; KeepAlive MHL 856
1/31/2025 2:20:50 AM; ADSSClientQ 0; getEventCondLastUpdateTime
1/31/2025 2:20:56 AM; POLICY 1; policy 1 heartbeat 99
1/31/2025 2:20:57 AM; ADSSClientQ 0; keepAlive
1/31/2025 2:20:57 AM; ADSSClientQ 0; KeepAlive MHL 857
1/31/2025 2:20:57 AM; ADSSClientQ 0; getEventCondLastUpdateTime
1/31/2025 2:21:04 AM; ADSSClientQ 0; keepAlive
1/31/2025 2:21:04 AM; ADSSClientQ 0; KeepAlive MHL 858
1/31/2025 2:21:04 AM; ADSSClientQ 0; getEventCondLastUpdateTime
1/31/2025 2:21:56 AM; POLICY 1; policy 1 heartbeat 100
1/31/2025 2:22:56 AM; POLICY 1; policy 1 heartbeat 101
1/31/2025 2:23:56 AM; POLICY 1; policy 1 heartbeat 102
1/31/2025 2:24:56 AM; POLICY 1; policy 1 heartbeat 103
1/31/2025 2:25:56 AM; POLICY 1; policy 1 heartbeat 104
1/31/2025 2:26:56 AM; POLICY 1; policy 1 heartbeat 105
1/31/2025 2:27:56 AM; POLICY 1; policy 1 heartbeat 106

I know the event handler still works

1/31/2025 2:55:13 AM; DISPLAY UI; Calling ADSS chg DS event
1/31/2025 2:55:13 AM; ADSSClient 0; ChgWorkingDS EHL

[joerg.hampel]

I fear this goes beyond the support the DQMH forum can give. It seems to me an application-specific problem.

[shuttlefan]

---

@joerg.hampel wrote:

I fear this goes beyond the support the DQMH forum can give. It seems to me an application-specific problem.

---

Yup, understand it's not easy in forum.  

Just trying to understand and get possible means of how the queue portion of the module can die so I can even start digging in the right place.

[shuttlefan]

I think I've nailed it down to this.  The vi circled is my object calling a lower level dll talking to a server.  
if it's this that's crashing somehow, how should I protect the model/message queue so that it doesn't bring half of the module down as well?

[ChrisFarmerWIS]

Is it not returning an error to indicate the crashing?  Perhaps ensure this is handling errors appropriately. 

Perhaps ensure that this VI has a timeout.

Also perhaps consider a roundtrip rather than a request and wait for reply.