Joining to imported components

Joining to imported components

R4SMEs
Advocate Advocate
1,462 Views
9 Replies
Message 1 of 10

Joining to imported components

R4SMEs
Advocate
Advocate

I am experiencing strange behaviour when trying to join to imported components.

 

For a modular shelf system, I am using a separate model for each component.

 

There is a Post model, a Bracket model and (a yet to do/ simple) Shelf model.

 

There is the "Bookshelf3Shelf260mm1Bay" overall model which is based on importation of components from each of the other models.

 

My overall plan is that by having each component as a separate model I should be able to easily implement an alternative shelf system.
For example, the next could be double width having 5 shelves and 3 posts (2 bays) which I would implement as "Bookshelf5Shelf260mm2Bay" model.
[There could be other future variants having different shelf widths - hence the 260mm in the current model names.]

 

The Post and Bracket modules have been implemented without any issues.

 

The general plan is that "Bookshelf3Shelf260mm1Bay" will not involve design of any additional components of its own but simply integrate the various imported components.

 

For this overall model, I have a sketch with a simple rectangle, the main purpose of which is to define the required horizontal spacing of the 2 posts that are to be imported.
My plan involves joining the posts to the construction lines of this sketch.
This simple sketch is fully constrained, with the bottom line being centred on the origin.

 

I now import the post, refer graphic:

Graphic1_AfterPostImported.png

Issue 1:
The next step involves joining the imported post to the construction line at the left.
It does not seem to be possible to first select the joint location on the post and then on the construction line.
However, it is possible to select in the different order, i.e., the sketch line and then the post.
(Is this a Fusion 360 bug?!)
The joint occurs.
However, the post has remained at the origin whilst the sketch has moved to the right.
(The origin is now (401,0,0))
Since the sketch was fully constrained, this was not the expected behaviour!

Graphic2_AfterJoiningSketchLineToPost.png

I now ground the post.
[Another approach could be to ground the sketch - but it seems that is not possible?]
I then mirror the post.
I then import the bracket, refer graphic:

Graphic3_AfterImportingBracket.png

Issue 2:
When I join the bracket to the desired position on the post (at its lowermost hole), the bracket remains where it was whilst the post moves down 😞
This is surprising given that the post had previously been grounded!
At this point the origin shows as being at (401,0,-191) instead of the expected (0,0,0). (z is vertical)

Graphic4_AfterJoiningBracketToPost.png

 

At this stage the browser is as illustrated:

Graphic5_Browser.png

 

Issue 3:
Whilst working on this, I experienced the issue of the joint origins that had been defined in the component models (with their visibility turned on) not being seen after being imported.
At the present time, this issue is not apparent, (i.e., may have "gone away?).

 

In relation to overcoming the above issues, I should prefer that solutions do not involve breaking the links to the imported components.
It is desirable that future changes to what we can refer to as the "master library components" result in update of the overall models that use those components.

 

Issue 4:
I use parameter in each of the models and am wondering about what is the best way to maintain consistency between each component?

 

For example, there is such as holeSpacing in the models for both the post and the bracket.
It would be desirable that everything is somehow kept "in sync".
How could the bracket be made aware of a change in the hole spacing of the post?

 

As an another example, I have yet to design the "Shelf" module.
It involves holes in the shelf bottom for the two locating dowels.
Ideally the model for the shelf should therefore somehow obtain the diameter and spacings of those dowels from the bracket model.

0 Likes
1,463 Views
9 Replies
Replies (9)
Message 2 of 10

davebYYPCU
Consultant
Consultant

I need the assembly file to decipher the written word.

Why is the sketch not grounded, it is the base article in the system.

 

Parametric spaced holes across various files, not sure about that.

Where are the joints discs positioned and where are the part origins?

 

First impression, you don't need the sketch,  First post is positioned as required on import, repeat for the other imports, and as you don't have the shelf, being the dictating component, you have the cart before the horse and in trouble.

 

Might help....

0 Likes
Message 3 of 10

R4SMEs
Advocate
Advocate

I can provide (have provided?) the model - but there are 3 models involved ...


I don't see a way to save as .f3s - is this because of there being linked components?

I saved the master (overall) model as .f3z, which is attached.

Does that include the post and bracket models or do I need to also send those?

 

I thought of grounding the sketch, but this does not seem to be possible.
Here are the available actions:
Graphic6_OptionsForSketch.png

 

The joints are a little complex ...
There are round pegs in round holes but the diameter of dowel and hole is different and their axes are at an angle.
The idea of this is that it is easier to fit the dowels in the holes ...
So the joint point is where the dowel rests on the outer edge of the hole.

 

I though that the sketch would be a good way to define the required positions ...

 

Regarding "Issue 4" (how one model can know about dimensions of an associated other model) ...
the shelf model could import the bracket model and use the bracket as a cutting tool to cut the locating dowel holes in the bottom of the shelf.  The bracket could then be deleted from that shelf model.
However, that would be a messy and convoluted process!

 

The main requirement is that all components in the overall family should somehow share common aspects such as the vertical spacing of holes.

0 Likes
Message 4 of 10

davebYYPCU
Consultant
Consultant

Got the File, I am first to admit, my models exist in one file, with fasteners etc imported.

Sketch is Grounded, 

Four inserts, jointed the brackets to the post because you had the discs in place,

Rigid group, done.  

 

Is there a problem with this setup?

 

Might help?

Message 5 of 10

R4SMEs
Advocate
Advocate

Many thanks.

 

So .f3z seems to act as a container which includes also the associated linked files.

 

Grounding of the sketch seems to have resolved most of the issues!

But how did you manage to ground the sketch?
As I previously illustrated I don't see that as being an available option (when I right click on the sketch).

 

Also, how did you import and place the posts in the desired positions?
There is no associated Move or Joint operation showing in the timeline.

 

Did you use a point to point or some other variant of the so-called "free move" that is available as part of the component import process?

I thought that a "free move" resulted in a "move" event going into the time line.
I avoid use of moves and capture positions since there is then no clear timeline sequence of events.
I believe that "point to point" moves don't have such drawbacks but I am unfamiliar in their usage (I always think of joints when such needs arise ...).

 

[Probably my alternative of using a joint of the post to the sketch would work now that the sketch has been grounded?]

 

-------------
There is still the open question about sharing of parameters between associated models.

For the bracket model, ideally, (in pseudo code) something like:
import(global family parameters) i.e., hole spacing, diameters, ...
...

 

Ditto for the post model,
import(global family parameters)

 

In this way the bracket and post models would "know" the hole spacing rather than having to define a parameter for each of themselves which could become inconsistent with that used for the other ...

 

A change of holeSpacing in the global parameters (could that be a "model" which only has parameters and no geometry?) would result in a consistent update for the bracket and the post.

0 Likes
Message 6 of 10

davebYYPCU
Consultant
Consultant

You Ground the component that contains the sketch.

Yes, Point to Point when it arrives. (Any way that suits, it's free and where you need it)

Even so, this then requires something to lock the post in place, 

I would have done the same with the brackets, but you gave me joint discs to save the maths.

 

Rigid Group the whole lot, as there is no movement involved, and would save having any joints.

 

Parameters - each imported component brings it's own set, so there are two sets of the same parameters that can't be edited in linked posts, no point.

 

A Master file with parameters and components made in the master file, would work,

but you want to use library parts.

 

I have not explored the Edit in Place for linked components, but I still think working in one file is more logical than your attempt.

 

Save As - the master file, modify for the next version.  (One set of parameters to update - makes more sense to me)

 

Might help....

0 Likes
Message 7 of 10

R4SMEs
Advocate
Advocate

I shall need to play with this import/ point-to-point move to better understand its capabilities and possible limitations.

 

I am wondering if it provides as much flexibility as the joint tools do?
For joints, there are edges, possible offsets, etc, as distinct from "point-to-point".

 

As you indicate, the imported post is not fixed after the move.
Arguably, there is a case to not use the move during import but instead follow up with a joint which locks it in the required position.

 

However, you make a valid point that there is no movement involved in the model so a Rigid Group at the end can lock everything.

 

In that way there is less in the timeline although the magic of how the items got to their positions is not available for inspection.  That seems a big limitation - there is no way to look at the design and understand exactly how the brackets were positioned.  All that can be seen is that the brackets are probably more or less in the intended position.
I trust you and it is okay today! But if I review the design in 6 months there is no easy way to understand exactly how the brackets were positioned.
In contrast, the presence of a joint event in the timeline provides a clear documentation of what was done!

 

----
Regarding parameters, you write:
> A Master file with parameters and components made in the master file, would work, but you want to use library parts.

 

I am not sure what you are getting at here.
Is there a way to have all the components in a "master file" and then pick out only a selection of those required for input to a particular "shelf system model".

 

I believe that there is a tool called "Derive" or something similar? I have never used it (and may even be referring to it by the wrong name?!).

 

In general, there could be a lot of different components even for this simple example of a shelving system:
narrow brackets, wide brackets, ornate bracket, basic bracket, 2m post, 3 m post, post with 2 columns of holes, long shelf, short shelf, ... and not only shelves could be hooked on to the posts ... but also a wine rack, ...
The general idea is that a particular "shelf system model" would choose from the available components.
I am unclear as to whether the components could be together in some sort of "master file"
- can a selection of particular components be somehow plucked out of the master file into the "shelf system model" currently being developed?

 

If there were, for example, 10 shelf systems (A, B, C, ...) whilst more could be envisaged in the future, are you talking about 10 "master files" in which each master file contains a particular bracket, post and shelf?
If the same bracket were to be used in shelf system A and C then repetition would be involved 😞

 

A future change/ improvement to some detail would then involve changes in each of the A, B, C so-called master files?

0 Likes
Message 8 of 10

davebYYPCU
Consultant
Consultant

Well, that’s a different story, for a range of different posts, or brackets and shelves, 

i can see that each version of each as a component, (library of Parts) is fine, what I can’t see, is why placing them as a combination Assembly needs parameter updates.

 

So no master file, but customer requested assembly of parts off the shelf.

 

Point to point Assembly, assumes you don’t need an Offset.  Point to point generally, uses the same points available to align and joints.

 

Yes I think Derive is what you are looking for, which works as, - a Component (with Parameters) is imported, that is linked in such a way to be editable in the customer file, these changes do not flow back to the library version.  However subsequent changes in the Library part, will be notified, and you choose to update or deny those changes.

I have not tried to copy paste or pattern a Derived Component, as this Assembly would need.

 

Might help....

 

 

 

 

Message 9 of 10

R4SMEs
Advocate
Advocate

You wrote:
> ... what I can’t see, is why placing them as a combination Assembly needs parameter updates.

 

The requirement is that each component (in the library of Parts) should be aware of the parameters of the other components, for example, they should all use the same holeSpacing, hole diameters, ... otherwise the bracket peg may not fit in the post hole 😞


I may decide to change one or more of such dimensions later in the design process and, ideally, there should be a mechanism whereby all parts are easily and consistently updated.

 

A combination Assembly (shelf system model A, etc.) wouldn't and shouldn't by itself initiate a change to any component in the parts library from which it has been built.

 

Derive needs to be investigated ... however, it sounds like it may not be what I need - it is inappropriate to be editing an importation in an integrated system product file (shelf system model A, etc.) if we are working on the basis of there being a range of standardised components, each of which is modelled in its own file.

0 Likes
Message 10 of 10

ManikantaAthukuri
Contributor
Contributor
Thanks for this discussion. I have faced a similar issue in my current project. This discussion thread has helped me solve some of the problems in the design. Thanks
Manikanta Athukuri
0 Likes