I have a problem with the assembly editor. In my simulation I have two plane-like objects whose origin is in the corner when I import them into Visual Components. In the standard window I then change the location of the origin, previusly defined by the CAD, so that the origin in Visual Components is in the middle of the object. Now, I want to use these objects in an assembly. So I create a new assembly in the process tab and switch to the assembly editor to define the assembly.
Here the problem starts. First, the origin redefined and relocated in Visual Components is now back in the corner of the object and second the origin of the object is not at the same location as the origin set by the step in the assembly editor. So I observed, that if I place the part visually at the right position in the editor, the created assembly created by a feeder node in the 3D world has a different outcome than specified in the assembly editor. My guess is that Visual Components changes the origin back to the defined position in the middle of the part in the 3D world from the origin in the corner which was displayed in the editor, therefore also changes the position of the part in the assembly in the 3D world. This leads to a misshaped assembly.
In contrast, if I work with the step origin in the assembly editor and leave the plane-like part alone and do not position it as it should, then because of the changing origin from the editor to the 3D world the plane-like part snaps into place, due to the changing of the origin
Can someone please explain to me what happens here and is it in these kind of scenarios favourably to not touch the origin in the 3D world, so that the origin can not change during the creation of the assembly in the 3D world.
In VC each component has its own coordinate system where its content geometry is defined, and then the position of the component is an offset between that coordinate system and the parent coordinate system. (It is actually a tree of sim nodes, but simplifying a bit here…)
If you “change the origin” of a component, it actually just moves all its content geometry around such that there is apparent change in origin relative to the parent (e.g. world).
PM product types have additional “OriginFrame” property, which defines how the product’s component is positioned relative to the “position of the product”. This is a convenience feature, because when you assign the component to a Product Type by setting the ComponentUri, it makes a copy of that component into the Product Type and any changes made to the original component no longer apply.
Where this can get confusing is that some of VC’s simulation logic only deals with components and doesn’t know anything about product instances, so they only see and use the component origin, while PM specific logic deals with product instances. When dealing with product instances the position of the product’s component is calculated taking that OriginFrame from the Product Type into account.
In practice, all motion paths (in conveyors, feeders) and other component containers only know about components so the OriginFrame from the Product Type is ignored. Motion paths usually try to “retain offset” i.e. retain relative position of components, so in most cases the components don’t just jump such that the component origin would be directly on the path or container’s location frame.
Thank you TSy for the very fast reply to my question.
So if I understand you corretly, the difference between PM and the usual “world” of VC is that PM creates a copy with the “changed” origin instead of dealing with the component itself. If I now generate a component via the feeder node or the process node, these nodes then take the component again, while the PM setup is done with the copy and the different origin.
If that is correct I see the problem and again thank you very much for your help
PM product instances are separate “abstract” objects from the components. In the API you can see that e.g. ISimComponent has a property Product which returns a ISimProduct object if that component is associated with a product instance.
The product instance and its (dynamic) component are tied together such that deleting the component makes the product instance die as well.
When you assign the component to the Product Type it does not change the origin in the component, just makes a copy and the OriginFrame is always applied at runtime.
To move a product instance the code needs to move the associated dynamic component, because the product instance is just an abstract object without geometry or other direct presence in the 3D world. However, in all code that wants to e.g. move product instance to location (X, Y, Z) in world, there needs to be a calculation (X, Y, Z) + product.ProductType.OriginFrame and then setting the component position accordingly. If some code works with the component directly without knowing that it is associated with a product instance, then that OriginOffset gets ignored.
