LogMAN

@Dataflow_G You should revive this topic 😉

We'll grow into it eventually 😋

There are multiple ways actually. Here are a few that come to mind: Let it run faster by adjusting the code inside the loop accordingly Split it into multiple loops to utilize more cores of your CPU Buy a faster computer Note that there is a limit to how many concurrent threads LV supports: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PARmSAO&l=en-US The maximum speed of a while loop is only limited by the speed of your CPU at 100% load (and of course the way your operating system shares the CPU between processes and threads). That is assuming your loop does nothing, which makes it pretty useless. Of course, if your computer has multiple cores, you can run multiple loops in parallel to make use of them. This is contradictory to your first statement. I suppose you mean to increase the loop speed, right? If your code is simple, it should be easy to optimize for speed or to run multiple instances concurrently if applicable.

I think this is a valid comparison: (from https://forums.ni.com/t5/LabVIEW/Global-Variables-Are-Better-than-Functional-Globals-So-There/td-p/1528392/page/5) You are either Novice or Guru 😋

Here are some links to MS Docs that might be helpful: Using the Address Resolution Protocol Description of Address Resolution Protocol (ARP) caching behavior in Windows Vista TCP/IP implementations The second one is for Vista. I couldn't come up with any information on W10, so details can/will differ. Not sure if I misinterpret the information, but shouldn't the ARP table keep updating (i.e. not sending additional ARP requests) while packages are being transfered, or is this limited to TCP? If an entry is not used for a time between 15 to 45 seconds, it changes to the "Stale" state. Then, the host must send an ARP Request for IPV4 to the network when any IP datagram is sent to that destination. RFC 826 only mentions timeouts briefly: It may be desirable to have table aging and/or timeouts. The implementation of these is outside the scope of this protocol.

I just had this issue and found a way to reproduce (and fix) it: Create a new VI in a library (use the right click menu of the library to create the VI). Place the VI on the block diagram of another VI The VI is only selectable if the selection goes completely around it. To fix it, open the icon editor on the offending VI and simply press OK to close it. Now selection works as expected (i.e. partial selection selects the VI).

Good point. Now that you mention it, the output of the multiplication functions are connected to a VI that (as far as I can tell) builds status messages and updates the progress bar (see the references connected to it). The output of that VI is displayed on the FP at a rapid pace. The VI obviously has too many responsibilities and should be split into multiple VIs. For example: Calculate Progress Calculate Estimate Time To Complete Calculate Estimate Time To Next User Action Display Progress Display Status Message Display Time To Complete Display Time To Next User Action These VIs can be put in sequence, which makes it very easy to follow. It's also much more reusable than the current solution. I'm well aware that the example above is probably too fine grained for the purpose of this application, but there is a high chance that each of these VIs can be reused multiple times or even omitted if not needed. That is not possible with the current solution. That is probably why there are two Boolean constants attached to the VI right now (i.e. too enable features that are only required in this particular section of code).

If the boolean controls are clicked by the user, use the event structure instead: http://www.ni.com/white-paper/3331/en/

@smithd has stated very important points. It's also very important to get accustomed to techniques like the state machine in order to keep the code readable. However, in my experience it is very unlikely that a) shifting to a new system (like Teststand) solves the problem. That's for the same reason the previous one failed: A lack of understanding, planning and structure. b) using "better" techniques improve the application. Again for the same reason. c) replacing the current structure is even remotely possible because either the lead programmer left (or rather ran away) or it is too complex to comprehend. Edit: To clarify, you should take those solutions into consideration of course! This is of course my personal experience. Your situation may be entirely different. That being said, I'm sure we all have made these mistakes and learned from it. You should do the same. At first glance your VI looks confusing and hardly maintainable. On a closer look, however, it strikes me as a rather simple VI (i.e. not many different jobs going on at the same time) that only lacks structure and uses way too many indicators that presumably serve no real purpose other than being there (and maybe occasionally being viewed). I think the word we agreed on for such a VI is "paintainable", right? You asked for suggestions to improving your current situation, so find below a summary of what you can do, based on the code you shared: Remove code that is only meant for debugging purposes. With this I mean indicators such as the ones in the inner while loop. If the loop runs at max. speed, it updates the indicators every 20 ms. That is quite a bit faster than any human being can physically comprehend. Therefore, you have no reason to keep the indicators updating inside the loop. If you need to display the last value, simply move them outside the loop and use the last value. Once you removed the indicators, remove any code that isn't connected anymore. That should get rid of "dead" code. Take a closer look at the inner while loop and replace it by a for loop If you look closely, you'll notice that the inner while loop is actually a for loop. The conditions are: a) The boolean control "Stop Loops and Save Data 2" must be True, or b) The number of iterations is equal to the length of the "Frequency" array. Condition b) is clearly a perfect fit for for loops. Once you have made it a for loop, the second condition can simply be removed, which makes it a bit easier to understand. Move static functions outside the loop Inside the inner while loop are some multiplication functions that multiply values that come from outside the loop. These functions will always produce the same result inside the loop and therefore should be placed outside. It's a small change, but stuff like this makes the diagram easier to comprehend. Initialize the cluster outside the loop This is probably the biggest and easiest fix you can do. Take a close look at the "Bundle By Name" for your cluster in the loop. With the exception of two indexed arrays, all parameters are statically provided from outside the loop. You can easily clean up this code by initializing the cluster outside the loop and only add the indexed arrays in the loop. This should reduce the size of this loop considerably. It will also allow to see the purpose of the loop. Rearrange wires and don't hide wires behind structures or VIs This may sound like a lot of work (because it is), but one very important factor in LV is managing wires. There is actually a thread on LavaG dedicated to handling wires. I suggest taking a look, you can learn how other people do it:Take your time to remove wire bends whenever possible. I know it sounds ridiculous, but once you get accustomed to it you do it by reflex at which point you can start getting lazy again 😉

You are right, hardware and drivers probably play a huge part in it. In fact, the computer I use to record the videos isn't really up to the task, which is why it's easy to reproduce. That's really strange, can't say that I've ever had issues like that. Everything with the exception of structures and wires should simply work with partial selection. Does it only happen in LV2015? Oh and I finally figured out why the block diagram sometimes renders one line at a time like this: (sorry for the potato capture, it's impossible to capture the screen because the graphics driver is busy rendering lines) lv2015highlights.mp4 I can reproduce it 90% of the time on a decently slow VI using this method: Open a complex VI that slows down the editor (like the VI mentioned before) Select an area that has lots of stuff in it. The more elements are highlighted, the better Scroll the window down until some of the selected items disappear from the screen (it should lag) Quickly left click into a free area to deselect all elements and scroll up immediately (it's important to have a delay when deselecting and scrolling or it won't work) I've reproduced it in LV2015 and LV2017 and it happens maybe once per month on my dev machine. I'm curious if someone else has seen it? Any idea why this is happening? Can you reproduce it too?

Wow, thanks again for sharing! That is so much better, it might actually work for me. Now I'm even more excited for LV2019 😍

That is good news. Thanks for sharing, Darren! Your hardware sounds reasonable. By significantly faster do you mean "fluently" or "stuttering, but not as much as before"? I'm so ready to replace LV2015 and finally get my hands on malleable VIs (not to mention all the other features that were added). Can't wait to finally try out LV2019.

NXG Send them this VI for reference: https://forums.ni.com/t5/LabVIEW/Very-complicated-labview-block-diagram/td-p/3187507 It may be broken and surely doesn't win a price for simplicity, but it makes the issue clearly visible to anyone. Now that I think about it, does the Example Finder ship with a decently complicated VI or project to show this issue? That would be hilarious. I really hope they fix it in LV2019 (fingers crossed🤞).

The compiler shouldn't be involved as long as no changes are made to the code. In fact, turning it down to 0 (always limit optimizations) had no impact whatsoever (neither in LV2017 nor in LV2015). On a smaller VI the selection box is more responsive, but the CPU usage is still about 10-15% while resizing the selection box. Tested on an empty VI in LV2017. The same test in LV2015 shows a CPU usage of about 1%. Results can vary depending on the hardware of course. Not sure if it only happens on reentrant VIs, but very rarely (maybe once per month) LV2015 lags very badly while scrolling the block diagram. It literally renders the diagram line by line over a period of maybe 20-30 seconds. Once it's done, scrolling is as fluent as it should be. I still haven't figured out why that happens. Maybe the UI thread is clogged by the compiler or something. It is also not tied to a particular machine.

I can present less complex VIs with the same behavior, more or less intense. @Neil Pate likely also doesn't use broken VIs for real world applications and gets similar behavior. The VI in my video is certainly an extreme case that is not fit to be part of any code base, but it serves as a good example for how bad things can get. I don't expect that VI to work flawlessly, but it wouldn't hurt trying to achieve that, even if that means disabling fancy stuff for more complex VIs. Here is the same VI in LV2015 for reference. To be fair, scrolling is as slow as in LV2017 (or vice versa), but the selection box is so much better. 2019-02-01 21-33-45.mp4 The VIs I'm normally working with are much smaller than this one. Most of them fit on the screen, so scrolling is not an issue for me. The selection box, however, is a different story and part of my daily work. It being slow is a red flag.