No, I'm not talking about hacking an Internet file server. At CFC, Inc. we kept the CNC drilling and routing programs on a file server running Xenix which was a Microsoft branded version of Unix. The CNC machines were plugged directly into this file server using RS-232 ports. Until we purchased this server we had been keeping all our programs on punched paper tape and stored on shelves but now we could keep all this stored electronically.
Okay, this new way of doing things would have been great except that the file server cost lots of money and it wasn't reliable. Every so many weeks or months the computer would crash for one reason or another. When this happened it would run fsck on bootup. This would sometimes find some file system records to repair because the machine didn't have a chance to write everything to disk when it crashed. The end result? We would sometimes lose files from the file server. Bad, bad and worse because all our backups were on tape and we had really bad luck restoring from tape.
We didn't want to spend any more money on this file server. I wanted to develop a replacement in house. It would run on DOS which didn't have the bad habit of delaying writes to the file system. Not bulletproof, but bullet resistant and cheap. But, I had a problem. The only documentation I had which explained the communication protocol for the file server was very thin and hard to understand. I was stuck.
Remember the RS-232 monitor that I grabbed at the GTE auction? I knew right away how useful it would be for this project! Back at the factory I installed this monitor between one of the CNC machines and the Xenix file server. With the ability to see data moving back and forth I was able to figure out how the file server worked. It was tricky because data was actually delivered in packets. There was a non-trivial conversation that happened between these machines but it looked like the code for this was going to be fun to write!
I was ready to get started!
Showing posts with label rs-232. Show all posts
Showing posts with label rs-232. Show all posts
Saturday, March 12, 2011
Wednesday, April 21, 2010
Our First Laser Printer
We decided to purchase a laser printer so we could print bill of materials sheets for each job. I managed to find a used HP LaserJet cheap. This was the original LaserJet printer model and had only 128K of RAM. This was fine, except if you wanted to print graphics. You could not even draw a half page of black and white graphics with 128K. This also meant that there was very little room to load fonts into the printer. The saving grace was that there was a font cartridge slot. I bought one of those super font cartridges that had lots of fonts. It turns out that we really only needed one font. I don't remember which one we used, but it was a small monospaced font.
The printer had a serial port, not a Centronics printer port. Normally this would have been considered a limitation, but this was perfect for our shop floor control system which I was building around Arnet multiport RS-232 cards.
I needed to learn just a little bit of Hewlett Packard's PCL (printer control language) to make the LaserJet do its thing. I wrote some code in Smalltalk to drive the printer. Depending on how complex the board design was, these bills of materials sometimes had a lot of information on them. It was somehow very satisfying to produce software that would drive a printer elsewhere in the building. I had never done that before.
The printer was located up in the engineering department, and after they designed a circuitboard for an order they would fill in some fields into the shop floor control system and print out the bill of materials on the LaserJet.
The printer had a serial port, not a Centronics printer port. Normally this would have been considered a limitation, but this was perfect for our shop floor control system which I was building around Arnet multiport RS-232 cards.
I needed to learn just a little bit of Hewlett Packard's PCL (printer control language) to make the LaserJet do its thing. I wrote some code in Smalltalk to drive the printer. Depending on how complex the board design was, these bills of materials sometimes had a lot of information on them. It was somehow very satisfying to produce software that would drive a printer elsewhere in the building. I had never done that before.
The printer was located up in the engineering department, and after they designed a circuitboard for an order they would fill in some fields into the shop floor control system and print out the bill of materials on the LaserJet.
Sunday, April 4, 2010
My Skunk Works Project
What is a skunk works? A definition from Wikipedia: The designation "skunk works", or "skunkworks", is widely used in business, engineering, and technical fields to describe a group within an organization given a high degree of autonomy and unhampered by bureaucracy, tasked with working on advanced or secret projects.
In order to prototype the multiuser shop floor control system, I needed a real video terminal. The idea would be to take a computer and install one or more multiport RS-232 cards and connect terminals to them from all over the building.
The following work was done more or less under the radar. I wasn't trying to get away with anything, but I hoped to surprise Bob with the results I hoped to achieve. I managed to requisition an old Lear Sieglar ADM-3A terminal on the cheap. This was one of those pastel blue terminals with a "space age bubble" look to it. Needham High School had a few of these connected up to their PDP-11.
In order to make this work with Smalltalk/V I needed a tiny machine code routine so I could make calls to the serial port. I was lucky to find someone on a bulletin board who was kind enough to write this for me. I was even luckier that it worked! The machine code file was only 14 bytes long!
It didn't take me very long at all to create a master monitor, a login routine, a simple command parser, a simple job object, departments that could hold jobs, and the ability to move the work from one department to another and list the contents of each department.
What was absolutely most amazing about what Smalltalk/V made possible is that the system was extensible and debuggable... as it ran! If there was a runtime error while executing some command from the terminal, a debugger opened on the computer screen. I could then fix the bug right there, and the terminal could be restarted without bringing the system down for a recompile.
This was very promising to say the least.
In order to prototype the multiuser shop floor control system, I needed a real video terminal. The idea would be to take a computer and install one or more multiport RS-232 cards and connect terminals to them from all over the building.
The following work was done more or less under the radar. I wasn't trying to get away with anything, but I hoped to surprise Bob with the results I hoped to achieve. I managed to requisition an old Lear Sieglar ADM-3A terminal on the cheap. This was one of those pastel blue terminals with a "space age bubble" look to it. Needham High School had a few of these connected up to their PDP-11.
In order to make this work with Smalltalk/V I needed a tiny machine code routine so I could make calls to the serial port. I was lucky to find someone on a bulletin board who was kind enough to write this for me. I was even luckier that it worked! The machine code file was only 14 bytes long!
It didn't take me very long at all to create a master monitor, a login routine, a simple command parser, a simple job object, departments that could hold jobs, and the ability to move the work from one department to another and list the contents of each department.
What was absolutely most amazing about what Smalltalk/V made possible is that the system was extensible and debuggable... as it ran! If there was a runtime error while executing some command from the terminal, a debugger opened on the computer screen. I could then fix the bug right there, and the terminal could be restarted without bringing the system down for a recompile.
This was very promising to say the least.
Thursday, February 25, 2010
The Job Tracking System in BASIC
It was time to put my new SBASIC tool to good use. Bob wanted a new tracking system to replace the old TRS-80 one. We decided to use one of the Kaypro II machines for this. I'm a little fuzzy on whether Bob started this one and handed it off to me, or if I was the developer from the get-go. Regardless, this project was a showcase for what could be done with the BASIC programming language.
This was a pretty easy application to build. There were a dozen or so departments on the factory floor. Each time a new job was ordered there were some essentials entered like job #, customer name, board type, due date, etc. and these were just stored in a simple random access file. Several times a day a young lady from Brazil named Danusa would make rounds collecting information about jobs and where they were in factory. Then she would come back and enter this information. Status reports would get printed out.
C.F.C. specialized in quick turnaround orders. Anything we could do to improve information about important rush orders was critical. A more timely tracking system was in our sights. We took one of the Tandy Model 100 portables and bought a barcode wand for it. A data collection program for it was written in BASIC. This would be used to collect the locations of all the jobs. I wrote a program in the tracking application for printing 3 of 9 bar code on label stock using an Epson compatible dot matrix printer. These had job numbers on them and we stuck them on the job bill of materials sheets that went with each order. Then we printed large bar codes for each department.
So now all Danusa had to do was go to a department, scan the bar code on the department sign, and then go to each bill of materials sheet and scan in the job number bar code. Then she would repeat this with each department. When this was done (and it was a lot faster than using a pen and clipboard) all she had to do was come back and we would read the information into the Kaypro II using an RS-232 cable and we would just suck that information into the tracking system and print the reports.
It really stands out to me that this sort of very useful application programming was easily achievable by a high school graduate with a knowledge of BASIC. For a good while we used this system to expedite manufacturing. End users used to do this kind of thing a lot more back then and I'm sure that Bob could easily have written this himself if he were so inclined and it he weren't so busy running the company. People should take more interest in programming because it's fun, it teaches important thinking skills and even untrained programmers can accomplish real productivity enhancements.
This was a pretty easy application to build. There were a dozen or so departments on the factory floor. Each time a new job was ordered there were some essentials entered like job #, customer name, board type, due date, etc. and these were just stored in a simple random access file. Several times a day a young lady from Brazil named Danusa would make rounds collecting information about jobs and where they were in factory. Then she would come back and enter this information. Status reports would get printed out.
C.F.C. specialized in quick turnaround orders. Anything we could do to improve information about important rush orders was critical. A more timely tracking system was in our sights. We took one of the Tandy Model 100 portables and bought a barcode wand for it. A data collection program for it was written in BASIC. This would be used to collect the locations of all the jobs. I wrote a program in the tracking application for printing 3 of 9 bar code on label stock using an Epson compatible dot matrix printer. These had job numbers on them and we stuck them on the job bill of materials sheets that went with each order. Then we printed large bar codes for each department.
So now all Danusa had to do was go to a department, scan the bar code on the department sign, and then go to each bill of materials sheet and scan in the job number bar code. Then she would repeat this with each department. When this was done (and it was a lot faster than using a pen and clipboard) all she had to do was come back and we would read the information into the Kaypro II using an RS-232 cable and we would just suck that information into the tracking system and print the reports.
It really stands out to me that this sort of very useful application programming was easily achievable by a high school graduate with a knowledge of BASIC. For a good while we used this system to expedite manufacturing. End users used to do this kind of thing a lot more back then and I'm sure that Bob could easily have written this himself if he were so inclined and it he weren't so busy running the company. People should take more interest in programming because it's fun, it teaches important thinking skills and even untrained programmers can accomplish real productivity enhancements.
Thursday, February 18, 2010
The Osborne 1
The Osborne 1 was a portable CP/M computer with a Z-80 processor. It looked like a portable sewing machine. You tip it on its side and undo the latches and the end would come off revealing a keyboard which was attached to the rest of the machine by a wide ribbon cable. Removing the keyboard revealed two large floppy drives, a tiny 5 inch screen, cubbies for floppy disks, and a bunch of ports. We would plug the RS-232 cable from the paper punch into one of the ports.
The 5 inch screen could only display 52 characters wide, but it could scroll. You had to have a tolerance for reading very small type to use this machine. I was okay with it, but today I probably wouldn't enjoy it.
Aside from editing CNC programs, we also had MBASIC on these machines and so we could do a little programming to help us with our work. Bob knew how to write in BASIC and he had written a few things. For example there was a program for spitting out a simple routing program for a rectangular board. You just punch in the size of the board and it would generate a file. Anything more complex than that required manual coding.
One problem we had with the Osborne 1 machines we had was that the keyboard bezel was metal and it wasn't grounded well. If you walked up to the computer and touched the keyboard it wasn't unusual to discharge some static electricity and reset the computer, losing whatever work you were doing.
The 5 inch screen could only display 52 characters wide, but it could scroll. You had to have a tolerance for reading very small type to use this machine. I was okay with it, but today I probably wouldn't enjoy it.
Aside from editing CNC programs, we also had MBASIC on these machines and so we could do a little programming to help us with our work. Bob knew how to write in BASIC and he had written a few things. For example there was a program for spitting out a simple routing program for a rectangular board. You just punch in the size of the board and it would generate a file. Anything more complex than that required manual coding.
One problem we had with the Osborne 1 machines we had was that the keyboard bezel was metal and it wasn't grounded well. If you walked up to the computer and touched the keyboard it wasn't unusual to discharge some static electricity and reset the computer, losing whatever work you were doing.
Subscribe to:
Posts (Atom)
