Grading Rubric

Grading Rubric

This document describes the criteria that are used to evaluate all LabVIEW programming projects in WKU PHYS 318.  These guidelines are loosely modeled upon the National Instruments Certified LabVIEW Developer (CLD) Exam Evaluation Criteria.

All programming assignments will be worth a total of 100 points broken down according to:

• Functionality [50%] – Does the VI perform as expected?
• Programming Style [30%] – Are acceptable style guidelines followed?
• Documentation [20%] – Is the program well documented?

Functionality [50%]

• All project VIs should compile properly when opened [no broken run arrows].
• The project should properly perform the requirements listed in the assignment specifications.
• The VI should respond to user inputs in a reasonable time limit (100 ms).
• No VIs or subVIs should use 100% of CPU time.
• File I/O should be implemented correctly.
• The application should handle errors gracefully.

Programming Style [30%]

• The application should be organized in a LabVIEW Project with all files pertaining to the project together in one appropriately titled folder.
• The top level VI should be easily identifiable the the project is opened.
• SubVIs should be grouped together according to function in appropriately labeled auto-populating folders within the project.
• Control type definitions should be grouped in appropriately labeled auto-populating folders within the project.
• The application should follow accepted LabVIEW development guidelines.
• VIs should be:
  • Readable.
  • Constructed for scalability.
  • Easily maintainable.
  • Not overly complex.
  • Hierarchical.
• VIs and subVIs should follow LabVIEW frameworks/design patterns.
• Use state machine architecture for top-level VIs when appropriate.
• Repeated code should be in SubVIs.
• Type-defined enumerated controls should be used to define program states.
• Avoid the use of unnecessary temporary variables.
• Use appropriate data types, ranges, and format/precision for front panel controls.
• Group data in appropriate data structures: arrays or clusters.
• Avoid the use of deeply nested structures.
• Minimize the use of sequence structures except for initialization or cleanup.
• Minimize the use local and global variables.
  • Local variables can be used to initialize controls.
  • Global variables must be protected to avoid race conditions.
• Front panels and block diagrams should be laid out in a structured and organized fashion.
• Avoid cramming block diagrams into small spaces.
• Avoid unnecessary bends in wires.
• Avoid overlapping objects or wires.
• Avoid having wires running under structures or structure borders.
• Always wire the error terminals on subVIs.
• Always close references appropriately.
• Optimize VIs for memory and performance.

Documentation [20%]

• All VIs should be documented through File»VI Properties.
• Wires that flow through structures from shift registers should be documented with appropriate labels.
• The functionality of the VI should be documented at the block diagram level, and the nested structure level.
• Front panel controls and indicators should have descriptive names.
• VIs should have descriptive icons.
• Non obvious constants should be documented.
• Front panel controls should be documented and have associated tip strips.
• Top-level VI should not have the default icon.
• SubVIs should have consistent icon design.

 Instructor

Calendar