Introduction to Section 1
As every add on or application will be different from a code perspective, this section will give some guidance and pointers on meeting the LVTN requirements. This section will be deliberately generic and very much open to discussion, depending on your viewpoint.
The main aim of this part of the guide is to help you to successfully meet the requirements first time, this saves a lot of rework and should be easily achievable.
If you have not done so already, we recommend reading the Introduction and the background to this guide.
The Requirements
The full LVTN requirements can be found here and are officially called the LabVIEW Tools Network Software Requirements. It is quite a comprehensive list, but it comes with links and guides for the less obvious items.
It is very important to note that there are different requirements for developing an Add-on than those for an Application. By this point in your project it should be clear which you are developing so only concentrate on the relevant section.
It is strongly recommended that you read and understand all the requirements before you start the coding. This can save you a lot of time towards the end of the project, and makes some of the more tedious aspects — such as documentation — easier to handle.
Some of the requirements are covered by default if you meet another requirement. For example if you use the TPLAT to license your product then the requirement “Users are reminded of the remaining trial time or uses” will be taken care of by TPLAT and LabVIEW. This is another example of why the requirements should be read and understood before starting, as what seems like a long list can be made shorter with this kind of knowledge. It is always better to have a short “ToDo” list when building your business case.
Notice that there is no mention of any requirements of the code itself, nothing to do with architecture, coding practices or block diagrams. This is for a very simple reason, the actual code (i.e. the block diagram) is not checked. The block diagram does not even have to be accessible by the LVTN team to be approved.
First Time Right
One of the best ways to meet the requirements first time is to follow the various guidelines published by NI that all developers should follow as their standard way of working.
General LabVIEW:
Specifically for the LVTN:
By following these you will meet many of the requirements, leaving just the more specific items such as licensing to deal with. These will be covered in later section of this guide.
Clear as Mud
Ok, so maybe not all the requirements are crystal clear on first reading. “There are no memory or processor resource issues when using the product”, what exactly is an “issue”? Surely this depends also on the machine it is running on and also the task being carried out? If simple text manipulation is railing the processor at 100% then maybe this is an issue, but the same cannot be said for advanced image processing.
Some are also a little ambiguous, such as “Detailed help outlines all hardware, software, and operating system requirements”. So mouse, keyboard, monitor etc…? Granted this example is a little bit extreme, but it is included to show that the requirements should also be taken in context and not always literally.
The point here is that these are requirements and are open to interpretation by both the programmer and the LVTN team. If you are in doubt about any of them then ask, there are several ways of contacting the LVTN team:
- Basecamp
- LVTN Community pages
The response to all these methods is usually quick and concise. If you have a difference of opinion about how one of the requirements applies to your product then explain this and an agreement can often be reached.
What is not Checked
Equally important as knowing what will be checked, is knowing what will not be checked during the approval process.
The main purpose of the approval process it to ensure that the user of your product has an experience that meets the standards of NI. This includes installation, activation, finding examples, help files and uninstallation.
So, what is not checked? Well most importantly the actual functionality of the add-on or executable is not tested. Just because it has passed the Tools Network review process it does not in any way guarantee that it will do anything you claim it will.
As already mentioned, the block diagrams are also not checked. This means that as long as the connector pane meets the requirements, everything else is down to your own preference and style. Note that this should not be used as an excuse for creating so called “Spaghetti code” on your block diagrams, you are still unofficially representing the LabVIEW community with your work.
Architecture. This is a topic that sparks debate in almost every LabVIEW based environment; the discussion forums, community pages, CLA Summits and so on. Everywhere in fact except the LVTN. How you choose to code your product is entirely up to you as the product owner and designer. You can use anything from sequence structures to actor framework and everything in-between, as long as it meets the requirements.
If you are developing an application then by all means use what ever architecture solves the problem in the best way, or whichever you are most comfortable with as a developer. If however you are designing an Add-On then you need to keep in mind your target audience and their LabVIEW proficiency. There is no point developing something that makes maximum use of the Actor Framework, if the people you want to sell too are only casual LabVIEW users who are self taught and can just about handle the data flow concept.
Summary
- Read the LVTN Software Requirements thoroughly, including any linked documents
- Keep in mind your target customers requirement with regards to complexity
- Document your code, VI Properties etc. as you go along
- Make sure you comply with the general style guidelines listed above
- If in doubt, ask! Clarifying an issue early can help prevent extensive rework later