fix(schematic): Fixes port rendering issue with custom symbols #1472
+31
−10
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
/claim #1409
/closes #1409
This PR fixes an issue where ports defined inside a custom symbol were not able to be rendered on the PCB side. The issue was that the ports were not able to find the
pcb_component_id
andsource_component_id
of the parent chip.The fix involves traversing the parent chain of the port to find the
pcb_component_id
andsource_component_id
from a parent component.The related test
SchematicRect with traces
has been updated to include the necessaryfootprint
property, as it is required for the ports to be properly defined and connected in this test case.Test Logs
Explanation
The original issue was that ports defined within a custom
<symbol>
were not being correctly associated with the parent<chip>
component's PCB and source information. This was because the port's direct parent was the symbol, which doesn't have this information.I've resolved this by updating the
Port
component to traverse up the component hierarchy to find the necessarypcb_component_id
andsource_component_id
from a parent component (like thechip
).It's important to note that for this particular test, the
footprint
property on the<chip>
components is still required. Thefootprint
is what triggers the creation of the underlying PCB and source components that the ports need to associate with. Without it, the test fails because the trace cannot be created.I have updated the test file to include the necessary
footprint
properties and the test is now passing.