Jump to content
Sign in to follow this  
Manudelavega

Aborting Timed Loops

Recommended Posts

Hi,

I am trying to abort a timed loop in order to quickly stop the VI that contains it without having to wait for the next iteration to wake up the loop. The example that ships with LabVIEW works fine, but when I do what appears to be the same thing, the loop itself returns error -816: "Timed structure aborted or attempted to execute another iteration of the following aborted Timed Loop.", and the Wakeup Reason left data node is "Normal". When I run the example, there is no error and the Wakeup Reason is "Aborted".

Does anybody know what could be different in my code? It's a complicated VI with a lot of code inside the loop, but I believe all that code is unrelated...

One difference with the example is that the Abort function is in the same VI as the loop in the example, whereas in my case it's inside a separate VI, but that should still work, right?

Thanks for your help!

Share this post


Link to post
Share on other sites

I've never seen abort work without an error, so I think you have to be able to handle both situations.

Maybe it has something to do with how they're named, or the timing source, or something along those lines? I'd try just taking a subset of your code and fiddling until you spot the difference.Or just handle the error :)

Share this post


Link to post
Share on other sites

Actually I realize that even the NI example does generate -816 in its left data node if you add it. The error node coming out of the loop didn't have any error, but if I link the left error data node to the right error data node, then the error node coming out of the loop does have the error as well. Long story short you're right, it always produces an error.

Thanks!

Share this post


Link to post
Share on other sites

Our software now periodically run into critical errors where some resources (most likely DVR) are not released, and many components simply hang. I am highly suspicious that it comes from the Abort Timed Loop function. There are many operations inside the loop that function as pairs (open/release DVR in an IPE, dequeue/enqueue elements,...) and I want to be sure that one operation won't be performed without its counterpart also being performed. If we're unlucky and the abort occurs just after opening a DVR and just before releasing it, is it possible that the DVR dies?

The reason for the abort is not too shorten the duration of an iteration, which is always pretty short, but rather to force the loop to stop if it's just sleeping and waiting until it's time to perform its next iteration.

At this point the only acceptable solution I see would be to use a semaphore: the loop would acquire it when it starts a new iteration and release it when the iteration is done (before going back to sleep). The code sending the abort would only do so when the semaphore is available.

Am I on the right track?

 

Share this post


Link to post
Share on other sites
4 hours ago, Manudelavega said:

Our software now periodically run into critical errors where some resources (most likely DVR) are not released, and many components simply hang. I am highly suspicious that it comes from the Abort Timed Loop function. There are many operations inside the loop that function as pairs (open/release DVR in an IPE, dequeue/enqueue elements,...) and I want to be sure that one operation won't be performed without its counterpart also being performed. If we're unlucky and the abort occurs just after opening a DVR and just before releasing it, is it possible that the DVR dies?

The reason for the abort is not too shorten the duration of an iteration, which is always pretty short, but rather to force the loop to stop if it's just sleeping and waiting until it's time to perform its next iteration.

At this point the only acceptable solution I see would be to use a semaphore: the loop would acquire it when it starts a new iteration and release it when the iteration is done (before going back to sleep). The code sending the abort would only do so when the semaphore is available.

Am I on the right track?

 

It doesn't actually abort the timed loop, the help says:

" If you attempt to abort a running Timed Loop, the Timed Loop immediately executes the current iteration and returns Aborted in the Wakeup Reason output of the Left Data node. "

You can see this in the form of a horrible horrible example which nobody should ever follow, here: https://zone.ni.com/reference/en-XX/help/371361J-01/lvconcepts/aborting_timed_structs/

If the code is possible to run on a windows target (potentially using remote references to the FPGA for example, or if you have a HAL) then you can use desktop execution trace to see memory leaks.

I've never heard of a DVR being unlocked but not locked again, I don't think this is possible (if it is, well thats just silly). That doesn't mean you still can't deadlock with them. I'd make sure your code doesn't have any DVR IPEs within other DVR IPEs, anywhere if you can help it. You might also check for fixed size queues or similar -- I've definitely seen people disable sections of code which read from a queue but forget to disable the enqueuer and hang their system that way. And I've also definitely seen DVR access within class property nodes which were themselves accessed by reference, leading to a deadlock. I wouldn't imagine any of this is caused by the fact that you're 'aborting' (but not really) the timed loop.

  • Like 1

Share this post


Link to post
Share on other sites

Again, thanks Smithd. I will keep troubleshooting this issue later. For now I have another issue which is even worse: the "Stop Timed Structure.vi" itself hangs quite frequently and I can't figure out why. This is getting quite frustrating and I'm on the edge of giving up... Anybody knows what could be causing it?

I 100% guarantee that the timed loop itself is running when the call to the "Stop Timed Structure.vi" occurs. The name is correct, and most of the time it works fine, but after a few dozens of cycles (a cycle being start timed loop and abort timed loop 1s later), the "Stop Timed Structure.vi" hangs, with no possibility to recover. So this is worse than any error message :(

EDIT: I started a new thread for this purpose, please reply there instead of here.

Edited by Manudelavega

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Similar Content

    • By Manudelavega
      I am experiencing frequent occurences where the Stop Timed Structure.vi hangs. I found online that issue #42CHH33W used to be a possible cause, but it's supposed to be fixed in LV8.2 and I'm using LV2015! I tried hard to identify a pattern for the hanging, and implemented a system based on semaphore that would guarantee that I only abort the loop if it's sleeping (waiting to start its next iteration). If it's awake, I simply rely on a Boolean to exit the loop. Even now it still hangs sometimes. Getting a little frustrated here 
      Anybody has experienced such scenario before? Do you think I should try the suggested workaround (putting Stop Timed Structure.vi in a another timed loop that is in sync with the timed loop I want to abort)? What does "in Sync" really mean?
      Thanks
    • By Manudelavega
      Our data logging engine is based on a timed loop, and the Actual Start left node is used to log the current absolute time. 99% of the time it works perfectly, but once in while it will give the value 11/11/1903  10:57:12.702 PM. Each time it gives an erroneous value, it's this exact value. Has any of you ever seen that? We use LV2011 32bit.
    • By Manudelavega
      Our CANbus driver contains 3 timed loops:
      - #1 prepares and sends outgoing messages
      - #2 receives and parses incoming messages 
      - #3 handles events and check the communication status
       
      Our driver's performance are not satisfying enough (we want it to run at a 10ms rate). It works ok most of the time (11ms, 9ms, 12ms, 10ms, 11ms, and so on) but the gap between loop iterations sometimes jump to 200ms before going back to an acceptable value. Quick tests showed that it is related to a user's request to change what HMI to display in a completely unrelated area of our application.
       
      This logically led me to one obsession: making sure our driver never relies on the UI thread. To achieve that, I set the execution thread to "other 1" and the priority to "time-critical". I know setting the thread to "other 1" is not a full guarantee, so I also tried to get rid of everything that would force the VI to go to the UI thread: I got rid of all the indicators and all the property and invoke nodes.
       
      The performances have already improved a lot, and the HMI activity in other part of our application no longer seem to influence the timed loop iterations.
       
      However I'd like to see what else I could optimize:
       
      - I still have a "stop" Boolean control. When it is set to True from another "manager" VI, the driver has to stop. All 3 timed loops poll this control to know whether to exit (one directly through the terminal, the other 2 through local variables). I know polling is not great, but my main worry is: because this is a control, does the VI still go to the UI thread whenever it is polled? Or only when its value change? I should also mention that I am not ever opening the front panel of the VI.
       
      - Loops #1 and #2 need to be able to notify #3 that a read or write operation failed, so that #3 can take care of resetting the device and restarting the communication. Right now, #1 and #2 simply write the error in a dedicated error cluster (so I actually still have 2 indicators left I guess) and #3 polls those errors through local variables. Does that mean that at each iteration the VI goes to the UI thread since I am writing to those error clusters at each loop iteration?
       
      Any comment on optimization in general is more than welcome!
       
      Emmanuel
    • By Jon Kokott
      Un-abortable from VI Server: Start Asynchronous Call Prepare to call and forget 0x80 
       
      I'm trying to abort call and forget VIs that don't get shutdown properly.
       
      I'm launching using 0x80 (call and forget)
       

       
      Problem is, I can't seem to find them in memory using VI server.
       

       
      If I "trick" labview and just start opening a VI by name, and put in the correctly (guessed) clone name
       
      i.e. dameon.vi:3
       
      and it just so happens to be the right name I can find it.
       
      Why isn't it appearing in all VI's in memory?
       
      Is there any way to find clones of a VI through server?
       
      Stranger still:
       
      the name of the VI when i hover over the abort button is something like dameon.vi:Hostdaemon:ProxyCaller.234908238:3
       
      wtf?  how can I abort call and forget VIs problematically?
       
      Lastly, I'm aware of Abort.vi which I forget who programmed.  I got it off lavag at some point, see attached.
       
      ~Jon


      Oh yeah, even if I get the right clone name from VI server through my educated guess, I still cant abort it problematically with the abort method.
       
      Showing the front panel with an invoke node does work however (wtf? why?)
       
      I can then hit the abort button on the front panel of the daemon, and it does stop.
       
      ~Jon
      Abort_LV82_v100.zip
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.