Assembly3 preview

[realthunder]

Well, this was more of a general type of question, not only related to Draft Array. Therefore yes, lets say Draft Array is needed. How hard would it be, to achieve something like that?

It will not be that hard to modify Draft Array code to be used inside PartDesign. On the other hand, it is not straightforward to just add any foreign objects into body without modification, if that's your intention. But it is still doable. I can imagine to have some kind of proxy object acting as a container to bridge PartDesign with its child objects.

On further thought, maybe the same proxy idea can be applied to other bodies to have better support of multi bodies.

[triplus]

I can imagine to have some kind of proxy object acting as a container to bridge PartDesign with its child objects.

From an average external feature point of view, would such bridge take all this complexity away?

It will not be that hard to modify Draft Array code to be used inside PartDesign. On the other hand, it is not straightforward to just add any foreign objects into body without modification, if that's your intention. But it is still doable.

And could such bridge hold the weight of a feature like Draft Line?

[realthunder]

From an average external feature point of view, would such bridge take all this complexity away?
And could such bridge hold the weight of a feature like Draft Line?

Can't say for sure. But I'll give it a try once I got time.

[triplus]

Can't say for sure. But I'll give it a try once I got time.

Great, that is more i can ask for. Note that there is PoM Module:

https://forum.freecadweb.org/viewtopic. ... 98#p160150

PoM Module would still need a bridge, though. But by itself it doesn't need a bridge for "external features". I mentioned PoM Module, as when Part Design (NEXT) workflow was introduced, some room for improvement could still be foreseen, or in short, the bridge was missing.

[Brutha]

Hi All,

Doing some more testing while designing my barn door startracker. Of course, complete overkill to model the hinge, but it's fun to play around with Assembly 3 anyway!

For some reason though, I've got to the point where I can't move the pieces of my hinge; a coplanar face constraint for the highlighted faces (see below) fails, but also the mover tool doesn't seem to want to move the bits at all!

Am I missing something obvious? I've also attached the file.

Cheers

Brutha,

screenshot.png (521 KiB) Viewed 1653 times

Code: Select all

OS: macOS 10.14
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.14555 (Git shallow)
Build type: Release
Branch: (HEAD detached at FETCH_HEAD)
Hash: 49e18e2cb348edc6c565d8a10e59363de23f5880
Python version: 2.7.15
Qt version: 5.11.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedKingdom (en_GB)

[triplus]

OK, i read the rest of the discussion, and a lot of that is still focusing on initial ideas and personal views, on how one would like to Assemble in FreeCAD. Some suggestion i must say are not all that clear and it's hard to decode them, terms like "fundamental" were used. The whole Part Design (NEXT) experience exposed a thing or two about that. People want to use PD in more ways that it was designed for, and it therefore needs to support more use cases in the future. Highly likely the same will apply to Assembly. Now, at some point we will likely be able to say this is it, this is the solution we are comfortable with. But the thing is, such solution will likely be a superset of different solutions. For example an AWS effort currently claims to be an assembly without a solver, but it uses a solver, expression engine. For prototyping purposes expression engine is a good choice, but when things mature i doubt expression engine will be responsible to Assemble in such way? Maybe therefore this would be a good starting point for discussions about FreeCAD tailored assembly solver. And AWS effort would result in FreeCAD Assembly solver.

In general i agree Assembling in such way could and should be explored and possibly supported, but things still need to mature more.

bikeshedding with endless discussions about new logo

LOL I'll grant you that! But you'll notice that mostly end users are taking part in there recurring topics. The majority of developers, thankfully, are not wasting their time on this.

That is the point isn't it? You just can't assume all developers are interested in progressing design aspects of FreeCAD further and in addition for that part being easy or less important. Well, you can assume that, but such assumption usually fades a bit, when you are confronted with some real task, related to this area.

And i guess when it comes to AWS and general discussions. They are now best suited here:

https://forum.freecadweb.org/viewtopic.php?f=20&t=34585

In the end i am rather excited all this solutions exist today. In the past we could only place everything manually. Today we have something people can actually use in their projects and developers to build on. Therefore we are getting somewhere with all of this. It's not like nobody is trying or no progress was made in the past. Sure it was and rest assured it was substantial, including efforts like Part Design (NEXT). And just because some don't want to use existing solution, that doesn't come down to FreeCAD not having Assembly capabilities. It had them for years now and some have utilized it for things like assembling a satellite and sending it to space, hard to argue with that.

[bill]

...AWS effort currently claims to be an assembly without a solver, but it uses a solver, expression engine....

Precisely!
I think, ASMB W/O Solver has its merits, however, critically coupling it to the expression-engine effectively sets it up for life-support dependency immediately! This will eventually become apparent when trying to implement/determine clearances and collision management.

So, that is at least 1 solver-solution it requires.

The Second, which is not mentioned in the forum areas I have read and/or perused, might be in determining WEIGHTS and BALANCES (critical, especially to quote the zlko use case: AIRBUS) of assemblies; a lone LCS-relation is possibly insufficient/unsatisfactory because of lack-of-constraint definition. Additionally, ASM3 needs this solution/tool/feature as well!

That being said, I still feel it is a worthwhile effort; another tool in the FC armada that is worth further development and could be integrated into rthndrs solution.

[Mark Szlazak]

The Second, which is not mentioned in the forum areas I have read and/or perused, might be in determining WEIGHTS and BALANCES (critical, especially to quote the zlko use case: AIRBUS) of assemblies; a lone LCS-relation is possibly insufficient/unsatisfactory because of lack-of-constraint definition. Additionally, ASM3 needs this solution/tool/feature as well!

Can you explain more on the WEIGHTS abd BALANCES issue. I am not clear what you mean by these. Thank you.

[Zolko]

The Second, which is not mentioned in the forum areas I have read and/or perused, might be in determining WEIGHTS and BALANCES (critical, especially to quote the Zolko use case: AIRBUS) of assemblies; a lone LCS-relation is possibly insufficient/unsatisfactory because of lack-of-constraint definition.

Can you explain more on the WEIGHTS abd BALANCES issue.

I think he means to be able to calculate the combined mass and CoG of an assembly, using the info from included parts.

Except that the LCS method is best suited for this question, because the info about the position in the assembly's reference of each part's CoG is trivially available in the assembly if you know it in the part's reference: all you need to do is parse the assembly tree, and for each linked part get it's position vector (it's an App.Placement), retrieve the position of the part's CoG from the part file in it's own reference (that's the part's responsibility to provide), retrieve the placement of the attachment LCS relative the the part's reference (the info is available in the constraint feature), calculate the position of the part's CoG in the reference of this attachment LCS (multiply by the App.Placement.inverse() ) and add everything together. It's literally a 1 liner.

[bill]

Except that the LCS method is best suited for... and add everything together. It's literally a 1 liner.

Yes simple math, maybe not a 1-liner, but certainly not more than a 2, 3, or 4 line macro(s) is how I calculate them now (my coding days are long gone) to manually determine static lift points and shipping/delivery crating of builds. I hate housekeeping after macros that probably should be incorporated features in any application.

My idea is more like shown below. Disregarding the reddish object being machined, determining in realtime, the influence between the sub-assmb (trundle) CoG and the super-assmb CoG; where these solutions fall in relation to one another depending on the axial position(s). How high to mount the selected/highlighted stepper motor to balance the trundle to a near-balanced-condition as reasonable. This is one of the types of features I myself expect out of an "Assembly Workbench".

Just my ideas of what an assemblyWB should be capable of providing. Total weights, weight distribution(to supporting legs,hangers, armatures) overall-dimension(bounded-box), etc. Sort-of-like determining: Assembly attributes

Maybe some of these should be included/incorparated into WorkFeatures!

An assembly to me is yet another interactive tool/model. I want the jet-version; not the helicopter version. As they say in the aircraft business, a helicopter is just a bunch of parts flying-in-formation!

Just dreamin,

45TrndlBlnc.png (66.51 KiB) Viewed 1419 times