Assembly 4 workbench

[OficineRobotica]

Looks great, yes. How did you do it ? QtDesigner ?

Yeah....i wish lol. It's just a Inkscape mockup. I'm triyng to learn programming but time seems to always be our most precious commodity. As I already have QtDesigner installed I can give it a try if that can offset some of the programming work for you.

Talking about keyframes(or should we call them keySteps?). Is there a technical reason at the moment that we can't animate from a high to a low value of a variable? Because , within a step range of a animation , if a keyframe is set to a high variable value , going forward in steps, the animation should permit a second keyframe to be set to a lower variable value.

you simulate the rotation/travel distance for the clamp axle ... Could you please give a step by step explanation on how you implemented that?

The idea is to create an LCS in Model that you can rotate and then attach the Part LCS to it. This is only one way to do this but may not be the best, still experimenting:

Thank you so much for this. Yet another workflow to be combined with the new features in 0.19 to build some incredible animations.
P.S. have you seen the tweaks Zolko made to the hexaAssembly in the user showcase thread? It is now completely controllable. Simply beautiful. If he manages to bring up the animation panel,the range of motion could be set up within the physical range of motion of the assembly and then animated with keyframes. I'm so excited with the possibilities.

[arcanemachine]

Does anyone know of a solution to the following problem:

When I modify a sketch, my LCS mappings for that part get messed up.

Many small changes to my sketches alter the values of my Edges, Vertices, etc. This causes my assemblies to realign to a new place since the value of (for example) Edge23 has jumped to a new location, even from minor, non-destructive changes!

I know about the new 'Release' feature, but I need my parts to move to the new location when a change is made.

Also, this is a non-animated assembly. I have considered trying a master sketch as a base to map things to, but this would not solve my issue since the issue occurs in the part before it joins the assembly. I need a way to make sure that Edge23 is always Edge23 and does not change to Edge24 or Edge32.

Is there some workaround that I'm not aware of, or perhaps my modeling strategy needs to be adjusted? Has anyone else found the same problem? Have you solved it? Is it a common occurrence for Edge/Vertex numbers to change from one value to another?

Thanks in advance, I do love the potential behind this workbench.

EDIT: It seems as though Edge/Line/Face numbers are recreated with each new Feature that is added. Perhaps I can link an LCS to an earlier Feature in my design so that there is less of a chance that a later Feature corrupting the names?

OS: Windows 8.1 (6.3)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.19239 (Git)
Build type: Release
Branch: master
Hash: 49e4e45ff38b0459f0f9a76df634f6da4995b731
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)

[ppemawm]

Is there some workaround that I'm not aware of, or perhaps my modeling strategy needs to be adjusted? Has anyone else found the same problem? Have you solved it? Is it a common occurrence for Edge/Vertex numbers to change from one value to another?

This is a well known problem. Search the Forum for "topological naming". The key developers are feverishly working to solve it.

In the meantime, make it a rule to not attach sketches or LCS's to feature edges, vertices, or faces. In many instances it is possible to attach them to origin planes or to a master sketch(es)...as long as there are no geometry or constraint changes expected in the master. So, it takes some ingenuity and forethought. With this approach you can avoid the problem 95% of the time.

[arcanemachine]

This is a well known problem. Search the Forum for "topological naming". The key developers are feverishly working to solve it.

Oh, that is the topological naming problem in action?

Thanks for pointing that out. I didn't understand the nature of the problem. I saw an example given of the topological naming problem and did not realize that was the same problem that is currently affecting me.

I have already gotten in the habit of designing my sketches based on origin planes with parametric offsets, so I'll just do the same with my LCS's from now on.

Much appreciated.

[catman]

Oh, that is the topological naming problem in action?

Thanks for pointing that out. I didn't understand the nature of the problem. I saw an example given of the topological naming problem and did not realize that was the same problem that is currently affecting me.

I have already gotten in the habit of designing my sketches based on origin planes with parametric offsets, so I'll just do the same with my LCS's from now on.

I find that the topological naming is not so bad when using sketches as reference. For example when you put an LCS at the center of a concetric edge of a hole of a part. Instread you could make the sketch visible and mark the concentric edge there and attach the LCS to it. You can still adapt the height with the attachment offset.
I am sure you have found out about the Variables. If you use a variable for the pad lenght you can use that for the LCS offset as well and have it fully parametric. Its a bit more work to set up but very nice once you need to change a part.

[catman]

I have a question about variables and dependency loops.

Please consider the following example setup of a multi-file assembly:

Code: Select all

                                 asmTop.fcstd                                  // has  1 Assembly4 placement of Middle
                                          |
                              asmMiddle.fcstd                                 // has many Assembly4 placements of multiple Low parts
                             /             |              \ 
                Low1.fcstd    Low2.fcstd  Low3.fcstd                //  no links but a local variable 'length'
 

• The file asmTop.fcstd has a variable "overallLength=1000mm"

• The file asmMiddle.fcstd should get a variable localLength=overallLength-100mm.

So I would create in the file asmMiddle.fcstd an Assembly4 Variable "localLength" and enter the expression

Code: Select all

asmTop#Variables.overallLength

The variable value shows up correctly. But when I try to save the file I got an error "Graph must be a DAG". (Directed Acyclic Graph), which means I made a dependency loop.

• When I remove the expression the error is gone.

• When I replace the link with Low1.fcstd#Variables.length all works fine.

• When setting up an external document only containing a spreadsheet with that variable overallLength with value "1000" I am getting an other error: "Failed to recompute asmMiddle#Variables: Invalid type 'l' in property binding 'overallLenght'"

To me it seems that without the faulty expression, there is only information flow from lower to upper documents. When the faulty expression is entered, this is the first time an information should flow down from a top document. I read that a dependency loop is document based and that it is formed when information flows both ways between two documents. So if you count in the placement links the example above does have information flowing both ways.
Up to now I was not aware that a App::Link is considered a dependency relevant item, but doesn't this seem to indicate that both variables and links affect the cyclic dependency issue? Or what am I missing?

If so, how could I use both

• an App::Link based Assembly

• a top down (or centralized) control of a parametric assembly using Spreadsheets or Variables?

[Zolko]

If so, how could I use both

• an App::Link based Assembly
• a top down (or centralized) control of a parametric assembly using Spreadsheets or Variables?

Did you try to have an independent Assembly4 Model that would act as a master_document holding all your values and link it ? I did the following for testing and it seems to work:

• Create an Asm4 Model called MasterControlPart
• Create an Asm4 Model called Assembly
• Create an Asm4 Model called Part
• Insert (link) MasterControlPart in both Assembly and Part
• Define variables in all 3 of them
• In Assembly and Part you can now set the variables values by MasterControlPart#Variables.Length, including operations on it

[catman]

Did you try to have an independent Assembly4 Model that would act as a master_document holding all your values and link it ? I did the following for testing and it seems to work:

• Create an Asm4 Model called MasterControlPart
• Create an Asm4 Model called Assembly
• Create an Asm4 Model called Part
• Insert (link) MasterControlPart in both Assembly and Part
• Define variables in all 3 of them
• In Assembly and Part you can now set the variables values by MasterControlPart#Variables.Length, including operations on it

thanks a lot for testing this and the proposal. Your structure worked for me, too.

It surprised me, because its very similar to what I had tried with the separate spreadsheet document. I had the spreadsheet in a different folder, but your variable file also works when I placed it into a different folder. So I added your solution into my separate speadsheet file.
Interestingly, when I add both to Assembly document expressions (i.e. MasterControlPart#Variables.Length and MasterControlPart#<<spreadsheet>>.Length) they behave differently.

• I can not save nor re-calculate the Assembly document when a spreadsheet variable is linked. I get the same error "invalid type 'long'".

• All works fine as soon as I only have Variables variables lined.

I think the spreadsheet error is not related to any dependeny issue, so hopefully there will be solution to use both. In every case its a working solution around that dependency issue.

[catman]

.. its very similar to what I had tried with the separate spreadsheet document. Interestingly, when I add both to Assembly document expressions (i.e. MasterControlPart#Variables.Length and MasterControlPart#<<spreadsheet>>.Length) they behave differently.

• I can not save nor re-calculate the Assembly document when a spreadsheet variable is linked. I get the same error "invalid type 'long'".

• All works fine as soon as I only have Variables variables lined.

I think the spreadsheet error is not related to any dependeny issue, so hopefully there will be solution to use both. In every case its a working solution around that dependency issue.

I found the problem. The cause was in the spreadsheet itself, I just did not understand what the error was telling me. All values in a spreadsheed must have units (except if a value is only used as a factor in expressions). I had entered the numbers without units.

Code: Select all

               Spreadsheet doc              Assembly doc                                                                  Error
                Value          Alias              Document expression

Wrong:    "1000"       "Lenght"         MasterControlPart#<<spreadsheet>>.Length               Invalid type 'long'

correct   "1000mm"  "Lenght"         MasterControlPart#<<spreadsheet>>.Length               none

Maybe Its worth to note that this "value with explicit unit" does not show up in the expression result of the variable. The assigned values above was shown as "1.000,00 (MasterControlPart#<<spreadsheet>>.Length)"

[ppemawm]

This small project is not about assembly, but it is about the remarkable usefulness of the Variables object in Assembly4. I discovered that the Variables table can be conveniently used in place of a moderately complex spreadsheet.

I first created this model using a spreadsheet and V0.18 for a client who wanted a family of "inducers" for centrifugal pumps. An inducer is an axial flow helical pump in the inlet of a centrifugal pump for the purpose of reducing the suction pressure requirement to avoid cavitation. Inducers are particularly useful for high speed pumps used in the space industry. This fully parametric model is based on design recommendations from the NASA reference 'Liquid Rocket Engine Turbopump Inducers',NASA SP-8052, 1971.

Several screenshots with a few comments about the process are as follows:

The process begins and ends with the Assembly4 workbench. The first step is to create the Variables table as shown above in the expanded Property panel by entering variables, constants, expressions, and comments using the Add variable tool.

Note that the variables are entered in a logical sequence preceded by an alpha character. This keeps them in the preferred sequence when the names are sorted alphabetically on recompute.

Comments can be added by a type string variable.
Expressions can be added by selecting the Value field in the property panel.

Once entered, any of these variables can be used in any sketch or any other object property similar to a spreadsheet.

The weird combination of units in the table is the result of engineering in US units and modelling in metric only.
PS For you non-pump guys, NPSHR is the available suction pressure Margin in excess of the fluid vapor pressure, i.e. total pressure - absolute vapor pressure.
.

Picture1.jpg (85.65 KiB) Viewed 2636 times

Once all of the Variables are defined, the next step is to create the Body's. This graphic shows the blade sweep sketch in which the taper, thickness, inner diameter, and inclination angle are all defined by the Variables table.

The sketch has been rotated 10 deg about the Z axis to move the seam line of the conical hub so that it does not interfere with the blade sweep.

This type of blade is known as a flat plate since the helical lead is constant. High performance inducers require a parabolically cambered blade with variable lead. Someday, hopefully, a developer with add a variable lead helix. I am not a programmer. Or, I suppose you can use a b-spline with a bit more effort.

The blade thickness used in this sketch is the axial thickness not the thickness normal to the blade surface. This is an approximation and a little awkward but close enough for all practical purposes since the blade angles are usually quite small.
.

Picture2.jpg (85.61 KiB) Viewed 2636 times

The helix reference for the blade sweep is defined in its property panel using variables also extracted from the Variables table to specify the pitch, height, and radius. The image shows the blades' (3) boolean fuse with the hub.

The helix is either right or left handed depending upon the desired direction of rotation of the inducer.

One to four blades are possible with this model controlled by the blade number in the Variables table.
.

Picture3a.jpg.png (143.83 KiB) Viewed 2636 times

This is a model of the inducer with a completely new set of input and design variables. The image also shows the tree structure used to develop the model.
.

Picture4a.jpg (91.1 KiB) Viewed 2636 times

Inducer3.2_variables.FCStd

(353.12 KiB) Downloaded 109 times

My copyright file is attached for EDUCATIONAL PURPOSES ONLY, not to be used for construction. Beware, it is possible to break the model with the wrong combination of input and/or design variables. If that happens all you can do is close without saving and reopen. Other than that, it should be stable over the range of variables restricted by the comments shown in the Variables table.

ping...

The Variable object is so already wonderful I hate to ask for more, but please consider the following:

1. It would be nice to be able to change the variable name once entered
2. A description field would be helpful for documentation
3. Why do the constants in the variables show up with so many decimal places? Is there any way to suppress that?
4. IMHO the Add Variables tool is significant enough that it should be made available globally to all the workbenches without going through the Assembly4 interface.

Once again, thank you for this powerful workbench.



OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.19311 (Git)
Build type: Release
Branch: master
Hash: 120b69c74f7dac8c4fa6dbc0a7e10674bde9216c
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United States (en_US)