Software Development
Resume:
*** ****** **. ***** 248-***-****
Berkley, MI murrellr@ameritech.n
Robert A. Murrell
Objective To continue a career in software development that will take
advantage of my experience in the programming of embedded systems
and allow the opportunity to move into new software development
environments.
Summary of I have much experience in design and development of software for
qualificati microprocessor systems and PCs used for industrial control. I
ons program primarily in C and PERL for UNIX/Linux, and Microsoft
C++/Visual Basic 6 for Windows. I also have experience in
programming other languages including JavaScript/CGI/PHP/HTML,
PASCAL, assembly languages, and other proprietary and scripting
languages.
My career can be summed up as making disparate systems communicate
and cooperate with each other, be they software, hardware, or human.
Work Jul 1985 - Feb 2009 FANUC Robotics America, Inc. Rochester Hills, MI
experience
Senior Product Development Engineer
I worked independently or as part of a team in the development of
robot controller core and peripheral software. The controller is
essentially a large embedded system comprising of almost 30,000
source modules. My responsibilities also included preserving my
code in IBM Clearcase, and testing and documenting my work in an
ISO-9000 environment.
Software build administration - I have basic administration skills
for UNIX and Linux, including LAMP server maintenance. I programmed
in C, PERL, and BASH scripts to run the software build environment.
I also created web interfaces to the software build tools using
DHTML, JavaScript, CGI, PHP, and Server Side Includes.
Off-line robot programming tools - I wrote customer programs for
Windows in C++ and C using Microsoft Development Studio and Visual
Basic 6. The C++ projects were primarily MFC but included some STL
for ported code. These products ranged from reusable ActiveX and
GUI-less COM/DCOM components to full applications.
Robot core software development - I developed code in C and assembly
language for the robot controller operating system. Most code was
targeted for Motorola 68000, Freescale PowerPC, and Intel x86
architectures, with some other miscellaneous processors. The
functions I developed ranged from low level drivers to user
interface components.
Debugging and diagnostic tools. - I have experience operating
software and hardware tools used for developing embedded systems
such as In-Circuit Emulators, protocol analyzers, logic analyzers,
oscilloscopes, spectrum analyzers, VOMs, etc., and can solder. I
have a good grasp of how the hardware works. I create software and
hardware modules used to link disparate development tools for ease
of program development.
Industrial communications - I Implemented both on and off-line
drivers and tasks to implement serial and Ethernet based proprietary
and standard protocols to allow the robot controller to communicate
with external devices. The Ethernet protocols included standard
Internet protocols like BOOTP, DHCP, TFTP, and HTTP.
Oct 1980 - Jul 1985 Westinghouse Electric Co. Numa-Logic Department
Madison Hts., MI
Junior Engineer
Design, prototype, and program Programmable Logic Controller (PLCs).
- I worked in all phases of product development, from design to
prototyping and release, including in-house test fixtures to
maintain the product.
Military Oct 1973 - Oct 1980 U. S. Air Force
Staff Sergeant, Ground Navigation Aids Repairman
USAF Commendation Medal
Education 1982 Macomb County Community College Macomb, MI
Associate Electronics Engineering Technology
Summa Cum Laude
Patents and U. S. Patent No. 4414632, Automatic Monitoring System for Radio
licenses Signal
FCC General Radiotelephone License
Technician class Amateur Radio Operators license
960 Oxford Rd. Phone 248-***-****
Berkley, MI murrellr@ameritech.n
48072 et
Robert A. Murrell
Resume Embedded Software Development Experience
Supplement
My first job at Westinghouse was working either independently or as
part of a team developing Programmable Logic Controllers (PLCs),
both hardware and software design. These devices were designed
around 8-bit microprocessors, specifically the Intel 8080 and 8085,
and the Zilog Z80. One advanced unit used a 56-bit processor built
with the AMD Am2901 bit-slice ALU. It also used an Intel 8088
16-bit processor for communications and control. We also designed
peripheral devices using microprocessors from Motorola, Rockwell,
and RCA. Software was written assembly language due to the
time-critical nature of the PLC execution.
I also worked on off-line software to run on IBM-compatible PCs
under MS-DOS. This included program loaders and monitors, and
drivers for various industrial communications protocols to interface
the PLCs to third-party Human-Machine Interface (HMI) products.
At FANUC Robotics, I worked either independently or as part of a
team to develop software for what was essentially a very large
embedded system. Almost all the software was developed in-house,
from the real-time operating system to the user interface. All the
software was written in ANSI C except for certain time-critical code
in the OS, which was written in assembly language. This device was
originally designed around the Motorola 68000 processor, but evolved
through the PowerPC PPC603e/MPC860 and then the Freescale
MPC7440/MPC8270 processors.
To support this unit I also worked on off-line products that ran on
a PC, first under MS-DOS and then under Microsoft Windows. These
products were written in C++ and Visual Basic, and often
incorporated ported code from the unit. This development ranged
from low level communications drivers to the user interface. The
communications involved moving information in and out of the primary
system to external computers using proprietary or industry standard
protocols. The transmission medium was primarily RS-232/422 or
TCP/IP Ethernet, but had included the international standard
Manufacturing Automation Protocol (MAP) early on.
I also worked on a few smaller single board computer peripheral
devices. The most recent of these was a tethered control pendant
for the primary controller. This was essentially a dedicated
terminal. It used a Hitachi SH3 card PC with proprietary peripheral
hardware, running Windows CE 2.1 as the OS. Its purpose was to
provide a graphical user interface for the controller. All the
software was written under Microsoft C++ using Visual Studio. My
primary responsibility was to create COM object wrappers to the
display, keyboard, and communications devices.
Debugging and testing was accomplished through software and hardware
tools. Software tools consisted of built-in monitor tasks or the
native debugger in Visual Studio. Hardware tools consisted of
In-Circuit Emulators (ICE), logic analyzers, protocol analyzers,
spectrum analyzers, oscilloscopes, and other test equipment. Many
of these tools required custom firmware to make the development
tools work together in a seamless environment. This ranged from
specialized fixtures for interfacing disparate devices to software
for converting compiler symbolic output to a loadable format for the
emulators.
For all these systems, software was developed off-line on UNIX using
standard editing tools and cross compilers, or on Microsoft Windows
using Visual Studio in a simulated environment. Source code was
controlled with IBM Rational Clearcase running under both UNIX and
Windows.
In addition to the above, I worked within a well-defined ISO-9000
compliant development process and provided clear documentation for
each phase of a project development, from specification to
post-release support.
960 Oxford Rd. Phone 248-***-****
Berkley, MI murrellr@ameritech.n
48072 et
Robert A. Murrell
Resume PC products Development Experience
Supplement
At Westinghouse Electric Numa-Logic department, I worked as part of
a team to develop the Advanced Program Loader. This program was
used to load ladder programs and monitor all Numa-Logic Programmable
Logic Controllers (PLCs). It was to be run on an IBM or Compaq
portable PC under MS-DOS. This program was written in PASCAL and
assembly language. I was responsible for the communications and
program status screens. The communications required writing a fully
interrupt-driven handler in assembly language that accessed the PC
hardware directly, bypassing its Basic Input/Output System (BIOS).
I also wrote a stand-alone communications driver to allow any PC to
communicate with the PLCs. This driver gave third-party
Human-Machine Interface (HMI) programs the ability to monitor the
PLC status. The driver was written in assembly language and C. It
was an MS-DOS Terminate-and-Stay-Resident (TSR) driver that had a
BIOS-like interface. It could communicate with a PLC directly
(point-to-point), over several proprietary networks, or the industry
standard Modbus protocol.
At FANUC Robotics, I wrote a more advanced communications driver to
communicate with all FANUC robots. It was written in assembly
language and C, and was also a TSR driver under MS-DOS. However, it
executed during the system timer tick, borrowing small blocks of CPU
time each tick. This allowed it to run in the background
simultaneously with the application using it. I wrote an API
library to access its functions allowing it to be used by most any
program development language. Several FANUC software products were
created using this driver.
To aid in the loading and deployment of FANUC robots, I created a
program for the PC that emulated an external floppy disk drive.
This was a very expensive device that was needed to load a robot
controller in the field. The emulator program allowed any PC,
specifically a laptop, to be used instead. This program was widely
used by customers and internal service technicians until the
development of the newer Internet-enabled robot controllers.
Throughout my career at FANUC Robotics I worked on the off-line
program development tools for the robots. These tools consisted of
native robot controller code written in ANSI C and ported to the PC.
They allow the operator to develop robot programs on a PC and to
transfer them to the robot for execution. Initially, I was the sole
developer of these tools. The early versions ran under MS-DOS. The
controller code was given an MS-DOS command line interface to create
a set of utility programs. I wrote a character-based menu shell to
run the utilities to make them easier to use.
The next version of the off-line program ran under Windows. I was
responsible for the individual development tools. The menu shell
was written in Visual Basic. I converted the ported code into
Dynamic Link Libraries (DLLs) so they could be called by Visual
basic as APIs instead of shelling the executables. This gave the
menu shell greater control over calling each function and handling
returned errors. This Windows version of the off-line program
supported over fifteen different versions of robot controllers.
Each robot version required its own version of off-line tools. I
developed a mechanism to dynamically load the correct DLLs for the
targeted version. I also maintained the command-line version of
each tool for compatibility with earlier products.
The final version of the off-line development tools was to
incorporate them into FANUC's ROBOGUIDE robot simulation product.
This was a very large Visual Basic project consisting hundreds of
forms and class modules. The version-dependent DLLs were given a
GUI-less COM object wrapper that set up the environment and loaded
the correct DLLs based on the selected version and robot
configuration. These COM objects were written in Microsoft Visual
C++. I also created a context-sensitive editor for the robot
languages that was incorporated into this product.
One component of ROBOGUIDE is the virtual robot, which is the entire
robot controller software ported over to Windows as an
out-of-process COM server object. This server accurately simulates
the execution of a real robot. I developed the mechanism to
programmatically configure the virtual robot and to debug it using
Microsoft Visual Studio. Also, to help inventory and monitor all
virtual robots on a PC (more than one can be running at a time), I
created a Windows Explorer Namespace Extension to visually list them
and their properties.
At FANUC, the preferred program development standard was to develop
functional entities in C or C++ as ActiveX controls or GUI-less COM
objects, and to develop the user interface in Visual Basic. This
allowed the quick development of new products with the reusability
of functions.
I also worked on a tethered control pendant for the primary
controller. This was essentially a dedicated terminal. It used a
Hitachi SH3 card PC with proprietary peripheral hardware, running
Windows CE 2.1 as the OS. Its purpose was to provide a graphical
user interface for the controller. All the software was written
under Microsoft C++ using Visual Studio. My primary responsibility
was to create COM object wrappers to the display, keyboard, and
communications devices. The display object was a VT-220 terminal
emulator with FANUC extensions. This object required calling
low-level Windows API functions to properly render the text, as the
standard window objects available with Microsoft Visual Studio were
inadequate.
As part of this control pendant project, the entire functionality of
the robot controller was objectized as a GUI-less COM object using
standard Internet protocols to extract information from the robot
controller. I created many of the internal objects and the
mechanism to return asynchronous events from the controller to be
thrown by the object. This robot controller object was ported back
to Windows and has become the standard communications mechanism for
all FANUC off-line products.
Another project I worked on was FANUC's stand-alone vision
processor. This device was PC based and used cameras to locate
objects to be manipulated by one or more robots. To integrate this
device to the robot, a mechanism was needed to allow the displaying
of images on the teach pendant. The pendant was essentially a web
browser. I created an HTTP web server ActiveX control based on a
simple HTTP server example. The code was significantly modified to
implement CGI and SSI capability, and to give it an ActiveX
interface. The vision processor, written in Visual Basic, would
serve web pages as its user interface and provide dynamic content
including images.
960 Oxford Rd. Phone 248-***-****
Berkley, MI murrellr@ameritech.n
48072 et
Robert A. Murrell
Resume Build Administrator Experience
Supplement
Since 2001, I had been the build administrator for all software
products at my previous employer. The system software was built on
a Sun SPARC server running Solaris OS-5. Source code was managed by
IBM Rational Clearcase and was built using its Make utility.
However, the overall order of the build and the staging and
assembling of the final product was accomplished through PERL and
BASH scripts. At the time I took over this responsibility, the
process was poorly documented and the tools consisted of many small
scripts that had to be executed in the proper order with specific
arguments. We were maintaining 11 active versions of the software,
and the process took much manual intervention and was very error
prone. Initially, it took 100% of my time to build the products and
the release of a product took as long as two weeks.
After thoroughly documenting the process I analyzed the process to
determine where the errors were being made. I established common
naming conventions for all aspects of the build (file and directory
names, Clearcase label, branch, and view names, etc), and wrote
several supervisory PERL scripts to run the lower level scripts in
the proper order with the correct arguments. This has allowed the
building and releasing of several versions simultaneously and yet
reduced the amount of my time dedicated to building software to less
than 50%.
The basic build scripts were written in the mid-1990s after a mass
conversion from DEC VAX based build. Although the actual build was
performed using standard UNIX software development tools, PERL
scripts were used to preprocess the file lists to create the
makefiles used to build the modules. A single large PERL script was
created to control the order of the build, which took 12 hours to
run. The process of applying post-build changes involved many
specialized PERL scripts that were very sensitive to the content of
the arguments and had to be executed in the proper order. This led
to a lot of errors by the developers running the tools.
All the PERL tools were procedural (not OOP). None of the
third-party build tools, include Clearcase, had PERL CPAN modules
created for them, so the only interface to them was through shelling
the process and capturing the output to determine pass or fail. To
run the low-level scripts, the supervisory scripts had to be
intelligent, "mining" the information needed to build the correct
command line arguments from various non-database sources (directory
names, file contents, documents, logs, program status, etc.) These
scripts did a lot of string manipulations using regular expressions
to glean the data from the sources.
To build the supporting off-line Microsoft Windows products, I wrote
PC PERL scripts controlled by the UNIX scripts to simultaneously
build these products with the system software. Microsoft
Development Studio, Visual Basic, and other third-party tools were
run from a command line, shelled from the PERL scripts like the UNIX
scripts. Since the steps for building the PC products were well
defined and common to all, the scripts parsed a text data file
listing the modules to build and then performed the proper steps in
the correct order. This made it easy for developers to add new
products with minimal interaction with the build process.
To ease the use of these scripts by the developers, I had an Apache
web server installed on the build computer. I created graphical
interfaces to these tools using Javascript, CGI (Common Gateway
Interface), and SSI (Server-Side Includes) to deliver dynamic
content to the web forms. SSI was the predecessor to PHP and ASP.
These scripts were used to retrieve dynamic content to the web
forms, like dropdown lists. The Javascript was used to manipulate
and validate the operator input. The CGI scripts were used to
process the forms and perform the requested task. The CGI and SSI
scripts were executed using the Apache interfaces.
Our ISO-9000 process generated hundreds of files for each release.
These files were put into Clearcase, but an indexing and
cross-referencing mechanism was ever put into place. I was often
called upon to write specialize PERL scripts to mine specific
information from these many files and assemble it into Microsoft
Excel spreadsheets to be used by management.
Contact this candidate