USER FORUM
(you are viewing a thread; or go back to list of threads)
link assembly issues (by Roberto Casini)
Greetings.
I've been banging my head on a minor but annoying problem, which I haven't been able to resolve for quite a few months now. I have three different solid components, which are all nicely watertight, not interfering and showing no naked edges. However, when I create the final assembly by linking the components together in a separate file, I always get a few naked edges. I'm not sure what I may be doing wrong, as the three elements are cleanly put together with the minimal number of constraints (i.e., allowing no redundant constraints). I tried all combinations of union vs assembly, NURBS vs no NURBS, and I cannot get rid of the problem. I always end up with at least a couple of naked edges. Curiously, I can export an STL model that opens just fine on OpenSCAD and validates without problems.
I'm attaching the three component elements, as well as the full assembly (this is for an old style tongue for a Hubbard harpsichord jack)
Thanks so much in advance!
Roberto
I've been banging my head on a minor but annoying problem, which I haven't been able to resolve for quite a few months now. I have three different solid components, which are all nicely watertight, not interfering and showing no naked edges. However, when I create the final assembly by linking the components together in a separate file, I always get a few naked edges. I'm not sure what I may be doing wrong, as the three elements are cleanly put together with the minimal number of constraints (i.e., allowing no redundant constraints). I tried all combinations of union vs assembly, NURBS vs no NURBS, and I cannot get rid of the problem. I always end up with at least a couple of naked edges. Curiously, I can export an STL model that opens just fine on OpenSCAD and validates without problems.
I'm attaching the three component elements, as well as the full assembly (this is for an old style tongue for a Hubbard harpsichord jack)
Thanks so much in advance!
Roberto
(no subject) (by Tom)
Assemblies where parts touch along faces will always generate "naked edges" errors. If you change the "solid model as" from "assemble" to "union" then they should go away, but that gets slow and sometimes fails. "Union" will also remove the pairs of touching faces, which isn't necessarily what you want in an assembly.
I'd just check the parts individually, and not bother at an assembly level. There's a separate command for finding interferences in assemblies, which doesn't have this problem.
I'd just check the parts individually, and not bother at an assembly level. There's a separate command for finding interferences in assemblies, which doesn't have this problem.
(no subject) (by Roberto Casini)
Thanks for your reply, Tom!
As I stated in my original message, I also tried union instead of assembly, but the problem doesn't go away. Sometimes the number of naked edges decreases if I use the assembly type for some of the components, and union for others, and various combinations of NURBS vs no NURBS. In the best case scenario, it appears that the "persistent" naked edges (at least 2) are produced in the central component of the total assembly, which has two intersecting pockets at 90 deg. However, when that component is analyzed by itself, there are no hints that those intersecting pockets should be posing an issue.
I'm starting to think that the solvespace build on my Linux system my show some buggy behavior, the above problem being one of the outcomes. I should try to analyze the model on a Windows machine...
Sincerely
Roberto
As I stated in my original message, I also tried union instead of assembly, but the problem doesn't go away. Sometimes the number of naked edges decreases if I use the assembly type for some of the components, and union for others, and various combinations of NURBS vs no NURBS. In the best case scenario, it appears that the "persistent" naked edges (at least 2) are produced in the central component of the total assembly, which has two intersecting pockets at 90 deg. However, when that component is analyzed by itself, there are no hints that those intersecting pockets should be posing an issue.
I'm starting to think that the solvespace build on my Linux system my show some buggy behavior, the above problem being one of the outcomes. I should try to analyze the model on a Windows machine...
Sincerely
Roberto
(no subject) (by Roberto Casini)
I can confirm that solvespace for Windows does NOT show this issue. So it must be something with the Linux build that is creating it. I'll wait for some new release to see if the issue is resolved.
(no subject) (by Andrew)
Using version 3.1 on Manjaro and the assembly exports with no issues once the second group wad changed to union along with the third group. If the second group is get as assembly, I get a couple of naked edges..
Also, I have found that PrusaSlicer can usually repair export problems, and so if you are 3d printing it is always worth looking at the export in the slicer.
Also, I have found that PrusaSlicer can usually repair export problems, and so if you are 3d printing it is always worth looking at the export in the slicer.
(no subject) (by Roberto Casini)
Thank you for testing the model, Andrew.
On my system (OpenSuSE Leap 15.3) v3.1 of the code, whether vendor-built or compiled from source, the property combination that gives me the minimum number (2) of naked edges is: cmp#1 as assembly, cmp#2 as assemply+NURBS, cmp#3 as union. Everything else, including your suggested combination, produces a larger number of interferences... :-(
Again, other than for the nuisance of this uncontrollable and non-debuggable behavior, the model passes the validity check on OpenSCAD, and prints just fine using Cura or Simplify3D.
Regards.
On my system (OpenSuSE Leap 15.3) v3.1 of the code, whether vendor-built or compiled from source, the property combination that gives me the minimum number (2) of naked edges is: cmp#1 as assembly, cmp#2 as assemply+NURBS, cmp#3 as union. Everything else, including your suggested combination, produces a larger number of interferences... :-(
Again, other than for the nuisance of this uncontrollable and non-debuggable behavior, the model passes the validity check on OpenSCAD, and prints just fine using Cura or Simplify3D.
Regards.
Post a reply to this comment: