Sie sind auf Seite 1von 44

Codding Guidelines

Mahendra Dhadwe

Agenda
OVERVIEW
FRONT PANEL
BLOCK DIAGRAM
ICON AND CONNECTOR PANE
MEMORY OPTIMIZATION
ARCHITECTURE
ERROR HANDLING
DOCUMENTATION

OVERVIEW

SOME COMMON LABVIEW


DEVELOPMENT
MISTAKES
No source code control(or project)
Stop isnt tested regularly
Wait until the end of a project to build an
application
Few specification/ documentations / requirements
No buddying or code reviews
Poor planning(Lack of consideration for SMoRES)
No test plans
Poor error handling

SOFTWARE ENGINEERING
PROCESS

DESIGN FOR SMoRES


Scalable: How simple is N+1
Modular: is the application broken up into welldefined components that stand on their own?
Reusable: is the code de-coupled from the current
application well enough such that it could be
reused in a future project
Extensible: how painful is to add new functionality
Simple: What is the simplest solution that satisfies
all of the listed criteria and requirement of the

FRONT PANEL

FRONT PANEL STYLE


Give meaningful names to
control and indicators
Use dialog font throughout all
the front panels
Set default values on the
controls and indicators in all
front panels
Create tips strips for front
panel items so users have an
easy way to understand the
functionality of controls on user
interface VIs

FRONT PANEL STYLE


Arrange control intuitively, using the
align Object and the Distribute
Object pull-down menus
Arrange control logically
Group related controls together
Consider decorations, tabs, clusters

FRONT PANEL STYLE


Use custom control for common controls, especially
for rings, cluster and enums
Make sure that all controls on the front panel are to
the same type

FRONT PANEL STYLE


Maximize contrast between text color and
background
For control indicate units in parenthesis or use free
labels
All front panels should have the following
Red: 212
Green 208
Blue: 200
Hue:27
Sat:29
Lum:194

FRONT PANEL STYLE


Apply symmetry and spacing and size controls,
indicators, and fonts according to importance
Use tab control or subVI to increase front-panel
estate
Apply color judiciously

SUBVI
PANEL
LAYOUT
Use default appearance for most object and text
Avoid using many colors, fonts

Use intuitive control positions


Controls at left, indicator at right
Refnum /test IDs at top
Error cluster at bottom

Size panel adequately, but less than full screen


Keep things neat, intuitive and symmetric

BLOCK DIAGRAM

BLOCK DIAGRAM STYLE


Leave the background color white
Set all control labels visible
Avoid creating extremely large block diagram
Limit the scrolling necessary to see the entire block
diagram to one direction
Make good use of reusable, testable, subVIs
Use error in and error out cluster in all subVIs
Make sure the program can deal with error
conditions and invalid values
Use a type definition when you use the same
unique control in more than one location or when
you have a very large structure passing between
several subVIs

BLOCK DIAGRAM STYLE


If you open reference to a LabVIEW object such as
an application, control, or VI, close the reference by
using the close LV object Reference function.
Otherwise, the reference stays in memory even
though the VI no longer use it

BLOCK DIAGRAM STYLE


Create, edit and view VI description by selecting
file>> VI Properties and selecting Documentation
from the category pull-down menu
The VI description is often the only source of
information about a VI available to the user.
The VI description appear in context help window
when you move the cursor over the VI icon and in
any VI documentation you generate.

BLOCK DIAGRAM STYLE


Left-to-right data flow
Straight wires
Align object prior to wiring together
Free labels to long wire
Consistent data types
Do not wire behind objects
Avoid placing block diagram objects such as subVI
or structure, on top of wires
Label long wire with small free labels with white
background

BLOCK DIAGRAM STYLE


Document your Block Diagram by writing
comments on the block diagram. The preferred
method of writing comments on the block diagram
is show in the figure below

ICON AND
CONNECTOR PANE

ICON AND CONNECTOR


PANE
Icon
Intuitive text or graphics
10-point small fonts
Color-coding for icons of related subVIs

Connector Pane
Control assign to left terminal , indicators assign to right
Refnum/task ID assigned to top left and right terminals
Error cluster assigned to bottom left and right terminals
Default value in parenthesis in owned label
Priority used where appropriate

VI description are required for ALL subVI's

ICON AND CONNECTOR


PANE
Create meaningful icon
Developer have better understanding
Follow standards
Choose only connector with 8 to 16 terminal
Use cluster to transfer more data
User error in error out cluster ever if does no
process error

Memory and
Optimization

Memory and Optimization


Add wait function in while loop if speed not
necessary
To avoid slow down other task
LabVIEW runs loop as quickly as possible
Take too much processor resources
Use Wait Until Next ms Multiple function

Memory and Optimization


Dont build array using the
Build Array function within
loop
Makes repetitive calls to
memory manager

Use auto-indexing and


replace array
Similar issue with
strings(array of character)

Memory and Optimization


Carefully use global and local variable
Encounter race condition and difficult to debug
Due to no data dependency
Instead use functional global variable(FGV)
FGV do not create extra copies of data

Memory and Optimization


Choose proper array data type
Example
Extended-precision floating point array of 1,00,000 store
only single precision point then inefficient use of memory

Memory and Optimization


Avoid coercion dots
Used unnecessary memory and speed
Converted the value in different representation and
made copy of data

Memory and Optimization


Dont update indicator frequently unless data is
different from what the indicator already display
Frequently updating affect the performance of VI
Display necessary information on front panel
Save cluster as type definition or strict type
definition
Avoid nesting of cluster and arrays beyond two
levels
Always use bundle and unbundle by name using

ARCHITECTURE

ARCHITECTURE
Modularize with subVIs but dont over modularize
Use state machine for top level VIs as it is easy to
documents, modify, debug and maintain
Use enumerated or string for case selector
Poll user interface events in No Events, Default
frame or in parallel event structure loop
Consider using event driven state machine if
applicable
Consider use queue for passing data between
parallel loops
Maintain separate text file for embedded
applications to facilitate change in program
parameters like timing, IP address or default state
of channels if applicable and train appropriate to
use them if need arise

State Machine Guidelines


Use enumerated or string for case selector
Poll user interface events in No Event, Default
frame or in separate event structure in parallel
loop
Use intuitive state machine
Include Initialize and Shutdown states

Clusters

Group related data into


clusters
Consider saving as strict
type definition
Avoid nesting clusters
and arrays beyond two
levels
Always use bundle and
unbundle by name

ERROR HANDLING

Error Handling
All Vis must trap and report any I/O-related errors
that might occur
Trapping is facilitated by propagation of error cluster
I/O functions include DAQ, file I/O, instrument I/O,
communication
Reporting methods include dialog prompt or log to file

All VIS error cluster should be connected and must


not be left unconnected, this it to enable
propagation or error that might occur
Also error occurred must be either displayed to the
user in dialog prompt or the error must be logged
with error information(error code)
Maintain custom error coding for user interface and
non-LabVIEW related errors

Error Handling

DOCUMENTATION

DOCUMENTATION
Use LabVIEW custom printing option to create a
function reference manual an maintain this
documents along with project folder for future
reference and upgrades
Include specification and/ or basic operating
instruction to complete documentation

PROJECTS
SVN(Subversion) Repository is used
as backup tool for the projects
A SVN repository should be created
before starting any work on a project
A project from SVN Repository has
the following directory structure

NAMING AND SAVING VIS


Give VIs meaningful names without special
characters, such as backslash(\), slash(/), colon(:),
and tilde(~).
Capitalize first letters of VI names
For Main VIs naming should be Module
Name_Project Name(in short form).
For Ex: Door durability Test System project Acquisition
module naming convention should be
Acquisition_Main_DDTS

For sub VIs naming should be Functionality of the


VI _Module Name_Project Name

For Ex.: Assume there is on VI, which generate tree structure


in configuration Module, the name should be Generate
Tree_Configuration_DDTS

Thank You

Das könnte Ihnen auch gefallen