Creating Engineering Software Applications On The Fly

 
Abstract
 
Rick Lukanen is a Senior Product Engineering Analyst at Douglas Machine, Inc., Alexandria, MN, USA. Rick has 18 years of experience in software development and numerical analysis used in engineering. Douglas makes high speed packaging machinery, most of which is custom designed for just about every major national and international brand you come across as you walk through a grocery store.
 
 
Richard W. Lukanen, Jr.  
Senior Product Engineering Analyst  
Douglas Machine Incorporated  

Rick first came across TK Solver in October 2003. Within a very short time he learned how to program in TK. His company has since developed a number of TK Solver models (programs) and has realized significant savings in engineering design time. They have also implemented some design improvements that, in Rick's words, would have been unthinkable without a tool such as TK Solver. Douglas Machine continues to substantially increase the use of TK Solver in a wide variety of engineering requirements. Rick says that, "after 18 years, I am finally seeing the light at the end of the tunnel."

The following is a first-person account -- told in Rick's own words--of how he came across TK Solver and how its use at Douglas Machine is now spreading.

 
My intention in this paper is to share a story of discovery with you. It was about one year ago when I uncovered an analysis system that is so unique, so powerful, that it allows our engineers to be creative with designs in ways that others could only dream about. If I told you that I solve problems by entering equations in any order and form, and that the computer works out the details of solving problems for me, what would you say? How about the ability to reduce a BASIC program from hundreds of lines down to only a dozen? Does any of this sound good? If I tell you that you can realize a 33 times increase in productivity, would you believe me? If this all sounds too much to believe, then you better read on.
 
I will start this story back some fifteen months from today. The date was October 15, 2003. This is approximately when I realized there was a better way to solve problems. From that point forward I have been more productive then any point in my eighteen-year career. It’s a story of how I came to a new understanding of what it means to be productive. It is also a story of how I learned to eliminate or reduce common programming paradigms afflicting nearly every program written today.
 
I hope to inspire you to shed your drudgery of numerical analysis methods that are based on imperative languages such as Mathcad, BASIC, C, Mathematica, or even Excel. These languages will never be good enough to solve real problems as they occur on the fly. To solve problems on the fly you must learn about declarative rule-based programming. Forget everything you know about problem solving for a moment -- let me take you on this journey now so you can see it unfold as I did over eighteen years’ time.
 
An introduction to the type of industry I am in is probably required to set the stage for this story to be meaningful to you. Since 1966, Douglas Machine Inc. has been a recognized innovation leader in paperboard, corrugated and shrink-film packaging equipment solutions. Over the years we have focused on cartoning, case/tray packing and shrink-wrapping equipment, and have achieved global recognition for our unique capabilities. An example of an application would be a machine that places products such as soda bottles into a corrugated tray and applies a film wrap over it. Our customers package items such as food, beverage, and personal care products. We have thousands of machines installed in more than 30 countries.
 
Some of the products we produce are:

High speed continuous motion case and tray packers
Intermittent motion case tray packers
Shrink Packers
Multiwrappers
ShrinkWrappers
Cartoners
Multipackers
Sleevers
Case opening/bottom sealing/top sealers
Tray Formers
Returnable case handling machinery

 
Douglas Machines in Action
 
 
 
 
These machines are expected to run 24/7 with an efficiency of no less then 98% uptime. Manufacturers of automated packaging equipment are expected to design high-speed machinery. A customer with just a few high-speed machines may need the capacity to run the entire production for North America. Optimizing the dollars of profits per square foot of floor space is a primary objective of our customers; it’s no wonder that machine uptime and speed are paramount to getting the next machine order.
 
Engineering high-speed machinery means that motion analysis plays an important role in our success. Each machine is a custom design, so we are solving problems every day that stretch our skills. Many are one of a kind and may never be repeated. One off designs often occur when packaging consumer goods such as shampoo bottles; they tend to be odd shapes. Some machines are more standardized and really are ready for mass customization. A good analysis group can ensure successful and profitable completion of machine designs and ensure repeat orders.
 
Now that you have had brief introduction to the packaging machine design industry I will begin my story. It’s now February 3, 2002, and I have just taken re-employment with Douglas Machine after spending some time in the failing electronics industry. I find myself here after 10 years of being away from the company where I started my engineering career some 16 years earlier. I was hired to develop and lead an analysis group that supports 70 machine designers. My first priority was to develop analysis tools used to design servo controlled case packers. This is something I was very accustomed to. These third generation servo controlled machines would lead to the replacement of the mechanical cam technology that has been the mainstay at Douglas for nearly 40 years. To begin this task I had to gather a few analysis tools and start working as quickly as possible, since machines were already sold and deadlines were quickly approaching.
 
Any time you begin with a clean slate it’s a moment to do a reality check. I decided to look at what tools Douglas Machine had been using for the 10 years since I was last here. I found the typical software: Visual Basic, Excel, and free configuration software given out by manufactures of machine components. A Douglas engineer, now working in my department, had done an exceptional job in creating a few analysis tools with Visual Basic prior to my arrival. He had clearly researched the needs of the many in developing his programs, but as always there are limitations to what you can program and how long you have to develop it.
 
Though they are highly popular, I had some concerns about such tools as Visual Basic or Excel. They inherently bring huge amounts of overhead in development time. Excel, in particular, has another problem; it hides your work in little bits all over the screen, making it difficult to do engineering. An artist would never paint in the dark; I was not about to engineer without seeing equations. I began the task with PowerBasic Console Compiler. I chose it because it is like old DOS programming. It was extremely cheap and it’s fast. I really didn’t need to deal with today’s glitz and glamour of GUI controls gone wild. I also knew that nearly every programming language today is based loosely on some dialect of BASIC, so I could likely reuse what I develop. I was holding off purchasing any analysis tools until I had a plan that would satisfy our requirements.
 
Beginning a new line of equipment such as the servo case packer designs would be a lot of work for any company. These machines would have an average of 24 axes of motion and each axis would need to be engineered. For each machine that crossed our desks we would need to calculate the inertia of mechanisms to be moved and to design a drive for it based upon complex motion analysis. This would require us to write an all-inclusive timing library--but we didn’t have time for that.
 
I decided to write code that would be capable of solving only the motions required. I would use text files for inputs and outputs. The programs would need to study the motion and the strength of the drive train, and of course to select the servo drives and motors. These programs would be run over and over until acceptable results were produced. Often you would play the game of “well, three didn’t work – maybe I will try five for the gearbox ratio and see what the results are”. When a design was found we would need to make a CAD drawing to document the results. The drawing showed the particulars of the drive but we also entered the results of the analysis into the drawing by hand. Tables of motion data pertaining to the servo were also included in the drawing. This job was tedious because often when you are just about done the specifications of the machine change and you have to do it all over again.
 
I knew this system was not good, but it had to suffice for now. The trouble was that even if the process of creating CAD drawings was easier, we still would not have the ability to reverse-engineer what we wanted. I really wanted to start specifying numbers in the results file and see what the input file should be. I wanted to, at any time and without rewriting a single line of code, solve for some other variable that suddenly seems to be a concern in a machine design. This is not a possible right? Mathcad, Mathematica and Excel users would agree with that. Well, it is possible; I just didn’t know that yet.
 
After about six months’ time I had written about six thousand lines in BASIC that we were using for the majority of our analysis needs. At this point I had familiar concerns that cross every programmer’s mind. First, “who besides myself is ever going to be able to use this stuff?” Even worse was, “Boy, I don’t want to be the only one capable of doing this work and get stuck with it forever”. Equally bad was: “How would anyone, or even I for that matter, support this code in the future?” I needed to find a better way to do programming that simplifies the code. Doing this work in Excel was not the answer either; it just hides all the code, making you feel better – for a while anyway.
 
Each day brought more totally new designs across our desks and the need for more programs. Some machines resembled the ones that we had seen a few days before, but as always we required a new program that addressed the slight variations in concepts. There are also customer specs that introduce a challenge to the mass customization issues. Don’t forget the problems of physical space constraints in machine size. This introduces the need for optimization: not everyone can accept machines of a standard size. Designers are given what seems to always be an inadequate number of hours to design machines. They are always trying to reuse work they did in the past. More often then not this makes the analysis a complex affair that must be solved on the fly each time.
 
Looking for a better way to do my work, I searched the Internet looking at Mathematica, MatLab, Maple, FORTRAN 95 and Mathcad, and I read everything I could find about these tools. Not one of these had the ability to really solve problems the way I WANTED TO. They all required an algorithm that I had to strategize and specify exactly every step on how to solve a problem.
 
I recalled that there was a product called TK Solver that might do the job. I found it on the net and ordered a demo. It arrived in the mail and just a few days later I was presented with a problem that needed to be solved immediately.
 
A machine on the shop floor was nearing completion. During tests we found that a cam had excessive jerk, so we had to design a new cam. I could try pounding it out in Power Basic CC or just go for it in TK. I decided to use TK. I would have to learn to use TK Solver while I engineered the cam design. The schedule would only allow for two days of engineering time because the customer acceptance tests were the following week.
 
The series of events that followed would change the way I performed analysis from that point forward; I suddenly realized the power of declarative programming.
 
The problem required me to blend a cam using half cycle cycloid, half cycle harmonics, and constant velocity segments in a way that reduced the jerk by a factor of three. The blending requires a number of difficult differential boundary value problems to be solved. I have done this many times in the past; each time I needed to derive the equations for the specific case I was working on. Every cam-blending problem is unique, so writing programs to solve these problems is just not possible.
 
I began solving the problem in TK Solver by placing equations on its Rule Sheet. The equations I placed there were not derivations of what I wanted to solve for. These were the equations I would start with in solving the problem myself in longhand or with Mathematica. I was able to place a few systems of equations on the Rule Sheet and hit solve, and to my amazement the problem was solved. The declarative rule-based solving engine in TK solved the problem for me and I never described the specific steps required to solve it. All I did was specify the rules and assign some values to variables. TK Solver solved the problem on its own. I then iterated the design over several degrees, producing graphs of my work. This was accomplished without writing For/Next loops so common in other programming languages.
 
Within two days I was able to learn TK Solver and solve my problem on the fly. I had the freedom to try many design options, and I did not have to develop a new algorithm each time. I also created a report of the analysis, the quality of which would not have been possible prior to using TK Solver. Most important: the cam I designed was manufactured and worked perfectly and we met the production schedule.
 
To summarize, I was able to install TK Solver, familiarize myself with its unique rule-based approach, and solve the problem in two days. About a week later, the same calculations were required for a different machine. I was again under the gun to solve the problem as fast as possible; however, the 10-day trial license for TK Solver had expired. I did it the OLD way by deriving the equations and programming in BASIC. This time, it took eight days.
 
The inherent ability of TK Solver to solve for anything, in any direction, is what sets it apart from traditional analysis methods. TK Solver applies rules rather than an algorithm for solving problems. So time typically spent deriving the equations to solve a problem is totally eliminated.
 
The cam problems started the ball in motion for me – I was convinced that declarative programming is clearly the only effective means to solve problems on the fly. I immediately began to develop a plan to implement the new approach. I had to be certain I could create enterprise-level software without the need to reinvent the wheel. This occurs when you try to develop an Excel or Visual Basic program that exactly mimics what already has been accomplished in Mathematica, Mathcad, etc. If you have to do any translation of work to a new syntax, or if you lose any functionality, this would be an issue for my plans.
 
Satisfied with TK’s ability to use Microsoft’s COM (Component Object Model) and OLE, technologies, I realized I could call a proven TK model from Visual Basic, or even Excel. Hey--problem solved! No more reinvention of the wheel ever again! Now even these imperative languages can contain knowledge management technologies that are based entirely on the ability of TK to solve problems without an algorithm. With light shining bright at the end of this eighteen-year battle I wrote a proposal describing a new analysis approach, department goals, and required software.
 
My recommendation to management was to use TK solver in two distinct ways. The first was to use TK as a firefighter’s tool – to perform on-the-fly analysis with designers nipping at my heels directing my every action. The second was to call my TK Solver models from Visual Basic or Excel in order to create enterprise knowledge management solutions. These solutions would be accessed via our intranet. Knowledge management occurs when the programming language works from rules, leaving the interpretation of how to solve the problem to the computer. The implications of such an approach are HUGE. It is a system that can “serve up” more subject matter experts with a minimum of training costs. It’s a system that solves problems rather than simply replaying code that is stuck in some paradigm. It’s a way to greatly reduce the engineering time and costs for custom engineered equipment. Declarative programming simply does it! Our cost for buying the fist copy of TK Solver license would be a very affordable sum of $600.
 
Here is an excerpt from my software proposal:
 
The analysis requirements at Douglas Machine can be broken down into the following analysis methods: symbolic computations, numerical methods/modeling, and solid model (FEA and kinematics) analysis. Each of these analysis methods is best served by software that is designed for those specific tasks. The intent of this paper is twofold: (1) propose an analysis style for the department, and (2) propose what development and analysis software would likely be required to make every aspect of the plan a success.
 
Selecting software appropriate for an analysis job is the first consideration you must make to ensure a quick and accurate solution is found. There are varying amounts of investment in time required to use a particular software package. Some software packages require a rigorous development for their interface design; thus, investment of time is considerable. For example, PowerBasic Console Compiler (PBCC) has no interface design requirements; thus, developing engineering software libraries or code that will be used infrequently is preformed more expeditiously in PB than VB. PBCC code is intended primarily for use by the subject matter experts, while a properly developed VB application with a good Graphical User Interface (GUI) is essential for developing knowledge based computing programs. I have tried to create a mix of analysis and programming tools that offers both rapid development times and the power to develop modern programs using OLE, ActiveX technology, and standard Windows development tools.
 
The analysis department at Douglas has a number of basic responsibilities I will strive to satisfy. Briefly, these responsibilities are:

Respond quickly to machine designers’ needs and produce results on time.
Provide accurate and cost-effective solutions.
Develop and maintain databases of materials and machine components that will keep analysis results   consistent.
Produce results that follow Douglas standards.
Develop software for the analysis group.
Deploy knowledge based engineering and sales software on the Douglas Intranet.

 
Documentation of programs deployed on the intranet will be important in order to preserve that investment for the future. All programs that are to be deployed via the Douglas Intranet will have online user manuals incorporating hot links to the application software. Detailed documentation will be required to describe the inner working of the programs. I feel that it is also the responsibility of the analysis group to know that appropriate programming methods are being deployed and that robust numerical methods are used. This should all be possible with the plan that I am about to describe.
 
I created a software tree to describe the analysis development cycle – this is really my proposed analysis style. At the base is PBCC, the lowest technology development tool. At the top are the highest technology development tools – these are the Web enabled knowledge based programs.
 
 
A program called Galaxy is missing from the top tier of this software tree. It can build Web-enabled applications via templates and wizards so no programming is necessary. This was an oversight on my part when this tree was created. As of today we have not tried Galaxy; we are using Component Object Model technology to make our customized interfaces with TK. In the near future I expect to try Galaxy.
 
RuleMaster is a DLL that contains TK Solver’s declarative engine. It gives you a second way to incorporate declarative programming into Visual Basic, C++, and many other languages or applications. With RuleMaster you don’t need to start with an existing TK model. Think of RuleMaster as a function. RuleMaster accepts rules and inputs, and then returns values for unknowns.
 
A success story
 
Using TK Solver’s declarative programming with an optimization wizard has produced astonishing results for me. A “technical timeout” may be appropriate before I tell this story.
 
What does the combination of declarative programming and optimization do for you? With imperative languages (BASIC, FORTRAN, Mathcad, etc.) you have to provide instructions in code (an algorithm) to solve a problem (the one(s) you want to solve). With declarative programming, the computer all on its own solves every possible problem described by your rules (a solution space). So optimization with imperative programming yields the best of what the programmer(s) could conceive, where optimization in declarative programming yields the best results in a solution space – something so complicated programmers maybe couldn’t write an algorithm to describe.
 
Designing guard door lift mechanisms can become a major problem when the lift strut must fit into the smallest of imaginable spaces. This is a story of just this problem. It’s a common practice to release prints to fabrication in groups of hundreds rather then the entire print package. It is also very common for the customer to request changes in the design after we have started fabrication. This scenario occurred recently and the result was a guard lift strut design that would not work. On-the-fly analysis was initiated to dodge what would a very unfortunate amount of rework, lost profits, and not to mention, a customer that would need to change his future projected production capacities.
 
Rules were developed that describe the lift strut’s linkage, the compression spring design, and constraints for each component as well as the strut itself. This is all quite confidential so I will not go into great detail, but it would make the lift strut by optimization of the spring design, linkages, and size/orientation. Optimizations of three complex systems concurrently are not trivial problems. I recall saying to myself, “I can’t solve this problem; it’s just too complex”. Working on it for only three days I solved the most complex problem of my life. It was shockingly simple. If I had used an imperative language, I believe it would not have been possible – we would have had to scrap or rework portions of the machine and inform the customer that we would not be able to deliver the machine on time.
 
The custom spring strut was manufactured and it proved to work so well it is now our standard due to its compact size. This design is not only small; we believe it to be impossible to make it smaller.
 
Important engineering milestones we have accomplished in 12 months
 
Motion Library – These thirty-two user functions are used in any program that requires analysis of mechanical or virtual cam motions. It forms the foundation of all our work. This library is absolutely unique in that it allows our analysis engineers to solve transcendental equations as systems via declarative programming. The total time to complete the library and test each routine was about one month.
 
Cam Analysis Program - Designs cams with advanced proprietary information pertaining to linkage phases. Program produces DXF CAD drawings, PDF reports, and CNC data files. Has enhanced our ability to design and manufacture specialty high-speed cams resulting in increases in machine speed and efficiencies.
 
Servo Linear Actuator - Using the motion library this model solves all linear actuator servo problems. This work has decreased our actuator design times from what were typically two to three days to just a couple of hours. Quality of designs has increased due to motion library developments and knowledge management techniques that describe the design in terms of a solution space rather than a solution method. We can now specify desired output and obtain an unknown design parameter.
 
Contour Analysis Models – This is a collection of TK Solver models that has been produced entirely on the fly during the design of this new line of machines. Refinements to the models over the last six months have resulted in simplification of machine design and a higher quality machine for our customers. The models also have greatly increased our ability to understand our current capabilities.
 
Component Databases – This is a Microsoft Access database that contains information on each component in our servo designs. These databases are read into our TK servo design models to ensure the servos are sized correctly and the electro-mechanical components properly fit together.
 
Programming - Eliminated all Excel and BASIC programming. Excel’s VBA language and Visual Basic .NET will now only be used as an interface device to our solution engines developed in TK Solver.
 
Added one more analysis engineer, bringing the total number of employees doing analysis full time to three.
 
Departmental successes realized
 
The analysis plan put into motion October 15, 2003 has proven to reduce costs and lead times. When creating enterprise software it has ended the reinvention of the software wheel, resulting in both time savings and condensing of our knowledge into one system.
 
Six months ago every tray and film machine required investigation by the analysis group. Newly developed TK models now enable project engineers the able to identify which machines require specialized analysis. This change results in a more effective project planning right from the start.
 
Using OLE into Visio, we have virtually eliminated the manual creation of documentation for servo designs. The TK model’s graphs, tables and calculations are automatically updated and linked to drawings every time we solve a model. Changes are made in seconds rather than hours.
 
The analysis of indexing machinery infeeds has always been the most challenging. Now with the linear actuator model it has become the easiest. This one change has reduced days of work to hours and significantly increased quality. We now routinely find the best design, rather than an acceptable one.
 
The analysis database of components has grown steadily over the last eighteen months. The result of this work is that designers have a much greater understanding of our design goals, they find design solutions much quicker, and servo drive solutions now use a few highly standardized components. This helps Douglas, and our customers, by reducing the number of parts we have to stock.
 
The reinvention of the software wheel has been stopped – we make machines, not software.
 
Where do we go from here?
 
We are currently developing enterprise solutions made from TK Solver models. We have shown a minimum of programming is required to take existing TK models and control them via Excel and/or VB.NET. This means a new custom interface can be developed that better suits our design engineer’s tastes. The enterprise solutions we create will have the same declarative rule solving abilities found in TK.
 
The implementation of SQL programming is being worked on. This will allow designers to have access to our current component standards. This in turn should reduce costly specification of non-standard parts. SQL will also ensure that components selected will properly match one another.
 
I would like to switch from Microsoft Access to Microsoft SQL Server to ensure we don’t have database “meltdown”. Microsoft SQL Server will allow many people to use the databases simultaneously. This is a change that the IS department can help with. I would like to see the changes beginning some time in May of 2005.
 
By the second quarter of 2005 we should start to see engineering that uses the enterprise solutions. We have created many models and it is not difficult to create interfaces for them, so I am confident this will happen. Our sales people could also use some of these tools.
 
Closing Comments
 
I hope that the story strikes some level of curiosity about declarative programming. I have demonstrated how declarative software is used to create engineering software applications on the fly without the need to specify complex algorithms. I feel that the design of custom automated packaging equipment should be a conclusive test. Douglas Machine’s volume of custom machine orders is likely only matched by a few hundred companies in the world.
 
TK Solver has been produced now for about twenty years by Universal Technical Systems, located in Rockford, IL. It seems that nearly every review I have found mistakenly sees TK as an equation solver rather than the powerful declarative software development tool it has become today. This story is certainly proof of this power.
 
I would like to thank everyone at Universal Technical Systems for all their help in making this very aggressive fast paced plan a success. UTS, has exceeded my expectations in quality of customer support – they have routinely stepped up to the plate offering expert advice – and have demonstrated a willingness to learn the customer’s business.
 
Comments from Managers
 
Engineering Manager - Douglas Machine Incorporated
 
It’s important that we continue to develop our enterprise software for our designers. This reduces hours, improve quality, and minimize risks in designing one up custom designs. On the fly work has been put to the test under the most critical moments with great outcomes.
 
Recently during the final design process a critical component became constrained to a very confined space. It was through the use of optimization that the analysis group solved the problem. Customized components had to be outsourced for manufacture and when they arrived they had to work. The design worked correctly and as a result we did not have to ask the customer for an extension of calendar time, or risk cancellation of the order.