4 bugs (at least) related to Occurrences
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
I love F360, but it is clear that the program has not got it's head around occurrences. A number of bugs have already been fixed - see this thread, but it appears that the symptoms are being addressed and not the underlying cause. I would venture to suggest that the implementation of occurrences, in general, is broken.
The following code highlights at least four issues - and this is just with creating holes. I believe this is just the tip of the iceberg (other features and anything that has either .createForAssemblyContext or where .creationOccurrence can be written to, to name a few). I've included the sample model along with a screen cast.
import adsk.core, adsk.fusion, 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
#Create sketch and circle for component at root level
def createHole(occurrence, faceNo, vertexNo):
body = adsk.fusion.BRepBody.cast(occurrence.bRepBodies.item(0))
face = body.faces.item(faceNo)
vertex = face.vertices.item(vertexNo)
point = vertex.nativeObject.geometry
component = adsk.fusion.Component.cast(occurrence.component)
sketch = component.sketches.add(face, occurrence)
pointInSketch = sketch.modelToSketchSpace(point)
sketchPoint = sketch.sketchPoints.add(pointInSketch) #as the centre is placed on midline endPoint, it automatically gets constrained
holes = component.features.holeFeatures
holeInput = holes.createSimpleInput(adsk.core.ValueInput.createByReal(.5*2.54))
holeInput.isDefaultDirection = True
holeInput.creationOccurrence = occurrence # work around if this is commented out!!
holeInput.tipAngle = adsk.core.ValueInput.createByString('180 deg')
holeInput.participantBodies = [face.nativeObject.body]
holeInput.setPositionBySketchPoint(sketchPoint)
# holeInput.setAllExtent(0)
holeInput.setDistanceExtent(adsk.core.ValueInput.createByReal(2.0*2.54))
holes.add(holeInput)
faceNo = 1
createHole(root.allOccurrences.item(0), faceNo, 0)
createHole(root.allOccurrences.item(1), faceNo, 2)
createHole(root.allOccurrences.item(2), faceNo, 0)
createHole(root.allOccurrences.item(3), faceNo, 2)
except:
if ui:
ui.messageBox('Failed:\n{}'.format(traceback.format_exc()))Bug 1: After running the script you should find each component (plus copy, mirror and mirror copy) have two hole features added. The holes that are created in the nativeObject appear correctly. The holes in the copies are NOT. Until, that is, you edit the hole in the timeline. These holes appear in the right place and in the right occurrence, However, once the edit dialog box is closed the hole appears on the model, correctly formed.
Bug 2: If you then open the dialog again, the hole being edited is now on the nativeObject - I strongly believe this is wrong - if you create a feature in an occurrence, it should definitely copy itself to the nativeObject, but its assemblyContext should remain with the occurrence and not change.
Bug3: If line 27 (holeInput.creationOccurrence = occurrence) is commented out, the hole appears on both the nativeObjects and the copies. If keeping track of the assemblyContext was not the design intention then holeInput.creationOccurrence along with sister features such as sketches (
component.sketches.add(face, occurrence)) are broken.
Bug 4: using component.sketches.add(face, occurrence)) (line 18) should have resulted in the sketch remaining in the occurrence context it was created in - similar to as described in Bug 3. It reverts back to the nativeObject!
Bug 5: if you look at the hole dialog box that is created by the API - the placement icons are missing!! (a minor bug, but indicative of something not quite right with the API)
In several documents, for example here at the AD university presentation by Brian Ekins, it's implied that an Occurrence takes care of the positional and rotational relationship of an occurrence to the rootComponent. There's no evidence to show that the F360 implementation has actually followed that philiosophy - it would be wonderful if it did.
In the same vein - it is totally bizarre to me to mix coordinate systems. Anytime an Occurrence is referenced in the API, all coordinate systems should be consistent - for instance:
holeFeatureInput_var.setPositionByPlaneAndOffsets(planarEntity, point, edgeOne, offsetOne, edgeTwo, offsetTwo)
"point" here is related to the NativeObject and its coordinates, whereas edgeOne and edgeTwo relate to the same coordinate system as the planarEntity (which is usually in an occurrence context). Why are they different? - it goes to show that something is amiss in the implementation philosophy. It's also unnecessarily confusing and complicated.
Regards
Peter
Life long R&D Engineer (retired after 30+ years in Military Communications, Aerospace Robotics and Transport Automation).
