DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Invalid Refnum in Request and Wait for Reply

Solved!
Go to solution

If I call a Request and Wait for Reply Event, I always see this error in the Event Inspector Window of the destination module:

5920	10	79330989	A6E00008	User Event	Get Something Argument	{Wait Notifier => Invalid Refnum - 0x9A000001}

It seems to have no effect on the functionality of the Event (the payload arrives correctly at the tester), but I was wondering why it is invalid and if this can have unwanted consequences. Or maybe it's something known and it is as it should be....

 

I stumbled upon this error while diagnosing a (still unsolved) timeout in a Request and Wait for Reply from a DQMH module to another DQMH module.

 

 

0 Kudos
Message 1 of 10
(6,556 Views)

Just as a side note, I solved the timeout problem: I was flushing the MHL queue within another temporally close event thereby preventing the Request's message from being processed by the MHL.

0 Kudos
Message 2 of 10
(6,550 Views)
Solution
Accepted by topic author carlod80

I was able to reproduce the 'Invalid Refnum' issue, but it happens with any Notifier or Queue refnum passed as an argument for a user event, no matter whether the refnum is valid or not. So this is not a DQMH issue, it is an Event Inspector Window issue. I think you can safely ignore the 'Invalid Refnum' message.

 

And to reply to your side note, I suggest looking for an alternative to flushing the MHL queue in your application. Usually if someone feels they need to flush the MHL queue, there is probably another issue that needs to be addressed. Perhaps you should be utilizing a helper loop instead of getting in the situation where you need to flush the MHL queue?

 

 

Message 3 of 10
(6,541 Views)

 And to reply to your side note, I suggest looking for an alternative to flushing the MHL queue in your application. Usually if someone feels they need to flush the MHL queue, there is probably another issue that needs to be addressed. Perhaps you should be utilizing a helper loop instead of getting in the situation where you need to flush the MHL queue?

 


Darren, thanks for the architectural tip! Indeed, my design is sub-optimal (or simply bad!). Presently, my module is an acquisition module and in the MHL I have a "Start Acquisition" message (1), and "Acquire" message (2) and a "Stop Acquisition" (3) message. The flow is like this: (1) enqueues (2), (2) keeps enqueuing itself until an event in the EHL enqueues (3). When I handle (3) in the MHL I need to flush the queue since even though the EHL has enqueued a priority (3) message, I have not way to make sure that in the MHL other (2) messages get enqueued after (3) - which would mess things up.

 

At first glance, I can't see a way to avoid this with a helper loop, I need some thinking (or some hint if you have one)...

 

The only (naive) thing that comes to my mind is that I could use a boolean flag to stop the acquisition (rather than a MHL message), checking the flag in the (2) event and enqueuing (2) or (3) depending on the flag.

0 Kudos
Message 4 of 10
(6,527 Views)

Maybe this topic on helper loops can point you in the right direction(?).




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Message 5 of 10
(6,514 Views)

Thanks Joerg, it seems exactly my use case!

0 Kudos
Message 6 of 10
(6,486 Views)

Hello Darren,

 

I got  into similar situation for Request and wait until reply event.

The MHL is not recieving refnum sent by EHL, rather some other invalid refnum. Hence not replying with data to main module from this sub module. so timeout errors in Main module. What is the fix?

Thanks & Regards,
Bharath Kumar
GCentral
0 Kudos
Message 7 of 10
(4,344 Views)

Are you dealing with a Cloneable module? Because if so, the first instance that receives the reply will cause the Request VI to close the reference, and then subsequent instances will try to operate on a reference that is invalid.

 

If that's not the problem, then you should probably inspect your code to see if there is any other place in the code that is manipulating the reference and closing it in between when it arrives in the EHL and when it is processed by the MHL. The simplest case I've seen this happening is when you accidentally specify a FALSE for 'wait for reply?' instead of a TRUE for Request and Wait for Reply events.

Message 8 of 10
(4,342 Views)

Hello Darren,

 

yes it is a cloneable module. But it is called only once no other clones are created. one instance started, synchronized and request &wait for reply event is called.

Thanks & Regards,
Bharath Kumar
GCentral
0 Kudos
Message 9 of 10
(4,327 Views)

Then it sounds like there's a race condition in your code somewhere that is closing or otherwise invalidating the reference between when the EHL frame and MHL frame execute.

0 Kudos
Message 10 of 10
(4,311 Views)