Community
Fusion API and Scripts
Got a new add-in to share? Need something specialized to be scripted? Ask questions or share what you’ve discovered with the community.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Modifying Joint X & Y Offset

7 REPLIES 7
Reply
Message 1 of 8
balunist
767 Views, 7 Replies

Modifying Joint X & Y Offset

I'm looking to modify the X and Y offset of a Joint.   Joint object has the offset property which is a ModelParameter object.  It has a role description of alignOffsetZ.  User Parameters exist with roles of alignOffsetX and alignOffsetY but no obvious direct way to access and modify them.  The Joint offset ModelParameter has the modelParameters property which was empty.

Thanks in advance for your help!

 

 

7 REPLIES 7
Message 2 of 8
balunist
in reply to: balunist

I did come up with the following to access X and Y modelParameters but it has the potential to be release depend and at best fragile.  It assumes that model parameters follow each other with incremental names as angle, offsetX, offsetY, and offsetZ.  I'm still looking to the correct way to access these user parameters associated with a joint.

The included code seem to work.  

pre, idx = joint.angle.name.split('d')
nameIdx = int(idx)
offsetX = joint.parentComponent.modelParameters.itemByName('d{}'.format(nameIdx+1))  
offsetY = joint.parentComponent.modelParameters.itemByName('d{}'.format(nameIdx+2))  

 

Message 3 of 8
jonrbloom
in reply to: balunist

I'm facing the same issue. Having a single offset is quite restrictive.

Is @balunist's workaround guaranteed to work in future updates?

If not, is there a more official solution for this?

Message 4 of 8
jonrbloom
in reply to: jonrbloom

I can confirm that the previous solution is indeed NOT reliable. I've had cases where the angle has the name 'angle', and others where it has a numeric id.

 

However, it's possible to identify the parameters using their 'role' attribute instead of relying on their id's. Like this:

 

for p in joint.parentComponent.modelParameters:
    param: adsk.fusion.ModelParameter = p
    if param.createdBy == joint:
        if param.role == "alignOffsetX" and jointOffsetX:
            param.expression = jointOffsetX
        elif param.role == "alignOffsetY" and jointOffsetY:
            param.expression = jointOffsetY

 

Sadly, this has the limitation that it will not work on DirectDesign types. For me that severely limits the performance of my scripts.

 

I REALLY REALLY wish Autodesk would address this shortcoming of the JointInput. It wouldn't be hard to support both the existing 'offset' attribute alongside xoffset/yoffset/zoffset attributes. And the underlying mechanisms are obviously in place, or the params trick would not work. Joint's are severely limited with just a ZOffset control.

Message 5 of 8
balunist
in reply to: jonrbloom

Sorry, for the delayed response on this topic. It has been a long while
since encountering this issue. The way I eventually solved this was
something close to the following.

geo1 = joint.geometryOrOriginTwo
origin = geo1.origin.copy()
# modify the origin x & y values here
joint.timelineObject.rollTo(True)
sketchPoint = targetProf.parentSketch.sketchPoints.add(origin)
geo1 = adsk.fusion.JointGeometry.createByPoint(sketchPoint)
joint.geometryOrOriginTwo = geo1
joint.timelineObject.rollTo(False)
Message 6 of 8
jonrbloom
in reply to: balunist

Another thinking outside the box solution 😁

 

Sadly this also prevents the use of DirectDesign to improve perf, due to reliance on timeline. My solution (really an enhancement of your solution) prevents DirectDesign by reliance on the model params.

 

Looks like this is the best we can expect though.

Message 7 of 8
MichaelT_123
in reply to: balunist

Hi Fellows,

 

Yes, jointOrigin offset is limited to Z-axis only. Is this limitation terminal?

No, it is not. There is the planar joint type which does not only X&Y virtual offsetting but also adds the rotation along Z-axis. The underlying values of offsets are controllable by respective jointMotions functions. I have a strong feeling that these internal procedures will be faster and much more efficient than any script you will devise modifying directly model's dxxxxs in your scripts (and you might break something on the way).

If the rotation, included in planar joint type is not enough, throw on the top another joint of your choice, being rewarded by up to 6DOF.

 

On the side note, … F360 software architecture is/was not particularly built to be very responsive regarding kinematic simulations. It is more like an anaconda serpent (F360) digesting a python snake  (Python) which in term consumes your script (which might not be porridge on fermented milk), battling with an operating system and other contenders in order to be finally squeezed into processor's thread (the single one in this case). All at the same time! So, set up your expectations accordingly🤔. Having said that… it is still possible to do a thing or two…

 

Regards

MichaelT

MichaelT
Message 8 of 8
jonrbloom
in reply to: MichaelT_123

@MichaelT_123 You are making assumptions on our behalf 🙂

A planar joint doesn't help if you need the reference point for any motion to be offset from the edge or vertex being attached.

 

Sure we have workarounds but it's frustrating to know that the underlying functionality is there with no way to get to it through the API.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report