array subset truncating end of 2d array

[teknikal2]

The beauty of Labview is that something can be thrown together quickly to get something working, then optimize it later.  I am a EE in an R&D department for consumer products.  So 99% of what I do is only for my own use, and really only needs to be pretty or optimized if it runs too slow or if other people will use it.

The original program allows the user to dynamically enable, disable and change many parameters of the signal frequency and modulation of multiple signals superimposed on each other, then continuously output to a DAQ device.  I found that optimizations like demonstrated on this thread actually eliminated the problem, but I didn't want to eliminate the problem in the demo code.  I see how deleting controls and functionality from the code makes it seem useless.

This kind of bug scares the crap out of me actually.  What other code may I have written that might use array subset in a way that would cause data loss on under certain conditions?  Who knows.

I do appreciate the coding tips, but remember it's just demo code that serves as an example to make the array subset malfunction.  There are many things besides changing that one wire that makes the problem come and go - seemingly related to the overall memory usage of the program.

[JÞB]

---

@teknikal2 wrote:

The beauty of Labview is that something can be thrown together quickly to get something working, t

I do appreciate the coding tips, but remember it's just demo code that serves as an example to make the array subset malfunction.  There are many things besides changing that one wire that makes the problem come and go - seemingly related to the overall memory usage of the program.

---

I appologize that my first reply sounded a bit harsh.  "LabVIEW - so easy a caveman can do it!" is perhaps the best and worst thing about LabVIEW.  The staff at NI that actually develops this amazing tool is fairly good but, there are a few use cases that might never get tested.  Example: seen here where I did something insane.

A small amount of "Style" can help alot for readability of your own code and "Tweaking it" when the project encounters "scope-creep" 6 months later.  You may find the style guide a useful resource to improve your code http://www.ni.com/pdf/manuals/321393d.pdf#labview_style_guide it is a very good resource.  VI Analyzer has many tests that would have also exposed the questionable Software Engineering practices in anyone's code.  The "Test Failure" discriptions have often helped me improve my coding.

[altenbach]

---

@teknikal2 wrote:

This kind of bug scares the crap out of me actually. 

---

Me too. That's why it is important to do a lot of testing. No software or compiler is completely bug free. In the early eighties, we were taught that one of the laws of software is that the last bug can never be found, i.e. after testing and debugging by an infinite amount of programmers for an infinite amount of time, there will be exactly one bug left. If you think you found the last bug, there is guaranteed to be another one. Look at the constant stream of windows updates!!!

The LabVIEW compiler is a miraculous piece of software and it does work correctly in a billion other applications. If you think other compilers are completely bug free, welcome to fantasy land. 😄

---

@teknikal2 wrote:

 There are many things besides changing that one wire that makes the problem come and go - seemingly related to the overall memory usage of the program.

---

No, memory usage has nothing do do with it here. You can set the buffer sizes to 10 elements and generate arrays with 3 and 4 (resp.) elements to be appended, and the problem shows exactly the same way.

One of the strenghts of the LabVIEW compiler is speed and memory optimization. Without these, all programs would be slow and bloated and will run out of memory at random times. It seems in very rare and complex edge cases such as in yours, it reuses a buffer that it should not. The "always copy" primitive is a function that thould never be needed, but if you search the forum, there were a few cases in the past where it acted as the magic fairy dust to make code work correctly. In all cases, the bugs were CARd and probably fixed.

Jeff is also correct of course. If code design is clean to the eye and mind, it will also look cleaner to the compiler and the compiler is less likely to slip up.

 If you program it as a fully "in place" solution as I suggested, the compiler does not need to worry about buffer re-use at all.

[JackDunaway]

---

@teknikal2 wrote:

This kind of bug scares the crap out of me actually.  What other code may I have written that might use array subset in a way that would cause data loss on under certain conditions?  Who knows.

---

@hi @teknikal, I share some of the same concerns, and tend to look into these things. Thank you to @altenbach for alerting me to this and helping pare down the issue.

Attached is a snippet of a more minimal test case, using just primitives (no loops, waveforms...) of what is almost certainly a compiler bug you found:

Virtually all wires and sequencing on this diagram are significant in order for the bug to evidence itself.