So, I know you are looking for a quick way to get started in LabVIEW. It isn't going to be that easy... you are operating under the assumption that because both LabVIEW and LabWindows are produced by NI that they will be similar. This is not the case! They are completely independent languages with different design patterns / paradigms. The only direct 1:1 correlation you might find is the use of daqmx drivers talking to hardware.
That having been said, don't despair! In terms of learning, I think LabVIEW is one of the easiest languages to pick up. There is no syntax to worry about, and the help files / documentation available is thorough and often has examples.
GerdW already pointed you in the right direction for getting started. In addition to his reading, I would like to emphasize a couple of points that hopefully will help your transition be easier. These might seem counter-intuitive initially, but will help you build better code faster.
- Wires are your variables. I can't stress this enough. Your first inclination is going to be to declare your variables and types. Initialize them. And then use local variables everywhere. While this isn't necessarily "wrong", it leads to code that is very hard to follow, debug, and support.
- LabVIEW is a dataflow language. GerdW mentioned this and linked a couple of whitepapers. For me this was one of the hardest concepts to pick up when I first started developing in LabVIEW. What does this mean practically when comparing LabVIEW to CVI? In LabVIEW, every bit of code that can execute will. Code will execute once all of the data required to do so has arrived. This makes race conditions much easier to create, and ties back to point 1. Over use of local variables causes race conditions. Using wires as variables prevents race conditions.
- Avoid sequence structures. Coming from CVI you will want to enforce execution order, and you will want your program to look nice, consistent and linear. This can just as easily be done with wires (back to point 1, 2!) and doing so will make your code much, much easier to read.
- Use sub-vis regularly. Even though each sub-vi is a separate file, think of them in terms of functions rather than files. Each sub-vi is a written function that can be called elsewhere in your code. Starting in LabVIEW it is easy to want to just create one block diagram with all of your code. This makes the block diagram fairly large and difficult to follow. Doing this is the LabVIEW world is the same as:
void main()
{
entire program goes here
}
in the CVI world. Not a good idea in CVI, and not a good idea in LabVIEW!
- Learn the event structure. Again, one of your first inclinations will be to have a "polling" type application in LabVIEW. Developing responsive GUIs with easy to follow and maintain code is much easier with the use of the event structure and perhaps a couple of standard design templates. I'd also recommend reading this document completely and making sure you understand it before diving too deep into events.
- Learn the producer consumer design pattern and the state machine. These two design patterns should cover the vast majority of your early LabVIEW applications. While there are other more advanced designs available, I would suggest sticking to these two until you are comfortable working with them.
Good luck! And don't hesitate to post any questions you have here as you are learning. If you post code and request it, there are several people who will gladly go over it, make suggestions on improving it, and comment on what you have done correctly.
