[Greg McKaskle]

So far, I think this thread has yielded a lot of good advice.

In the vein of leaning a tool better, let me comment on the nested if/else code. As you probably noticed, LV doesn't even have an if/else structure. Arguably, it would be easier to learn if it did. But those structures, in any language, lead to a large number of logic errors. So LV doesn't have one, ... skipped it, ... not dope.

Instead, the LV case structure can switch on a number, enum, string, or Boolean type. This allows, and hopefully encourages, you to combine inputs into a single selector taking you to a single diagram of code. In fact, if you follow this to its logical conclusion, you generally wind up making a state machine. State machines are not the beginner's goto tool, but they are taught in the LV basics class. At least I think they are. And for an assembly line control program, or any other mechanism with rigorous state definition, I'd encourage you to start with a state diagram, documenting and naming the states and transitions, and then coding with a state machine.

Similarly, many robot mechanisms would benefit from a state diagram and machine. I have written them many languages, and they are a great technique to learn and will make you a better programmer and engineer.

So, while not hard and fast rules:
Nested case structures are not the answer. The right number of frames for a film strip is one. Variables, you don't need no stinking variables. And custom VIs are the basic building block of all things -- they will provide you with what you need.

But seriously, if you find something hard to do in LV, please ask. Ditto for other languages. FRC should not be just a robot hackathon. Learning to program is way different and way better than learning a language.

Greg McKaskle