Unofficial Forum Rules and Guidelines

[Hooovahh]

I realize there is an official Community Guidelines thread, but I feel it should cover more topics than it does.  So here is my attempt to have a thread I can point new users to, if they are unsure how forum etiquette works.

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.  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.
• 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.
• 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.

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.  Here are the preferred methods.

• Kudos
• You can thanks 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 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.

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.  Make a new thread asking your new question.

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.

NI Learning Center

NI Getting Started

-Hardware Basics

-LabVEW Basics

-DAQ Application Tutorials

3 Hour LabVIEW Introduction

6 Hour LabVIEW Introduction
Self Paced training for students
Self Paced training beginner to advanced, SSP Required
LabVIEW Wiki on Training

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.

[altenbach]

Of course if you made a mistake giving kudos or marking a solution, you can easily change that back.

[crossrulz]

---

@Hooovahh wrote:

• 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.

---

Include code whenever available.  Asking somebody to troubleshoot your VI without any code is like asking your mechanic to fix your car without taking your car to him.

[Hooovahh]

Okay thought of another one and apparently I waited too long and can't edit my original post.

If you find the solution to your question on your own, posting "I figured it out never mind" does no one else any good.  Please explain how you fixed your issue, or how you discovered the answer to your question.

[altenbach]

When attaching code:

• Include all subVIs, typedefs, and global variables, etc.
• Remove all passwords from password protected VIs.
• 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 it is an entire project, zip everything up. (A "*.lvproj" file does NOT contain anything useful. All code referenced in the project needs to be included).
• If you attach more than one VI, tell us the name of the toplevel VI.
• Set all controls to typical values, then make them default before saving. Do not set indicators to new default values, especially e.g. graphs containing huge amounst of data.
• Ideally, all we should need to do is open and run the VI to see the problem.
• 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 guranteed to always be the case.
• Tell us how to demonstrate the bug (e.g. Run A, set control B to X, Indicator C is now Y while I expect it to be be Z instead, etc.). Include these instruction as diagram comment on the toplevel VI.
• If the problems is with reading a file, include a sample file that demonstrates the problem.
• If you run the newest LabVIEW version, you might want to downconvert to a lower version before attaching (file...save for previous...). This way there are more people that can potentially help. (Of course if the suspected bug depends on the version, you should attach the version that demonstrates the bug.)
• ...

If you make claims about speed or benchmarking:

• Tell us what you consider fast or slow. "Seconds" could be fast for one problem while "microseconds" could be considered slow for another.
• Include your benchmarking code.
• Make sure the speed test is sound and not polluted by debugging settings. Keep the front panels of subVIs closed, watch for code running in parallel, and avoid front panel updates.
• Make a distinction between slow code and slugginsh FP responsiveness.

[altenbach]

---

@Hooovahh wrote:

Okay thought of another one and apparently I waited too long and can't edit my original post.

---

I recommend to start a document over in the community. You can update it forever.

[Hooovahh]

---

@altenbach wrote:

I recommend to start a document over in the community. You can update it forever.

---

Great idea.  I guess I started a thread because I'm used to other forums where they will have like a forum rules thread that is pinned and updated periodically.

Still I'm enjoying the feedback, and will make a document on the community side later.  I want to give others a chance to chime in.

[crossrulz]

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.

[Hornless.Rhino]

---

@crossrulz wrote:

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.

---

I so wish I could mark that post as a solution right now 😛

[tst]

---

Hooovahh wrote:

• 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.

---

Be very 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. This is crucial because different people think in different ways and something that you think is obvious might not be obvious. Sometimes, just the process of explaining the situation properly could be enough to help you understand it and point you towards the actual problem.