Skip to main content

Thirty-four Years - Instructor, Machinist, CNC and CAD/CAM (Part 1)

As I've now ended 34+ years of public service, I'm going to burn a few posts on where I've been and what I've tried to accomplish.

Like many people my age, my path toward a career in technology was non-linear. My first stop after a Baccalaureate in Physics was a move into teaching Machine Tool trades at a 2-year college. Make sense, right? Actually I had taken a few programming courses in college (FORTRAN, Pascal, PDP-8 Assembler, SNOBOL, FORTH), had worked my way through college as a machinist, and taught myself how to program CNC machines. So the trade school route wasn't too much of a stretch.

When I started teaching (in 1984…arghh…) the tools of choice for programming machine tools were either a Flexowriter, a Model 43 Teletype with a tape punch, or a really expensive CAD/CAM system. The CAD/CAM system that I inherited was a 1970's vintage TTY based system running on a Data General Nova 3. Input was a proprietary language entered via a TTY. Output was either a tape punch or a one-pen HP plotter. To boot the Data General you toggled switches on the front panel to fire off a couple of instructions that would boot from floppy. Note that there was no video/monitor/CRT. If you wanted to see your machine tool path, you put ink in the pen and plotted the path on 11 x 17 paper.

I convinced the college to move from that to a modern (for the day) PC based system that had a color monitor,  8" floppies and ran the UCSD P-System operating system. And that cost $25,000. The CAD side of the system could draw 3D wire frames and output to the CAM system. Students would learn manual G-code programming and a bit of drafting and CAD/CAM while programming and running their parts on the CNC. They also learned a bit about using a keyboard, digitizer and mouse, editing saving and retrieving text, managing files, etc. For nearly all students, this was their first exposure to computers.

The college was closely aligned with local business and industry, and as a result we developed a relationship with the tool room at the local 3M plant. They hired our graduates and advised us on curriculum. At the time, our CAD/CAM was far ahead of what the local plant had available to them. The tool room did pretty complex mold repair and a CNC, but with no reasonable means of programming one-off mold repairs, the machine was underutilized. As a favor to them I used the colleges CAD/CAM to generate machine tool paths for their CNC. The most complex and interesting was a machine tool path for one of 3M's most popular tape dispensers, generated using a ton of algebra that the CAD/CAM could convert to a tool path.

About that same time, our Drafting Department introduced AutoCAD on first-generation IBM PC's that still had the cassette port. At the time is was pretty primitive compared to the CAD/CAM that we had in the machine shop.

We also had a significant issue teaching students how to program and operate CNC machine tools. As those of you who have done any machine tool programming know, typographical errors can get really expensive really fast. Misplace a decimal point and you can crash machine and incur thousands of dollars worth of damage. Some schools tried to mitigate this by limiting students exposure to the CNC machines, something which I thought would defeat the point of  hands-on vocational training.

After having to tear down CNC machine tool spindles, replace spindle bearings and re-align ways, I decided to go a different direction and try and come up with a way of proving that the students programs were valid and would not crash the machine. I did a little bit of experimenting, learned 'C', and wrote software that could read a machine tool G-code program and draw the three dimensional tool path on screen. One could also run the simulation from different 3D viewpoints, edit and save the G-code program, and download it to the CNC machine. We sold a few copies of that program to other schools - just about enough to pay for the ads that we ran in trade publications.

The available PC screens at that time were technologies like EGA, CGA, and Hercules graphics. The Microsoft 'C' compiler has libraries that helped manage graphics and isolate most of the low-level screen management from the developers, so I didn't have to use much assembler, and could reliably draw onto a canvas and let the libraries worry about the details of the graphics cards.

I also was frustrated at the quality of the CNC textbooks that were commercially available, so I started creating my own content. That content eventually evolved into a CNC textbook that was published by one of the major textbook publishers. Writing a textbook, drawing the line art in AutoCAD, and having a friend take all the photos was a great learning experience. The text was  somewhat successful. Even after 27 years you can still buy a copy of the book on Amazon - though the published dumped all their copies years ago. Seems like some things never die.

The college's teaching and learning methodology was heavily dependent on both written and video content. To facilitate creating written content, I started using Desktop Publishing systems - really just a PC with a decent monitor and GUI editing software. Once word processors were reasonably capable, the dedicated desktop publishing systems were overkill so I stopped using them.

By the time I had the textbook ready to publish, I had plenty of experience with desktop publishing, word processing and CAD/CAM. I offered to provide the text and line art electronically, but the publisher clearly wasn't going for that, so I supplied a stack of printed paper, plotted line art, and 8 x 11 photos. The publisher handed the stack off to an independent contractor who started to key and scan the whole mess into a desktop publishing package. I contacted her directly and sent her a few floppies. She thanked me. 

I enjoyed teaching - at least for a while. I think my proudest moment was when a student of mine came back a few years after graduation, had started his own mold-making shop, hired a handful of people and offered that 'anytime I needed a job, he'd hire me'. Having helped bootstrap him and many others was very rewarding.

Part 2 - Networks and Software Development


Popular posts from this blog

Cargo Cult System Administration

Cargo Cult: …imitate the superficial exterior of a process or system without having any understanding of the underlying substance --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.
The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:
Failing to understand the difference between necessary and sufficient. A daily backup …

Ad-Hoc Versus Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to…

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. These …