Good catch: the Cancel button cancels the placement of the part. There is a dialog to insert the part does have also a Cancel button which cancels ...
Assembly 4 workbench
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Assembly 4 workbench
Re: Assembly 4 workbench
it sucks. It only works with very simple parts. Actually, this is a FreeCAD bug, that Asm4 tries to use at best.
Re: Assembly 4 workbench
Well, can you post a FCStd sample file that can explain this feature working correctly?
So we can follow your way and use it correctly.
Thanks
Re: Assembly 4 workbench
Hello, could-you please update to the latest v0.11.9 version that fixes this I hope. Still not perfect (doesn't store Variables for different configurations, nor Placements of parts that have been manually placed) but it should at least work for most things.
Re: Assembly 4 workbench
Hi,
unfortunately, there still are some problems compared to earlier versions, which might need a second look.
It seems that commit 656d2b broke compatibility with older configuration sheets, when the ASM4_CONFIG_TYPE string was changed.
This basically prevents such older configurations from showing up in the UI, although they would otherwise load without problems.
It might be a good idea to add the old identifier to a list of allowed values or the like (see here), so that automatic compatibility with older models is maintained.
More importantly tho, the checks for 'Asm4EE' of property AssemblyType prevent correct handling of fasteners and some other features, which e.g. report back Part::Link.
A solution might be to for now limit (or rather extend) configuration sheet contents to objects for which isAsm4EE() is true (see here). This can be changed again later, if needed.
In the current state, the entries in column OBJECT_ASM_TYPE_COL seem somewhat obsolete anyway. Should this column be dropped or be replaced by SolverID?
In any case, as I understand that Variables/Variant Links etc will also need to be stored at some point, some format-changes in the tables are to be expected in the future.
I suggest to add some format-version information now (nothing fancy, just an integer Field B2 or the like) to make it easier to cope with change as more features are added. I can put together some code for that as well, if you like.
unfortunately, there still are some problems compared to earlier versions, which might need a second look.
It seems that commit 656d2b broke compatibility with older configuration sheets, when the ASM4_CONFIG_TYPE string was changed.
This basically prevents such older configurations from showing up in the UI, although they would otherwise load without problems.
It might be a good idea to add the old identifier to a list of allowed values or the like (see here), so that automatic compatibility with older models is maintained.
More importantly tho, the checks for 'Asm4EE' of property AssemblyType prevent correct handling of fasteners and some other features, which e.g. report back Part::Link.
A solution might be to for now limit (or rather extend) configuration sheet contents to objects for which isAsm4EE() is true (see here). This can be changed again later, if needed.
In the current state, the entries in column OBJECT_ASM_TYPE_COL seem somewhat obsolete anyway. Should this column be dropped or be replaced by SolverID?
In any case, as I understand that Variables/Variant Links etc will also need to be stored at some point, some format-changes in the tables are to be expected in the future.
I suggest to add some format-version information now (nothing fancy, just an integer Field B2 or the like) to make it easier to cope with change as more features are added. I can put together some code for that as well, if you like.
Re: Assembly 4 workbench
good catch ... but this might make it live on forever. What about :Thowil wrote: ↑Tue Feb 15, 2022 10:56 pm It seems that commit 656d2b broke compatibility with older configuration sheets, when the ASM4_CONFIG_TYPE string was changed.
This basically prevents such older configurations from showing up in the UI, although they would otherwise load without problems.
It might be a good idea to add the old identifier to a list of allowed values or the like (see here), so that automatic compatibility with older models is maintained.
Code: Select all
def isAsm4Config(sheet):
if sheet and sheet.TypeId=='Spreadsheet::Sheet':
if sheet.get(HEADER_CELL)==ASM4_CONFIG_TYPE:
return True
# old/legacy config header
elif sheet.get(HEADER_CELL)=='Assembly4 configuration table':
return True
else:
return False
You're right about Variables and variant links. So, why-not ... does it cover all corner cases ?Thowil wrote: ↑Tue Feb 15, 2022 10:56 pm More importantly tho, the checks for 'Asm4EE' of property AssemblyType prevent correct handling of fasteners and some other features, which e.g. report back Part::Link. A solution might be to for now limit (or rather extend) configuration sheet contents to objects for which isAsm4EE() is true (see here). This can be changed again later, if needed.
EDIT: I made a recent change that clarifies AssemblyType and SolverId: AssemblyType is set to Part::Link, so it indicates that the assembly container is a Std_Part, and components are linked into it, and SolverId is set to Asm4EE, so that later is is possible to handle other types of solvers (I'm trying to port the A2+ solver to Asm4. In this case, AssemblyType would still be Part::Link but SolverId would be A2+). I pushed this to the development branch
yes, that is definitively a good idea. Wouldn't the WB version be the best string there ? There is some code in InitGui.py:I suggest to add some format-version information now (nothing fancy, just an integer Field B2 or the like) to make it easier to cope with change as more features are added. I can put together some code for that as well, if you like.
Code: Select all
def Initialize(self):
# Assembly4 version info
# with file VERSION
versionPath = os.path.join( Asm4_path, 'VERSION' )
versionFile = open(versionPath,"r")
version = versionFile.readlines()[1]
Asm4_version = version[:-1]
versionFile.close()
'''
# with file package.xml
packageFile = os.path.join( Asm4_path, 'package.xml' )
metadata = FreeCAD.Metadata(packageFile)
Asm4_date = metadata.Date
Asm4_version = metadata.Version
'''
And if you manage to make it work with the package.xml file, that would be ever better (it fails for me). If you do a PR, please do it against the development branch. Thank-you for your help
Re: Assembly 4 workbench
Thanks for the uodate, just tried the new update... now the "Visibility" attribute of a part is working, but what else can I do with this "Configuration" switch setting? In the screenshot I attached you can see different columns like "Assembly.Type", "Pos.X" ...and so on.. can I insert manual values or formulas in order to take effects of these attributes?
I tried to displacement a part from another (linked with LCS) but seems it doesn't work... can you explain the main working features please?
- Attachments
-
- screenshot.jpg (69.64 KiB) Viewed 4370 times
A thought on terminology
Hi All,
This morning, as per my other post, I finally clicked on how Assembly4 works, and am now very happy indeed with it!
But it has prompted a thought: the thing that really prevented me getting there earlier was probably the terminology. I found the idea of "linking local co-ordinate systems" quite an abstract mathematical idea and difficult to relate to real life models.
Does anyone think there is an argument for renaming LCS to something like "Connection points" or "Connectors"?
I think that might have made me realise much more quickly how you assemble things: simply define features on two different parts, and specify how they link to each other.
Anyway, just an idea!
Cheers
Brutha
This morning, as per my other post, I finally clicked on how Assembly4 works, and am now very happy indeed with it!
But it has prompted a thought: the thing that really prevented me getting there earlier was probably the terminology. I found the idea of "linking local co-ordinate systems" quite an abstract mathematical idea and difficult to relate to real life models.
Does anyone think there is an argument for renaming LCS to something like "Connection points" or "Connectors"?
I think that might have made me realise much more quickly how you assemble things: simply define features on two different parts, and specify how they link to each other.
Anyway, just an idea!
Cheers
Brutha
Re: A thought on terminology
a coordinate system is a precise mathematical construct, we should not rename it. But you're right that "linking" them is probably not the correct terminology. What about "connecting local coordinate systems (LCS)" ? Would that be easier to understand ?Brutha wrote: ↑Sun Mar 06, 2022 12:12 pm But it has prompted a thought: the thing that really prevented me getting there earlier was probably the terminology. I found the idea of "linking local co-ordinate systems" quite an abstract mathematical idea and difficult to relate to real life models.
Does anyone think there is an argument for renaming LCS to something like "Connection points" or "Connectors"?
The Assembly4 documentation is now quite outdated, if you have proposals to improve would be helpful.