Manudelavega

If most of what you read in that thread is new to you, start with queues. That's really a must-know in LabVIEW, on which many more sophisticated patterns are based.

Well the string selectors listboxes of instrument tuner.vi (Cello Strings, Guitar Strings, and so on) are not related to the ones inside String Selector.vi at all... You need a way to pass their values to String Selector.vi otherwise String Selector.vi will keep using their default value (index 0).

I found the culprit!! 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 Stop Timed Structure Hang.zip

Wow that's a big deal. Even though he remains chairman of the board, it's still a huge page that is turned in the NI book!

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...

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

Since the connector panes of a child and its parent need to be exactly the same, you need a way to make the passing of parameters generic: either the path of an INI file, or a variant (the child method will know how to cast it back to a cluster), or a string (XML or JSON)... Keep in mind that the child object will contain both a set of parent private data and a set of child private data. So put any common parameter in the parent private data, and any child-specific parameter in the child private data.

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

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.

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?

I'm also running Chrome 52.0.2743.116... I'll try clearing the cache. EDIT: It did the trick! Thanks

Really weird, I get signed out each time I hit the Home button. But if I hit one of the sub-item (see example below) then I remained logged in. Everybody else with that issue? The frustration is growing in me Home > LAVA Site Related > Site Feedback & Support

I might be lacking imagination, but I achieved results in my LV code that I feel I could never have done without OOP. I have a plugin architecture where all the plugins share a lot of functionalities, which I have coded inside the parent class. Then a "plugin manager" contains an array of all the plugins, only knowing them as "parent class" and never having to worry about which type of child class they are...

That's a fun demo I wrote for a LabVIEW User Group. FunLVOOP.zip

I see, ok thank you both, that was really helpful!

Oh so it has nothing to do with the DVR node of the IPE? So you're talking about putting an IPE with the simple In Place In/Out node?

Thanks. So we are talking about when you have a Dynamic Dispatch method inside the IPE, and not the other way around, right?

Good question, I never really understood that option.

I have some old VIs to which I need to give some love. All the error clusters were unwired, so I am working on that... I am wondering what would be the best practice when it comes to DVR. The IPE structure gives an error cluster on both the left and the right data node. The attached picture shows all the error handling I can think of, but I wonder if it's not an overkill. Here is the breakdown: 1) Outer case structure: If there is an error before going inside the IPE, it just skips the IPE altogether and propagate the error cluster. 2) IPE left data node: I don't need to merge it with any incoming cluster since we are in the "no error" case (what about warning? am I speaking too quickly?). 3) Inner case structure: as long as the code inside it knows how to deal with the error (likely skipping its own code and propagating the error), I probably don't need this structure. What do you think? 4) IPE right data node: in what scenario would it actually give en error? If the DVR is bad, the left data node will take care of generating the error... Is it there is case the DVR becomes bad during the IPE execution? If I wire the right data node, then I need to merge it with the error cluster coming from the code inside the IPE... Any comment more than welcome!

So the leak would come from the variant stored in the shift register?

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!

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!

Dear all, My company is hiring a new developer to join our software team. Please see link below for details and to apply. http://www.greenlightinnovation.com/company/careers/articles/225.php

A few comments on the LabVIEW code in general: - You don't have anything that paces your VI (such as a Wait until next multiple), so your VI will run as fast as it can, putting an unnecessary load on the CPU - Instead of initializing and clearing the task inside the while loop, you can perform those tasks outside of the loop. Look at the examples that ship with LabVIEW

Come on!