BreakPoint
Rube Goldberg Code
t06afre wrote:This weekend I picked up this golden nugget from the Labview forum.
Ouch! I somehow missed that. No wonder I stayed out of that thread. 😄
I would guess we have about 98.5% too much code.
- Near identical subVIs, just differing in a diagram constant and name.
- Wait loops that check the tick count every nanosecond, consuming all CPU in the process. (He knows the wait function, because it is used two frames later in the same flat sequence).
- "one iteration" while loops.
- "code only" VIs (e.g. "select picture.vi") that are set to "show front panel when called"
- Completely useless property nodes and methods (e.g. s+presentation.vi" is already set to open when called and close afterwards, so closing the FP in the last frame and then reading the setting without ever using the output of the node seems pointless.)
- Warping of pane origin and button positions..
- ....
I would guess a single small toplevel VI state machine some logic, and the four picture VIs are all that's really needed.
It does not really take any brains to disassembe this monstrosity, just a gigantic monitor, paper and pencil and a huge amount of free time, which I unfortunately don't have.
It would be much cheaper to get the detailed specs and code it from scratch. 😄 Shouldn't take more that 10 minutes.
The "referenceophils" way of programming:
- Place all terminals disconnected inside the first sequence frame.
- In the next sequence frame place static references.
- Do everyting (everything!!!) with value reference nodes connected to the reference wires.
Here's how we simulate latch action booleans, e.g. "quit" (but there are many more).
To retrieve an I16 from a 4 chars string received on a serial port, you can convert the string to an U8 array, chop off the last two elements, index explicitely the two remaining elements, convert each one to I16s, shift-left the first one and logical-or-e the result with the second.
Or you could typecast the string...
I love the cast function and i use it a lot. But has not your solution a smal flaw. 4 chars is 32 bytes or 2 I16. So the type input (in the type cast function) should have been connected to an array. Your solution will only convert the 2 first bytes to an I16. But this person needed the 2 last char converted to a number. 
Intaris wrote:Correct. You need to cast to a cluster of 2 i16, and select the second one. A bit more complicated, but still much easier than the original code.
Assuming we are not interested in the first two bytes at all and we know we only get four bytes in the string, we only need to convert the correct string subset as follows.
That's a "Delete from Array"? Would have never noticed that since I never really use it. I "saw" "Array Subset" too. 
OK, then the operation in the original code is totally pointless.
Shane.
