topic Re: Scary LabVIEW images in LabVIEW

Scary LabVIEW images

Ben — Fri, 27 May 2011 16:53:47 GMT

I was given coe developed by others to fix and support. While cleaning up the error clusters I started to run acroos the "Clear Error" VI used TOO many places so I did a quick serach to see just how extensive and got this.

I am going to have to take a shower when I get home becuase I feel dirty after touching this code.

Please post your scarry images you come across here.

Take care,

Ben

Re: Scary LabVIEW images

johnsold — Fri, 27 May 2011 17:13:58 GMT

One way to claim "Bug-Free Code!" It will never show an error.

Lynn

Re: Scary LabVIEW images

RTSLVU — Fri, 27 May 2011 17:33:33 GMT

I was asked to see if I could improve this program...

Needless to say I threw this out and started over from scratch.

Re: Scary LabVIEW images

JÞB — Fri, 27 May 2011 17:40:36 GMT

Ships in the LabVIEW examples! (method re-initialize all to default must be super-secret)

Re: Scary LabVIEW images

Mark_Yedinak — Fri, 27 May 2011 18:01:37 GMT

I don't have an image of this one program I was asked to help fix but when it was printed out on a large chart plotter (the only way to get a view of what was going on) it covered the entire table in a large conference room. Talk about a nightmare.

Re: Scary LabVIEW images

altenbach — Fri, 27 May 2011 18:21:56 GMT

@Ben wrote:

While cleaning up the error clusters I started to run acroos the "Clear Error" VI used TOO many places so I did a quick serach to see just how extensive and got this.

If an error occurs and nobody sees it, did it really happen??? 😄

I am curious if it was just a misguided attempt to silence automatic error handling?

(Many times errors don't matter and an overzealous effort to "catch" all errors can lead serialization of the code and loss in parallel code optimizations.)

Re: Scary LabVIEW images

SteveChandler — Fri, 27 May 2011 20:05:04 GMT

Lucky for you there are only eleven!

Re: Scary LabVIEW images

SynergyMike — Fri, 27 May 2011 20:12:54 GMT

Ok, now you have my curiousity piqued... in LV7 code that I took over, I found numerous instances where, in order to test for the existance of a directory or file, the error cluster was used. In order to preserve dataflow, I added a clear error to each instance of a case structure that had selected the error - is there a preferred alternative? (The VI probably has 5 or 6 clear errors total).

Michael Tracy

Synergy Microwave

Re: Scary LabVIEW images

SynergyMike — Fri, 27 May 2011 20:21:33 GMT

> Needless to say I threw this out and started over from scratch.

Hey, I think your author went to the same programming school as mine - only throw in some big stacked sequences for good measure... 🙂

Michael Tracy

Synergy Microwave

Re: Scary LabVIEW images

JÞB — Fri, 27 May 2011 20:38:03 GMT

I have to admit I do use the clear errors.vi but, to enforce specific behavior.

I specifically use it when scanning a string to a type def'd enum where the string was in a configuration file. I do not want the error handle popping up when some dratted user typoed the file when I can't find what system state got me there The scan from string function allows me to define a default value that I can use in my code to trap the bad value. (Its why most of my AE's have a "Null"<Default> method . they do not ALLWAYS have null code - sometimes they have debug tracing utilities)

I'm assuming that was NOT the case with Ben's example and that it did indicate a horror.

Re: Scary LabVIEW images

CMal — Fri, 27 May 2011 22:14:44 GMT

On the subject of scary images, LabVIEW was recently honored by an article on thedailywtf.

Chris M

Re: Scary LabVIEW images

Mark_Yedinak — Fri, 27 May 2011 22:41:05 GMT

@CMal wrote:

On the subject of scary images, LabVIEW was recently honored by an article on thedailywtf.

Chris M

Unfortunately people are taking an example of extremely bad code and using that to bash LabVIEW. When I have some time I will need to reply to some of the ridiculous posts over there.

Thanks for the heads up.

Re: Scary LabVIEW images

altenbach — Fri, 27 May 2011 22:45:23 GMT

@CMal wrote:

On the subject of scary images, LabVIEW was recently honored by an article on thedailywtf.

Re: Scary LabVIEW images

jcarmody — Sat, 28 May 2011 00:21:47 GMT

@Mark Yedinak wrote:

@CMal wrote:

On the subject of scary images, LabVIEW was recently honored by an article on thedailywtf.

Chris M

Unfortunately people are taking an example of extremely bad code and using that to bash LabVIEW. When I have some time I will need to reply to some of the ridiculous posts over there.

Thanks for the heads up.

Re: Scary LabVIEW images

Ben — Sat, 28 May 2011 14:12:20 GMT

@SynergyMike wrote:

Ok, now you have my curiousity piqued... in LV7 code that I took over, I found numerous instances where, in order to test for the existance of a directory or file, the error cluster was used. In order to preserve dataflow, I added a clear error to each instance of a case structure that had selected the error - is there a preferred alternative? (The VI probably has 5 or 6 clear errors total).

Michael Tracy

Synergy Microwave

Legacy code get grandfathered out of modern expectations but there are functions on the Files Advanced palette to list check etc.

To judge my own rules I tend look at a software developers relationship to their code as analogous to a doctors relationship to their patient. To evaluate the current state, the doctor will probe and look for specific conditions and/or reactions. A patient recoiling when the abodmen is probed could indicate a specific ailment while attempting to open the file the user specify returning an error 7 File not found, or parsing a binary file and check from error 4 EOF are specific checks for conditions that we expect will happen. The attempt to do the operation followed by the observation are a valid methodology. Of course pulling out that ultrasound scanner instead of poking is a better approach as is using the functions on the advanced palette that check it the file exist.

I prefer the more elegant approach when I am aware it exist and it is available.

Extending the anaology...

But using the "Clear Error" is not a specific probe. It would be like a doctor treating an in-grown toenail by cutting the nerve and telling the patient to go about their life as normal. The code construct of "Clear Error" followed using the data downstream just feels like cut the nreve and go on situation.

Full Disclosure time!

In my Control Ref Nugget I used a similar construct but rather than using the Clear Error function, I used a Case Structure selector to handle the error returned when the class was wrong. For the sake of that Nugget, it was acceptable since it would have introduced more complexity to an already complex subject. But I digress.

So Using Clear Error is not malpractice. Over use on the other hand if not abusive should give any careful developer reason to investigate (In my case shiver and fear for the sake of my patient not knowing what kind of gangreenous growths I will find inside the extremities).

But that is just my 2 cents and I admit that I have an analretentive side and the control freak in me wants it to be "error free" and as Christian mentioned above, "Is it really 'Error Free' ?".

Re: 31 instances!

That is beyond scarry. Are you being punished for something?

Ben

Re: Scary LabVIEW images

tst — Sun, 29 May 2011 06:24:40 GMT

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

@Mark Yedinak wrote:

When I have some time I will need to reply to some of the ridiculous posts over there.

Please don't. Like I said in the other thread, it seems to finally be dead and some of those posters didn't prove to be particularly adept at actually listening to what other people have to say. Jim's comic (one of my favorite XKCD's) sums it up nicely.

P.S. Of course, the images from here can also count as scary LV code.

Re: Scary LabVIEW images

Ben — Sun, 29 May 2011 06:41:04 GMT

@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

Ageed. After you examine the context.

This thread is all about scary images. When you do a search and find 291 Clear errors and you DON'T know what is the context, its scary.

Is there a story that goes with the number 291?

Ben

Re: Scary LabVIEW images

tst — Sun, 29 May 2011 07:34:57 GMT

@Ben wrote:

Is there a story that goes with the number 291?

No.

Re: Scary LabVIEW images

SteveChandler — Sun, 29 May 2011 13:54:12 GMT

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

You are right. Without going into how they are used let's just say that at one point the code with 31 clear error vis had over a hundred calls to the abort function. It doesn't anymore because I wrote a vi with nothing but the abort function in it and did a search and replace so now there is only one. My thought is that now I have a vi where I can do the software equivalent of deploying an airbag before the car hits the tree.

Re: Scary LabVIEW images

johnsold — Sun, 29 May 2011 13:57:34 GMT

Did it also watch the clock so that it did not work past quitting time?

Lynn