MVX.json

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 is wat outdated: de nieuwe waarde is "34 - 7". Op deze manier ligt het schroefgat van de geleider 7mm boven het center van de opvullijst, waar ook net het gat van de opvullijst zich bevindt.
Idem voor de rechtse opvullijst.

De reden waarom ik die commit hier niet heb toegevoegd is omdat er anders weer een hoop extra meekwam (reviewopmerkingen van vorige tickets).

Heel goede opmerking. Ik weet niet meer goed van waar het kwam. Waarschijnlijk inderdaad op zicht bepaald, maar ik had het nu overgenomen van de front reling.
Ik heb het aangepast, ook voor de front reling.

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.

string() is nodig voor numerieke waarden zoals BoxSystemDepth, maar niet voor waarden die al strings zijn zoals CutOutCode_Z1.
Ik heb het even nagekeken, en het lijkt dat ik dit consistent doe voor enkel numerieke waarden.

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.

Ik heb dit kenmerk moeten toevoegen aan 'NeededFor3D' omdat voor een of andere reden de andere niet altijd ingevuld was.

De Z-as in Encoway is de 'diepte-as', spiegelen wilt zeggen dat de voorkant de achterkant wordt en omgekeerd.
Dit is omdat de Z-as uit het beeld komt, waardoor alle Z-translaties negatief zijn. De lengte van dit onderdeel moet echter wel positief zijn (ik heb een negatieve lengte uitgeprobeerd, maar dit zag er niet uit).
Hierdoor begint de contour op het nulpunt, maar wordt dan langs 'de foute kant' uitgetrokken (naar voor toe), waarbij twee opties zijn om ze naar achter te krijgen:
1) Een translatie over de Z-as gelijk aan de lengte
2) Een spiegeling t.o.v. de Z-as

Ik heb de tweede, en toegegeven minst voor de hand liggende, optie gekozen.

Edit: ik heb bij het verwerken van deze opmerkingen de eerste optie gekozen sinds die logischer is.