(A) Here we spin a loop at double-speed doing nothing but writing local variables to their own terminal (Reminds me of C programming). The LabVIEW equivalent of a short circuit! If we would delete that loop and delete all the local variables in it, nothing (nothing!!!) would change (except better performance and cleaner diagram).

(B) Here we spin a loop updating a chart every 500ms. If we would eliminate that loop and place the bundle in the other loop at (C), it would update at the same rate, exactly!.

(C) See (B)

(D) Since we have all these extra loops, we cannot use a latch action boolean, so let's do something funky! Interestingly, the actual stop button wire is not even used anywhere.

Re: Update, update!

i was assuming the other cases also has same locals, with different inputs. i played long ago with similar configuration, (LV5 tough), and found out that depending on the case chosen ( and actually the position of the locals within the cases ), the write would be before or after the read just after the case structure. that would totally destroy the order (altough keep a pattern ).

maybe i will try that again...

-----------------------------------------------------------------------------------------------------... And here's where I keep assorted lengths of wires...

Re: Update, update!

isnt it there a very bad race condition in (C), (values in the case structure vs out)

Ah, now I see it! I thought you were talking about the big case structure.!

Yes, you are absolutely correct. There is no guarantee that these green locals going to the subVI are read after they get updated in the small case structure. Most likely, they get read even before the small case executes, thus calling the subVI with stale values.

Re: Rube Goldberg Code

One very late night of coding, several years ago, having had the program "blow up" several times during testing, I created an icon for the top level vi that was a picture of the U.S.S. Maine on a fateful night in Havana harbor. It is probably still there (the icon).