Creating Family of Parts Members

One major drawback of the implementation of the family of parts system is that the parts can only be created in a module of CADDS called the Local Data Manager (LDM). Raytheon normally doesn't use this module of the program because of the immense overhead involved. This is due to the large volume of parts stored on the server. Also, in order to enter the LDM, the designer has to close whatever parts or assemblies are active.

Another problem is that because of the configuration options used to cut down the overhead of the LDM when it does have to be used, the only way to generate these parts is to type in the command manually. The command is fairly complicated, and parts of it are case-sensitive. Normally, the command could be generated by the search program, and the computer's cut and paste system could be used to copy the command into the LDM. Unfortunately, the cut and paste system doesn't function properly in the LDM. This leaves only the manual entry of the commands into the buffer. Given this large overhead in creating the parts, a better method had to be devised.

Fortunately, CADDS was designed such that it could read in a set of commands when it starts, and execute them. With a few exceptions, this could be done without any user interaction. The solution to this problem, therefore, was to create another program that would generate parts on demand. This program, called a daemon or server, would run on one of the workstations. Once started, it would just wait to be sent requests for parts. It would then carry out the necessary steps to create that part. The search engines could be written such that instead of giving someone the command they need to use to generate the part, the program would contact the server and ask it to generate the part.

Out of this arose another problem. What if someone knows the name of a part they need, but it doesn't currently exist on the system? Should they have to go through the whole search process to have it created? The solution was to create another set of programs that would handle this situation. The designer would enter the name of a part, and the program would contact the server and have the part generated if it did not already exist on the system.

This actually led to the resolution of some other issues that had been raised. These involved ownership of these parts once they were created, and the ability of users to modify the parts. Because these parts are to be shared with all the designers, any changes made to the parts by one designer can cause problems in projects that other designers are working on. Also, since these are generated parts, they can be removed and regenerated at any time, thus losing any modifications. To avoid these problems, the parts have to be made read-only, which prevents anyone from modifying the parts. If all of the users were creating parts themselves, enforcing this would be extremely difficult. Since these parts are now being created by a program, they can be guaranteed to be read-only with no problems.

Last Modified: Wed Aug 28 14:41:29 EDT 1996