in an Assembly edit a part in separate window causes disassociation of constraints

[Drutort]

I believe I have seen this since v26? I have been working around it, but its quite annoying and I am not sure if it has to do that im using Global parameters and a number of configurations in generating a number of part features?

The issue, opening an assembly, right click edit part in separate window.

regen the part features, while having this part still open in its own window

If I go and click on any part of my assembly it goes crazy and my constraints are lost.

But here is the kicker only while I have that part in its own edit window, as soon as I close it, then the assembly for the most part goes back to normal.
Some constraints like gears and angles get messed up.

So I either edit the part in the assembly, or do not mess with my main assembly at all until I close the part that is in its own window.

This is quite time consuming during design process, and I did not have this issue a few versions back.

The assembly and parts i have been using where made a few versions back, I have tested fresh parts designed in latest version and this happens.


I am sorry if this is a known issue or if others have talked about, but I thought that this would be addressed maybe a major version of SP but it has not, and I took the time to write this post.

(most all my systems are running windows 11)

edit:

more testing a simple asm that was made in v27 seems to work if I press the full regen in the assembly

In a more complex asm this is not the case, and the constraints stay messed up, even after closing the part that was edited or simply regen on its own.

I try not to save and reopen and start over otherwise some constraints i have to redo



I did a screen capture of a simple asm that displays this issue.

The only difference with the more complex asm is that after pressing regen on the asm it will not fix and go back, and those constraints being messed up stay that way.
only if I close the edit window of the part then the constraints somewhat go back to normal. ( I can not share the files of said asm)

edit:

SO apparently I got this simple asm as I was working with the gear script to do almost what my main asm does.
This asm is using global param and configurations, as I was trying out multiple gear configurations.

(Partial) solution had to do with auto regenerate:

Here's info about Regenerate and setting Auto-regenerate:

Articles

help.alibre.com

Here is a thread where that secret regenerate combo was discussed, but also a strong caution from Alibre not to use it:

In 2D drawing, how to draw center-line for one hole ?

Dear In 2D drawing, how to draw center-line for one hole ? Thanks

www.alibre.com

Full solution included going and getting rid of broken and even suppressed constraints, that some how have an impact on the asm at times even though they are suppressed?
After cleaning that up, I can have auto regen on and work on the parts, do part full regen go back to asm or have it next like the pic below and asm constraints are all happy and working.

(auto regen does not stay on by default but off? for me)

 

[Ex Machina]

I have not had that in v26 or v27 and I have run both versions in Windows 10 and Windows 11.

However, make sure that you insert a part into an assembly when it is finished or almost finished. Editing a part and deleting a surface that is used in a constraint will cause a cascade of constraint failures. Alibre has the tendency to fail all of the constraints that reference parts that in turn reference that part, and so on. So you can get 30 of the 50 constraints failing and in reality it's only 1 that's gone wrong.

 

[Drutort]

I have not had that in v26 or v27 and I have run both versions in Windows 10 and Windows 11.

However, make sure that you insert a part into an assembly when it is finished or almost finished. Editing a part and deleting a surface that is used in a constraint will cause a cascade of constraint failures. Alibre has the tendency to fail all of the constraints that reference parts that in turn reference that part, and so on. So you can get 30 of the 50 constraints failing and in reality it's only 1 that's gone wrong.

I understand the issue is not that.

I can simply regenerate the part when its in a separate window being edited from the assembly, go back to the assembly and the constraints will go crazy.

This was not issue pre v26

 

[HaroldL]

For some reason it is necessary to Rebuild the assembly as the first step upon closing a part edit window and returning to the assembly. At least that is what I have learned to do and it keeps my assemblies intact.

 

[stepalibre]

I experienced a similar effect awhile ago. I made subassemblies of piece parts to solve this issue. Try adding the assembly as a subassembly and then edit the gear. It depends on what constraints you use and your setup. The issue I had was related to InterDesign relations I think, I'm not sure but I redesigned the assembly. I've noticed in Alibre it does matter how you build a design, in what order are constraints, equations and reference geometry to properly regen for some designs. I'm hesitant to call it a constraint/regen bug because I think some of it is but it's also how Alibre's regenerate/update system works. It's more finicky than other CAD systems (in someways).

When we change/regen a part, the assembly constraint system needs to reevaluate everything with constraints for motion. I loved Simulate for Geomagic Design and Dynamic Motion before it. They were a separate environment that did all the constraint solving work. Alibre's current constraint/motion system as merged with the rest of the assembly system/environment which I think is causing conflicts between the systems/features. I don't know if they are independent systems or not but it seems to be some fighting happening between parameters, geometry updates, regen and or constraint update order and or timing. A dedicated mode or app for constraint solving is common for good reasons. The constraint system could be managed separately or have a separate update button.

A change to a part should require the constraint system to reevaluate only and the assembly should not regen unless there is a parameter change. But with the current design it's all updated on regen which appears to be related to the issues including InterDesign relations. I like what Alibre Design Expert offers and I like the current constraint system, It just needs some updates and love.

 

[Drutort]

All are good points, what I'm saying is same assemblies worked perfectly fine pre v26, now I have to take extra steps and it's very time consuming during the design phase, as I make constant changes and this requires constantly opening and closing in a new window, while in the past I could continue working in those windows , and go back to the assembly and all was fine.

I use often global parameters to modify the assembly and the parts, along with configurations, like left and right part or what not.

All of this worked flawlessly in the previous versions.

 

[stepalibre]

I understand. This may need to be a support ticket in your exact case.

 

[DavidJ]

Not sure if it explains what is reported above, in last version or two there have been some changes to how much regeneration goes on and when, by way of performance optimisation. Auto-regenerate in assemblies now defaults 'off'. Try turning auto-regenerate on to see if that improves matters in your case.

 

[Drutort]

Ya that was my next step

I understand. This may need to be a support ticket in your exact case.

 

[Drutort]

Not sure if it explains what is reported above, in last version or two there have been some changes to how much regeneration goes on and when, by way of performance optimisation. Auto-regenerate in assemblies now defaults 'off'. Try turning auto-regenerate on to see if that improves matters in your case.

Good to know.

Hmm I check all the options, and I do not know where exactly is this feature that can be toggled on off?

 

[NateLiquidGravity]

Not sure if it explains what is reported above, in last version or two there have been some changes to how much regeneration goes on and when, by way of performance optimisation. Auto-regenerate in assemblies now defaults 'off'. Try turning auto-regenerate on to see if that improves matters in your case.

There may be something wrong with the icon in the menu showing it as on when not on.

 

[Drutort]

There may be something wrong with the icon in the menu showing it as on when not on.

hmm it was not an icon issue, I dont think so. It was just messed up.

I have been able to some what get it to work when I went and created a package of the asm, and then extracted that package and worked on it and it seems like it didnt have issue? but I also went and deleted a few features that where not needed, im not 100% sure what caused to fix the issue of regen not working in asm at all.

 

[NateLiquidGravity]

Sorry, I meant that I had a nearly exact experience with constraints requiring Regen after returning from editing. I thought the auto-regenerate icon in the menu was indicating it was turned on in the assembly, but it behaved as if it was actually off. At least until I clicked it multiple times testing between and it seemed to be working then.

 

[Southernpedro2017]

Hi Drutort
This is an interesting Thread and I have battled with this problem in V26 and V27 for some time.

The annoying thing I find is that its very random. I edit a part in another window, close the part window and regen the main assembly.

The previously worked on Part/Assm then floats in the main assembly but the Constraints are still present in the feature tree.

Before I became aware of the issue I would re-constrain the Item. This then creates a total mess in the Constraint tree as a double constraint conflict occurs. I then started closing down the main assembly and re-opening it and problem was solved. This is a big pain as some of my assemblies a rather large and take some time to open. The trick i have started to use is after working on an item in another window and then returning to the main assembly I always click and grab worked on part and try to move it. If it moves then I save and reboot main assembly. This sounds time consuming but I have found its the shortest loss on design time.

I have always tried to see how my design process creates this problem but the only things I have found are as follows

- Avoid using configurations in parts or assemblies when they are to be included in large complex Parent assemblies. ( This can also bugger up Colored images in Drawings)
- I use reference planes to constrain all my parts/Assm in Parent assemblies. ( Caution when using 3 planes, 2 Planes a 1 ref point creates a more stable constraint)

Hope this helps

It would be great if other users can report on possible solutions

Good luck

 

[stepalibre]

I think these are all related. I find common things that all circle around each other. There is a clear conflict between orders of operations and timing between features, parameters, constraints and regen tasks. It's all dependent on your feature tree, equations and related features used. This is hard to debug.

I have API code that work reliably. I control what regenerates and I know what's going in the code so it all works. I time forced regens and saves under certain conditions. I save some data externally and perform my own checks before Alibre code to prevent dirty data / regen confusion issues which all effects update speed and general performance. This is not because of Alibre. I work with many other APIs.

I want to be very clear. On the API development side Alibre tech works and is awesome. Updates to existing designs and some that were code generated all work with Alibre's other features without any issues.

My work has always been ~80/20 Part/Assembly only and ~70/30 API/Non-API.

 

[Drutort]

Hi Drutort
This is an interesting Thread and I have battled with this problem in V26 and V27 for some time.

The annoying thing I find is that its very random. I edit a part in another window, close the part window and regen the main assembly.

The previously worked on Part/Assm then floats in the main assembly but the Constraints are still present in the feature tree.

Before I became aware of the issue I would re-constrain the Item. This then creates a total mess in the Constraint tree as a double constraint conflict occurs. I then started closing down the main assembly and re-opening it and problem was solved. This is a big pain as some of my assemblies a rather large and take some time to open. The trick i have started to use is after working on an item in another window and then returning to the main assembly I always click and grab worked on part and try to move it. If it moves then I save and reboot main assembly. This sounds time consuming but I have found its the shortest loss on design time.

I have always tried to see how my design process creates this problem but the only things I have found are as follows

- Avoid using configurations in parts or assemblies when they are to be included in large complex Parent assemblies. ( This can also bugger up Colored images in Drawings)
- I use reference planes to constrain all my parts/Assm in Parent assemblies. ( Caution when using 3 planes, 2 Planes a 1 ref point creates a more stable constraint)

Hope this helps

It would be great if other users can report on possible solutions

Good luck

So this is spot-on the issue I have, mine is worse I guess cause if I save the broken constraint state it stays that way on opening again, it's really strange. So like you I would go and try to fix them, but my fix usually has been don't touch anything in the main asm until you closed all edited windows, then Regen main asm.

 

[stepalibre]

I don't like how constraint state and solving seem to influence other systems in this way. I don't recall this before the Simulate and Motion change.

 

[Drutort]

I just wish I did not have to close/open the part edit window every time, and just press a refresh/regen button and be done with it, but having to keep open and closing each part when im designing is a pain, and slows me down a lot!

I can not always use the edit in the asm, that seems to work ok, I just do not get it why in a different window it goes crazy when pre V26 this was working flawlessly with global param and cofigs.

Whatever is causing the issue, they should either give use some toggle/check box if its possible to do it the old way, or if it slows down something in the graphics/rendering area. I lived with v25 and older just fine, I didn't say anything in V26 because I was thinking that this would get fixed soon enough.

 

[stepalibre]

I hate to reference other software too much because it can be annoying in certain context, but I use other CAD apps all side by side.

It really feels like something isn't being triggered when it should it particular conditions not always. I'm finding while debugging the helix boss feature some combinations in the feature tree create solver related problems. It's tricky because it can be fixed by reordering your features. I'm trying to document this and will share with Support. It's not a design intent issues either.

The assemble problems resemble the behavior you can see in 3D programming and in constraint solvers where some states will make the whole system go crazy. I started to port the SolidWorks URDF/SDF plugin to Alibre.
This project:

GitHub - ros/solidworks_urdf_exporter: SolidWorks to URDF Exporter

SolidWorks to URDF Exporter. Contribute to ros/solidworks_urdf_exporter development by creating an account on GitHub.

github.com

The robot will go crazy in a similar way when a constraint parameter is not updated correctly or is missing. It is funny to see. It's not the same but the concepts are related. I don't remember the term for this type of problem in mathematics.

I'm sure the Alibre developers understand what's happening internally.

 

[stepalibre]

in a different window it goes crazy when pre V26 this was working flawlessly with global param and cofigs

So maybe a bug in the different window code? It shouldn't be a difference.

I wonder if this is a design complexity problem. I'll need to think about the type of designs I build and which ones had the problems. When I had assemble issues that was a structural steel model. I knew a fully modeled structural steel project with connection details would be fun do in Alibre...not really but possible.

This topic and other issues aren't about size complexity but some are made more obvious.