Rube Goldberg Code

[altenbach]

Yes, I know it's not quite the same, also e.g. for negative numbers. Still I doubt the code was intelligently engineered for that purpose. 😄

[Norbert_B]

---

Dennis Knutson wrote:

A truly painful experience when looking at the VI here. 

---

Has somone else tried the "diagram cleanup" on this? This shows definetly:

Even the most prudent cleanup cannot replace proper design!  

Norbert 

[RobCole]

---

Norbert B wrote:

Has somone else tried the "diagram cleanup" on this? This shows definetly:Even the most prudent cleanup cannot replace proper design!  

Norbert 

---

I tried it - and the diagram got even bigger. It *did* uncross a lot of the lines though.

     Rob

[Jeff at home]

Would it be proper to use an ETLA? (extended TLA?)

[smercurio_fc]

---

Jeff at home wrote:

Would it be proper to use an ETLA? (extended TLA?)

---

I'm sorry, but it's not clear what this is in reference to. What sort of TLA (three-letter acronym) are you referring to and for what?

[JÞB]

Sorry,

I tried to fit it in part of the discussion about 15 pages back.  -- and still failed to follow the sub thread despite the discussion around pg 3.  

a FLA (four/five letter acronym) is  confusing.  so they are properly ETLA (extended TLA) and DETLA (Double extended TLA)  --- It was funnier around 3AM

[J.Mamakos]

---

Ravens Fan wrote:

Sometimes it may be better if the code does take up more than one screen!

---

...and here's one I made earlier!  I'm still working on this, and most of the code is hidden in several layers of Sub VIs (I think I've traced one hierarchy down through about 30 levels).  It's written with LabVIEW 6.1 and when I started (about 4 months ago) I'd never even heard of LabVIEW!  To my credit, at least there are no hidden wires...! 

P.S.  I'm almost certain there'll be some Rube Goldberg Code in there somewhere!

Message Edited by James Mamakos on 04-29-2009 05:08 AM

[Ben]

---

James Mamakos wrote:

---

Ravens Fan wrote:

Sometimes it may be better if the code does take up more than one screen!

---

...and here's one I made earlier!  I'm still working on this, and most of the code is hidden in several layers of Sub VIs (I think I've traced one hierarchy down through about 30 levels).  It's written with LabVIEW 6.1 and when I started (about 4 months ago) I'd never even heard of LabVIEW!  To my credit, at least there are no hidden wires...! 

P.S.  I'm almost certain there'll be some Rube Goldberg Code in there somewhere!

Message Edited by James Mamakos on 04-29-2009 05:08 AM

---

Thanks for playing along James!

That case structure in the bottom left corner is hiding wires. 

Ben

BTW:

To imbed an image in your post you first attach it as you have done and post the message.

Get teh URL of your image by either right-click and selecting properties or open the link in a new window and copy the URL.

Edit your post (options top right of your post).

Place your cursor where the image should be and hit the insert image button (looks like a tree).

Paste in the URL in the top box...

Post the edited version.

Yes our editor is cumbersome but that what we have to work with.

Message Edited by Ben on 04-29-2009 07:33 AM

[J.Mamakos]

Bottom right, actually, but yes - I realised that shortly after i posted.  The shame!  Only five wires though.  Not that bad considering most of the diagram is wires!

If I were to post a library on here d'ya think someone could have a 'quick' look at it to check it out for any dreaded Rube Goldberg slip ups?  I've only been using LabVIEW for a few months now, and I'd lean quite a bit more from having my mistakes pointed out.  

*WARNING*

 The above mentioned library is written on LabVIEW 6.1 and includes VIs converted up from lv5.

 I attach a visual of the library's hierarchy to assure you that it won't be too great a task.  I have removed the VIs that don't work yet, but some that do still need work - as always!

Message Edited by James Mamakos on 04-29-2009 10:01 AM

[altenbach]

---

James Mamakos wrote:

P.S.  I'm almost certain there'll be some Rube Goldberg Code in there somewhere!

---

Thanks for sharing! True Rube Goldberg code is correct and functions flawlessly but in an overly complicated way. This thread contains many examples where the code is potentially flawed and your pictured code may fit this label.

A couple of things I noticed:

• There is at least one uninitialized shift register that (seemingly) grows an array of a cluster without bounds. It is actually difficult to tell, because the initialization wire could be buried underneath the FOR loop. Please check.
• Blindly writing the same properties (many properties!) over an over with every iteration of the loop is relatively expensive and disruptive. Properties should only get written when the property actually changes.
• All value properties should be replaced by locals. For example, in the center we read from a local, process it, and write back to a value property of the same. e.g. [C(v), M(mV/dB)]. Of course ideally you would keep them in a shift register or action engine.
• There are potential race conditions, for example some of the controls at the bottom left are also modified by code above it, meaning that code fragments that depend on both data paths (e.g. the small case structure in the lower right) could get hybrid data, some based on the old and some based on the new values. Of course there is no real way to check all this without seeing actual code and spending hours debugging.
• There is a reference kept in a shift register (top SR in outer loop) that goes through a case where some cases drop the reference (use default if unwired). This means that the reference can potentially become invalid. (this can lead to errors and even buildup, because dropped reference cannot be closed)
• ...