Jump to content
Sign in to follow this  
Manudelavega

HANG when aborting timed loops: Is 42CHH33W really fixed??

Recommended Posts

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 :throwpc:

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

Share this post


Link to post
Share on other sites

Bumping this thread as I really would like to see some comments, even if you can't propose any fix. At least I would like to know that I am not the only one who encountered this hang issue. Please :ph34r:

Share this post


Link to post
Share on other sites

Well since you want comments too ;) :

At one point I was working with some folks on making a timed loop you can plug into. We played around with a variety of features including using a custom timing source, using the timed loop abort functionality, etc. I can't remember them all anymore, but we had a lot of issues. For example, we had totally bizarre issues using a named timing source (if you didn't know, you can wire in a string name like "1 MHz absolute" rather than using the dialog)...sometimes it would work fine, sometimes the loop just would not ever run. On the 9068 in 2013 (first release of linuxrt), the 1 kHz clock in our testing had jitter of up to 1 clock cycle -- that is, if you request 1 ms it might give you 2. I don't know if this is fixed now, I just only ever use the MHz clock.

All this is basically to say that after really trying to push on the features of the timed loop, I came away less a decent chunk of time and uninterested in using it

The solution we went with was to just make a really simple class for a timer function, you pass in a time to wait in ns and you run this inside of a non-timed loop (to avoid timed loop overhead), which in turn was inside of a timed sequence structure (to make it single threaded and give rt priority). We didn't see any meaningful performance degradation going this route. For your purposes, you could create a 'timing source' which waits on a rt-fifo in polling mode for example, and tells you if an exit or some other message was received or if the wait time elapsed. Admittedly you do have to write the math for this and keep track of when iterations start and stop, and make it work cross platform -- all the stuff the timed loop does for you -- but you have total control over it and can stop hitting your head against the wall, so thats what we did.

 

Edited by smithd

Share this post


Link to post
Share on other sites

Thanks smithd!

I should have mentioned that I'm just running on regular Windows, no RT anywhere. You will probably reply: then why on earth are you using a timed loop? Well back in the days I naively thought that timed loop would be more deterministic and have higher performance, but later on I read that not only is it not more deterministic when run on Windows, it also has additional overhead and end up using more CPU than a regular while loop. Yet we kept it because we liked the possibility to abort, and the fact that we can use the "Actual Start [ i ]" left data node in order to log the time stamp of the actual iteration in our log file.

So it seems that you also found stinky stuff with the timed loop eh... Well I might end up getting rid of it altogether, replace it with a while loop, and handle the timing myself...

Edited by Manudelavega

Share this post


Link to post
Share on other sites

I found the culprit!! :ph34r:

Back in the days a coworker of mine had the noble intention of increasing the performance of our application by adding some code that would assign a HIGH priority to its thread in Windows (you can do it manually through the task manager).

It took me a while to figure that out, I’ve been stripping code from our application bit by bit, until that little subvi was the only thing remaining!

The online documentation does recommend not to modify the priority and warns that unexpected behaviors might occur. So I’m not sure if NI will try to fix anything. But at least you guys should add this to your troubleshooting database so that next time you hear about this symptom you can tell the developer to check this setting.

I’m attaching a project that will reproduce the issue very quickly if you set “HIGH PRIORITY”. It will run smoothly all night long if you set “NORMAL PRIORITY”.

Closure feels so good, workarounds suck :D

Stop Timed Structure Hang.zip

  • Like 1

Share this post


Link to post
Share on other sites

But...but...setting high priority should make the whole labview execution system high priority. Very weird.

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
      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!
    • 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
×
×
  • Create New...

Important Information

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