Matthias Claessens

Ging jij alle DND's groeperen?
Indien niet, dan ontbreekt deze hier.

Wat geeft deze 3mm weer?
een verplaatsing naar achter ja, maar ik begrijp niet waarom deze nodig is.

Dit lijkt ok, maar conflicteert met Ladehoogte E in BoxCap / BoxCover.

Dit is vermoedelijk op zicht bepaald?
Voor parametrische componenten heb ik ontdekt dat je dit kan uitdrukken als volgt
(aftrekVolgensCataloog - aftrekVoorBodem) / 2

In dit geval:
(111 - 51) / 2 = 30

Ik markeer het als defect, maar het mag zo blijven.
Weet gewoon dat er een formule is dat je kan gebruiken om exact de cataloog te volgen.

Dit werkt duidelijk, ik zie de kap in de 3D visualisatie.

Dat wil zeggen dat je niet string(CutOutCode_Z1) moet doen.
Nu voor de andere doe je dit wel expliciet.

Het is misschien wat muggenziften maar zou het beter zijn om dit allemaal uniform te hebben?
Dus allemaal zonder string(), of allemaal met string()

Hier ga ik dezelfde feedback geven dat ik van Wim heb ontvangen over dezelfde component.
Door deze variabelen te gebruiken lijk je een verband te leggen tussen deze cutout en de variabele.
Dit terwijl er geen verband is.

Persoonlijk ben ik ook fan van mijn cutouts iets groter te maken dan minimum nodig (in richtingen die er niet toe doen.)
Zo gebruik ik:

"size": {
     "x": "CutOutData_CapZ1_Width + 18",
     "y": 500,
     "z": 500
}

Zo is duidelijk dat enkel in de X-richting er een afhankelijkheid is van een andere variabele.
Als ik het niet duidelijk genoeg uitleg kunnen we samen nog eens met Wim praten om zijn standpunt duidelijk te laten maken.

Kleintje, nu is deze comment twee keer aanwezig.
Zou je kunnen toevoegen of het om de rug of bodem gaat?
Idem voor Rechts uiteraard.

Deze +6 is één van je experimenteel bepaalde waardes vermoed ik.
Als je wil kan ik laten zien van waar deze komt op de technische tekeningen (die ik heb gekregen voor het freeswerk).
En dan is het +7 of +8 dacht ik.

Maar +6 is zeker goed genoeg!

Deze mapping wordt niet gebruikt in de visualisatie hieronder.
Je hebt mogelijks gewoon alle sifon kenmerken gemapt die beschikbaar waren.
Nu blijkt dat deze niet gebruikt worden zou ik deze verwijderen.

Goed opgemerkt.
Aangepast en gaat de volgende commit mee.

Hier vind ik de formule voor x nogal verwarrend.
Deze werkt, daar geen opmerking over.

Wat denk je van deze aanpak voorbeeld van (LBX):

"SideStabiliserSynchroLinkageLength = InternalWidthFor3D - 295",
"SideStabiliserSynchroLinkageOrigin = (BaseWidth / 2) - (SideStabiliserSynchroLinkageLength / 2)",

{
            "comment": "Parametric SideStabiliser SynchroLinkage",
            "if": "is(HasSideStabiliser, 1)",
            "cylinder": {
                "start": {
                    "x": "SideStabiliserSynchroLinkageOrigin",
                    "y": -28.4,
                    "z": "-BoxSystemDepth - 4.6"
                },
                "end": {
                    "x": "SideStabiliserSynchroLinkageOrigin + SideStabiliserSynchroLinkageLength",
                    "y": -28.4,
                    "z": "-BoxSystemDepth - 4.6"
                },
                "radius": 4,
                "slices": 16
            },
            "material": "MT_Kunststof_OG"
        },

Is maar een suggestie, maar ik vind dit duidelijker wat de intentie is.

Idem vorige commentaar over Z-as spiegelen.
X-as is logisch hier.

Dit begrijp ik niet zo goed.
Spiegelen rond de Z-as zou willen zeggen dat dit ondersteboven staat.
Maar dit is een eigen contour, en ik zou verwacht hebben dat de DXF/JSON juist georienteerd is.

Is de contour ondersteboven verwerkt?

Aangezien de zijkanten hoogte E er nog niet zijn is het een beetje moeilijk te oordelen of deze correct gepositioneerd zijn.
Ik ga er ook geen fout van maken, en voor mij is dit OK.