View and Share Any Design File

Instantly view your designs online—no software required

Drag-Drop

View 2D and 3D designs in over 50 file formats including DWG™, DWF™, RVT and IPT, as well as formats from SolidWorks, ProE, Catia and others. View large and complex files right in your browser—no downloads or plug-ins needed.

Interface

You can also invite other people to look at the design with you.

Invite

Give it a Try: LINK

Posted in Autodesk Revit/BIM | Leave a comment

What is Autodesk Dynamo Studio?

The Dynamo team at Autodesk has been cooking up a piece of software based on the core open source Dynamo technology that rolls it together with some closed source Autodesk stuff (Geometry tools, ability to sign in to cloud services, stuff like that), set to officially launch at the AIA convention in Atlanta. For some of you, Dynamo Studio might not change a thing about how you use and interact with Dynamo. We are going to continue building and posting the existing Dynamo for Revit installer on DynamoBIM.org and the whole open source toolkit is going to remain unchanged. We’re going to continue to provide the sandbox/standalone environment that many of you are already using.

Read More Here

Posted in Autodesk Revit/BIM | Leave a comment

The Why is More Important Than the What

I like this article because it goes down the road of what I have always used in my life, Kaizen Event Processes…

As practitioners of problem solving and troubleshooting, we often quickly identify what happened. We know almost immediately what the solution is for the symptoms we see. The fuse is blown. Replace the fuse. The gate is open, the cow got out. Close the gate. Go chase the cow. Insert your own problem and solution.

How far did we take the process? Not far enough. Why? Why Indeed. Why is it not enough to find a problem and fix it? Well, because nothing was done to stop the problem from recurring.

Why must steps be taken to stop problems from recurring? Eliminating recurrences is the essence of continuous improvement. We believe continuous improvement is a good thing. We reduce waste, We move on to new challenges once old challenges are solved. We become more productive, more capable, more predictable. Recurring problems are road blocks to improved productivity.

How do we eliminate recurrences? We must first know why the event happened. The interesting point here is that many of us just accept that the fuse was blown or the cow got out, replace the fuse, or close the gate, and move on. Do we know why these things happened? Do we care? Dare we ask why? How many whys should we ask?

Many of you have heard of the “Five Whys”. The Five Whys is an iterative process used in identifying the cause of problems. It is a tool used in Root Cause Analysis. You ask why did the fuse blow, and the answer is that there was too much circuit current. Then you ask why was there too much circuit current. The answer was that the motor was over loaded. Why was the motor overloaded? The load on the motor was over the motor’s rated capacity. Why was the load over the motor’s capacity? The conveyor was jammed. Why was the conveyor jammed? It had too many potatoes on it. Why did it have too many potatoes on it. And on and on, until the root cause is determined.

In the above example we asked why six times and still did not get to the root cause. Thorough investigation (several more whys were asked) of the above problem uncovered a control system problem that on startup assumes all of the infeed belts are empty, which is not always the case. A change was made to the program that used a weigh scale value and time to determine if a soft start was required. So rather than wearing out motors, motor controls, and conveyor parts, the system soft starts when under load.

Can you substitute “cause” in place of “why”? I don’t think so, and here’s why (there’s that word again). Arrival on a cause assumes that the why is known, when in fact, the why is often not known. The cause was identified so that we could move on. It takes work to ask a lot of whys, (the hard part is getting answers) and let me say that I believe that until the last why is asked, the actual cause or causes will not be known. And when the actual cause is not known, true preventive measures cannot be taken.

My many years of troubleshooting and problem solving boils down to one thing. If I knew why something was happening or had happened, I could find a permanent solution. If something broke, and I simply replaced it, I would expect that I will be replacing it again. I needed to know why it broke. If it was because of misuse by an operator, was the operator the cause? No, because I needed to ask why did the operator misuse the broken part. You should know that the cause is never people, and is always system or process. Keep that in mind so you can avoid “witch hunts” in your “whys” investigations.

So if you really want to know the root cause of a problem, get to the root why of the problem. You cannot improve without the why. Without the why you are stuck in place, repeating the same actions again and again. If you are in auditing, Lean Transformation, troubleshooting, continuous improvement, or helping others solve problems, you must get good at asking why. Your success will be enabled by your ability to get to the root why as you work to get to the root cause.

Asking why is really the easy part. Finding the answers takes great investigative skills and team work. Your answers to whys must be valid. Get good at asking why, getting answers, and validating your answers to every why, and you will discover your team has improved, your productivity has improved, your predictability has improved. You and your team have become more capable.

Original Article

Posted in Architecture, Early Design, Engineering, General | Leave a comment