easyw-fc wrote: ↑Fri Aug 17, 2018 11:15 am
I don't think transparency is supported by the standard AP214.
No other cad should be able to export this parameter as STEP file.
easyw-fc wrote: ↑Fri Aug 17, 2018 11:15 am
I don't think transparency is supported by the standard AP214.
No other cad should be able to export this parameter as STEP file.
easyw-fc wrote: ↑Sun Aug 19, 2018 12:13 pm
thanks again, I found much more friendly the Axial move instead of the old transformation tool... it is much easier to control how to move a part ..
Yes, it will be the default dragger for link too.
I have an other question ...
When I export to STEP an object and its link with a different placement and label, the STEP re-imported will keep the correct placement but will lose the label assigned, using the same of the referenced object... is it a limitation by OCC exporting?
There are two options controlling this. You need to disable 'Reduce number of objects', and disable 'Ignore instance names' (I mistakenly put this option to Export. It is an Import option). 'Ignore instance names' is enabled by default, because some legacy occt step files has auto generated meaningless instance names.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
Good morning,
concerning the problem with my build of FC (which is looking for libTKMath.so.8 instead of libTKMath.so.7 or simply libTKMath.so) I would like to add that the same error message (already reported in my previous post with reference to the "Assembly" module) is also produced when starting the "Part Design" module, but it is not with the "Part" module.
The "Part" module is OK and in fact I was able to make an extrude from a sketch. I think that this operation requires the OCC library which indeed was found in the cmake configuration as you can see from the attached image taken from ccamake.
I was looking around in the CMakeLists files trying to understand how the OCC_LIBRARIES are set but I have not found where this operation is done. Anyway it is quite strange that the OCC configuration is good for the "Part" module but it is not for "Assembly" and "Part Design".
In the following line I am reporting the gdb trace related with the failure in loading the "Part Design" module:
[New Thread 0x7fffd88b6700 (LWP 7380)]
[New Thread 0x7fffd0aa2700 (LWP 7394)]
[New Thread 0x7fff9019f700 (LWP 7398)]
[New Thread 0x7fff8f2de700 (LWP 7399)]
libTKMesh.so.8: cannot open shared object file: No such file or directory
Traceback (most recent call last):
File "<string>", line 50, in Initialize
^C
Thread 1 "FreeCAD" received signal SIGINT, Interrupt.
0x00007ffff3453bf9 in __GI___poll (fds=0x5555577aea40, nfds=8, timeout=38)
at ../sysdeps/unix/sysv/linux/poll.c:29
29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) bt
#0 0x00007ffff3453bf9 in __GI___poll (fds=0x5555577aea40, nfds=8, timeout=38)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007fffecc35439 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007fffecc3554c in g_main_context_iteration ()
at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff3e9120e in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4 0x00007ffff443a666 in () at /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#5 0x00007ffff3e5f12f in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#6 0x00007ffff3e5f495 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7 0x00007ffff48703ac in QDialog::exec() ()
at /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#8 0x00007ffff48932b0 in () at /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#9 0x00007ffff48933af in QMessageBox::critical(QWidget*, QString const&, QString const&, QFlags<QMessageBox::StandardButton>, QMessageBox::StandardButton) ()
at /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#10 0x00007ffff6d6c70b in Gui::Application::activateWorkbench(char const*) (this=0x7fffffffb5b0, name=0x7fffe0033e8c "PartDesignWorkbench")
at /home/walter/Software/FreeCad/FreeCAD/src/Gui/Application.cpp:1198
#11 0x00007ffff6d8ef8b in Gui::Application::sActivateWorkbenchHandler(_object*, _object*, _object*) (args=0x7fffe0035d50)
Attachments
Screenshot at 2018-08-20 09-52-09.png (191.04 KiB) Viewed 1370 times
wsteffe wrote: ↑Mon Aug 20, 2018 8:01 am
In the following line I am reporting the gdb trace related with the failure in loading the "Part Design" module:
The trace shows it crashed at opengl library. Probably the same GPU driver issue of 18.04? See the post above for a solution.
Edit, on second look, the trace is after you pressed CTRL+C? That's not very useful. Any error message in report view (Menu->View->Panels->Report view)
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
libTKMesh.so.8: cannot open shared object file: No such file or directory
Traceback (most recent call last):
File "<string>", line 50, in Initialize
Actually It is the same message as that one given in my trace before pressing CTRL+C. I presses it because FC did not stop after at the error.
The exception was handled inside and an error message saying (more or less the same thing) was reported in the GUI.
I have also tried again gdb with "catch throw" entered before run.
But there are other exceptions thrown before and I can not reach the point where it is possible to start the Part Design.
However the error message seems quite clear: It is trying to load libTKMesh.so.8 while in my installation all the libraries of OpenCascade 7.3 ends with so.7 (not .so.8). This is normal if you build OCC using cmake from sources taken directly from OpenCascade download center.
May be that in you installation the OCC libraries have 8 as the last extension. And this is encoded somewhere in the build configuration.
wsteffe wrote: ↑Mon Aug 20, 2018 9:40 am
However the error message seems quite clear: It is trying to load libTKMesh.so.8 while in my installation all the libraries of OpenCascade 7.3 ends with so.7 (not .so.8). This is normal if you build OCC using cmake from sources taken directly from OpenCascade download center.
May be that in you installation the OCC libraries have 8 as the last extension. And this is encoded somewhere in the build configuration.
That's strange. All I can find out about libTKMesh.so.8 is from some package called OCE-modeling. Can you check your build/CMakeCache.txt file and look for OCC_LIBRARY, and OCC_INCLUDE. What are the values?
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal