I am isGrounded ...

[MichaelT_123]

Hi,

I am stumbled on the ground of perhaps only mine inability to understand the simplicity of F360 API.

The simple code:

"

comp.occurrences.item(0).isGrounded = True

comp.occurrences.item(0).isLightBulbOn = False

comp.occurrences.item(1).isGrounded = False

comp.occurrences.item(1).isLightBulbOn = True

"

work as a charm but ... only for isLightBulbOn functions. The isGrounded property in F360 window is 'False' no matter what ...

I would welcome any enlightenment . How to ground  comp.occurrences.item(0)?

Regards

MichaelT

PS.I am writing from the planet Earth so theoretically should not be an issue 🙂  

[marshaltu · Accepted solution]

Hello,

There was a bug in the method. We should throw exception if clients are trying to set grounded property for an occurrence with relative path. For example: setting "Component3:1" grounded by "Component1:1" should fail. 

The solution for you would be to create a proxy object for the kind of occurrence and then set grounded property by proxy object. Please refer to the sample codes.

Thanks,

Marshal

import adsk.core, adsk.fusion, adsk.cam, traceback

def run(context):
    ui = None
    try:
        app = adsk.core.Application.get()
        ui  = app.userInterface
        
        design = adsk.fusion.Design.cast(app.activeProduct)
        root = design.rootComponent
        
        occ = root.occurrences.item(0)
        comp = occ.component
        subOcc1 = comp.occurrences.item(0)
        subOcc1Proxy = subOcc1.createForAssemblyContext(occ)
        subOcc1Proxy.isGrounded = True       

    except:
        if ui:
            ui.messageBox('Failed:\n{}'.format(traceback.format_exc()))

[MichaelT_123]

Thank you Mr Tu,

I am isUngrounded ...

Before I have seen your VERY SPEEDY response, I did some testing by moving the component I wanted to ground to the root level. In such arrangement, grounding was not a problem.

After applying the patch you sent, I have had no problem to do the same, with the component at lower levels in the assembly.

So your diagnosis was on the spot .... perhaps I was not only one which encountered such tricky situation :).

Intuitively, grounding is a grounding no matter when and where: Bourbon Road in New Orlean, King Cross in Sydney or Prag in Warsaw ... I am talking about electricity ... of course.

So hopefully, .... there is some way to implement it transparently (at the kernel level ) without changing API docs/references ...or even worse ... teaching Earth populus to do it by proxy ... unless there are reasons, I do not understand ... which is possible!

With Regards

MichaelT

[marshaltu]

Hello,

We had a topic "Documents, Products, Components, Occurrences, and Proxies"(link as below) to explain why we need proxy in some case.

In fact, when users pick up a leaf node in the browser in Fusion 360, it implies users select an unique path in the assembly tree. We need provide a way to do that in API world.

http://help.autodesk.com/view/fusion360/ENU/?guid=GUID-88A4DB43-CFDD-4CFF-B124-7EE67915A07A

Thanks,

Marshal

[MichaelT_123]

Thank you Mr Tu

It is valuable reference ....

Additional elaborations about the role of proxies can be found under the keyword 'Proxy' in 'Autodesk Inventor 2017 Help', which might help many others finding themselves in the proximity of F360 API.

As per my understanding, when I create (via API) component's occurrence, I give it in the process of successive steps the distinctive address path in the design. (yes?no?)

So there is not a confusion about the identity of the particular reference ( which can be easily checked by "fullpathname" property) and as such, there should be not confusion in the 'grounding' function.

As a matter of fact one can not ground respective component.

One more thought ...

Sometimes there is a confusion between a model and model's interface. 

It is particularly visible in F360 ... and somehow enforced by the "InputMethod" paradigm.

A model itself (this is a little bit philosophical) can exist without interfering with it user(s) . A model's interface is the distinctive abstraction of an interaction with the model(s).

Both are two different things ...

With Regards

MichaelT

PS. Still struggling with proxies 🙂