2005 Articles

Simple steps for integrating CAM systems.

While CAM software becomes more advanced and effective, solutions remain, in general, too general. That is, no vendor can make software that will effectively address the issues of all potential customers. So how does a company take a great CAM software from vendor A and make that same software work effectively for customer B, C, D and E? The answer, of course, is with automation and integration. Automation code makes the CAM software run more quickly, easily and efficiently within itself and integration code “hooks” one CAM system into another or perhaps into a PCB layout tool or a relational database (such as Oracle).

The first and most obvious problem with automation software is that it is, by definition, beholding to a parent software system. The parent makes rules by which the automation software must live. This means that the automation must constantly undergo adjustments to maintain its integration with the parent software.

A second issue, and one which makes automation software tedious to maintain, is that you never stop developing it. Once some automation is in the hands of users, the process of finding the faults and shortcomings in the software begins. This is also true of the parent software that the automation drives. However, this parent software is generally not in control of the automation developer and the automation software is generally perceived as being easy to change. While this is mainly true, there are risks involved in changing, even in the smallest manner, automation software. A hard-and-fast rule I had when working in the front-end engineering department of a major PCB company was to never change CAM automation on a Friday. Something would always go wrong, no matter how small the change.

A final point has to do with the people who generally develop this type of software. They are not usually computer scientists. (This is not a putdown; I myself am not a degreed computer professional.) Largely self-taught, these developers do not have the underpinnings and background that one would attain through higher education in computer science. (Of course, we make up for it in our willingness to tackle the seemingly trivial tasks.)

With these three points in mind, the question is, What methods can be applied to manage automation software in a way that will make it 1) easy to use, 2) easy to administer, 3) easy to code-maintain from one programmer to the next and 4) a long-lived library of code.

Last issue first, as it is the driver behind the methods that will be laid out here. Procedures and innovations in the manufacturing world occur at such a fast pace that software can become obsolete quickly, which leads to inefficiencies in development time. When software needs to change, it is often thrown out and a completely new project developed, even if it overlapsd the previous project by 80%. So, many of the goals laid out will focus on ease of change and maintenance so that the core of the code will be viable for many years.

Now, with all I have said about almost immediate obsolescence, this issue seems out of place. Not true! Although industry procedures change frequently, there is always a hardcore group of functions that change slowly, if ever. One such area in CAM automation is data input. Since data input will always exist, construct code relating to these functions in a way that it can be stored in a library and easily integrated into any new projects. This method will save money in the long run, as this basic code will be slightly modified over the years but will never have to be written from scratch. Project after project can access this redundant code and can therefore get underway and out to users more quickly with less testing time and with fewer bugs that actually get to the shop floor or the PCB designer’s desktop.

The first issue – make it easy to use – is a no-brainer! If your user base (customers) will not use your automation, you’ve wasted time developing it. They could be forced to use it, but then why write automation that is not easy to use?

Ease of administration is not as obvious. What is meant is that the automation needs to reflect the diversity of the user base: the code must support different needs for different users and still support the same basic functions, even for, say, top tier EMS companies with large user bases spread worldwide. This involves default values for various user-filled entries, file paths (never hardcode a path in the software) and even things such as colors, if applicable. Different people see colors differently. Automation can and should support this.

How do you do this? Use parameter files, written in formats that are easy to use and change by the administrator or users. Also, do not skimp on the parameter names by using abbreviations. The DOS limitation on memory is long gone; the computer can spare the bytes. If you have a parameter that controls the color of the “quit” button, then call the parameter “quit_button_color”, not “!#@*&:/?.” Also, do not just have one set of parameter files. Have a system set, which gets installed at initial implementation, and a user set for the user’s discretion. The location of these user parameter files may be specified by the use of an environment variable, such as USER_PARAM_FILES, for example. Be aware of the length here though, because some Unix systems have a limit on these names. Everything in the system parameters would not have to be included in the user parameter file. The user values would simply “overlay” the system. That is, the automation would read the system parameters at start and then read the user parameters if found, writing over any system parameters with the user values.

Another close cousin of parameter files are process control files. This issue delves into the structure of the code, but simply put, build the code in such a way that reflects the actual process. For instance, with a typical CAM data DfM process, you input Gerber files, clean up the files (i.e., change drawn pads to flashed) and then perhaps add some value-added attributes, if the CAM system permits it. In the automation code, these would be three distinct processes that could be added or removed from the automation by simply modifying the process control file. When programming in a language such as PERL (Figure 1), which supports subroutines, this goal is easily attainable. With more mature languages such as C-Shell, it can be somewhat difficult.

FIGURE 1: An image of a PERL script displayed in the text editor. The tool can be configured to color-code line according to the syntax of the PERL structure.

Another level below the process control file can be implemented to make each process customizable. This would be to layer in rules files. There can be a corresponding rules file for each process. The process’ complexity will affect the number and complexity of the rules that can be developed for that process. Data input, for example, would not require a diverse set of rules because there is not much to the process, but even a simple rule which is conditional based on data input type (i.e., is it Gerber, Fatf, Allegro) can be helpful in allowing administrators or users to customize the automation for a particular user, customer or situation. An example of a process that may lend itself to a multitude of rules would be value-added attributing of data after input. Many input format specific rules may be developed in that area.

Construct the code in a very general, object-oriented way so that the administrators of the code can form the automation to specific needs. There is, obviously, a general thrust behind the automation, but with enough use the automation will reveal that it needs to be more flexible, even when developed for the needs of a specific company.

An accompanying document (such as a .pdf file) is always desired to convey to the administrator the meaning and use of every parameter and rule. If the administrator does not know what the parameter does, they will likely not make the best use of it. If a parameter is not used, it is not needed.

Making the code easy to maintain from one programmer to the next rarely receives attention in CAM automation. It is deemed that it is not important code or that it will be quickly obsolete or it just may be a case of the developer being shortsighted. But the bottom line is, to be considered professionals, right up there with the degreed engineers, we have to act like it! So, comment that code. Effect revision control for every file or subroutine plus revision control for the entire project. Make it easy for the code to be passed on to the next programmer or elsewhere within your company.

Following these simple principles can make for a more cost-effective development of CAM automation. When the procedural issues are organized and out of the way, the developer can get down to the real task of making automation that is easy to develop, implement, use and maintain.

Stephen Potter is application engineer at Valor Computerized Systems (valor.com); stephen.potter@us.valor.com.