Assembly 4 workbench

[catman]

A suggested for a usability improvement

The Assembly 4 Add-a-LCS button does not work when a none-top element is selected.
After adding a new LCS, pressing the Add-a-LCS button again it does not work, because no top item is selected. I select the Assembly4 model and then press the button again, then it works.

Since I find that I am adding quite a few LCS for some parts (e.g. with an adapter plate one for each hole) it would be great to streamline that a bit more to be able to select then in a row.
It is great that already an automatic name is generated and suggested. With that it could be the perfect drill in working only the 3D window: LCSbutton, <Enter>, geometry, LCSbutton, <Enter>, geometry, etc.

Would it be possible to modify the button that way?

[Zolko]

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.

1) this is not possible in FreeCAD: an object's name cannot be changed, only its label, but properties have no label
2) there is already one, but I don't know how to show it
3) I don't know
4) yes, I agree: there is already an "Spreadsheet" button, there should be one for creating a FeaturePython object (that's what the Variables is). You should suggest it in the Open Discussion forum probably.

Would it be possible to modify the button that way?

I'll try. There is a reason for the current behaviour: if you have multiple Parts in the same document, selecting a Part will put the LCS into that Part. When nothing is selected then the LCS is automatically put into the Model. What I could do is that if a datum object is selected then the next datum object (an LCS) will be put into the same part as the selected one. Thus, you could chain-create LCS.

[catman]

There is a reason for the current behaviour: if you have multiple Parts in the same document, selecting a Part will put the LCS into that Part.

Yes, acutally I am using that quite a bit. Initially I wondered why you would create this added "Parts" folder. In the mean time I made it a habit to put in the Model folder only links, document external or document internal (from the Part folder). That way its easy to clean up the model folder and rebuilt it if things get corrupted (there are still some issues, but i have not yet tracked them down to be re-producible). So the feature to create LCSs for models outside the Model is essential, indeed.

I feel that by using the Parts folder I can better control the LCS interfaces of the design item. I am only importing the relevant interface LCS from any of the sub-models.

So my standard use of Assembly4 looks like this

Code: Select all

 Parts
    basePlate
        LCS0, LCS_legAttach1, LCS_legAttach2, LCS_legAttach3, LCS_legAttach4
    strut
        LCS0
    handle
        LCO0, LCS1_Grip
 Model
     LCS_0
     Constraints
     Variables
     basePlate001
     leg1
     leg2
     leg3
     leg4
     handle1
     LCS_Grip                           // imported Datum from handle1

I am not sure that was how you intended its use, but while setting up parts re-usable from a library this seems to make most sense to me. If your idea was different I would be interested to learn about it.

When nothing is selected then the LCS is automatically put into the Model.

Cool. I did not really notice that. Mostly I have something selected in the tree at any time, but thats good to know.

What I could do is that if a datum object is selected then the next datum object (an LCS) will be put into the same part as the selected one. Thus, you could chain-create LCS.

Yes. that would absolutely improve it. Also it is a rule that is very easy understand and remember.
It would allow me (in the example above) to hammer out the basePlate LCS's once i selected the basePlate for the first one.


There is another thing I noticed. When I create Group Folders within the Model I can not import datum object any more. As far as I understood a Group Folder does not have an own local coordinate system and is more or less transparent to the internal geometry hierarchy. Is there a technical limitation against considering objects within Group folders as on root level to the Model?

Here is what I think should be considered identical to the example above

Code: Select all

 
 Model
     LCS_0
     Constraints
     Variables
     basePlate001
     Other                                             // this is a FreeCAD Group Folder 
            leg1
            leg2
            leg3
            leg4
            handle1                                 
     LCS_Grip                                       // imported Datum from handle1

[catman]

I am sorry, but I have another one

This is how a selected LCS looks like in my V0.19 version. It also looks like that when I am inserting a linked parts. I never know which axes I should rotate about. Its quick to trial-and-error with the dialog push buttons, but on the other hand, its really a rather stupid idear to highlight the active LCS all green in the first place... However, probably its a system thing a single workbench can not do aynthing about. I am sure it must have been discussed before - but I could not find any posts about it.

Asembly4_Selected_LCS.png (25.14 KiB) Viewed 1803 times

Suppose you need to add 100mm up. Now is it X,Y or Z?

[ppemawm]

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.

4) yes, I agree: there is already an "Spreadsheet" button, there should be one for creating a FeaturePython object (that's what the Variables is). You should suggest it in the Open Discussion forum probably.

Before I do that, is it possible for you to provide the Add Variables tool as a stand alone macro which could then be installed with the AddOn Manager and custom toolbar?

[saso]

Before I do that, is it possible for you to provide the Add Variables tool as a stand alone macro which could then be installed with the AddOn Manager and custom toolbar?

I also prefer this variables over the spreadsheet in most cases and I have been using them for quite a long time (some years?). Before it was possible to add them with python commands, now the DynamicData add-on is also already available for some time...

[ppemawm]

the DynamicData add-on is also already available for some time

OK, thanks.
Seems as though I need to review the new workbench/macro additions more often.

[Zolko]

Thank-you ver ymuch for your testing. A new version (0.7.12) of the workbench is out, you can update with the AddonManager:

What I could do is that if a datum object is selected then the next datum object (an LCS) will be put into the same part as the selected one. Thus, you could chain-create LCS.

Yes. that would absolutely improve it. Also it is a rule that is very easy understand and remember.

Done

2. A description field would be helpful for documentation

Done: the description is visible as tool-tip when the mouse hoovers above the variable name.

[catman]

Thank-you ver ymuch for your testing. A new version (0.7.12) of the workbench is out, you can update with the AddonManager:

Its an honor to get the testing feedback returned as feature so quickly . I was not sure how much feedback you can stand . Please give me a hint if its too much...


Yesterday I noted an effect with the visibilty of LCS. Maybe you could confirm that on your system for me. When I try to toggle the visibilty of the main LCS (LCS_0) in a linked part document in the Model, I can not switch it off from the tree.
There is a workaround: I go to the separate part document and then set the LCS visiblilties as I like them. That reflects to the upper documents.
Generally I am clicking a lot LCS visibilties in my models, because its disturbing a bit to see every sub-sub-sub-sub model LCS in the final assembly file. A context menu function to make all LCS invisible down the path of a selected item in the tree would be another useful addition. The use of LCS in practival use is imho always limited to to the root level and the next lower level of a Assembly4 Model. The root LCS are the interfaces a part would offer to the outside world. The next level all all the LCS that a new part could be linked to. Before linking in a new part, I often check the available LCS of the other part visually (if they have been badly named). So if technically feasible, maybe toggling root level LCS and 2nd Level LCS would be also a possibility. The drawback is that it then the GUI is not as intuitive to new users any more.


If you check out A2plus, you will not that they have 2 Import buttons for assemblies:

• the full document

• only parts of a document

Currently I have the case that I have constructed a part that needs to be used as a left and right hand version. The only difference are the counterbores. In one for the left side use they have to be left, for the right side use they have to be right. I am thinking at what level I am splitting the parts in two documents. It would rather use sketch cross-references to build the two version in the Parts folder and link them into the Assembly4 Model with different LCS (one for left and one for right attachment points). But that way I can not put them into the top assembly, because I only can connect the whole file to one single LCS.
This might be a more demanding feature, but probaly worth doing in the future. I used it very often when I worked with A2plus

Another usefult thing would be a kind of "switching" App:Link. Maybe something like this already exists? I have in mind a switching nore that I can attach to two linked parts. With a button click I can switch them from one item to the other. Two very obvious uses would be

• different Level-of-Detail (LOD's) for some complex subparts

• different options for a part, e.g. different tools attached to a robots hand.

I am sure there are other uses... If that does not exist yes, I am thinking of suggesting that to @realthunder..

I am testing your new version tonight and will give you feedback.

[OficineRobotica]

Yesterday I noted an effect with the visibilty of LCS. Maybe you could confirm that on your system for me. When I try to toggle the visibilty of the main LCS (LCS_0) in a linked part document in the Model, I can not switch it off from the tree.
There is a workaround: I go to the separate part document and then set the LCS visiblilties as I like them. That reflects to the upper documents.
Generally I am clicking a lot LCS visibilties in my models, because its disturbing a bit to see every sub-sub-sub-sub model LCS in the final assembly file. A context menu function to make all LCS invisible down the path of a selected item in the tree would be another useful addition. The use of LCS in practival use is imho always limited to to the root level and the next lower level of a Assembly4 Model. The root LCS are the interfaces a part would offer to the outside world.

What I have tried to do to mitigate the "problem" of the always visible LCS's is to put them into a folder(created with the button next to Create part and create body in the part design workbench) but when moved inside that folder the LCS's are not visible to the "Model"(assembly) anymore. Perhaps Zolko could look into that.

Solving the folder problem would solve the hide/unhide LCS's problem in a quite elegant and intuitive way for every user. Also would mean a much more organised tree being able to create folders of LCS's in the parts or folder in the model thus separating them.

Just my 2 cents.
Cheers