component sketches don't move with component

[pludikar]

Hi,

When you create a copy of a component and paste new, then move the component into a new position, the sketch associated with the new component remains in the original location.  Unless I'm missing something, this surely defeats the purpose of having a separate coordinate origin for components.  Shouldn't the sketch be tied to the component origin, and if that moves, then the sketch should move with it.

I've illustrated this in the attached drawing here  - it seems like odd, counter-intuitive behaviour - is this the way it's supposed to work?

BTW - With a more complex component I got a "failed to get owner occurrence transform" error when I pasted new.  I know this was reported over a year ago (see here) - I discovered that if you open the offending yellow history event then close it - it goes away (at least it did for me).  is it still on your todo list to fix?

Peter

[masa.minohara]

Hi Peter,

Thank you for posting! When you move a component, sketch should move with the component. How are you moving a component? Are you selecting a body instead of a component by any chance? Would you be able to record a screencast of the behavior?

Regarding the other issue, it seems like the development is still working on it. Hopefully we can fix it in the near future.

[pludikar]

Hi @masa.minohara

I'm moving using component not body.  It's also the default when you paste new - as you can see in the screen cast.

Peter

[HughesTooling]

While pasting you moved the component and captured its position, when you edit the sketch the timeline rolls back before the capture position so the edit sketch returns to it's original position. The only workaround will be don't move the component while copying just paste in position then roll the timeline back to before the sketch and position the component then roll the timeline to the end. Make sure the new component is active when you do the move.

Mark

[pludikar]

Hi @HughesTooling

I can see that editing the sketch moves the timeline back, but what you suggest is a work around that's a bit awkward and most people won't remember - I'm not even sure that it works.  IMHO when you "paste new" - you are automatically placed in a "move" mode - at that time F360 should inherently move everything together - ie set the position after pressing "OK" to accept, instead of "on paste".

Any chance you could post a screencast showing how you would set the position after moving the timeline back?  Unless I'm missing something, the paste new action places the sketch on the timeline first and if you roll back to the sketch, there's nothing to move and therefore can't position anything.

Regards

Peter

[pludikar]

Interestingly, when you hover over the sketch in timeline, the outline shows in the correct place, and not in the original location - something seems amiss here.

Peter

[HughesTooling]

In your simple case it seems easy for the sketch to move but what if the sketch contained projected edges and references to other parts and you completely reoriented the part, all the references would brake. So it's not a workaround it's just the way the timeline works. For your example it might be easier to paste without a move then edit the sketch so it's in the correct place. If you export your design as a f3d file and attach to this thread you'll get more help. The share links are too much hassle and you'll find you don't get much held if you use them.

Mark

[HughesTooling]

Here's a screencast that shows how you can drag the saved position feature before the sketch to achieve what you're after.

This will only work on something simple, if you references other parts you'll get problems like this where the hole projected from another sketch misses the part.

Mark

[pludikar]

@HughesTooling

Hi Mark,

Many, many thanks for your time - I really appreciate it.

Hmm - I can repeat exactly what you showed, and I get the same results.  However, when I try it on my original model, the copied component jumps back to the original location after moving the capture element in the timeline.

I think I'm following exactly the same steps, but getting different results - can you spot what I'm missing?  I still think F360 has some way to go to make it intuitive.  The model I'm using can be found here

Peter

[HughesTooling]

If you want to make components that can be moved in the way you show there are a couple of rules you should follow.

One, you can't make references to other components or the move will break the references or give unpredictable results. You'll need the component to be totally self contained.

Two, you need to make your sketches fully constrained, this is a general rule and the only fixed reference you'll have is the component origin. So the easiest way is to build your sketches around the origin. It is possible to position an empty component before you have any sketches so you have the origin in a convenient place. In the screencast below I create an empty component and position it then start the sketch and create a solid. When I Copy Paste New the new component has a saved position and not a joint, I don't like the way the joint is converted and I'll make another thread about that. The screencast also shows the difference between a joint and a move point to point, I got a bit lost with the move command as I don't use them because they're not parametric, notice how the 2 components using joints update to match the rectangle I've anchored them to.

I've attached my file from the screencast. My advice if you want help with a design is attach it to the thread, don't use the A360 share links because they are to much of a time waster and people don't bother downloading and helping you'll get more interest with some bait. To export right click the top node in the browser and select Export and save as an f3d file. To open my file use New Design From File on the file menu.

Mark

[pludikar]

Hi Mark @HughesTooling

That's hugely helpful - many thanks, I'd give you more kudo, if they'd let me :-).  The real gem is now knowing that one can relocate the origin of a new empty component before adding sub components.  I've been keeping sketches fully constrained for a long while, but this is the first time I've ventured in any depth into the art of building components of any complexity.  The rules you outlined now make enormous sense when trying to build an assembly of components.  

What I was attempting to do was to construct a cabinet, which I had no problems with - my problem arose when trying to add different sized drawers, using the same drawer base component.  I couldn't figure out how to move the component origin to where I needed the first drawer to be, and I started sketching relative to the cabinet, which I now know was a mistake.  I'm sure I'll be back, but in the meantime many thanks again, that was truly useful.

Maybe you should give Lars Christiansen, or someone at Autodesk fusion a nod to make a tutorial about workflows designing more complex assemblies - Lars did a great tutorial on making a drawer- he could expand that to designing a drawer into a cabinet or drawer space.

Peter

[HughesTooling]

@pludikar I put a request on the ideastation for the joint to be copied with the component Here in case anyone wants to vote.

Thanks Mark

[pludikar]

@HughesTooling

Hi Mark,

It definitely has my vote, but I believe F360 makes the component functionality mush more complicated than it needs to be.

I would like to see the component as a self contained object (just as it is in real life).  Thus, when you move the component, everything, and I mean everything, inside it moves with it.

I have a background in software, and F360 obviously uses OOP (object oriented programming) internally, but they've missed the point of OOP because it should translate directly to UI - they only do some of the job.

At the moment you can create a component, as as soon as you add one or more sub-components, it stops being a component - try making a drawer component with 4 side sub-components and a bottom sub-component.  You can't make a join on the drawer - the join dialog doesn't recognise the drawer as a component - that's a fundamental disconnect with OOP.  You can make as-built joins to glue the components together, and then move the whole lot, but then you are not moving the drawer - you're moving the sub-components.

I am putting together a CNC router to make cabinets - it means I want to design a cabinet model, that I can easily take apart and lay out flat on a 4x8 sheet.  (I found the easiest way of doing this is to import the whole cabinet design as a component into another design - it allows me to dismantle to cabinet, but still keep the original cabinet in one piece).  Having joints is a pain, because you have to undo them all to perform the last step.  It would frankly be a million times easier to put a drawer together as a component, with loosely coupled parts, that I can place in a cabinet space - then dismantle the parts to lay them out.  I can't do that at the moment.

I think if I put in a properly worded idea, it could get a lot of votes.  What do you think?

Peter

[HughesTooling]

Can you attach a file. You should be able to create joints at all levels of components as assembly and subassemblies. In your component you're using just a container for the other components have you tried making a joint origin to make joining\positioning easier.

Mark

[HughesTooling]

I missed the last bit of your post about flattening the design for machining. I think there are plans for nesting as as you've found assemblies are not easy to transfer to CAM for machining. I make moulds so only machine one part at a time and they can be machined in place. 

I found this video on youtube, not sure if it'll help as it's not something I'd use.

https://www.youtube.com/watch?v=7SY367qt3YQ

Mark

[jeff_strater]

I've hesitated commenting on this thread, because I don't want to raise any controversy, but I'm going to comment on a couple of points anyway.

• There was a comment (that I can't find just now) that said something to the effect that "the joint should be copied with the component, because it is part of the component".  This is where we run into problems, conceptually as well as in the implementation.  The Joint, in fact, is not owned by the component, in the case cited here.  It is owned one or more levels up.  Which is why it does not get brought along with either Paste or Paste New.  I'm not convinced that it should get brought along, conceptually, because it is not part of the component being copied.  I completely understand the desire for the joint to come along, but if I think about it, it's not clear even how such a thing should behave.  Say you have Component A and B, joined together with a rigid joint at specific locations in both components, owned by the root component.  If you copy/paste component B, should it create the same joint at the same location on Component A?  If so, then you would have two component instances occupying the same 3D space, and you would have to edit the joint to get it to the new location.  What if your desire is to join B to a third component C?
  
  Inventor has the concept of an 'iMate', which, essentially is "half of an assembly constraint".  For instance, you can have an iMate which is a Mate constraint, but which has an opening for another component, which also has a Mate-flavored iMate, and together they make a complete assembly constraint.  The best approach here would be something like this for joints.  In the above example, Component B would bring along a "joint half", which is a Rigid joint with only one component plugged in, and then at Paste time, you would select geometry on another component which says where to create this joint.
• From @pludikar's comment:  "I would like to see the component as a self contained object (just as it is in real life).  Thus, when you move the component, everything, and I mean everything, inside it moves with it.".  It depends on what you mean by "move" here.  If you mean "comes along when you copy/paste new", I'm pretty sure that this is what happens today.  A component owns a set of:  Bodies, sketches, work geometry, and child components.  All of those items which are owned by the copied component will be in the new component.  However, if by "move", you are talking about moving in 3D space, that's a different story.  Without going too deep, that is intentional.  All Fusion components are "flexible", meaning that positions of instances of sub-assemblies can all vary.  So, moving a component which is an assembly (meaning, has child components) is really meaningless, because the leaf-level components can all be moved independently.
• Another comment is: "At the moment you can create a component, as as soon as you add one or more sub-components, it stops being a component - try making a drawer component with 4 side sub-components and a bottom sub-component.  You can't make a join on the drawer - the join dialog doesn't recognise the drawer as a component - that's a fundamental disconnect with OOP.".  That is true in one sense, but not true in another sense.  In Fusion, everything is a component.  Adding sub-components does not make it "stop being a component".  What is true, though, is that joints have to be made to geometry, and a pure sub-assembly (meaning a component which has only child components, no solid geometry) cannot make a joint, this is true.  Joints are made to the component which owns the geometry.  You can, however, make a sub-assembly which does own geometry (sketches, or even solid bodies), and then you can create joints to that component.

Hope I have not made things even more muddy.

Jeff

[pludikar]

@jeff_strater

Hi Jeff,

You won't get into any controversy from me.  I would just like to help make a great product even better and more user friendly.

• Your first point is good and has helped me understand how to get from a jointed assembly to an assembly that can be nested on a board.

• On your second point: "A component owns a set of:  Bodies, sketches, work geometry, and child components" - from the evidence I've experienced, I don't see that as necessarily being true.  If it did then it would also own a common origin for all these, and if the parent component moved, then the origin would move, and all those child elements would be carried along with it.  It means that if you had a component that contained nothing but children components, when you moved the parent, absolutely everything would stick together - that clearly doesn't happen, as you can see in the screencast I posted earlier in this thread.  A component ought to be the owner of it's own co-ordinate space - and all sub elements reside in that space.  From a OOP design point of view, I can see calculations being much easier to manage by doing them at the component level, so that no matter which level the calculation is being performed, it is only interested in it's own co-ordinate space and not some neighbouring or parent component - which it seems to be doing now.  In particular,  my suggested approach results in a much more intuitive UI - IMHO I would say it still has a long way to go to achieve that!

• "So, moving a component which is an assembly (meaning, has child components) is really meaningless, because the leaf-level components can all be moved independently." - what I'm suggesting does not change component independence.  As an illustration - suppose you have a workshop in an elevator and you are designing a drawer assembly.  It really doesn't matter which floor the elevator is on, everything you are doing to the drawer is relative to the elevator floor.  Presently with F360, when you design a component on the ground floor you leave the sketches on the ground floor, as the elevator goes to another floor.  That's not intuitive.

• On your third point: "What is true, though, is that joints have to be made to geometry, and a pure sub-assembly" - I'm not sure why that has to be the case - the origin could easily be classified as a geometry - and all components have an origin and three planes.  As it is, once you create an empty component, it can be moved, which implies that there's something in the component to reference, and that's the minimum that a joint should need.

I've never been one to do things by rote - I have had a life time of pushing functional boundaries to make things easier to use - I guess it came from my formative years as an Electronic engineer designing equipment for the military, where you know things have to be intuitive and easy to learn, because the lives of soldiers could depend on it.

Peter

[TrippyLighting]

Following the example you outlined above I created an empty components with only an origin in it.

When I move the upper level component the origins of the lower level components move with it. You an still move them independently until you have actually assembled the lower level components in some way to the user level component suing the joints in Fusion 360. the you cannot move the lower level components independently from the upper level components.

Anyway, interesting discussion and thanks for starting it!

[pludikar]

@HughesTooling

Hi Mark,

Many thanks for the link to Patrick Rainsberry's video and nesting script - I already knew about his dogbone script (credit should mostly go to Casey Rogers), but this was very helpful.  The downside of the script, and hence back to the original discussion is that Patrick's nester script relies on planar joints between cabinet parts and the 4x8 (or whatever) stock.  As you can't have a component joined to two separate components in different locations and orientations, it means you have to remove all the joints in the cabinet before using the nester.

This makes F360 unnecessarily cumbersome, and I don't think it needs to be that way.

Peter

[pludikar]

@TrippyLighting

Hi Peter,

Apologies for the delay - Many thanks for the screencast - it does exactly what I expected.  I replicated your workflow, and no surprise, it did the same.  However, at the end of my screencast I combined two components (the cube cutting the hex), and you can see the moment I selected the cube tool, it's position moved to the highest parent origin.  Does the same happen to you? I've experienced similar to this with sketches - hence my original post.  However, for the moment this model is behaving itself wrt sketches. 

Peter