Community Documents

Showing results for 
Search instead for 
Did you mean: 

Unofficial Forum Rules and Guidelines

There is an official Community Guidelines thread, and a Quick Introduction for New Users, and more recently an official Users Guideline put out by NI, but I feel it isn't as complete as it should be.  So here is the list of unofficial forum rules.  These are community sourced guidelines and new users can be pointed here, if they are unsure how forum etiquette works.  These guidelines are focused on the LabVIEW forums, but most of the suggestions apply to all NI forums.


Before Posting a Question

Many posts have been made on the forums over the years and many topics have been covered.  You are likely not the first person to attempt something, or having difficulty.  Search the forums first for the question you would like to ask.  NI's forum search works well but feel free to use Google to search the forums.  Try searching with alternate terms, like "System Tray" instead of "Icon Tray".


Posting a Question

When posting a question you should first follow the guidelines linked earlier.  Ben on the forums has a good quote which is "The first step in solving a problem is clearly defining what the problem is."  In addition to those points I'd like to mention a few more:

  • Not everyone on the forums speaks English.  If English is not your native language feel free to post questions in your first language, but be aware that there are several non-English speaking sub-forums.  If you post a non-English question in the English forum, you may or may not get people who speak your language. Stick to forum for that language to ensure you get the help you need.
  • Post in the right sub-forum. Language is the first sub-forum to consider, but topic is another. If you are asking a question about LabVIEW exams, it is better to post in the Certification board, rather than the LabVIEW board. If you posted in the wrong forum ask a moderator to move it to the appropriate section.
    Have a useful title. The title of your question should never be "labview" for "fpga". Your title should also not be a paragraph. It should be a quick summary of the topics your post is going to discuss.
  • Do not use caps lock unless you are really yelling. It would be rude for me to ask a question by yelling and the same goes for the forums. This goes for the title and the post.
  • Do not beg for help using words like URGENT, or LIFE AND DEATH. This is again rude, we are largely volunteers that like to help, but not when we are being yelled at.
  • Use words not letters "NEED hlp Plz R U labview xpert?" Use full English sentences. If you have trouble with this please refer back to speaking in your native language, or go back and take English class.
  • There is rarely a need to change the font size, color or style from the default settings. You are wasting your time, and likely making your post harder to read. Stick with the default font styles.
  • Be clear about what you're actually asking. Don't just say things like "it doesn't work". Explain what you're trying to do, what you expect to see and what you actually see. Sometimes, just the process of explaining the situation properly could be enough to help you understand it and point you towards the actual problem.
  • If you are seeing errors, state what the error are and where they are coming from.
  • Try giving as much information about the conditions of your question. Things like: What version of LabVIEW are you using? What operating system are you using? What hardware are you using? and What sensors are you using? are a few common ones.
  • If you want to ask the same question on another LabVIEW board like LAVA, feel free to do so. One thing that helps collaborate efforts is to provide a link in your post back to the other place where the question was asked. This way someone on the NI forums can see what has already been said on another forum. This is known as a crosspost.
    Include code whenever available. Asking somebody to troubleshoot your software without any code is like asking your mechanic to fix your car without taking your car to him.  

When Posting Code


  • When posting code post the actual code not a screenshot. You wouldn't take a screenshot of a text file and post it on a text language forum. Upload the actual VI, or zip several files and upload the zip. The exception to this rule is when uploading a VI Snippet. This is an image with the VI embedded in it, so the source is still intact.
  • Include all subVIs, typedefs, global variables, project files, and any other files you made to run the VI. Do not just post the project file, this has no source, and will be of no use without the rest of the files.
  • Do not post code that is password protected.
  • Do not include anything from vi.lib or that is part of a standard LabVIEW installation.
  • Do not include libraries from commercial third party drivers unless you suspect them to be the cause of the problem.
  • If you attach more than one VI, mention which VI is the top level.
  • Set all controls to typical values, then make them default before saving. Do not set indicators to new default values, especially graphs containing large amounts of data.
  • The default data should be typical and not biased in any way. If an input is a matrix, don't make it square or symmetric unless that is guaranteed to always be the case.
  • Explain the steps to reproduce the issue.
  • If the problem is with reading a file, include a sample file that demonstrates the problem.
  • If you run the newest LabVIEW version, you might want to down convert to a lower version before attaching. This way there are more people that can potentially help. This is only recommended if you suspect that the issue isn't version specific.
  • Do not set your VI to "Run when Opened" unless that is necessary to demonstrate the problem. WARN us in your post if this attachment will run when opened.
  • Warn us first in your post if the code will not exit normally when run. Users may have their own projects open and be working on it. When your VI crashes LabVIEW a warning will help remind us to save our code before helping you with your problem.
  • To summarize, when posting code, ensure all that is needed to reproduce the problem is run the VI.


When you don't get the help you want

If you posted a question and didn't get any response, or didn't understand the responses you got, do not make a new thread on the same topic.  Doing this will fragment the conversation and you will have two groups of people working on the same problem.


Don't simply BUMP a thread with a new post without more information.  This is a sign that you don't want to put in any effort and are simply nagging others to help you.  If a thread goes dry and you want more help, try getting more information on the subject, or try something and reply to the thread with this new information.  This shows you are willing to work towards your goal, and aren't just looking for others to do your work for you.


When you get the help you want

Volunteers put in effort to help you and they want to know they are appreciated.  The forums have several ways to say "Thank You" to those that have helped.  More information can be found on NI's official Recognition and Ranks topic.  Here are the preferred methods.

  • Kudos
    • You can thank a person on the forum by giving them a Kudo.  A user on the forums can Kudo a post by another user once, but multiple users can Kudo the same post which can highlight posts that a collection of users find useful.
    • Here is a thread discussion about when users choose to give Kudos. 



  • Marking Solutions
    • Any reply to a post can be marked as a solution to the post, if the sub-forum supports marking solutions. This is helpful because the thread will get a green check mark showing a solution to the question has been found.
    • Threads can have multiple posts marked as a solution, but it is best to limit the number of posts that are the solution. Mark the posts that answer the question, not just helpful posts. A helpful post can be Kudo'd, but doesn't need to be marked as a solution.
    • If you change your mind, solutions can be unmarked.
    • Here is a thread discussion about when users choose to mark solutions to questions.
    • If you figured out the solution on your own, don't post back saying "never mind I figured it out". Other might have a similar problem, and would like to know what you did to solve the issue. If you found the solution to your own question, not posting it is selfish.
    • Do not mark a post as a solution to your thread until you actually have your problem solved. Many people will skip over "solved" threads. If your problem was not solved, then these people will not be helping.

Things Not To Do

  • Do not send private messages to a user asking a question. Forums exist so we can work to solve a problem as a group. Contacting someone privately causes that to not work.
  • Do not post personal information. This includes Email, or phone contact information. Spam bots crawl forums like this looking for your information. This also means don't make your user name an email address.
  • Do not have huge signatures. They waste space on the forum and can clutter the conversation. Signatures are okay, but large ones are discouraged.
  • Do not post homework assignments. We are not going to do your homework for you. You are welcome to ask specific questions about things you don't understand. But don't post your homework and expect someone to do it for you. You won't learn this way.
  • Do not resurrect old threads that have nothing to do with the new question. A post from 2002 about how to setup a DAQ task will likely not be related to your question about reading a serial port. That old of a post will probably not be very useful to someone trying to setup DAQ in modern versions of LabVIEW either. Make a new thread asking your new question.
  • If you edit your post, don't remove information. Some users choose to edit their posts after they get the answer they were looking for. And they will completely remove their original question and replace it with nothing or "Thanks". This creates a thread where the first post just says "Thanks" and then there are several replies answering a question that is no longer there. The community exists to help others with the same question find help, editing your question or posts this way helps no one.
  • Don’t be rude. We all have bad days, let’s try to not take it out on others.


Looking For Free Training

Many times new users of NI hardware or software just don't know where to start.  They will ask a question but without knowing the terms, or the intended purpose, they will not be able to form a proper question.  Here are some free training tools primarily focused on LabVIEW and NI hardware to help get started.


Getting Started on LabVIEW Wiki

NI Learning Center

NI Getting Started

-Hardware Basics

-MyRIO Project Essentials Guide (lots of good simple circuits with links to youtube demonstrations)

-LabVEW Basics

-DAQ Application Tutorials

-cRIO Developer's Guide


Learn NI Training Resource Videos

3 Hour LabVIEW Introduction (Alternate Google Drive)

6 Hour LabVIEW Introduction (Google Drive)
Self Paced training for students
Self Paced training beginner to advanced, SSP Required


The best way to learn, is to follow the tutorials, then ask lots of questions. 


More general forum etiquette tips can be found here.  Not all of these are relevant to the NI forums but there is very good advice in there.  There is also the How To Ask Questions The Smart Way.


Beyond the Training

People take training for various reasons, but one of them is be proficient enough to get recognition for their experience.  This can come in many forms, but the easiest to put on a resume is a certification.  LabVIEW has three basic levels of certification, the first is the CLAD, the second is CLD and the last is the CLA.  Each of these have their own specific challenges but useful user experiences for each of these are discussed in these Certification Nugget threads.


Certification Nugget: CLAD - Certified LabVIEW Associate Developer

Certification Nugget: CLD - Certified LabVIEW Developer

Certification Nugget: CLA - Certified LabVIEW Architect


The original discussion for this document started here.  Feel free to add comments below of suggestions.  This document should be updated periodically.


This information is so useful for the new members like me. I was wondering what Kudos were, didn't know what to do and very much want to thank the contributors who helped me.

Knight of NI
Knight of NI

Broken link 

@ "see and what you actually see. Sometimes, just the process of explaining the situation properly could be enough to help you understand it and point you"


Not sure where the source was.  

"Should be" isn't "Is" -Jay