Page 1 of 2

Finding the source of a console error in an Assembly4 Project

Posted: Fri Jun 03, 2022 11:28 pm
by PAS_Drafter
OS: Windows 10 Version 2009
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.24267 +148 (Git)
Build type: Release
Branch: Branch_0.19.4
Hash: 476ecf091941bead59b14e44afa6064d5a66afa3
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.5.3
Locale: English/United States (en_US)

Hi

I have an Assembly4 project with a number of sub-assemblies and various parts that are imported in to make it. When I go to recompute, my console gives me the following messages.

Code: Select all

16:17:39  Sketcher::SketchObject / Sketch036: Links go out of the allowed scope
16:17:39  PartDesign::CoordinateSystem / LCS_Pipe_R: Links go out of the allowed scope
16:17:39  PartDesign::CoordinateSystem / LCS_NB01R: Links go out of the allowed scope
16:17:39  PartDesign::CoordinateSystem / LCS_NB02: Links go out of the allowed scope
I'm not so worried about the "Links go out of the allowed scope" error itself as once I find the right file/part/drawing, etc. I can usually fix the error. My problem is trying to find that specific file/part/etc. based on the error message that I'm given. With the "LCS_Pipe_R" and "LCS_NB01R" where I have custom naming, I have a chance to at least look in the right spot, but the ones that come up with "Sketch036" is a lot harder to find. In an assembly, there might be many "Sketch036" that I'd have to comb through.

Is there an easy way to identify which file gave you the error without having to go in and load each file separately? If not, is there a way to add a the file/part/body info to the error message to make it easier to track down?

Thanks

Re: Finding the source of a console error in an Assembly4 Project

Posted: Mon Jun 13, 2022 6:36 am
by Zolko
PAS_Drafter wrote: Fri Jun 03, 2022 11:28 pm Is there an easy way to identify which file gave you the error without having to go in and load each file separately? If not, is there a way to add a the file/part/body info to the error message to make it easier to track down?
These are core FreeCAD warning messages – due to AttacherExtension – and unfortunately I don't know what can be done about it. These are generated in C++ and not Python, so I'm not even sure whether it's possible to intercept them from the workbench. Sorry

Re: Finding the source of a console error in an Assembly4 Project

Posted: Mon Jun 13, 2022 3:33 pm
by a.l
Zolko wrote: Mon Jun 13, 2022 6:36 am
PAS_Drafter wrote: Fri Jun 03, 2022 11:28 pm Is there an easy way to identify which file gave you the error without having to go in and load each file separately? If not, is there a way to add a the file/part/body info to the error message to make it easier to track down?
These are core FreeCAD warning messages – due to AttacherExtension – and unfortunately I don't know what can be done about it. These are generated in C++ and not Python, so I'm not even sure whether it's possible to intercept them from the workbench. Sorry
Maybe @wmayer has an idea https://github.com/FreeCAD/FreeCAD/comm ... 9e7e64433c , but I guess everyone is busy finishing up the 0.20 release - and a big thanks for that!

Re: Finding the source of a console error in an Assembly4 Project

Posted: Mon Jun 13, 2022 3:57 pm
by wmayer
With git commit fdabaf692b there was a change to add more information about where the warning is raised. However, it looks like it still doesn't print the name of the document that the object is part of. I think we can extend the warning to also print the document name here.

Re: Finding the source of a console error in an Assembly4 Project

Posted: Mon Jun 13, 2022 4:35 pm
by a.l
wmayer wrote: Mon Jun 13, 2022 3:57 pm With git commit fdabaf692b there was a change to add more information about where the warning is raised. However, it looks like it still doesn't print the name of the document that the object is part of. I think we can extend the warning to also print the document name here.
That would be nice!
But the reason why people that use Assembly 4 get these warnings is because we use coordinate systems to link different parts together in the assembly model.
So what do I mean?

Inside a Part (Std_Part / Asm4_newPart) we have these Local Coordinate Systems (LCS) that lie outside of the Bodies.
These LCS link e.g. to sketch lines inside a body, but are used outside of the Part in an Assembly 4 assembly. Then we get these warnings!
I use a recent 0.20 build myself and get e.g. such a warning:

Code: Select all

18:17:50  PartDesign::CoordinateSystem: Link(s) to object(s) 'Sketch002' go out of the allowed scope 'LCS_1_RightSuspensionAttachmentPoint'. Instead, the linked object(s) reside within 'ApplicationInterfaceRod Assembly'.
The warning is relatively clear to me (that it is used outside the Part), but I think what @Zolko, I and others would like is the ability to suppress these warnings if possible? (Unless it is an "illegal" use case).

Thanks :)

Re: Finding the source of a console error in an Assembly4 Project

Posted: Mon Jun 13, 2022 4:44 pm
by wmayer
The warning is relatively clear to me (that it is used outside the Part), but I think what @Zolko, I and others would like is the ability to suppress these warnings if possible? (Unless it is an "illegal" use case).
In RT's fork the warning is completely disabled and IMO we can do it here too or at least degrade it to a log message that won't be printed in the output window by default.

Re: Finding the source of a console error in an Assembly4 Project

Posted: Mon Jun 13, 2022 4:48 pm
by a.l
wmayer wrote: Mon Jun 13, 2022 4:44 pm
The warning is relatively clear to me (that it is used outside the Part), but I think what @Zolko, I and others would like is the ability to suppress these warnings if possible? (Unless it is an "illegal" use case).
In RT's fork the warning is completely disabled and IMO we can do it here too or at least degrade it to a log message that won't be printed in the output window by default.
Great! @Zolko do you concur?

Re: Finding the source of a console error in an Assembly4 Project

Posted: Mon Jun 13, 2022 4:59 pm
by Zolko
a.l wrote: Mon Jun 13, 2022 4:35 pm Inside a Part (Std_Part / Asm4_newPart) we have these Local Coordinate Systems (LCS) that lie outside of the Bodies.
These LCS link e.g. to sketch lines inside a body, but are used outside of the Part in an Assembly 4 assembly.
hold-on: this should not happen. If you want to use Bodies as parts, you can do that directly, no need to wrap it inside a Part since a long time. You should use Bodies inside Parts only if you really need it, like when you do multi-body things. Or if you use Parts directly (from a STEP import for example).

Then we get these warnings!
wmayer wrote: Mon Jun 13, 2022 4:44 pm In RT's fork the warning is completely disabled and IMO we can do it here too
these warnings have a reason to be , they should not be disabled. But if the printout could tell which Part/Document is at fault, that would sure help.

Also, the text of the warning is not very helpful ("Links go out of scope"), but the previous one was actually better. The new message in v0.20 is even worse. What would you think about:

Code: Select all

"Links between different GeoFeatureGroups are dangerous and can lead to unexpected results"
(the reason they're dangerous is because the don't follow cascading Placements, and that's why ShapeBinders exist)

Re: Finding the source of a console error in an Assembly4 Project

Posted: Mon Jun 13, 2022 5:16 pm
by wmayer
Also, the text of the warning is not very helpful ("Links go out of scope"), but the previous one was actually better. The new message in v0.20 is even worse. What would you think about:
The message shouldn't sound too alarming because this may cause too much FUD for many people where there isn't a real problem.

Re: Finding the source of a console error in an Assembly4 Project

Posted: Mon Jun 13, 2022 5:28 pm
by Zolko
wmayer wrote: Mon Jun 13, 2022 5:16 pm
Also, the text of the warning is not very helpful ("Links go out of scope"), but the previous one was actually better. The new message in v0.20 is even worse. What would you think about:
The message shouldn't sound too alarming because this may cause too much FUD for many people where there isn't a real problem.
There is a real problem:
  • create a Part
  • in the part create a sketch, and draw something on it
  • inside the Part, create a Body
  • inside de Body, create a datum point
  • attach that datum point to a point in the sketch
  • right-click on the Body, and choose "Transform"
  • move the Body somewhere
=> the point is not correctly located on the sketch.

This happens in real-life with STEP imports, so I think it's important to leave a warning message. What would you think of:

Code: Select all

Links between different GeoFeatureGroups can lead to unexpected results
And then list the data that is to blame (the badly attached object, the object/document it was attached-to)