02-06-2018 10:39 AM
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.
Solved! Go to Solution.
02-06-2018 11:06 AM
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.
02-06-2018 11:50 AM
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?
02-07-2018 03:25 AM
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.
02-07-2018 11:07 AM - edited 02-07-2018 11:10 AM
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)
02-08-2018 01:46 AM
Thanks Joerg, it seems exactly my use case!
06-04-2021 02:34 PM
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?
06-04-2021 02:47 PM
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.
06-06-2021 04:38 PM
06-07-2021 10:52 AM
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.