So, this is how the story goes. Way back in 1998, Unverferth attended our first Autodesk University in Chicago at the McCormick Center. AU started in 1993 and over the years we had heard about AU, but it was never that close to our vicinity, and was not sure what to expect or what we might get out of it. In fact, before AU settled in Vegas for a time, Autodesk had four AU’s throughout the country.
So, we persuaded the powers above to let us to make a four-hour road trip to Chicago. Looking back, from an engineering perspective, that conference took us down a road that we may not have taken. It provided us with insight into the future of CAD and data management, connections to Autodeskers, and more importantly to other users of Autodesk software. It never entered our mind that at some point we would be teaching one session at AU, let alone several over the years.
Anyway, back to the real problem…
At that time, we were pushing the limits of Mechanical Desktop. Our goal was to model complete machines with multiple levels of bill of materials. The ultimate end goal was that we wanted to create what we call today, a "digital twin" of our product. That would include the smallest bolt, to the largest bundles when we ship. We wanted to mimic how our production floor would produce it. MDT was slow and cumbersome and would often crash because it really was just AutoCAD with a parametric modeler built on top of it. AutoCAD was not made for high-end assembly modeling. We could not mimic what we wanted to. We were lucky to model a fifty-piece assembly in MDT, when in reality, we needed to model a few thousand component assemblies. We were in the market for possibly replacing it.
While at AU Chicago, we saw a new prototype 3D modeling software that Autodesk called Rubicon. At that time the market was full of high-dollar 3D modeling software with high-pressure sales. Back then, with those packages you almost had to have a PhD to operate, which was more than what we needed at the time. Most had to have special high-end workstations to run the software and just did not fit our needs or our pocketbook.
We were intrigued so we attempted to make connections and figure out how we might be able to get our hands on the new software. I think it was in 1999, that the software was officially released as Autodesk Inventor, and we grabbed a couple of seats. At R1/R2 time frame it was extremely green and for the most part, worked, but it couldn’t yet provide all our necessities. We saw the future, so we continued to push and make connections with the Inventor product team.
As Inventor matured with R3-R5, we made a push to see if we could implement it. At about the same time, our company was looking for a more diversified product line and since the agriculture industry was going through a recession, our marketing team decided to give our first try at a self-propelled piece of equipment. Their concept project was a skid loader design and would be built from ground zero. The only two things we knew were that we had to model in 3D and Mechanical Desktop was not that tool.
Our investigation of a replacement for MDT had started several years earlier at about the same time when we saw the Rubicon beta at AU. We were investigating other mid-range competitors to MDT as well as some high-end modeling software. Ultimately, we knew we had always had a good relationship with Autodesk, its people, and the CAD software, and there was really only one company that could truly migrate all of our .dwg data, and that was Autodesk. The others say they can read a .dwg, but did they really have all the code to do so? We knew Autodesk could and would. So, we dove into the world of Inventor and performed a proof of concept.
As you can tell, the test was a skid loader design. From the brochure above, 20 years ago, Inventor for only being 3-4 releases, was a robust tool. It didn’t have all the features we have today, but we could accurately model a complex machine that included every nut and bolt, to hydraulic lines, fuel lines, the engine, and provide almost photo-realistic images. Inventor was the future, and we knew that. There’s no way this was even possible from Mechanical Desktop.
We ended up designing and building three prototypes. Inventor had passed the concept test. The product line never did get implemented into production, but we as a company, learned a lot from this design. Once we proved that Inventor was our tool, our next phase was to determine how we might implement Inventor into our entire engineering team and that would include three separate engineering departments at three different facilities.
The closest facility to our corporate headquarters in Kalida, Ohio was 20 miles away, while the other was 500 miles away in Iowa. Even though our servers were connected and kind of acted like one data repository, they were truly separate. File manager was our data management tool of choice and there were a lot of manual manipulation of files and duplicate files. We never knew who had the latest and greatest file. The last one always won, and it wasn’t necessarily the correct one. We moved files around with copy/paste, people would mistakenly delete files, users would get upset after spending weeks on a design while another person was working on the same file and most, if not all, of the effort was lost. It was just not a good situation.
In addition, Inventor didn’t like having files moved around and having the same file in multiple folders. So, the first one Inventor saw, in the folder structure was the file it picked. Which wasn’t always the one it should have been using. We NEEDED a true data management system if we were to consider making the switch to Inventor.
---
Stay tuned for our second blog post on the continuation of our journey with Autodesk Productstream (Later to be replaced by Autodesk Vault).
3 Comments
