Windows Service
for
Visicon Inspection Systems
The project will be divided into four phases. Each phase will be
completed and tested before work begins on the next phase. The
definition of each phase can (and probably will) change before work begins on
it. Phases may be merged, divided into parts or even eliminated altogether.
Each phase contains an automated test that will serve as a marker for the
end of a phase. Each automated test builds upon the test from the
previous phase and retains all applicable tests from all preceding phases.
Phase 1
Being the first phase, phase 1 is the most clearly delineated phase of the
project. It is in this phase that the initial versions of each component
are created. All subsequent phases build upon the work started in phase 1.
Objective:
Assemble the basic components of the motion control service.
Deliverables:
- A Windows service that accepts goto commands and
read requests. The service will not pass commands down to the
motor drivers. Instead it will simply wait 2 seconds, update its internal
position value and then output a debug message.
- A console-mode automated test program to verify that the service is
working properly. The test program will send a series of goto
commands to the service and then verify that subsequent read
requests will return the proper positioning values in the order in which
they were sent. It will also attempt to cause the service queue to overflow.
- A small GUI program that will allow a user to send individual goto
commands and read requests to the service. This can be run
concurrently with the automated test program.
- A DLL for the above two programs to use for interfacing with the service input queue. This library will become
the standard interface for all Visicon applications.
- An installation utility which will install the service. (This utility is provided by Microsoft's .NET Framework free of charge.)
- A debug monitor program which will display and log debug and error messages from the service. (This is a third-party freeware utility.)
Technical Details:
Phase 2
Phase two will result in the first "useful" system. Where phase
1
focused on the interface between applications and the service, phase two
focuses on the interface between the service and the lower-level drivers.
A good estimate of the time involved in getting phase two completed cannot be
made until the device driver interface is reviewed. However, it is very unlikely
that it will take longer than phase 1.
Objective:
Connect the service to the motor control drivers.
Deliverables:
- The 2 second hard-coded delay will be removed from the service and all goto
commands received by the service will be passed on to the appropriate motor drivers or motion class.
- The automated tests will remain unchanged. However, in order for a test to
pass, all motion commands sent to the service must result in the appropriate changes in position.
- The other components will remain unchanged.
Phase 3
The service delivered in phase two provides a very minimal set of
functions. In order for the service to be truly useful, it needs to be
able to process blocks of commands, cancel pending commands and be notified of
events such as safety button presses.
Objective:
Upgrade the service to provide for more application control and
notification of events.
Deliverables:
- The service will be upgraded to handle the following new commands: cancel,
home, get_error, lock and unlock.
Other positioning-related commands may also be added in this phase.
- The service will process emergency safety button presses by clearing its
position queue and alerting registered applications of the button press and
release.
- The library interface will be expanded to support all new commands as
well as registration of callback routines for safety button presses and
other events.
- The automated test program will be expanded to include one or more tests
for each new command supported by the service. It will also test the
library's callback routines.
- The GUI program will be expanded to allow interactive access to all new commands.
It will also display an alert box for each asynchronous event from the
service.
Phase 4
Phase three will have delivered a solid working service. Phase four
will add on to that service the capability to handle all remaining non-motion
controls and any remaining data-acquisition commands.
Objective:
Add non-positioning commands such as light control commands.
Deliverables:
- As with phase 3, all components will be modified to support the additional commands.
Miscellaneous
All software will be written in C++ using the Microsoft Visual Studio .NET development environment.
Before the end of each phase there will be a brief code review.