Rube Goldberg Code

[altenbach]

So we acquire dynamic data but ultimately are only interested in a single scalar. I pointed this out, so the OP "fixed" it as follows (seen here😞

[altenbach]

Here's a small section of non-scalable code (see the navigation windows for the full size, seen here)

... and yes, it can be simplified and made more scalable with code that would fit half of a postcard. (took me just a few minutes once I got to my desktop with a bigger screen).

[VinnyLaTaupe]

If someone sees the point of doing this, please explain me...

False case is empty; Sending false in the subvi just send an empty path to a file.

[altenbach]

---

@VinnyLaTaupe wrote:

If someone sees the point of doing this, please explain me...

False case is empty; Sending false in the subvi just send an empty path to a file.

---

Certainly a bit convoluted, but we don't really have enough information to judge because you left out what the subVI does if it receives a TRUE. I don't even know what "sending a path to a file" really means.

The true case executes whenever the control changes and that's a valid scenario. So far we don't even know the mechanical action. 😉

[crossrulz]

---

@VinnyLaTaupe wrote:

If someone sees the point of doing this, please explain me...

False case is empty; Sending false in the subvi just send an empty path to a file.

---

The Feedback Node and the Not Equal are detecting if the value changed.  Seems valid to me.  I would need to know a lot more on what the rest of the code is doing before making any comments about the empty path to a file.

[VinnyLaTaupe]

Yep fair enough, sorry.

The mechanical action is Switch when Released, and a false action sends an empty string to a shared variable that is read and  "somewhere else" in the code.

The compilation of Monday+tiredness+this code is just making me grumpy ^^

Have to admit, I'm kinda off-topic here sorry.

[billko]

---

@altenbach wrote:

Here's a small section of non-scalable code (see the navigation windows for the full size, seen here)

... and yes, it can be simplified and made more scalable with code that would fit half of a postcard. (took me just a few minutes once I got to my desktop with a bigger screen).

---

At least it's neat...

[altenbach]

Meaningless array operations (seen here)

[altenbach]

To show progress using a variable length (max=9) row of LED apparently needs two case structures, 81 visible properties, 72 local variables, and 9 separate LEDs and terminals. Herding cats!

(Seen here)

All we really need is one array of LEDs, one property node, and a little bit of code. Right?

[wiebe@CARYA]

For your patient, an array seems spot on!

There are situations where an array (or cluster) isn't possible.

On plant P&IDs the controls and indicators can be scattered all around. As we can't have clusters with controls and indicators, a cluster of controls will block the cluster of indicators.

I'd do this, and all handling of controls and indicators, by reference and label. It's not ideal though.

I also tend to get customers that not only want to have Boolean values, but also want my code to enable\disable them. That also rules out arrays.