A Message to Readers

November 9, 2011

It has truly amazed me that a few of you continue to come here to this very nearly dead blog in the many months since I last posted anything new. I am both surprised and perplexed by this. What is it that you are finding that keeps bringing you back? If there is something here that you find useful, please leave me some comments, and perhaps I can expand on that material.

In particular, I would like to hear from you, telling me who you are (not necessarily a personal name, but at least a screen name other than anonymous), what your station in life is, what you do, and where you live (at least which country). This will give us a small basis for conversation, and I will try to post more things of interest to you.

I sincerely hope to hear from each of you.

Old Engineer

Accelerated Systems: The Deck Plate

February 20, 2010

DeckPlate3

One of the interesting problems in dynamics of machines occurs when the appropriate coordinate system for describing the problem happens to moving, and not just moving but accelerating. This means that Newton’s Laws do not apply in that coordinate system, so suddenly things get complicated. That does not remove the need for answers, however.

One example of a moving coordinate system is such a system attached to a naval ship. Ships are often very large, but they are still subject to considerable accelerations due to the actions of winds and waves. Thus if we want to talk about the motion of shipboard equipment, we really need to consider this to be a situation of motion in an accelerated coordinate system.

The problem described in the attached PDF file falls into this category. It is one that came up some years ago, and I happened upon it in going through some old files a day or two ago. I thought I would share it with you.

I would like to invite those of you who are lurking out there to step forth out of the shadows and make a comment. I know that there is a modest group of you out there, but you are all very, very silent. I’d like to hear from you and get your feedback. Please feel free to leave a comment or ask a question on any of the posts.

Update  1: Well, wouldn’t you know it. I found an error in that write-up after I posted it. It will take a day or two to fix, but it will be back up shortly. Stay tuned!

Update  2: Now it is fixed and back up. It was a bigger problem than I realized at first, but it certainly needed to be fixed.

The Frahm Vibration Absorber

February 19, 2010

BELVibAbs2

When we think about means to reduce vibration, we most often think in terms of vibration dampers, devices that convert vibratory energy into heat and thus reduce the vibrational motion. Fluid dampers, using various fluids, have been constructed for many applications, and while they work quite well, it is often necessary to provide for the removal of the heat generated in them.

There is an alternative to dampers, a different class of devices known as absorbers. The idea of an absorber is to briefly absorb the vibrational energy, and then to feed it back to the system but out of phase in such a way as to cancel the motion. Thus the absorber itself is often subject to large motions as it is absorbing, and then reinjecting energy into the system.

The name commonly associated with absorber systems if that of Frahm, a German. For an application of a Frahm absorber in an actual industrial situation, see the attached PDF file.

Force Analysis, Pt 2 — Trammel Mechanism

February 5, 2010

Force Analysis Pt 2

In this post, we consider the detailed application of the principles set out in Part 1 to the analysis of dynamic forces in a Trammel mechanism. The trammel is a very simple machine which has the benefit that the kinematic analysis is uncomplicated, but at the same time, it requires all of the steps discussed in the introductory post.

Not surprisingly, the trammel mechanism motion is governed by a highly nonlinear differential equation, and the prediction of accurate forces requires that this differential equation be solved to accurately describe the motion as an input to the force calculation. The differential equation of motion, giving the angular acceleration of the system without reference to all of the internal forces, is available from Eksergian’s equation of motion. It can be solved numerically by means of the Runge–Kutta algorithm to produce the system motion for any prescribed starting conditions.

With the system motion known, in particular, with the angular velocity known at each value of time and angle, then the force solution can be made as described in Part 1. For the details, see the full article in PDF at the link above.

Force Analysis in Machines

February 1, 2010

Force Analysis Pt 1

In the design of a machine, some of the dimensions are easily determined by the geometric requirements of the task to be performed. The parts must be large enough to reach from point to point, they must be long enough to reach the required locations, and similar geometric considerations. But there is the ever present question as to how thick the members must be in order to carry the required loads, and this is a question for which there is no a priori answer. The answer is always, big enough, but how big is that? The only way to determine what is big enough is to determine what the loads (forces) are. As well as sizing the members themselves, there is the related matter of sizing the bearings of the machine.

In a static structure, the determination of the loads is simply a matter of a static force analysis. With a machine, where things move and the configuration of the components changes as the machine moves through a cycle, there are two complicating factors involved in the force analysis:

(1) the changing geometry means that the forces must be analyzed as functions of position;

(2) the inertial effects of the machine components enter into the dynamics of the system, affecting the force analysis.

Item (1) implies that the forces must typically analyzed at many different positions, with the understanding that they are expected to vary continuously between positions. Item (2) means that Newton’s Second Law, rather than the equations of statics govern the force relations. It also implies that a kinematic analysis through the accelerations will have to precede the force analysis in order to express the accelerations for the various components.

With very few exceptions, the typical machine is a single degree of freedom device. For that reason, the discussion to follow is limited to SDOF machines

Go to the link at the top for the complete article in PDF format.

Successs — In Spite of Everything!

January 26, 2010

In my previous posts, I have commented about the difficulty I was having with a “simple” problem and also an apparent glitch in Maple. The Maple glitch developed in my efforts to solve the “simple” problem, and they were never entirely resolved.

The Maple glitch involved variables that changed values for no reason in passing from one point in the code to a later point. I found a work-around by simply saving those values under different names, which survived unchanged even when the original variables underwent the unexpected change. With the saved values, I was able to complete the calculation successfully.  I am still puzzled about what went wrong with Maple, and I will have to “keep an eye on it” in the future.

The simple problem was indeed a simple problem, but I had managed to consistently make the same mistake for a full year (working on it off and on). It was just a Newtonian mechanics problem, but I managed to confuse the choice of signs for one of the coordinates and the way that related to the angular acceleration of a body. It is clear that I’m getting old!

In my defense, I can say, however, that I was unable to find a problem of quite this type worked as an example problem in any of the many text books that I have. I did find some that were similar, and those helped me to eventually find my error, but the actual problem I was working seems to be one that most authors have avoided. I hope to put it together as a blog post in the near future. Then readers can all say, “Oh, that is simple.” And it is, when you do it correctly.

A Glitch In Maple??

January 19, 2010

The Maple software is a well known mathematical software for both symbolic and numerical analysis. It is remarkably powerful, and is used by many people in many scientific and engineering fields. I have personally used it for about four years, and I have gotten alot of mileage out of it.

One of the things that I particularly like about it is the Fortran-like interface. While that may not appeal to many, since I began programming in Fortran back in the mid-1960s, this is very familiar to me and I find it quite comfortable and intuitive. It is rather like BASIC in that every result is printed, provided it is followed by a semicolon. Results followed by a (full) colon are not printed. Simply writing the name of a variable followed by a semicolon causes the value of that variable to be printed.

In a problem that I have been working, a part of the code and results are as follows below:

>kxc; Lxc; kyc; Lyc;
4.64764680879144297165622014511
-3.64340265491984652886473639967
2.80353921353886905817890988682
1.06540402044270413175134636777

> dx:=dth*kx;  ddx:=ddth*kx+dth^2*Lx;
dx := 96.9577516413419965354736543154
ddx := -4722.67120380085275417308249755

> kxc; Lxc;  kyc;  Lyc;  # the change in value of these quantities from just above is BAD NEWS!!!  ######################
49.8162097285017225372068589679
22.4346793056834320558007792067
10.4384198398520390765088259746
-8.12842535363665044750337341474

The part in regular type following the > is the input statement; the part in italics is the result of executing that input statement. Anything written after a # is simply a remark, such as the remark, “the change in value … #####”.

The values of kxc, Lxc, kyc, and Lyc were generated much earlier in the program (ahead of this point). When the calculation of  dx and ddx produced values wildly different from what was expected, the extra ouput statements were added to check the values of kxc, Lxc, kyc, and Lyc immediately before and after the calculation of dx and ddx.

This code has been run under both Maple 8 and Maple 10 with exactly the same results. To say that it is puzzling is more than an understatement. It really shakes my confidence in this program which I have come to trust so very well. If any reader has any thoughts on this matter, please comment on it.

Business Relations

January 13, 2010

The world of business has gotten more complicated. That will come as no surprise to anyone who works for a living, but the days of simple, honest, one-to-one dealing seem to be long gone. I got caught in this recently in an uncomfortable way.

At the end of this past summer, I received an e-mail from a former student, asking if I might be available to help his company with an engineering problem. He described the problem, and as described, it sounded like it was rather on the edge of my knowledge. I replied that this was not really my best area, but I thought I might be able to help with certain aspects of the problem which I outlined. They asked me to work on the problem, and I began work right away as soon as they sent me drawing of the equipment involved.

I worked on this problem quite a bit through the fall, and at one point I made a cross country trip to the factory to see the problem first hand. The factory visit confirmed some of the things I was beginning to suspect about the nature of the problem. About the first of November, I wrote them a third, and what I assumed was probably a final report, outlining my conclusions and recommending some possible approaches to fixing the problem. And then I waited. When I heard nothing from them by mid-December, I sent them an invoice for my services.

Then I got from them a request for additional information, such as Tax ID number, business location, etc., which did not surprise me. But the bombshell was their request for copies of my insurance. When I ask “what insurance” they gave me a form letter they had sent to all of their suppliers (except me) back in October asking for evidence of all sorts of high dollar insurance of various and sundry sorts. I just gasped! I reminded them that I am simply a retired engineer, an individual, not a corporation, and I cannot afford to get such expensive insurance. If I had known about this up front, we would have never begun this work. Further, to impose this “after the fact” is simply wrong.

Eventually they came around, but they explained that it was one of their “new business policies.” I had to explain to them that “one size fits all” generally means a poor fit, and would preclude any future work. What a poor way to deal with people! I will get paid, in about another three weeks.

Frustration!!

January 11, 2010

Do you ever work on a problem that you know ought to be simple,  ought to have a straight forward answer, and yet it just does not seem to work out? That is where I am right now.

For about a year, off and on, I have been working on a particular mechanics problem, not a particularly esoteric problem at all, that I should be able to work in a matter of a few hours and that would be the end of it. It is the sort of problem that an undergraduate ME should be able to put together and have a satisfactory solution in perhaps a couple of days. So what is the great difficulty?

Well, I am insisting on checking it, and that is where the rub comes. I can get numbers without too much difficulty. It is just a matter of solving Newton’s Second Law equations for a system of three bodies simultaneously, a problem that produces a system of seven linear equations in this case. The unknowns are six internal forces and the system acceleration. With the computer, this is all pretty straight forward, and crunching the numbers is not that big a problem. My program runs in much less than a second, so time is not a problem. There are some kinematic calculations to be done before the force solution is made which makes the use of the computer very advantageous, but the calculations fairly fly. I have it programed both in Maple 8 and also in BASIC and I get the same results in both.

But then there is that matter of checking it. Newton’s Second Law is pretty nearly infallible for mechanical systems, but the person applying it is not. So it is important to check the result. I can substitute the solutions back into the expressions for Newton’s Second Law, and they are satisfied, but all that says is that I got a good numerical solution. It does not say that I applied Newton’s Second Law correctly. What else can I do?

One of the happy alternatives to Newton’s Second Law for dyanical systems is the Lagrange Equation of motion, an energy based approach to determining the motion of a dynamic system. In many cases, it is significantly easier to apply than Newton’s Second Law and less prone to errors. Generally speaking, all that is required is to write the system kinetic coenergy, take a few derivatives, write the virtual work of the external forces, and viola’, the equation of motion appears! From this expression, the system acceleration is quickly solved and this provides a check on the Newton’s Law formulation.

Except when it does not! In the problem at hand, for a year or so, I have not been able to reconcile these two. I know that I am getting good numerical solutions to the Newton’s Law equations, so that is not the problem. In some cases, the accelerations determined by the two approaches are fairly close to each other; in other cases, they are significantly different.

This is truly a “head-banging” situation. I trust both of these approaches, and when they are in disagreement, it means one of them must be incorrect (it really means that I have incorrectly applied one of them). It looks like it is time to lay this problem aside again for a few weeks and hope for new inspiration. What to do?

New Book Almost Ready

November 26, 2009

Posting has been light to nonexistent recently because I have been working intently on trying to finish up a new book on the application of Hamilton’s Principle to engineering problems. This is a subject that has been dear to my heart for many years, and one that I have found to be of real practical importance in engineering practice. It is also a topic that is not in the tool bag of very many engineers, largely because of the mathematics required. I’ve had it in mind for years to try to do something about this, and now it is just about done.

I started some months ago pulling together materials that I had written over the years to try to make a coherent picture. Of course, in the process of doing something like that, you always find that there are missing pieces, parts that never got written previously. So it becomes necessary to

(1) write the missing pieces;

(2) smooth and blend the existing pieces into a style to make a coherent whole.

This has taken a number of months to do, but the process was well along, to the point where I was proof reading a draft in September when a consulting opportunity came up. Consulting opportunities tend to take precidence, so the book was put aside for a while, until the consulting work reached a lull where it sits right now (I’m not sure if we are finished, or if they are still just digesting my last report). In any event, I have finished up the proof reading, made the pdf file, and shipped it off to the print-on-demand publisher Lulu.

When the first copy comes back from Lulu in a few days, we will have to see how it looks. There is a nasty tendency for all sorts of errors to be vividly evident in a published copy that could never be seen in even a printed copy, so that is what the first published copy is for. After I get a published copy without errors (at least without errors that I find), then I will release the book to the market place to sell. Then we will find out if there are other people who think Hamilton’s Principle is as interesting as I do, or not.


Follow

Get every new post delivered to your Inbox.