base plate not rendering correctly

[itised]

I'm having an issue where the *_left_plate.scad and *_right_plate.scad files are only the borders of a base plate - the inside is hollow. I've also tried changing a few parameters like base_thickness and screw_hole_diameter, just to see if it would generate a different scad file, but nothing seems to affect the output of the base plates.

[joshreve]

The base plate generator only works for cadquery. OpenSCAD can't inspect objects as it is a "blind" generator so it can create the base plate in the same way. The bottom of the keyboard and the base plate are just cuts and projections onto the XY plane so the generator never directly creates coordinates to work from. I inspect the projected lines in the cadquery version to find the inner and outer loops and all the included circles, something not even remotely possible with OpenSCAD.

[itised]

Thanks for that. Getting cadquery and cq-editor working on a Mac was a bit of a hassle, but now that I've got everything installed I can see the correctly generated base plates.

[itised]

I got the base plate printed using the cadquery engine, but it has slightly different dimensions than the case that was rendered using the solid engine.

Since the base plate can only be rendered with cadquery, it might be worth it to change the default engine to cadquery, as I imagine most people will plan to print all the parts.

[joshreve]

Interesting. I'm going to look at it in detail. I think the cadquery version is actually a bit off. I'm guessing it is something with the projection since the method is different due to varied functionality in the packages. Thanks for pointing it out.

[itised]

I actually did not check whether the cadquery base plate has the same geometry as the cadquery case.

If both the base and case generated by cadquery match, then I don't imagine there is a real pressing issue. There is no way to generate a full plate using the solid engine, so cadquery has to be run anyway. And at that point, I would just use all the files generated during that run.

Being a bit off from the reference spec doesn't seem like a very big deal, unless people are trying to use different Dactyl forks to generate different parts of their keyboard, which I personally would never expect to work anyway.

Just my opinion; It seems like you have a bunch of great ideas for this fork, and if ignoring the solid engine in favor of the more powerful cadquery engine can simplify and accelerate development, I'd consider that a big net gain.

[joshreve]

I am keeping the solid engine for a bit since it really has a strong following. cadquery can be a bit harder to install. I did find the issue and fixed it. I'd like to keep them both if possible especially since the solid engine is really good for rapid checking. I actually use both in my debugging.

I didn't see the issue because each engine was acting internally consistent. I now fixed that they are consistent with each other. For the baseplate, some people just use the DXF for a cut plate, but I definitely prefer the printable one from the cadquery engine.

Thanks for pointing this out. It only took about 30 minutes to fix it with the info you gave me. It will end up being merged with the trackball design, probably this weekend.

[nethermead]

Just adding a note on this that, in your trackball branch (which I know you're working on so you may be aware of this), the plates don't render properly if you choose to have the trackball only on one half, regardless of whether it's solid or cadquery. The code in dactyl_manuform.py simply mirrors the right half to the left and exports that, which cannot work for asymmetric builds.

[joshreve]

I totally missed this. I added handedness to most functions, but missed this one. Fixing and merging to master. trackball has been merged with master at this point so that would be the place to look moving forward. I have an asymmetric flag but didn't apply it to the base. Should be merged shortly.