Skip navigation

Community

1 2 Previous Next 2127 Views 16 Replies Latest reply: Apr 9, 2014 9:08 AM by OlivierL RSS
JIV Calculating status...
Currently Being Moderated

Feb 23, 2012 9:47 AM

Previewing Items in a Send Queue

Whenever my actor core's front panel resizes, I want to enqueue a message in its self queue to resize a ceratin subpanel.  However, I want to cancel previously sent messages and only keep the latest information so that I don't burden the queue.  In the past, I would get all objects from the queue and remove the older entries of that message and reenque the elements.  How can I do the same thing with the send queue class?

 

Thanks, Jorge.

  • Currently Being Moderated
    1. Feb 23, 2012 11:04 AM (in response to JIV)
    Re: Previewing Items in a Send Queue

    You cannot. This is a key aspect of the safety net of the Actor Framework -- no toying with the queue. While it might be occassionally useful, it plays ever-lovin' havoc with deterministic order of messages for programmatic control and guaranteed delivery of messages.

     

    I can suggest a couple of alternate solutions, but I don't know the exact setup of your actors. The easiest is to modify your Send function so that it fires a Notifer with the size info and then puts the Notifier refnum into the message. Every send fires the same notifier. If multiple sends happen before the first message gets handled, the notifier keeps getting updated to the latest value. The receiver does a Wait on Notifier with a timeout of zero. If the "timed out" output is true, do nothing because that means you've already handled that resize.

  • Currently Being Moderated
    3. Feb 24, 2012 4:26 PM (in response to JIV)
    Re: Previewing Items in a Send Queue

    I can give you one workaround (in a moment), but the real answer is to handle messages faster on the receiver. Applications are bombarded by events from the operating system, especially mouse move type events, and rapidly dropping them is the name of the game. Generally, you set up some system that can handle the event very fast and tosses the event to some slower system that actually does the real work. For example, handle the event by reading the size and then write the size to a notifier. Have a whole different loop in your Actor Core that waits on the notifier and does the resize. By the time it gets back around to Wait On Notification, the event handler may have dequeued hundreds of events and overwritten the value in the notifier many times. You could also handle one event and record the timestamp and then ignore all further events of that same type that arrive during the next 100 ms (or appropriate window).

     

    You could also have a sender that sends one event but when asked to send another event doesn't do it until it gets a message back from the receiver that says the previous event has been handled.

     

    Those sorts of tricks are pretty standard for event handling systems everywhere.

     

    If you really need to filter on the sender side, I can offer only one workaround: I can imagine is using the Time Delayed Send VI (not actually in the Actor Framework.lvlib but distributed with the AF). You would set the message to be sent in 1 second (or something). If another item on the Send got there before the message got sent, you would send the cancel message and put the new one in for time delay. This is essentially the strategy used for updating LV indicators on the front panel, only we do it with low priority threads instead of with timing. The problem with this approach (or any similar approach) is that it risks the message never arriving because it keeps getting cancelled.

     

    Any sort of playing around with the queue generally has a hole in it somewhere. I have dug into many systems over the years where someone used the Get Queue Status primitive to try to do something clever, and they file the bug to National Instruments that there's a problem with the queues... it has pretty much always been the case that there's a race condition in their code between them checking the queue for some state and then doing something based on that state, but meanwhile the state of the queue has changed. It gets messy. Here There Be Dragons. :-)

  • Currently Being Moderated
    5. Feb 28, 2012 11:00 AM (in response to JIV)
    Re: Previewing Items in a Send Queue

    I *think* we have seen this same problem here in R&D. I've got some people tasked with digging into it. My current thought is that it is somehow related to the "Value (Signaling)" event... are you using that to stop any of your actors?

  • Currently Being Moderated
    6. Feb 28, 2012 11:35 AM (in response to JIV)
    Re: Previewing Items in a Send Queue

    Jorge:

    1) Is your code a project that you could share with me directly? We could analyze it in the lab and have a better idea whether what you're seeing is what we're seeing.

     

    2) You say this came on suddenly... is actor core VI particularly large/complex? What I mean is, is this a VI with just a few subVI calls, maybe even a loop, or is it one of those with a case structure with many cases and tons of code on the diagram?

     

    If it is a large VI, it is possible that you just added a bit of code to cross over a compiler optimization threshold. Can you take a bit of time and go through a do "Create SubVI From Selection" on as a few parts of your diagram to break it down into many smaller VIs and see if the problem goes away?

  • Currently Being Moderated
    8. Mar 1, 2012 3:09 PM (in response to JIV)
    Re: Previewing Items in a Send Queue

    For anyone else reading this thread: JIV sent me his code and we're investigating the issue. For now, I've suggested that rather than relying on LV's exit procedure to kill his application, instead he should trap the "Application Exit?" event, filter it, and then do a controlled shutdown to bring his VIs to completion, and when everything is stopped, call the LabVIEW Exit primitive as the last step.

  • Currently Being Moderated
    9. Mar 1, 2012 5:03 PM (in response to AristosQueue)
    Re: Previewing Items in a Send Queue

    Here's a VI snippet.. save the image to your computer then drag-drop it onto a block diagram and it should turn into code.

    shutdown example.png

  • OlivierL Calculating status...
    Currently Being Moderated
    10. Mar 24, 2014 8:09 PM (in response to AristosQueue)
    Re: Previewing Items in a Send Queue

    Was there ever a resolution of this issue or at least some more information regarding its root cause.

     

    We are currently seeing this exact same behavior on our project which doesn't use the Actor Framework but also runs with lots of dynamically launched VIs and user event for communication.  The keyword "VILinkObjRemoveCore" found in the dump does not seem to be very frequent on the forum.  Similarly, we are using LV 2011 SP1 and there is no issue in the development environment but it is easily reproducible (though not always) in the run time environment.

     

    Thank you!

  • Currently Being Moderated
    11. Mar 25, 2014 2:00 PM (in response to OlivierL)
    Re: Previewing Items in a Send Queue

    Olivier: LV R&D *thinks* we have it addressed in LV 2014. By addressed, I mean that we have not tracked down what is causing our unloader to enter the bad state, but we now can detect the bad state and set things right again without crashing out. You would need to join the beta program at ni.com/beta to try it out.

  • OlivierL Calculating status...
    Currently Being Moderated
    12. Mar 27, 2014 11:49 AM (in response to AristosQueue)
    Re: Previewing Items in a Send Queue

    Aristos,

     

    I've done quite a bit of reading on this forum and LAVA since Monday and found other similar issues related to the actor framework.  Because this issue is fairly recent in our case, I would expect that recent changes in our code and its execution has something to do with the problem. 

     

    I would appreciate if you could comment on a few things to help us address the issue immediately as this application is currently shipped to customers, waiting 6 months to build in 2014 is far from ideal and patching it with the "Quit LabVIEW" doesn't seem really clean and may hide other potential issues in the code.

     

    1. If this is the same error as you mention, you are suggesting that neither LV2012 nor LV2013 resolve the issue?
    2. Is there a CAR with public details about the issue that we can read about to understand what is happening?
    3. One strange thing is that the VI mentioned in the crash report (in lvlog.txt) has not been modified recently.  Is the VI mentioned in the log after "#** VILinkObjRemoveCore:" the real cause of the issue?  I believe that most of the time LVRT reports the error, that VI has not even exectued.

     

    Thank you!

     

    --- Crash log ---

    ####

    #Date: Mar-25-14 3:27:22 PM

    #OSName: Windows 7 Professional Service Pack 1

    #OSVers: 6.1

    #OSBuild: 7601

    #AppName: ---Removed for post ---

    #Version: 11.0.1f2 32-bit

    #AppKind: AppLib

    #AppModDate: 02/14/2014 20:35 GMT

    #LabVIEW Base Address: 0x30000000

     

    25/03/2014 3:39:46.000 PM

    Crash 0x0: Crash caught by NIER

    File Unknown(0) : Crash: Crash caught by NIER

    minidump id: 10e65032-542b-404d-a4c6-00608c6e1421

    ExceptionCode: 0xC0000025’ N

    0x3072D464 - lvrt <unknown> + 0

     

    [... A lot more line almost identical...]

     

    0x30650A57 - lvrt <unknown> + 0

    *** Dumping Bread Crumb Stack ***

    *** LabVIEW Base Address: 0x30000000 ***

    #** VILinkObjRemoveCore: "[Full path of file goes here...]

    *** End Dump ***

  • Currently Being Moderated
    13. Apr 2, 2014 9:52 AM (in response to OlivierL)
    Re: Previewing Items in a Send Queue

    Oliver: There is no public CAR because we found this coming in through the NI Error Reporter and we have no idea what causes it. Yes, 2012 and 2013 both occassionally have this issue. We have never isolated causing it. What we have done in 2014 is "assume this happens... how can we recover?" When we detect that something has gone off the rails, we do some work to put it back in place.

     

    The VI mentioned in the log did go wrong -- something tried to kick it out of memory when something else still needed it. It is likely something above it in the hierarchy (not a direct caller, but something higher up) that is somehow doing the wrong thing. Do you have a panel or VI Ref that you used to keep open that you now close programmatically that uses this VI in its hierarchy? Did you change the order that a set of VI Refs are closing? Did you start opening/closing library/class refnums that you didn't used to use?

     

    I really don't have much to offer you here. If your code replicates this crash reliably and you can share your code, please open a support ticket with ni.com/support and ask an AE to start working on identifying the source of the crash... that may help find a workaround.

  • OlivierL Calculating status...
    Currently Being Moderated
    14. Apr 7, 2014 4:22 PM (in response to AristosQueue)
    Re: Previewing Items in a Send Queue

    Hi Aristos,  We managed to resolve the issue internally.  Here is a brief description of what we believe the issue was and its resolution.  I hope that this allows NI to recreate it internally and resolve.  However, now that is done here, I can say that in our case, it was directly caused by our code and can therefore be fixed with better programming.  It would be nice if the error message was more relevant though!  In our application, we have one main user interface which launches many subVIs dynamically in the background and some of those subVIs are "managers" launching many more VIs dynamically.  At any given time, there is at least 6 of those VIs loaded in sub panels of the main VI and some of those VIs themselves include sub panels filled with other VIs.  All the VIs are launched using the "RunVI" method with "False" wired to "Auto Dispose Ref".    In one specific part of our code, the references of a group of VIs were not closed properly.  All of those VIs were definitely stopped before the top level VI completed its execution and closed its front panel, forcing LVRT to clean up and stop the process.  Along with closing the references, we also made sure to remove every VI from the sub panels before terminating the execution of the application.  Both of those things together resolved our issue and the "VILinkObjRemoveCore" error seems to be a thing of the past.  I assume that wiring "True" to "Auto Dispose Ref" could also solve the issue as you do not need to explicitly close the references.  One interesting thing is that the VI reported by NI crash reporter had nothing to do with the VIs which references were not closed properly.

1 2 Previous Next

More Like This

  • Retrieving data ...

Bookmarked By (1)