This LabVIEW programmer needs to know

Hello guys...

I'm working on labVIEW for 1 year last on mine.

If I have problems I will post my questions in the Forum of NOR.

But I don't know that a small drop of sea water...

So what should a labview programmer should know?

In short, how avoid the 10 screen wide spaghetti complete code of the structures of the sequence, local variables and the race conditions

Also I advice take you a look at the certificates of NOR and the "learning curve":

http://www.NI.com/white-paper/13120/en/

http://www.NI.com/training/certification/

http://forums.NI.com/T5/certification/BD-p/certification

Edit: perhaps, I would just add a few points that I usually have to keep in mind during the phase of a new project of planning:

  • Choose the right framework or model based on requirements
  • Keep in mind how to get and set values - indicators and controls. If possible, use the cable to transmit data. Keep in mind what's OK to do with local variables (for example updating a control), and which should be avoided (usually) (read/write indicators for example). If you cannot use the wire to go directly to information (parallel loops), learn the correct use of notifiers, queues, UserEvents, etc...
  • who will use the code (it is very important, you need a totally different approach if you develop for yourself, or others who are not programmers and perhaps even do not know the physical part of the system...)
  • GUI always be responsible. Avoid bad habits (longer time running things in the GUI event loop).
  • Avoid the overcrowded façade: use pop-up windows for the settings, etc. That the user don't need to see always.
  • Error handling! It is very important to make a robust error handling strategy: for example if one of your HW components creates an error, your application cannot just stop everything. Handle the error, close properly all HW and file references (do not forget if you don't properly close a file, you can lose a LOT of data : file write is buffered memory RAM). Also record the error information to a log file.
  • If you need to make an EXE or installer: use a configuration file to store the user's changes: If the user changed the colors (width, etc.) a chart/graph, store this information in a configuration file that you load at the next startup of the application.
  • Automatic detection equipment (or users the possibility to modify the port/channel): what happens if your application moves to another PC (numbering changes COM port, etc...)? Your application needs to adapt to the changes of HW.

Tags: NI Software

Similar Questions

Maybe you are looking for