Align Part Axis With Origin Axis with iLogic
Hi @william_nankervis8TS8Q. Welcome to the Autodesk Community. The good news is that all of that definitely sounds possible to make happen by code. There may be many 'variables' involved in this process though, so I have to ask some questions, because the code for a task like this needs to be extremely specific for it to work the way you want. Are any of these parts that you want to export this way 'multi-body', or do they all consist of a single solid body? If any of them have multiple bodies, then which bodies should be rotated, or should all bodies be rotated the same way? Is the 'polarity' (direction) of the alignment with the Y-Axis important, or are both directions OK? If alignment direction is important, then the code will likely need to include some prompts to the user, to confirm if the direction is OK, or if it needs to be flipped/reversed, which may add to the length and complexity of the code process. Is the rotation degree of the cylindrical part around the Y-Axis important? If so, then further manual user interactions may need to be prompted for, such as reference Edges and origin work features, and the code would get even longer and more complex. Do any of those parts have multiple ModelStates in them?...If so, then which ModelState should be edited, or should all ModelStates be edited the same way? Would using Move Body features be OK for you, instead of 'direct edit' features? I do not think we can create new direct edit features by code, but we can access the ones that already exist by code. I know that we can create new move body features by code though.
It sounds like you may be wanting to start this process from within the context of an assembly, where these parts you want to export would be component occurrences within that assembly. If that is the case, then would your Edge or Cylinder selection may be a 'proxy' of the original geometry, instead of the actual original geometry which exists within the context (3D coordinate space - component definition) of the part. That would be more complicated due to the different document contexts involved, and having to retrieve the original geometry from the proxy geometry, especially if it were down within any sub assemblies. It may still be possible though.
Wesley Crihfield
(Not an Autodesk Employee)
Add Modelstate to the tube. Use direct edit to rotate the tube. Export STEP from theat ModelState.
Hi @william_nankervis8TS8Q. Even though you have not answered any of my questions yet, I have developed a rough draft for an iLogic rule you can try out for this task. Since we are limited to using the MoveFeature, we are also limited in how we can move or rotate the model, because two of the 3 ways they allow us to manipulate the model require a reference to 'persistent' (not transient) geometry. This means, if the model needs to be rotated, then the axis about which it rotates must already exist within the model as a linear edge, the center axis of some sort of round geometry, or a work feature. Similarly, if we want to move the model along a ray, then there must be some type of geometry like that in the model for it to reference for that direction. We do have the ability to 'free move' the model using purely X, Y, & Z offsets though. There is nothing in there yet for prompting the user about whether they want to reverse the polarity or direction of alignments or rotations. Nearly every type of geometry entity has a 'direction' of some sort. In this first basic example code, it is just using the 'natural' directions of the entities involved. So, as long as the Edge or cylinder face you select is parallel or perpendicular to any of the origin work features, this rule should work OK for you...at least for the basic requirements. I did test it on one local part, and it did seem to work OK for that scenario.
Attached is a text file containing the code that you can copy & paste into a new/empty iLogic rule to try. I did start to make it compatible for running on an assembly too, but I suspect that part may not work well yet, because I think each part it attempts to work on would need to be visibly opened on screen first, due to the use of transient (temporary, purely mathematical, not visible) geometry. Normally when we start an iLogic rule while an assembly is Inventor's active document, that assembly will remain the active document throughout the code process, which may be a problem for a process like this.
Wesley Crihfield
(Not an Autodesk Employee)
Hi @william_nankervis8TS8Q. You are right about us being active at very different times. My time zone is GMT-4, so that is a big difference. I am glad the code I provided works for some of your situations. As for when the model is an an odd angle, the code for that would have been inserted around Line 126 of the code in the text file, but I did not put any code in there yet. When we want to create a MoveFeature by code, we first have to create a MoveDefinition that will be used during its creation to define how it will move the model. We create the definition using the MoveFeatures.CreateMoveDefinition method, which asks us to specify an Inventor.ObjectCollection containing the SurfaceBody or WorkSurface objects that we want to move. Then we need to add one or more MoveOperation objects to that definition using one of the definition's 3 methods for doing so. The first available method is AddFreeDrag, which only asks us to specify the X, Y, & Z offsets for translating the model, and returns a FreeDragMoveOperation (a MoveOperation sub-type). The next available method is AddMoveAlongRay (not being used in my example code), which asks us for a 'direction entity' (can be a linear Edge, planar Face, WorkAxis, or WorkPlane), then if we want to use its 'natural direction', then what offset to use, and returns a MoveAlongRayMoveOperation. Since that method is more restrictive, I did not use it. And last we have the AddRotateAboutAxis method (the only for rotation), which asks us for an 'axis entity' (can be a linear Edge, a cylindrical or torus Face, or a WorkAxis), then if we want to use its 'natural direction', then what angle to rotate the model around that axis. Since this method requires a piece of 'persistent' model geometry, that makes it pretty restrictive.
So, what we could do is, once we know that the needed axis of rotation is not parallel or perpendicular with any of the origin axes, is create a new WorkAxis that meets our needs. Then use that as the axis of rotation for that MoveOperation. There are many methods for creating a WorkAxis, which you can review under the WorkAxes online help page. But only one of those (AddFixed) will work in the context of an assembly, and is the only one that does not require 'persistent' model geometry as input. When we use that method to create a WorkAxis, the resulting WorkAxis will not update or move in relation to any other geometry moving or changing, since it is not dependent on any of that.
I do have some other stuff to catch up on at work right now, but I may attempt to further develop my earlier code a bit to include the WorkAxis creation step, when needed, so it can rotate the ones that are not aligned with any origin work features.
Wesley Crihfield
(Not an Autodesk Employee)
Hi @william_nankervis8TS8Q. I finally got back here after taking care of a lot of other stuff. And I have an updated code that now works to align the model with the Y-Axis, even if it is not originally aligned with, parallel with, or perpendicular with any of the model's origin work features. It actually wasn't as complicated as I first suspected, and required less additional code than expected.
The secret ingredient is a built-in method of the UnitVector named CrossProduct. The UnitVector is just a 'direction', with no 'location' or 'distance' involved. You can imagine its coordinates defining the end point location of a one unit long line that starts at the X0,Y0,Z0 origin point. Its CrossProduct method gets the third 'direction' that is perpendicular to the original direction that the method is being called from, and is also perpendicular to the 'input' direction. It can be used for finding the third direction when going from a 2D scenario to a 3D scenario, to define a UCS.
Now, if the picked geometry is at an odd angle to the origin axes, it will create a new 'fixed' WorkPlane as needed, then use that to rotate the model around within that MoveFeature. It then turns the visibility of that new WorkAxis off, because most folks do not want to 'see' work features.
The updated code is in the attached text file. When the code is long, I prefer to attach it in a text file, instead of posting it directly into the forum post in a code window, because it takes up less space, and requires less mouse scrolling to read through the topic later.
Edit: Almost forgot to mention an important additional detail in this version of the code. It now uses an Inventor.Transaction. Those are used by Inventor to bundle multiple actions into fewer items in its UNDO list. That way, you can quickly & easily undo a bunch of actions in one click. That may be important if you want to roll-back the model to the way it was before, after exporting the STEP file, instead of just suppressing or deleting the additional features this tool creates afterwards.
Wesley Crihfield
(Not an Autodesk Employee)
