Mod the Machine

You’re Invited to DevDays 2013

What’s DevDays you ask? It’s an event that the Autodesk Developer Network (ADN)team puts together every year to introduce the upcoming product releases and their new API functionality. It consists of presentations, demonstrations, and a chance to ask the experts your questions. In a few cities there are also DevLab’s scheduled which is a full day reserved for you to get 1-on-1 help with your questions about Autodesk’s various API’s.

In the past this event has always been an exclusive event for ADN members but this year it’s being opened up for others to attend. Below are the locations and dates for the sessions. I’ll be attending the conference and the DevLab in Las Vegas in December and would like to meet and see what you’ve been doing with Inventor’s API and help with programming questions you might have.

Asia and Australia
November 7, 2013 – Developer Day, Beijing, China
November 8, 2013 – DevLab, Beijing, China
November 11, 2013 – Developer Day, Shanghai, China
November 12, 2013 – DevLab, Shanghai, China
November 13, 2013 – Developer Day, Seoul, South Korea
November 15, 2013 – Developer Day, Tokyo, Japan
November 18, 2013 – Developer Day, Melbourne, Australia
November 19, 2013 – Developer Day, Osaka, Japan
November 20, 2013 – Developer Day, Singapore, Singapore
November 22, 2013 – Developer Day, Bangalore, India

North America
December 2, 2013 – Autodesk® Developer Network Conference, Las Vegas, USA
December 3, 2013 – DevLab, Las Vegas, USA

Europe
December 9, 2013 – Developer Day, Paris, France
December 10, 2013 – Developer Day, Milan, Italy
December 11, 2013 – Developer Day, Farnborough, United Kingdom
December 12, 2013 – Developer Day, Munich, Germany
December 13, 2013 – DevLab, Munich, Germany
December 16, 2013 – Developer Day, Gothenburg, Sweden
December 18, 2013 – Developer Day, Moscow, Russia

South America
February 5, 2014 – Developer Day, São Paulo, Brazil
February 12, 2014 – Developer Day, Mexico City, Mexico

You can learn more about the logistics of the conference at the registration page.  Below is the information from the ADN team about the event:

---

rEvolution

Where Desktop meets the Cloud

Got great ideas for cloud and mobile apps? Want to learn where Autodesk is taking the convergence of desktop computing and cloud technology?

If you’re an innovator developing on Autodesk platform technology and have not yet attended an Autodesk Developer Network Conference join us for a deep dive as we take an in-depth look at Autodesk’s newest technologies and the next generation of products coming in 2014. The Autodesk Developer Network is holding its annual, worldwide Developer Day Conference and DevLab in cities around the world from November 2013 through February 2014.

Called Autodesk DevDays 2013, the theme for this year’s event is rEvolution – Where Desktop meets the Cloud.  Come and learn about upcoming releases of several new web service APIs from Autodesk.  You’ll see how these new web services extend the power of the desktop: delivering easy collaboration, limitless compute power and big data – and are platforms that can deliver the same to you and your customers.  It’s an opportunity to learn about a range of “360 based” web service APIs delivering you Cloud based platforms for a number of industries - Manufacturing, AEC, Infrastructure and more. And, we will of course also cover what’s new in the next releases of our desktop products (AutoCAD®, Autodesk® Revit®, Autodesk® Inventor®, AutoCAD® Civil 3D® and so on)!

Note that material at Developer Days is forward-looking and highly confidential so ADN membership is required. Maybe you are using ADN Open and forums and would like to attend DevDays? Visit www.autodesk.com/joinadn or send an email to your local ADN representative and let’s talk. We like to hear from — and help — interested parties, innovators and companies just getting started.

Processing a Directory of Files

I was recently asked a question about the best way to create a PDF file for every drawing in a specified directory and it’s subdirectories.  My answer is to write a small Visual Basic application to do it.  Visual Basic Express (which is free) is fully capable of creating an application like this. 

Below is the minimal code to get all of the files within a directory and perform some type of process on each one. The first line calls the .Net GetFiles function and passes in the directory name, a search pattern, and an argument indicating that all subdirectories should also be searched. This used to be a lot of work in VBA and is now a single line with .Net. Next it iterates over the list of filenames that were found and opens each one in Inventor, calls the SaveAsPDF function, and then closes the document.  The SaveAsPDF function is a function I wrote that’s not shown below but it calls the PDF translator and exports the drawing to PDF.  By simply replacing the SaveAsPDF call with a call to a different function you can change this program to do any type of processing you want.

' Get all of the drawing files in the directory and subdirectories.
Dim drawings() As String = System.IO.Directory.GetFiles( _
                           txtPath.Text, _
                           "*.idw", _
                           System.IO.SearchOption.AllDirectories)

' Iterate through the found drawings.
For Each drawing As String In drawings
    Dim drawDoc As Inventor.DrawingDocument
    drawDoc = invApp.Documents.Open(drawing)

    ' Save the PDF.
    SaveAsPDF(drawDoc, _
              System.IO.Path.ChangeExtension(drawing, "pdf"))

    ' Close the drawing.
    drawDoc.Close(True)
Next

The above code doesn’t have any error handling or any user interface. Once you add that and a couple of bells and whistles the code grows a bit. I’ve created a full application in Visual Basic Express 2010 that has a user interface and the bells and whistles. The user interface is shown below.

You can see in the image above that some files failed to process.  This is because they were created in a later version of Inventor so the version of Inventor I’m using is unable to open them. The good news is that the program handles that case correctly and reports it.

The program is written to work with Inventor 2013 and later. You can download the executable here: SaveAsPDF_Exe.zip (28.5K)

And you can download the complete source code of the Visual Basic Express 2010 project here: SaveAsPDF_Source.zip (13.9K)

Working with Cameras (Part 2)

This is a continuation of a previous post introducing cameras.

A Camera Gotcha
When working with cameras associated with a graphics view you use the Camera property of the View object. Typically you’ll get the View object using the Application.ActiveView property. The behavior of the View.Camera property is that every time you call it, it returns a new camera. This behavior makes it easy to run into a very common problem when working with cameras. The code below illustrates the problem. It calls the Camera property of the View object and then calls the ViewOrientationType property of the Camera object, setting the camera position to be a standard isometric view. Once it does this it calls the camera’s Apply method. The result is that nothing happens.

' Set the camera orientation to an iso view.
invApp.ActiveView.Camera.ViewOrientationType = _
                                           IsoTopLeftViewOrientation
' Apply the camera changes to the view.
invApp.ActiveView.Camera.Apply

The reason that nothing happens is that in the first line the Camera property is called and a camera is created and returned. On this camera the isometric view is specified. On the next line the Camera property is called again and another camera is created and returned. On this camera the Apply method is called, but this camera hasn’t had the view orientation set but is the same as the current view so you don’t see any visible change. The code below illustrates the correct procedure and does create the desired result. In this case the Camera property is called and the camera is returned. The orientation for that camera is defined as an isometric view and the Apply method on the same camera is called. The view then updates to reflect the new camera position.

' Get the camera from the view.
Dim cam As Camera
Set cam = invApp.ActiveView.Camera

' Set the camera orientation to an iso view.
cam.ViewOrientationType = kIsoTopLeftViewOrientation

' Apply the camera changes to the view.
cam.Apply

Applying Camera Changes
Setting a property on a camera doesn’t have an immediate effect. This is because typically you’ll want to make several changes to the camera before you force the view to update. For example you might want to change both the eye and target points and then update the camera. There are two methods that cause changes to the camera take effect. They are Apply and ApplyWithoutTransition. The Apply method uses the same transition technique that inventor uses when you change to a new view orientation; it smoothly transitions from one position to another. The ApplyWithoutTransition immediately shows the new camera position without any transition. The ApplyWithoutTransition is used when you’re doing your own camera animation because you’ll be computing all of the camera positions yourself and don’t want the delay as Inventor transitions from one camera position to another.

Modifying the Camera
There are three properties on the camera that control the position and orientation of the camera; the Eye, Target, and UpVector properties. There are other properties that let you control the camera’s field of view. the Perspective property lets you toggle the camera from perspective to parallel. When the camera is a perspective camera you can use the PerspectiveAngle property to control the field of view. When it’s a parallel camera you can use the GetExtents and SetExtents methods to get and set the field of view. In addition to these functions that let you directly get and set the underlying properties of a camera there are also some convenience functions that make it easier to manipulate the camera. For example, the ViewOrientationType lets you specify standard view positions, (i.e. top, front, top-left iso, etc.) and Inventor will modify the eye, target, and up vector as-needed. The Fit method takes into account the size of the model and modifies the camera so the entire model is visible. There is also a function that takes mouse input and modifies the camera to reflect the mouse movement or scrolling.

Below is some VBA code that will fly the camera around the model. To simplify the code, the target is hard coded at the origin and the up vector is the positive Z.

Public Sub RotateCamera()
   ' Get the active camera.
   Dim cam As Camera
   Set cam = ThisApplication.ActiveView.Camera
   Dim tg As TransientGeometry
   Set tg = ThisApplication.TransientGeometry

   ' Define the number of steps in the animation.
   Dim steps As Integer
   steps = 360

   ' Define the distance between the eye and target.
   Dim eyeDistance As Double
   eyeDistance = 15

   ' Calculate pi.
   Dim pi As Double
   pi = Atn(1) * 4

   ' Iterate the specified number of steps.
   Dim i As Integer 
   For i = 1 To steps 
      ' Calculate the x and y coordinates of the eye.
      Dim x As Double
      Dim y As Double
      x = eyeDistance * Cos(i / steps * (2 * pi))
      y = eyeDistance * Sin(i / steps * (2 * pi))

      ' Set the eye using calculated x, y and a hard coded z value.
      cam.Eye = tg.CreatePoint(x, y, 3)

      ' Define the up vector as positive z.
      cam.UpVector = tg.CreateUnitVector(0, 0, 1)

      ' Apply the current camera definition to the view.
      cam.ApplyWithoutTransition
   Next
End Sub

Why Use the Camera?
There are several reasons you might want to use the Camera object. The first is that you have a need to control the view within Inventor. For example, you can create a custom fly-trough of an assembly or write some utilities that allow you to quickly go to certain views. The sample code above demonstrates the procedure to set the camera properties and apply it to a view. Watch for another post about how to make the camera follow a curve like what was demonstrated in the video in this earlier post.

A camera is also used to create non-standard drawing views. Using a camera you can create any view orientation you want. The following code illustrates using a camera to create a custom drawing view that is a perspective isometric view.

' Create a camera to be used to define the view orientation.
Dim cam As Camera
Set cam = ThisApplication.TransientObjects.CreateCamera

' Set up the camera.
cam.Perspective = True
cam.ViewOrientationType = kIsoTopRightViewOrientation

' Create a drawing view using the camera.
Dim viewPnt As Point2d
Set viewPnt = ThisApplication.TransientGeometry.CreatePoint2d(12, 12)
Dim drawView As DrawingView
Set drawView = drawSheet.DrawingViews.AddBaseView(doc, viewPnt, 1, _ 
                            kArbitraryViewOrientation, _
                            kHiddenLineRemovedDrawingViewStyle, , _
                            oCamera)

The Camera object can also be used to save an image as a file. You essentially capture whatever the camera is currently seeing and save that as an image file. The format of the file can be any of several popular image types, (i.e. jpg, bmp, png, gif, and tiff). This can be useful within Inventor but is particularly useful with Apprentice because Apprentice doesn’t have a visible graphics window. You can use a camera to create images for parts, assemblies, and drawings. The VB.Net code below demonstrates creating an image of a part or assembly using Apprentice. It assumes you’ve already created an instance of Apprentice and have opened the part or assembly, which are both passed into this sub, along with the filename to use for the image. The type of image created is dependent on the extension of the filename.

Private Sub CreateImage( _
              Apprentice As Inventor.ApprenticeServerComponent, _
              PartOrAssembly As Inventor.ApprenticeServerDocument, _
              Filename As String)
   ' Create a new camera.
   Dim cam As Inventor.Camera
   cam = Apprentice.TransientObjects.CreateCamera

   ' Associate the document with the camera.
   cam.SceneObject = PartOrAssembly.ComponentDefinition

   ' Define the camera and apply the changes.
   cam.ViewOrientationType = _
        Inventor.ViewOrientationTypeEnum.kIsoTopRightViewOrientation
   cam.Fit()
   cam.ApplyWithoutTransition()

   ' Save the result, defining the background color of the image.
   cam.SaveAsBitmap(Filename, 800, 600, _
           Apprentice.TransientObjects.CreateColor(255, 255, 0), _ 
           Apprentice.TransientObjects.CreateColor(15, 15, 15))
End Sub

The resulting image is shown below.

That’s the basics of using cameras. Watch for an upcoming post where we’ll look at a tool to better visualize the camera and how to use geometry in the model to control the camera.

-Brian

The “Portathon” is Happening Soon!!

Here’s the latest update on the upcoming Portathon.

App developers can still register and receiveUS$100 per app published!

The 48 hour virtual web based coding event runs through September 13 and 14, 2013.   There's still time to register and to participate early if you wish.  You can even submit your apps before the event.  In fact, over 100 apps have already been submitted for this event.  If you're a developer of apps for Autodesk products, there is no better way to reach Autodesk customers worldwide than Autodesk Exchange Apps.  Customers are active and engaged with Autodesk Exchange Apps as evidenced by comments: "Very grateful for this tool it is saving me a huge amount of time and the tedious task of doing it via the block editor" or "This one is a no-brainer. I have been searching for an app like this. Easy to use, and does what it says."

Don't delay - join well over 100 developers in getting the help you may need to get your apps published.  If you submit your apps by midnight on September 14, 2013 and if they are accepted for publication in the store by October 31, 2013, you will receive US$ 100 per app (for up to 5 apps – US$ 500 total).

For details visit: http://autode.sk/15DjZpq

Using MS Access Databases with Inventor 2014 VBA

Several people have had problems with existing VBA programs when they made the transition to Inventor 2014 from an earlier release. The problem they were having is that the portion of their program that tried to connect to an Access database was failing. Below is a description of what’s really going on.

History
For a long time Inventor was only available as a 32-bit application. It still is available as 32-bit but most people use the 64-bit version, primarily because of the ability to use much more memory.  Until fairly recently VBA was only available as a 32-bit component.  As a component it doesn’t run on its own but needs to be hosted within another process. In this case it runs within the Inventor process. To connect to an Access database you need to use the OLEDB Provider component. Just the same as the VBA component, it needs to run within another process, which in the case of Inventor VBA is running within the Inventor process. The picture below represents what’s happening with a 32-bit version of Inventor. When a component runs within another process it MUST be the same bitness.  That is 32 bit components MUST run within an 32 bit process and 64 bit components MUST run within a 64 bit process. There are no exceptions. By running in-process the speed of VBA is very good because the communication between VBA and Inventor is within the same process and is essentially a direct call.

 

When a 64-bit version of Inventor was being developed we had a problem; VBA was only available as a 32-bit component.  This meant that VBA could no longer run within Inventor. A lot of customers had written macros and were dependent on the functionality they provided so we didn’t want to abandon VBA. A workaround to the problem was invented, which is illustrated below. When you run VBA from a 64-bit installation of Inventor 2013 or earlier, a separate process is started called Inventor32bitHost.exe, (which you can see in Windows Task Manager). This is a small executable who’s purpose is to serve as the 32-bit host for the VBA component.  When the OLEDB Provider component is used by VBA it is also loaded within the Inventor32bitHost.exe process and everything works since it’s all 32-bit.

 

There are some definite drawbacks to the Inventor32bitHost.exe approach:

1. An extra process is being started. This is the reason for the slow start-up time when you first run VBA after starting Inventor. The Inventor32bitHost.exe process isn’t started until it’s needed but you pay the price then.
2. Running VBA in a separate process outside of Inventor means that the Inventor API calls are being made between two processes. Out of process API calls are much more expensive since each call needs to be wrapped to pass the call information between the two processes.
3. API calls that use certain argument types are not supported when using a COM Automation interface between two processes. For example, getting the thumbnail image of a document is not possible because it passes the image through the API.
4. There were also other issues and we had a list of reported issues that we really couldn’t do much about because of the architecture.

Initially we were told that there would only ever be a 32-bit version of VBA available and thought we would have to live with the Inventor32bitHost solution. We looked at possible alternatives, including VSTA (Visual Studio Tools for Applications) and Python but they didn’t have the same ease of use that VBA has and would have forced customers to migrate all of their existing programs. At some point Microsoft changed their minds and released a 64-bit version of VBA and we were able to incorporate this into the Inventor 2014 release.

Inventor 2014
The picture below illustrates what’s happening now. You’ll notice the architecture is exactly the same as with a 32-bit version of Inventor except everything is 64-bit. This solves all of the problems we were having with the 32-bit workaround; we now have fast VBA startup, fast program execution, and no limitations on API calls.

 

Issues
After the release of Inventor 2014 and thinking all of our problems were solved we started to get some reports from customers having problems with their VBA programs that use an Access database. The cause of the problem is that they were using the 32-bit version of the OLEDB Provider component. This probably should have been a fairly obvious cause of the problem but there are some side issues that made this a bit more of a difficult issue to diagnose.

The most common way to get the the 64-bit OLEDB Provider component is to install 64-bit Microsoft Office. I believe the first version of Office where you had the option of a native 64-bit install was Office 2010.

Issue 1
After some testing and some communication with Microsoft it’s been verified that when you install MS Office only one bitness (32 or 64 bit) of the OLEDB Provider is installed; the one that matches the bitness of Office that’s installed. Ideally, when installing Microsoft Office on a 64-bit machine it would be good if it installed both the 32 and 64 bit versions of the OLEDB Provider component whether you install the 32 or 64 bit version of Office.

The other thing we learned is that it’s not possible to have both the 32 and 64 bit versions of the component installed at the same time on a machine.

The following MSDN article discusses this.  Data Programming with Microsoft Access 2010: Using 32-bit and 64-bit ACE Providers

Where this can be a problem is if you have both 32 and 64 bit applications that use the OLEDB Provider component.  With this limitation it’s not possible that both of them can work.

Issue 2
As I said above, the typical way to install the OLEDB Provider component is to install MS Office. There’s a problem with this if you’re using MS Office 365. When it installs the OLEDB Provider component, it registers it in a way that it’s accessible from within the Office applications but not from other applications. So that means it’s not usable from Inventor’s VBA. Microsoft has verified this and is investigating the problem.

Possible Solutions

1. Install a 64-bit version of Office (but not Office 365 because of Issue 2 described above). Installing Office will also install the OLEDB Provide component.
2. If you’ve installed MS Office 365, you can install the Microsoft Access Database Engine 2010 Redistributable. Make sure you select the file “AccessDatabaseEngine_x64.exe” for download to get the 64-bit version.  Be aware that this still doesn’t solve the issue of having both the 32 and 64 bit versions of the component installed at the same time.

Issues
In all cases the solution is not compatible with a 32-bit version of Office since it has installed the 32 bit version of the OLEDB Provider component.  Because of issue 1 described above you have to have either 32 or 64 bit and can’t mix the two as far as the OLEDB Provider component. This means to use the OLEDB Provider component in Inventor 2014 you will need to have a 64-bit version of Inventor.

Working with Cameras (Part 1)

In my previous post I linked to an animation that a high school intern created using Inventor. A critical piece required to create the animation is the ability to control the camera within Inventor.

First, what is a camera within Inventor?  You can consider Inventor cameras to be the equivalent of a real-world camera. If you’re holding a camera you can move to any location, point that camera in a certain direction, tilt the camera in any orientation, and take a picture.  All of that is the same with an Inventor camera except it’s a virtual camera that only lives within an Inventor document.  When you use Inventor interactively to zoom in/out, pan, and rotate the view you’re actually manipulating the camera and seeing the result of what the camera sees in the graphics view. The model always remains fixed in model space but as you rotate, pan, and zoom the view you’re just moving the camera around the model. The pictures below illustrate this. The picture on the left shows the model in model space and a camera. The picture on the right shows what the camera is seeing and what is displayed in the graphics window. By moving the camera around the model, the picture in the graphics window changes.

In the API, a View object represents a graphics window in the Inventor user-interface. The view can be sized, collapsed, maximized, and deleted. Additional views can also be created. The Camera API object is an API only concept that’s not directly seen in the user-interface since all of the user-interaction to manipulate the camera is done through the view. The camera controls what is displayed in the view.

There are two types of cameras; perspective and orthographic (parallel). I’ll begin by discussing perspective cameras because they’re easier to understand since they behave in much the same way as a real-world camera. In Inventor you can switch between an orthographic or perspective camera using the command in the View tab of the ribbon or the context menu of the view cube.

There are three basic properties that apply to all cameras (perspective and orthographic); eye point, target point, and up vector. The eye point is the position of the camera in model space. With just the eye point defined the camera is fixed at a specific location but can be pointed anywhere and rotated to any angle. The target point is the location in space that the camera is pointed. With the eye and target point defined the camera can still be rotated to get a landscape, portrait, or anything in between orientation. The up vector defines a direction in model space that defines the direction the top of camera is pointed. With these three properties defined the camera is fully positioned.

For a perspective camera the other property you can define is the perspective angle. A camera sees a certain area in front of it, which is referred to as its field of view. The field of view of a perspective camera is represented by a view pyramid and the angle of the pyramid that controls this field of view is called the perspective angle. Changing the perspective angle of a camera is the same as zooming with a real camera. By narrowing the field of view you see less of the model, effectively zooming in on a smaller area, as shown below where the perspective angle has been narrowed in the picture on the right.

With a perspective camera there’s also a second way to zoom in on the part. Just like with a real camera you can just move closer to the object, as illustrated below. As you zoom in and out in Inventor with a perspective camera, this is what Inventor is doing; moving the camera closer or further away from the model.

Another behavior of a perspective camera is objects that are further away from the camera appear smaller, just as they do in the real world. You can see why that is because something that is further away takes up less of the field of view, since the size of the field of view gets bigger the further away from the camera it is. Things closer fill more of the field of view and appear larger.  In the picture below all of the boxes are the same physical size but because they’re different distances from the camera they appear as different sizes.

I said earlier that when you zoom in and out with a perspective view Inventor moves the eye point to position the camera closer or further away from the model.  This is true but it’s also possible to leave the camera positioned at the same location and change the perspective angle.  To do this, first make sure Inventor is using a perspective camera and then press and hold the Shift and Ctrl keys while rolling the mouse wheel (middle button).  As the field of view narrows the view looks more like an orthographic view (the picture on the left) and as it widens you get more of a contrast between objects close and far away from the camera (the picture on the right).

Orthographic or parallel cameras don’t follow any of these natural behaviors that we’re used to. Instead of a view pyramid, parallel cameras have a rectangular box and the camera sees everything within the box. One of the effects of this is that everything appears the same size regardless of how close it is to the camera. This is because everything takes up the same area in the field of view regardless of how close it is to the camera. The second big difference is that moving the camera closer to the object doesn’t zoom in. This is illustrated below. The model still takes up the same amount of area in the field of view no matter how close the camera is to the object.

To zoom in with a parallel camera the size of the viewing box is changed, reducing the field of view.

In the next post we’ll start looking at how to use the API to control the camera.

See the next post in this series.

-Brian