Issue with STEP and rotation / translation

[adri1mart1]

https://github.com/TousstNicolas/JLC2KiCad_lib/blob/d688d5c0e4c4059dc204179ebe1b3e6c71f05da8/JLC2KiCadLib/footprint/footprint_handlers.py#L358

Hello,

I have notice a misconversion with some components but let's focus on a single one first --> C347186

Using the command:

JLC2KiCadLib C347186 -dir My_lib -symbol_lib My_Symbol_lib -footprint_lib My_FootPrint_lib -model_base_variable JLCPCB_3D_MODEL

Results in a successful conversion to a kicad_mod but the component is not in the correct orientation. See image below where you need to apply manually a rotation of 180° to have the component in the correct way.

After enabling some debug, I found out that the issue may come from here (footprint_handlers.py l.345):

def h_SVGNODE(data, kicad_mod, footprint_info):
    [...]

    if "STEP" in footprint_info.models:
        get_StepModel(
            component_uuid=data["attrs"]["uuid"],
            footprint_info=footprint_info,
            kicad_mod=kicad_mod,
        )

By default, the model is STEP so the get_StepModel() function is called. The rotation and translation info is not passed as argument as the difference between the WRL mode for example.

Is there any reason why or it is simply not implemented yet ?

[TousstNicolas]

Thanks for your issue

This is what happens when you do not take time to properly test the PR. I will correct this.

[simonbarreau44]

Hello ToussNicolas, The translation issue is still present on some components : On C14170 I have too multiplie by 2 the value :

On the C7521 the Z axes is not good by 5mm and I have had to add 1mm on the X axes.

[TousstNicolas]

Hi, I know the translation has never been perfect. This is also an issue for wrl files. As always, I will try to solve this issue when I have time. In the meantime, help is always welcomed.

[Xyntexx]

Hello, As far as I know, the problem is identical on step and wrl files. I created a workaround. Check out my fork branch: https://github.com/Xyntexx/JLC2KiCad_lib/tree/footprint_alignment_workarounds There are several problems:

• On C9865, C82942: the c_origin is not the center of the 3d model for some reason. My workaround reads all points of the wrl and uses their center as the c_origin.
• On C7521 etc: easyeda uses the center of the model as the origin but Kicad uses the actual file origin. The Z adjustment in easyEDA starts from the lowest points, not the origin. My workaround reads all points in the wrl file and finds the center and adjusts accordingly.

The result is IMO close enough.

Let me know if there are some problematic parts and I'll add them to my test board.

[vk2diy]

Hey everyone. G'day from Down Under and bloody awesome work @TousstNicolas! Wish I'd discovered your work sooner! The hours of my life lost drawing footprints...

Anyway I had the same issue (Z level wrong on C5178545) but can confirm @Xyntexx's fix worked perfectly for me.

Any chance of a merge @TousstNicolas?

Rationale: Personally I'm OK with software and quite capable of determining the undocumented route to install a forked version of a python module requiring a virtual environment setup and entry and then exporting the results to a project manually but can't help but feel this is "a few" too many hoops to expect the average user to jump through. A merge of this awesome fix would significantly help them out!

Thanks again everyone! Go team!