Actually, it’s time for proposals for classes. If you have some cool tips and techniques or an interesting project to share, you should think about submitting a proposal and maybe you can be a presenter as AU this year. As a presenter you get the satisfaction of sharing something that’s important to you with your peers. But you also get an AU event Pass, (conference only; does not include travel or hotel accommodations). And you will also receive a $400 cash honorarium for each additional session they lead. You can learn more at the ”Call for Proposals” AU site.
Whether or not you feel like you’re up to the challenge of presenting, I would love to hear suggestions for topics on classes you would like to see related to both the Inventor and Fusion API’s. Remember, even if you’re unable to attend AU in person, you’re still able to benefit from the content from previous sessions.
I had posted a few weeks about some upcoming meetups discussing the Fusion API. To generate some interest for the meetups I created a small animation of some butter melting and forming a puddle in a butter dish. Here’s the original animation. At the meetups I presented an introduction to Fusion’s API and shared how the animation was created. The meetup in Seattle was hosted by Microsoft and Jeremy Foster, from Microsoft, was kind enough to record it and post it on Microsoft’s Channel 9.
If you’re wondering how I created the animation and are imagining something elaborate you’re going to be a bit disappointed. The good news is that it’s probably simpler to do than you’re expecting. First, there are not any elaborate volume calculations to make sure the volume of the puddle matches the volume that has melted from the cube. I just tried to do what looked good. The melting of the cube and the formation of the puddle is done using parameters so the majority of the work is building the model, not writing the program. Although I’m using Fusion here, this is all possible with Inventor using the same concepts. What the program is doing is actually very simple; there’s a loop where in each iteration it changes the value of one or more parameters, updates the model, and captures the screen as an image. That’s it. The challenge is building the model so you get the behavior you want by editing parameters.
Let’s look in more detail how the butter model works. There are three components that make up the model; the butter dish, the block of butter, and the puddle. Below, three sketches are shown that are the key to making it all work. The sketch at the bottom defines the shape of the puddle. The other two sketches are used to create a loft feature which is subtracted from the block of butter.
Below is a detailed look at one of the sketches used to define the loft that cuts away the block of butter. The sketch consists of three lines and a spline. The vertical position of the points on the spline is being controlled through the use of dimension constraints. When you place a dimension in a sketch, a parameter is automatically created that controls the value of the dimension. By editing the parameters the points on the spline will move up and down. The program modifies the parameter values so that the points slowly move down, causing the block of butter to disappear.
The puddle uses the same principal but is slightly more complicated because the points don’t just move down but move in two directions. Below is the puddle sketch. To move the points in two directions there are two dimensions to each spline point, one controlling the horizontal (x) direction and another controlling the vertical (y) direction. To make the puddle grow, the parameters are edited to slowly move the points “out” away from the cube. I didn’t worry about how the puddle intersects the butter dish. As it grows it will end up extending into the dish, but it looks ok because you can’t see the overlap.
Below is a snapshot of most of the parameters that are used to drive the model. Sketch7 is the puddle sketch and Sketch8 is one of the loft sketches. I named each of the parameters a name that made sense to me so I knew which parameter to edit to get the corresponding point to move in the way I wanted.
Below is a sample program that demonstrates the full basic workflow where it changes a parameter through a range of values and captures and image at each change. It has a loop where it continually changes the parameter named “ToChange”. In the example below, the loop goes until the parameter reaches a specified value but it could also go a pre-defined number of steps. It depends on what you need in your specific case.
The code is really fairly simple. It's all a matter of how creative you get with your parametric model. You can use anything to determine the parameter value and you don't need to be limited to changing a single value. In the melting butter example, I change several values and use a random number so the butter melted and the puddle formed in a slightly random way.
The result is a directory containing a bunch of image files. There are many products that will let you combine the images into a video. For the gif file at the top of this post, I used GIMP (Gnu Image Manipulation Program). For a higher resolution, full color animation I used another free tool called FFmpeg where I used the command line below to create the video:
Here is the Fusion model and the Python program for the melting butter example. When running the code it begins by displaying a message box to allow you to reset the parameter values back to the original starting values and then an option to run through the parameter changes and generate the images. If you look at the code you’ll see that it does some work to reposition the history marker in the timeline to reduce the re-compute time because Fusion re-computes with every parameter change without an option to delay the re-compute. It moves the marker to just before the features that will re-compute, changes the parameters and then moves it to the end of the timeline so there is a single re-compute of the model with each set of parameter changes.
You might have heard by now of the biggest ever Autodesk Developer Conference coming this June, Forge DevCon
The Early Bird tickets are running out this Friday, so you'll have to hurry up if you want to use them! :)
At the conference you can learn everything there is to know about our Forge Platform and how you can build on top of it.
Brian will be there to talk about Fusion API, and I will be there too explaining how you will be able to take advantage of our translation services to get data out of pretty much any design file you have.
Then the following week we'll also hold a Cloud Accelerator, a program that we have run many times by now all around the world with great success. Here we work side-by-side with 3rd party developers to jump start their development on our cloud technologies.
It's looking to be a great couple of weeks that nobody should miss :)
The first ever Autodesk Forge Developer Conference will take place in San Francisco on June 15-16. This is a great opportunity to get up to speed with what’s been going on with Fusion and to get a good look at what’s coming with the new Forge platform. We’ll be talking about a lot of upcoming functionality and will be able to demonstrate some of it. Complete information about the conference is available by clicking the picture below.
We’re still working on the agenda for the conference so check back often for updates. Besides the Forge conference itself, we’re also planning a Fusion API workshop on either the 13th or 14th, so if Fusion is your primary interest you won’t want to miss that. Keep watching for updates on the website as we firm up details.
Early bird registration is due to end on April 15th, so you don't have much time to buy your ticket at the low cost of $499. If you're a student, you can come for free – just sign up for a student ticket using an .edu email address.
The week following the Forge conference we’ll also be holding a Forge Accelerator in San Francisco. This is a chance for you to work on your product that uses Forge and get personal assistance from the experts at Autodesk. See the website for information about how to apply for the accelerator.
I hope to see you at any or all of the upcoming events.
A problem was reported in the beta of Inventor 2017, where an error dialog is appearing when shutting down Inventor. The error was being thrown by one of the add-ins delivered with Inventor. However, the Autodesk team was unable to reproduce the problem and couldn’t find any problems with the add-in. Someone suggested that maybe the cause was another add-in and after some testing an add-in on the Autodesk App Store could be used to reproduce the problem and using it the actual cause of the problem was found. Last week, I was notified that they identified the add-in that was causing the problem for the customer and it turned out to be my Sheet Metal Extents add-in. Not good.
My add-in has run fine for many releases now and I haven’t changed anything but apparently something has changed in some Microsoft components that is causing the problem to appear. After understanding the problem, it really is an error in my add-in and I’ve just been lucky that it hasn’t shown up before. The reason my Sheet Metal Extents add-in is causing the problem is because of how it is releasing the Inventor objects its referencing. It’s using the .NET function FinalReleaseComObject. Without going into a lot of COM details about object lifetimes and reference counting, this function forces an object to be released. At the time of the call everything seems fine, but the problem is that it might not be the only add-in using that Inventor object and when the other add-in tries to use that object the problem appears.
When we first started supporting .NET for writing add-ins, there was quite a bit of discussion about how to make it all work. With Visual Basic 6, when a variable goes out of scope or you explicitly set it to Nothing, the reference to the internal Inventor object is immediately released (actually the reference count is decremented by one and if it goes to zero then it’s released). With .NET, this doesn’t happen immediately but relies on the Garbage Collector to clean things up. That’s fine, but the Garbage Collector runs at an indeterminate time. Usually that’s ok but in the case of add-ins it was preventing Inventor from shutting down because Inventor thought there were still active external references to Inventor objects. .NET supports some functions to force the release of references and to force garbage collection. The functions FinalReleaseComObject and ReleaseComObject will do an explicit release. ReleaseCOMObject being the safer because it just decrements the reference count so if others are using the object it will still be available to them.
So, after seeing this I was planning to change my add-in to use ReleaseComObject instead of FinalReleaseComObject. However, I did a bit more research and found a very interesting article. It also made me feel better to see that Microsoft was struggling with some of the same problems. They strongly recommend to not use FinalReleaseComObject or ReleaseComObject but to allow the Garbage Collector to do it’s job. There were also some changes made in Inventor some time ago so that it won’t let an add-in keep it from shutting down.
What You Need to Do
In summary, you need to check your add-ins for any calls to FinalReleaseComObject and either change them to ReleaseComObject or even better is to remove them and just make sure you’re setting that reference to Nothing (null) so that the Garbage Collector can handle it correctly. If you’ve used the Inventor Add-In Template that’s delivered as part of the Inventor SDK, you should be in good shape because it’s already doing the correct thing. In the Deactivate method of the the add-in, It’s setting the variable that reference global Inventor objects to Nothing and then calls the Collect method of the garbage collection to force a collection. Let us know if you find any problems after making this change. I’ve removed the FinalReleaseComObject call from my Sheet Metal Extents add-in and everything seems to be working fine.
A problem was reported and I’ve made a fix and have created a new version of the Attribute Helper utility. If you’re unfamiliar with it, it’s a little utility that lets you create, view, and edit attributes within a document. If you’re relatively new to the Inventor API and are wondering what attributes are, here’s a post giving a quick introduction.
If you already have a version of “Attribute Helper” installed, you should first uninstall the version you have, which you can do using the standard Windows uninstall utility where you should see “Attribute Helper” listed as one of the installed programs, as shown below.
Once it’s uninstalled, you can install the 2.5 version of Attribute Helper. There is some help documentation delivered with the utility with instructions on how to use it and you can quickly determine if it was installed correctly by checking to see if the Attribute Helper command is now available in the Tools panel when you have a document open.
And when you run the Attribute Helper command, you should see the dialog below with the version displayed being “2.5”, as shown below.