Datum objects in App::Part

[Zolko]

Hello,

I didn't find a Forum Board for the Part module, so I post it here on the PartDesign board, if there's a better place please tell me.

I have a short question: is there a reason why it's not possible to create datum objects (PartDesigne::Plane, ::Point, ::CoordinateSystem, ::Line) in an App::Part ? It's possible to create such a Datum at the root of a document but outside of the Part container, and then drag it to a Part container in that document, but it's not possible to create it directly there.

Code: Select all

File → New
>>> App.activeDocument().Tip = App.activeDocument().addObject('App::Part','Part')
>>> App.ActiveDocument.addObject('PartDesign::CoordinateSystem','LCS')
>>> App.activeDocument().getObject("Part").addObject(App.activeDocument().getObject("LCS"))

So it seems that it is actively forbidden for the App::Part container to create Datum objects, but there is no actual technical limitation to for the App::Part container to contain such Datum objects.

Is this a bug, or is there a reason for this behaviour ?

[Zolko]

So it seems that it is actively forbidden for the App::Part container to create Datum objects, but there is no actual technical limitation to for the App::Part container to contain such Datum objects.

Is this a bug, or is there a reason for this behaviour ?

wait ... it is actually possible:

Code: Select all

File → New
>>> App.activeDocument().Tip = App.activeDocument().addObject('App::Part','Part')
>>> App.activeDocument().getObject('Part').newObject('PartDesign::CoordinateSystem','LCS')

but not from the PartDesign toolbar ... the "solution" would be to add the buttons to the Part toolbar ? Have to check

[chrisb]

Seems to be a python question and moved it there. If not it's a general help request.

[easyw-fc]

Seems to be a python question and moved it there. If not it's a general help request.

even if LCS can be included in an App::Part container, LCS will not work if you try to attach it to any objects inside the App::Part containers...
It is not a simple python issue, it is related to FC core code.
LCS works correctly only on Body objects.

lcs-inside-Part.FCStd

(4.85 KiB) Downloaded 43 times

EDIT:

Err: Unhandled Base::Exception caught in GUIApplication::notify.
The error message is: Access violation
Log: The event type 3 was sent to QPushButton
Object tree:
QPushButton is child of
QDialogButtonBox is child of
Gui::TaskView::TaskEditControl is child of
Gui::TaskView::TaskPanel is child of
QWidget (qt_scrollarea_viewport) is child of
Gui::TaskView::TaskView is child of
QStackedWidget (qt_tabwidget_stackedwidget) is child of
QTabWidget (combiTab) is child of
Gui::DockWnd::CombiView (Combo View) is child of
QDockWidget (Combo View) is child of
Gui::MainWindow

[ickby]

A part can have everything inside, there is absolutely no restiriction. You found the ways already, per UI with drag and drop, from console via add or new.

but not from the PartDesign toolbar ...

The reason is simple: All datum objects are designed to work with partdesign features, and with nothing else. They are only intended for that. Hence it makes no sense to have them outside of a body, as PartDesign features must be in a body. So there is a simple check for that in the tools themself.

[DeepSOIC]

They are only intended for that. Hence it makes no sense to have them outside of a body,

eem… but it DOES make sense! The main problem here is that properly supporting PD datums in, say, Part wb, creates a module dependency problem.

Being able to use a datum plane for Part Mirror would have been fantastic, for example. And it doesn't even require that module dependency.

[ickby]

OK, i should reformulate: when created it made no sense. Back than noone really thought of use cases other than part design. That is the rational behind the current design. But if wanted or required in part workbench or anything else there is nothing against moving it.

[Zolko]

Sorry, forgot about this, as I have solved my problem

They are only intended for that. Hence it makes no sense to have them outside of a body,

eem… but it DOES make sense! The main problem here is that properly supporting PD datums in, say, Part wb, creates a module dependency problem.

Being able to use a datum plane for Part Mirror would have been fantastic, for example. And it doesn't even require that module dependency.

1) in ~/src/Mod/Part/App/DatumFeature.h

Code: Select all

// This generic class is defined here so that the Sketcher module can access datum features
// without creating a dependency on PartDesign

class PartExport Datum : public Part::Feature, public Part::AttachExtension
{
    PROPERTY_HEADER_WITH_EXTENSIONS(Part::Datum);
...

apparently, some people have already thought that these Datum things are useful for App::Part, it's not that new.

And there is (at least) one very nice use of Datum things in App::Part: when App::Part is used as a container for assemblies, a wrapper for PartDesign::Body, where it allows perfect separation between part geometry (Body) and part references (Datums in Part). This is especially useful if the geometry is imported, from a step file for example: in this case, the Body contains the (imported) geometry, and the Part wraps it in useful native FreeCAD references. This is also useful if a Part is made with booleans, then there will be several Bodies — some may-be imported — and the Part wraps them together nicely. Thus, you can, even after the Part has been included into an assembly, modify the geometry without loosing the attachment references.

If App::Part are used as container for assemblies, having Datum objects available in App::Part is fundamental.

[Pauvres_honteux]

... if wanted or required in part workbench or anything else there is nothing against moving it.

Yes please!

We've waited sooo long for this to happen. Datum driven design is within reach!!!

Just checking: we are talking about Datums not having Part-container as a parent, right? Id est, Part-container will be child of the Datum? In yet other words: the files (*.fcstd) zero will be the Datum parent?

Hoping, hoping and hoping

[triplus]

FreeCAD 0.17 development cycle was rather PartDesign oriented. At that time discussions about more generalization more or less resulted in being out of scope.

Moving some of that effort out of PartDesign, like datum features to Part workbench, and on the other hand moving the rest of FreeCAD in PartDesign. Like using Part features directly in PartDesign workflow. That likely still should and will happen at some point in the future. Whenever and wherever that will make sense and somebody will be prepared to do it.