random EHL/MHL transition failure?

[shuttlefan]

---

@ChrisFarmerWIS wrote:

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.

---

yes, so as it turns out, the lower level .dll sockets had issues and was crashing.  So that propagated up the stack.
Need to figure out how to gracefully capture crash as this point.

[Ludwig72]

I normally use request and wait for reply only if the MHL can handle the code safely in seconds.

If it could take longer or there is some reason to run into a timeout it is better to send just a request and answer with a broadcast when it is finished. 

[joerg.hampel]

---

@shuttlefan wrote:
yes, so as it turns out, the lower level .dll sockets had issues and was crashing.  So that propagated up the stack.
Need to figure out how to gracefully capture crash as this point.

---

If by "crashing" you mean that the Call Library Function Node does not simply return an error code, but the DLL does "something" and violates memory, chances are that nothing but a full restart of LabVIEW will be able to recover from that situation (see this related KB page for example). At least that's my experience...

[shuttlefan]

---

@joerg.hampel wrote:

If by "crashing" you mean that the Call Library Function Node does not simply return an error code, but the DLL does "something" and violates memory, chances are that nothing but a full restart of LabVIEW will be able to recover from that situation (see this related KB page for example). At least that's my experience...

---

yeah, so the sockets weren't being closed and so at some point, it caused the dll call to die. 

This particular dll call was from an object that was wrapped around by the module as it created a dialog box for the user input.  This is to not lock up the rest of the code waiting for user input.  

That error went up the stack and ONLY killed the message queue part of the module never giving any error code.

[joerg.hampel]

---

@shuttlefan wrote:
That error went up the stack and ONLY killed the message queue part of the module never giving any error code.

I'm curious: How is that possible? Can you share more details or code?

[shuttlefan]

---

@joerg.hampel wrote:

I'm curious: How is that possible? Can you share more details or code?

---

The displayUI module calls ADSSclient module's public request to check to see if any data has been updated.  

At the lowest level is a function that is making a connection to the server.

The call is in an object wrapped around by the ADSSclient module in question.

The helper loop in the ADSSclient module asks for the last know data change time and to keep it alive (just calling itself and updating the counter)
The difference is keep alive didn't go through the DLL.  
as you can see here, the keep alive ran for 858 times and then stopped.   
ADSSClient message queue stopped working/responding after the last "getEventCondLastUpdateTime" due to the socket error. 

The message queue stopped responding/working as the keep alive messages no longer happens.

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

After this, I know the ADSSclient event handler still worked because a bit later, when I tried executing the same operation again, I can see that the DisplayUI module properly initiated it and that the ADSSclient event handler got it. 

However, nothing after that so it never got to the MHL from EHL.  I waited a bit and launched a different dialogbox (indented, not communicating with ADSSclient module) and it worked.

@ 2:56:04, I tried it again and same effect of stopping after EHL.  

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

1/31/2025 2:55:50 AM; ; EVTCONDcriteria IN
1/31/2025 2:55:51 AM; ; EventCondSch heartbeat 0
1/31/2025 2:55:51 AM; ; EventCondSch heartbeat 1
1/31/2025 2:55:52 AM; ; EVTCONDcriteria out
1/31/2025 2:55:56 AM; POLICY 1; policy 1 heartbeat 134
1/31/2025 2:56:04 AM; DISPLAY UI; Calling ADSS chg DS event
1/31/2025 2:56:04 AM; ADSSClient 0; ChgWorkingDS EHL
1/31/2025 2:56:24 AM; ; EVTCONDcriteria IN

[joerg.hampel]

---

@shuttlefan wrote:
The message queue stopped responding/working as the keep alive messages no longer happens.

---

The point I'm getting to is: I find it highly unlikely that the message queue - the reference itself - stops working or becomes invalid. That is really unheard of, that LabVIEW queue reference doesn't just go away.

It might be that the MHL is blocked because the DLL you're mentioning is stuck and therefor cannot process incoming messages, but I cannot imagine what else could be tripping the DQMH framework itself up. 

I'm too old to say "THAT CANNOT BE!", but I'm old enough to say "I find that highly unlikely" 😉