This article was first published on LinkedIn, as a two part series.

Has the time come for universal software on your Cylindrical Coordinate Measuring Machine (CCMM)?

I wish I could claim the idea of using universal gage software across multiple gage manufacturers.  However, I first heard this idea proposed by one of my auto industry customers over 20 years ago.  The original idea as I recall, was to allow the gage manufacturers to write the software to run the equipment, stopping short of performing the calculations.  Instead, the data would be saved to a common file format and be processed offline.  I’ve heard this idea proposed many times since the 1980s, but there were always significant technical hurdles in the past.  If achieved, universal software could be used to process the measurement data from different gage manufactures, providing a number of advantages:

•  A single supplier for software, which reduces the cost and complexity of performing software upgrades, or adding features.
•  The option to choose the best hardware and software separately.
•  The ability to objectively compare different gages, without concern for filters or differences (errors?) in calculation.
•  Transparency of calculations.
•  Ease of correlation between gage types. This last point is of particular significance, as commonality of legacy equipment is often a difficulty when switching manufactures of gage equipment.

 

For this discussion, I will address the special case of the Cylindrical Coordinate Measuring Machine (CCMM), as that is what I’m most familiar with and one of the easiest gage types to find a solution for. Cylindrical CMMs are a special type of CMM that employs a spindle to rotate the part relative to the measurement probe.  They are primarily used for shaft measurement. Special versions like the Hommelwerke CFM 3010, are also capable of measuring the unique features of camshafts and crankshafts.However, all CCMMs produce a data set that is some combination of radial displacement data, relative to angular position. It is from this root data that all radial measurement parameters are derived. Parameters such as roundness, diameter, profile (in the case of camshaft lobes), stroke, and angular position.

What Has Changed, to Make This Possible?

As late as the 1990s, many manufacturers of measurement equipment used software based in machine language, across various operating systems.  This made it difficult to find a universal software solution.  However, over the last 20 years all CCMM manufacturers have moved to the Windows platform.  As they did so, they also made it easier to extract the unprocessed measurement data in text file format.  The layout of these text files varies across manufacturers, but all contain similar information.

I propose that it would be a relatively simple matter to agree upon a standard file format which contains radial displacement data (including all runout components), angular location, and where required, an offset to adjust for gage size calibration. Such a file format for 3600 data points, might look like this:

Journal ID: Main 2

Displacement       Angle    Offset=5.0045

1.05546                     1

1.05348                     1.1

….                              ….

.67720                      3600

Or, the offset could be combined with the radial data.

Is There a Precedent for Universal Software on CCMMs?

At one time, all gage companies produced their own SPC software, or purchased third party solutions.  However, around 15 years ago, one of the major automotive companies moved to a single supplier of SPC software.  Other companies followed and now QDAS is the supplier of statistical software for the Detroit 3 and other automotive companies around the world.  By pairing with a single provider of SPC software, which was large enough to service the auto industry, the interpretation and storage of data has been streamlined.  This was possible because the OEM dictated the file format to the CCMM supplier (along with the suppliers of other equipment).  A similar initiative could be undertaken to dictate the required file format to the gage suppliers.

So Who Would Make This Software?

It is much easier to find a mathematics and software team today, than it was in the 1970s. Performing the calculations then, required a combination of skills that was not easy to find.  Today, sourcing the software and mathematics resources is much easier and a software company could easily be formed for the task. However, I do not think that is the best approach.  Instead, I propose that this software should be developed by one of the existing CCMM companies that has a reputation for building intuitive user interfaces.  Since this company would have already written code to perform these calculations on their own equipment, it would be a relatively simple process to adapt them to a common file format.

What About the Machine Control?

Once the master gage software is developed, the gage companies could better focus on machine control. The equipment would function as it does now, but raw measurement output files would be written to the network drive and stored for processing.  The operator would then receive the measurement results on screen or through a printed report, at the gage station.  If done in this manner, no additional training would be required for the gage operator.  This would also free up resources at the gage producer, helping to control product costs.

How Do We Start?

You, as the buyers and users of such equipment, must let your suppliers know this is what you want. I would suggest the following general steps to begin:

• A brief review of existing gage company software options, to determine the best UI and presentation of data.
• Agree on file format. This may be as simple as using the format that works best for the company writing the software.
• Require that unprocessed data be stored in this format, as a requirement on any RFQ. This would be no different from the requirement that the gage companies store results in the QDAS qs-stat file format.
• Test and compare across gage types

The company that embraces this approach first, would enjoy competitive advantages.  However, I think they should also understand that to make this truly cost effective, the software provider should be allowed to sell the solution to all of their customers.