LabVIEW
What is the best way to keep the block diagram/ front panel clean?
Solved!
It usually is mainly experience that will teach you the best methods to make your code look pretty. I don't know anyone who is proud of their first from-scratch application. There are a few resources out there to help with best practices, like this group on ni.com, but you'll learn the most from your own development.
Your front panel looks great. FPs in general are really up to you. You can make it look as ugly or pretty as you want. When you have some duplicate controls and indicator groups, you should utilize clusters and arrays to simplify. You could use a little bit of cleanup in that regard, but not much. Also, personally, I hate reading red text unless it's a warning of some sort.
Your block diagram could use some cleanup in a modularity sense. You have a lot of repeated code, which you could consolidate in to a subVI that is used in multiple locations, or in a For loop. A general rule of thumb is to keep your block diagram within a single monitor. You shouldn't have to scroll. Your application is pretty simple, so it's hard to mess it up 
Here are some specifics about your block diagram:
- Right click your terminals on the block diagram and uncheck "View As Icon". You're welcome.
- Duplicate operations on each waveform "(x*2-4)/16": create subVI and/or run the waveforms through a For loop.
- You do a lot of 2-element arrays and then indexing. Just replace those with a Select node based on the numeric.
- All of your code is running every time, including your property nodes at the bottom, which is unnecessary. As you learn LabVIEW architectures, you will learn how to bypass this with initialization and exiting code, but for now you should put a case structure around those for only when the motor numbers change.
- I'm not sure how you're timing your main loop, but you should put a delay in there because you don't need the DAQmx node to be pulling as fast as your CPU will allow.
There are free intro videos you can watch to learn what NI would suggest in terms of coding and teach you some of the basic features and such. Here's a three hour course, and here's a six hour course.
@James.M wrote:
Hehe, yeah, sorry. I went back and edited the post to add the specifics. That's the only thing I don't like about this forum, there's always new info or someone else posts while I'm typing up a response.
The easiest way to create a subVI is by selecting the code you want, right-clicking, and selecting Create SubVI. SubVIs are another file that you have to save with your code, so make sure you keep it all together.
Really, you should watch some training videos to get a better grasp of LabVIEW's functionality.
This is the easiest, but (at least from a block diagram cleanliness perspective) not usually the best way to create a subVI. This creates an ugly gap in your block diagram and you have to shift stuff around to fill up the hole. The best way is to have in mind the subVIs to begin with. (Think about each paragraph of a requirement to be a subVI, for instance.) Create them and drop them onto your block diagram. I think it was Altenbach that gave me the idea to use a one-frame flat sequence structure to attach all the input and output wires of your "proposed" subVI, select the flat sequence structure and create the subVI from that. (Don't forget to eliminate the flat sequence structure from your SubVI!) That way the hole will only be as big as the flat sequence structure. Create your code inside the newly created subVI.
It's easier to start and maintain a clean block diagram than it is to let it get messy and then try to clean it up all at once.
It's easier to start and maintain a clean block diagram than it is to let it get messy and then try to clean it up all at once.
Perhaps, but cleaning it all can be therapeutic, kind of like cleaning the kitchen or your room. Maybe that's just me
