kicad StepUp: ECAD MCAD bidirectional collaboration

[easyw-fc]

Thanks, that helps a lot. I now get a clean model and the silk screen is the way it should be. Nice!

fine

Does the "multi-part" object indicate a problem, or is it just information? Some of my models indeed are done that way, for example a connector with 40 pins. It seems sensible so they can separately have material assigned to them.

All the kicad 3d library models are made as single object. This is an approach to simplify the tree of the board... i.e. a chip is not a body plus hundred of pins... it is just a single object (this is an approach adopted also from many manufacturers)
StepUp is informing when there is a model which is not following the standard approach.

Any idea about the crash?

My mac mini had a GPU failure few time ago and now I don't have any mac to test the tool on.
Mainly StepUp seems to work just fine on mac, but I heard from some user that it could be a drivers issue.
Unfortunately I have no way to test it on a mac.

[M4x]

I don't have a Mac either but could you prepare test files and a short instruction to make it easier to find someone to test it?

[pkoning2]

I tried to install the Linux version, but the AppImage doesn't run on my test machines and the official package is 0.18 which doesn't include StepUp.

But the Mac case is completely reproducible. Just do the add-tracks operation on the attached PCB file. You don't even have to load the board itself, just the tracks will do. What I see is that the track load runs, it starts to display some of them, and then FreeCAD aborts with a segfault.

[easyw-fc]

But the Mac case is completely reproducible. Just do the add-tracks operation on the attached PCB file. You don't even have to load the board itself, just the tracks will do. What I see is that the track load runs, it starts to display some of them, and then FreeCAD aborts with a segfault.

Hi,
no issue on win

Code: Select all

OS: Windows 10 (10.0)
Word size of FreeCAD: 64-bit
Version: 0.20.25131 (Git)
Build type: Release
Branch: master
Hash: 7c519689f0d5ea78fb3292be36a857d283c05507
Python version: 3.8.10
Qt version: 5.12.9
Coin version: 4.0.0
OCC version: 7.5.2

traces.png (597.85 KiB) Viewed 5021 times

[pkoning2]

I just build a Fedora Core 34 system and tested it there; it works. So Mac OS is the only problem area. It fails on the latest weekly build (25157) too.

BTW, there is some text on the copper layers that does not appear on either side. It says "AK-005 A"; on the back roughly in the middle, on the front at the right edge roughly centered along that edge.

[pkoning2]

I tried a strange experiment.
1. Load the tracks on my Linux system. Save that to a FCstd file.
2. On the Mac, open that file. It opens cleanly, no crash.
3. On the Mac, in StepUp load the board. That works.
4. Merge the tracks.FCstd file into that. Works also, except that it's in the wrong spot (the board origin isn't honored). Repositioned it.
5. Loaded the silkscreen. Still good.

So we have an odd case where doing the tracks load operation crashes on Mac, but the actual 3d model resulting from that operation can be loaded safely from a file. I don't know if that helps.

[easyw-fc]

4. Merge the tracks.FCstd file into that. Works also, except that it's in the wrong spot (the board origin isn't honored). Repositioned it.

this should depend on the settings of your dxf exporting

So we have an odd case where doing the tracks load operation crashes on Mac, but the actual 3d model resulting from that operation can be loaded safely from a file. I don't know if that helps.

This is reasonable...
1) when you load the tracks the tool 'generates' the traces in the FC environment using some python calls
2) when you open a file already created, the tool doesn't act at all ... only FC interface is involved in loading an already generated geometry.

[pkoning2]

DXF exporting? The saved tracks I mentioned were saved in an FCstd file.

I see what you mean about the tool not being involved. That still leaves the puzzle: how can Python code crash FC?

[easyw-fc]

DXF exporting? The saved tracks I mentioned were saved in an FCstd file.

You are right, the issue is that traces will set its placement getting from the imported pcb... if not present they just sit in place

I see what you mean about the tool not being involved. That still leaves the puzzle: how can Python code crash FC?

python code, generating or deleting shapes, could trig some bug in the video drivers.
Unfortunately not having a mac hw would be almost impossible for me to debug it

[pkoning2]

I finally captured the backtrace from the crash. The failing function is App::DocumentObject::getNameInDocument (SEGV); that doesn't sound much like a driver issue.