This is the first in a series of articles describing the process of DMIS programming.
This is the first in a series of articles describing the process of DMIS programming. In future articles I will be covering specific areas of a typical DMIS program and providing actual program listings of those areas. I will try to cover the most important aspects of each area, giving the reader tips and tricks learned along the way. This first article is designed to provide an overview of the basic structure of a program and highlight the areas that any user should consider including in their program.
DMIS programs should be designed to be as portable as possible so that they can be used on different DMIS compatible CMMs. This means that all aspects of a program’s operation must be defined and the user should not assume that the CMM will take responsibility for any setting. A typical DMIS program starts with a DMIS main or module statement (DMISMN or DMISMD) and ends with an end file statement (ENDFIL). The commands contained between these statements will be driven by the demands of the inspection process. Most DMIS programs should include the following areas:
Machine Setup: usually means setting the current working units (UNITS) along with feeds, speeds, search distances, etc. At the very least a programmer should set probe backoff (RETRCT), pre-hit distance (APPRCH), search distance (SEARCH), machine move and measurement speed (POSVEL & MESVEL), machine move and measurement acceleration (POSACL & MESACL). If you will be using automatic (AUTO) mode you will also need to set clearance (CLEAR) and depth (DEPTH). If you do not explicitly embed these settings in the program, the process will use whatever settings are present on a particular machine at run time. In extreme cases this can be dangerous or at the very least return inconsistent results.
Setup Instructions: usually in the form of text output (TEXT) or in some systems by showing pictures using prompts (PROMPT). These prompts will guide the CMM user through the process of mounting fixtures or parts.
Data Input: is where the user would enter information that will be stored with the results. This data is most often used for traceability during audits. Typical data would be; Operator, Shift Number, Serial Number, etc. The information is usually obtained using program prompts (PROMPT).
Sensor selection: or calibration is required before any measurement can take place. Most DMIS based inspection systems will require that the user calibrate each sensor position before they can select them for measurement using the DMIS select sensor statement (SNSLCT). Some systems provide automated calibration routines but if you would like to maintain the theme of portability you should calibrate the sensor positions using the DMIS calibration statement (CALIB).
Manual Setup: is an optional procedure that uses various DMIS alignment statements (DATDEF, DATSET, TRANS, ROTATE, LOCATE, etc.) to setup a part datum (sometimes referred to as a reference system). Manual part datums should be kept as simple as possible to reduce operator error. Manual datums should not be relied upon and should always be followed by an automatic datum on automatic machines.
Automatic Setup: is compulsory unless you have a part locating fixture that has already been qualified and is being used as the datum reference. Even if a part locating fixture is being used it is advisable to visit key features before proceeding with part inspection in order to check that the part is located correctly. Like manual datums, automatic ones use the various DMIS alignment statements (DATDEF, DATSET, TRANS, ROTATE, LOCATE, etc.) to setup a part datum. A datum of some kind must be created in order to orient and locate the reference system with the relevant part features from which measurements will be reported.
Measurement: usually forms the bulk of most programs and covers a host of DMIS statements. Some measurements will be found using a simple feature (e.g. FEAT/POINT-MEAS/POINT-ENDMES) while others may involve constructions (CONST) to arrive at the desired solution.
Output: involves reporting the features found in the measurement section. Output can be left until the end of a program or initiated following each measurement. There is no wrong or right way here. Output during operation will give the user feedback after each measurement allowing them to abort in cases of failure. If this an automated cell this may not be important and results can be output at the end.
Machine Cleanup: can be as simple as parking the machine or may be a series of actions such as printing a report, archiving data, changing tips, etc.
The areas are listed in the usual order you would see them in a program, however some areas are interchangeable and some are not; e.g. data input could be left until the end of the program to allow the user to direct the data depending on success or failure whereas one wouldn’t see a manual setup after an automatic one.
Single programs containing the areas I have proposed are most common, which makes it easier to transport the program to other machines. If the program becomes very complex, users should consider breaking it apart into a main program that calls modules. In these cases the user should list the modules required by the main program in the header of that program or consider using the DMIS external dependency statement block (XTERN) to flag missing files.
As with any task, taking time to consider the big picture and asking the relevant questions prior to starting the project is the key to success.
Copyright © 2008 CMM Technology Solutions