Not every engineer’s workspace includes a recliner and a Chihuahua—but this setup works for David Cass Tyler, a retired embedded systems engineer from Willard, NM. Tyler’s “work environment” enables him to “do things at his own pace.”
Tyler explained his work setup via e-mail:
When I require extra space to spread out, I move into the spare bedroom and use the desk in there to set up the hardware.
Almost all of my projects are developed to be distributed and accessible through the network. When I need to program on a different computer, I tend to use the remote desktop to program on other Windows-based systems. There is seldom a time when I have to physically move to one of the other systems, so this keeps my dog happy.
Tyler is currently working on a 256 I/O channel hardware simulator. He says the PC/104 hardware stack gives him 256 channels of I/O, including 64 analog inputs, 24 analog outputs, and 168 digital I/Os, all in a single compact stack.
He provided some background detail about the system:
In 1995, I was a supervisor with ATK. I designed and had my crew build this system to provide hardware inputs to a control system we were developing for a government customer. I personally programmed the base system and others in my crew used it to develop the hardware simulator.
We also had a 3U 19” rack-mounted box that contained six Rabbit Semiconductor BL2100s, which were the actual controllers used in the system. They enabled us to build the control system before the actual hardware being controlled was delivered. This was the only time in my 30-plus year career that the system was delivered, the controllers were hooked up, and the system ran right out of the box. Of course we had some tweaking and tuning to do, but the system came up under control. There were subsystems that were potentially dangerous to human life, but, with the controllers in place, we were able to safely start up without hurting anyone and without breaking expensive custom equipment.
Tyler also listed some advantages to using the system:
- You can build the control system without having possession of the actual system.
- During code coverage and fault testing, you can simulate faults that would be expensive or dangerous to test otherwise.
- You can continue to develop components after the actual system has been delivered.
- When writing the simulator, you can understand the interactions better and more completely.
- You can do virtually all of the training on the simulator, using the exact actual software that will be delivered to the customer.
- You can respond to many customer requests without having be present at the customer’s site.
Tyler’s “workspace” includes several development systems from Rabbit Semiconductor and NetBurner as well as Microchip Technology PIC microcontrollers. He also has a MIL-STD-1553 system with a bus controller and a remote terminal, both controlled by Advantech PCM-3350 CPUs.
Tyler described some of his projects by saying:
I use a combination of hardware and software simulation to develop my control systems. Using hardware simulation, you can feed expected values to controllers to calibrate them and check their functionality. Using software-only functionality, you can develop systems anywhere. With virtual computers, you can test control systems distributed between multiple “computers.” Using this technique, you can deliver control systems, ready for final debugging, at the same time the system hardware is delivered—all from the comfort of your easy chair.
He provided a final thought about built-in web servers:
You can now embed web servers that enable you to run your system without installing anything on the user’s system. With ample available storage, you can put all the datasheets, manuals, and data files directly on the embedded controllers so they are always available, even without an Internet connection. Usually, you can also put some degree of manual control on the web server so you can perform at least rudimentary diagnostics and control.
Tyler is the owner and author of The Control Freak, which he uses to share back to the community. His is currently working on a Standard Commands for Programmable Instruments (SCPI) parser.
Tyler recently wrote a two-part article about Calibration. Part 1 will appear in Circuit Cellar’s November issue.