Scary LabVIEW images

[Darin.K]

---

@tst wrote:

Sorry. 11, 31 or 291 uses of the clear errors VI are not a problem in themselves. You need to see how they're used in the context of the code to see if that usage was reasonable (although I admit I would probably be concerned if I saw 291).

---

This was exactly my thought when I first read the post, which is too bad because tst is clearly the voice of reason and I find it much more fun to be unreasonable.  I have no doubt that the code is scary, but I also would not flinch at seeing that many Clear Error uses.  Using it 7 times in the Get Sample Rate vi might be a bit concerning.  This sounds like code dealing with hardware, and those errors (IMO) should be taken seriously.

We all know that Clusters and Enums are datatypes and not UI elements.  Sometimes for convenience sake we do it anyway.  Likewise, the Error In/Out terminals are meant to communicate errors and warnings to other parts of the code that need to take specific actions (notification, logging, power cycling).  They are not really meant to simply enforce execution order between two otherwise unrelated pieces of code.  There is a certain structure (two actually) whose job is to enforce such order, but who is really going to go there?  The price for avoiding the structures-that-shall-not-be-named is the occasional-to-frequent need to sift potential error messages. 

Those terminals are like BNC connectors, every piece of hardware has a few it seems.  Just because the plugs are compatible however...

At least Clear Errors is searchable, what would scare me is 31 or 291 or 1723 instances of 'Use Default if Unwired' tunnels on case structures.

You want scary code?  I came across this a week or so ago.

Signal Processing -> Waveform Measurements -> Extract Single Tone Information.vi

Open the BD and Check out the Extract Single Tone From Hann Spectrum subVI.

[JÞB]

Thanks Darin!

I hadn't looked at that before- I feel "dirty" and now I need to go wash my eyeballs

[SteveChandler]

---

@Jeff Bohrer wrote:

Thanks Darin!

I hadn't looked at that before- I feel "dirty" and now I need to go wash my eyeballs

---

Every LabVIEW programmer needs emergency access to one of these in case of exposure to such code. I just love the picture on the sign.

[Darin.K]

---

@SteveChandler wrote:

---

 

Every LabVIEW programmer needs emergency access to one of these in case of exposure to such code. I just love the picture on the sign.

---

Clearly graphical communication is failing.  The point of the sign, and the eyewash, is that your eyes must be OPEN. 

[altenbach]

Looking at the sign, I immediately thought this device is a collector for tears. 😮

(This is also equally needed when looking at some programs. :D)

[JÞB]

The part that amazed me about extract singal tone.vi was how long it took to drop onto a BD.  I assume the DFIR and optomizer had to go into emergency mode and make a few additional passes on that vi.

[MDC]

Thanks for making us aware of this (Extract Single Tone Information).  We'll look into updating this diagram in a future release.  We've created a CAR for this task.  For your reference, the CAR ID is 302256.

[altenbach]

---

@MDC wrote:

We'll look into updating this diagram in a future release.

---

I think just putting lipstick on the same algorithm is a waste of time and always has the potential of breaking things by accident. The VI works fine!!!

I would only consider maintenance if the algorithm should be modernized, either for better performance or better stability in edge scenarios. Is there a better algorithm? Even in this case it might be dangerous to upgrade because existing code might rely on some flaws of the existing code.

Over the last 15 years, I've done many "minor and apparently inconsequential" code edits that bit me later. 😄

[Ben]

---

@altenbach wrote:

---

@MDC wrote:

We'll look into updating this diagram in a future release.

---

I think just putting lipstick on the same algorithm is a waste of time and always has the potential of breaking things by accident. The VI works fine!!!

I would only consider maintenance if the algorithm should be modernized, either for better performance or better stability in edge scenarios. Is there a better algorithm? Even in this case it might be dangerous to upgrade because existing code might rely on some flaws of the existing code.

Over the last 15 years, I've done many "minor and apparently inconsequential" code edits that bit me later. 😄

---

Those floating point array indexes scare me as well.

Ben

[Darin.K]

Sometimes you have to be careful what you ask for...

http://forums.ni.com/t5/LabVIEW/Extract-Single-Tone-Information-from-Hann-Spectrum/td-p/139345