topic Re: The Mystery Code Thread in BreakPoint

The Mystery Code Thread

altenbach — Mon, 17 Jan 2011 06:31:24 GMT

Once in a while I run across some code that makes my head spin and I am trying to figure out one of the following questions:

"What was the programmer thinking when wiring this??!"
"Is there any possible reason that this code makes sense and I am just not gettting it??"

This thread should serve as a place to investigate such Code fragments. Maybe the collective brains of this forum can find a clear explanation. 🙂

Let's have a look at a small subVI program with a name containing "time delay" posted here.

Look at the diagram picture. The only reason that I can think of is that the original problem description was: "Create a VI that will never stop if it is run in execution highlighting mode". 😮

The VI will only work correctly if the bulk of of the loop content is guaranteed to execute within the same ms tick. (Else it will keep trying, possibly forever.) Fortunately it seems to work correctly as is, but why take the risk??

Is there are conceivable justification for all these wires? The tick count? The addition? The comparison? The while loop? Am I missing something obvious?

(The reason for the "invert" is clear. Back in the old days, loops only had "continue if true" mode for the termination condition.)

Re: The Mystery Code Thread

Ben — Mon, 17 Jan 2011 13:32:18 GMT

Could that be a "over-load" detector?

I'm thinking that code running in parallel with other code will keep running until the app becomes CPU bound and there aren't enough slices left over for toher threads so that one can drop out.

Just guessing.

Ben

Re: The Mystery Code Thread

altenbach — Mon, 17 Jan 2011 18:13:12 GMT

Interesting guess. I highly doubt that the loop diagram will get sliced by a thread switch here, but I would not know... Let's do some testing!

Even on a lightly loaded machine, there is a small chance that the wait is twice as long, simply because we might (by chance!) be very close to a tick count turnover. For example in the following code we can see that in a finite fraction of calls, the loop spins twice, thus doubling the delay. There is an even smaller chance that it spins three times, tripling the delay! The code is not deterministic!

Now lets add two greedy while loops to gobble up all spare CPU (I am on a dual core system), and yes, the chance for a double-delay is 5x higher.... maybe you are on to something here.

Still, would it really make a difference? Even here the chance for a double delay is less than one percent. Lots of code at the cost of determinism and no obvious gain. 😄

In any case, code such as this requires a diagram comment! 😉

Re: The Mystery Code Thread

JÞB — Tue, 18 Jan 2011 02:42:16 GMT

The butler coded it? possibly forever?

OMG (at the risk of offending certain participants) The code is a "Who done it!"

Re: The Mystery Code Thread

JÞB — Tue, 18 Jan 2011 03:29:53 GMT

Will the deceased body be found? Yup- under the uncommon circumstances described-Yet, Probably the "corpus delectii" will not be in evidence.......

^^^ LowerLoop 1 we "hide the corpse" ^^^ Lower Loop 2 we "destroy the time stage of the crime"

CSI writers- The perfect crime ......

In any case, code such as this requires a diagram comment! ; Or a corpse!

Re: The Mystery Code Thread

Ben — Tue, 18 Jan 2011 12:55:14 GMT

Hi Christian,

You alluded to but have not concidered a imporatant fact, this appears to be old code from prior to the option to "stop" if true for the termination terminal. Try runing the test with;

ESys.StdNParallel=0

(after restarting of course) in the LV ini file to force LV to run single threaded like in LV 5.0.

Ben

Re: The Mystery Code Thread

altenbach — Tue, 18 Jan 2011 16:44:35 GMT

Ah yes!

I think I can do the same (without impacting my entire development system!) by settting it to run in the UI thread, here's what I found:

(1) Without the two extra while loops, and setting a 1ms wait, I get the following histogram of actual delays.

1ms: 26268

2ms: 3205

3ms: 239

4ms: 8

5ms: 0

...

inf: 0

We get a >10% chance of extra delays!

(2) With the two extra while loops, the VI never finishes (!!) and gets stuck in the inner while loop forever!

1ms: never

2ms: never

3ms: never

...

inf: 100% !!!

This also means that if the application is not carefully designed and for example contains greedy polling loops, there is a good chance that the program locks up and can never finish!

Did it ever make sense to "over-engineer" a time delay in such a way? Maybe!

Has anyone else ever seen this construct? Could it be it was a widespread and accepted method to throttle sections of code in ancient times? I really don't know.

If this in fact was the functional intent, the VI name should have been more clear, e.g. "low priority time delay" or similar. Of course the complete lack of documentation is not helping either. No description, no diagram comments, etc.

Re: The Mystery Code Thread

AnalogKid2DigitalMan — Tue, 18 Jan 2011 19:23:16 GMT

I know where that code comes from and what its intent was. I came across it many years ago but never ended up using it for a potential project.

-AK2DM

Re: The Mystery Code Thread

LV_Pro — Tue, 18 Jan 2011 19:25:34 GMT

"I know where that code comes from and what its intent was." Pretty cryptic!

Re: The Mystery Code Thread

Ben — Tue, 18 Jan 2011 19:43:02 GMT

So we have a witnes be he ain't takin. He did give as clue "THe question drive us" so....

Twenty questions it is!

Q1) Is it used to detect the load on the CPU?

Ben

Re: The Mystery Code Thread

AnalogKid2DigitalMan — Tue, 18 Jan 2011 20:13:55 GMT

20 Questions? Man, I can't let you guys wait(ms) that long....

Q1 (Ben) Negative.

-AK2DM

Re: The Mystery Code Thread

AnalogKid2DigitalMan — Tue, 18 Jan 2011 22:10:26 GMT

The code came from Parker/Compumotor as part of an example to use with their Active X communications server for the 6K series of motion controllers.

The sub vi in question simply served as a delay between serial writes and reads to allow the 6K keep communications in order.

A simple wait(ms) with flow contol would have sufficed.

I played around with some of the Active X circa 2004/05 but did not apply LabVIEW for the 5 axis laser CNC I built around the 6K. The operators already know the 6000 command set, why complicate things by adding another layer.

I have seen some very badly written code from another major optics/motion manufacturer, in the end in many cases I just start from scratch- just give me the prgorammers guide!

That's my story and I'm stickin' to it!

-AK2DM

Re: The Mystery Code Thread

LV_Pro — Tue, 18 Jan 2011 22:38:06 GMT

This is why I cringe when a customer tells me that they have picked out some piece of hardware, "but it has LabVIEW drivers". I have seen too many instances where it looked like they were written by the summer student intern, who had the LabVIEW DVD dropped on the desk with the directive to "write a driver for the M6000 widget line". Ahhhhhh! Last fight was last fall when I was getting random LabVIEW crashes, traced it to a "dll" call, discovered that the dll was just a wrapper around a call to a common USB interface dll, but it wasn't written right. Calling the actually USB dll (after weedling the info of what the wrapper dll was actually trying to do) solved the problem, but at my billing rate it was an expensive "oopsey".

Re: The Mystery Code Thread

Yamaeda — Wed, 19 Jan 2011 23:25:26 GMT

The thought process is probably like this: Wait has a wait time input and a ms output, thus the output is the ms counter when the wait is over (making it a normal add ...) Therefore i must check against the current time.

Re: The Mystery Code Thread

AnalogKid2DigitalMan — Wed, 09 Mar 2011 22:06:43 GMT

The mystery vi just showed up in this post attached as "6KTimeDelay"!

http://forums.ni.com/t5/LabVIEW/Compumotor-6K-4-used-to-drive-goniometer-table/td-p/1480556

-AK2DM