Key Cap collisions with defaults & Cherry MX switches

[VolatileDream]

I've been building a DMOTE, and after I put on the key caps I discovered that a few of the key caps interfere with each other when pressed. I've used DSA keys from https://pimpmykeyboard.com/, which I think match the expected key cap form factor.

Delta between default (Makefile):

-dmote_62key: target/dmote.jar dmote/base.yaml
+dmote_62key: target/dmote.jar dmote/base.yaml dmote/mx.yaml

Upon reflection you can actually see some of the cross column collisions in the visualization render (top inner keys):

However, some of the interference is more noticeable after putting key caps on and pressing keys.

This affects the inner most column (all three keys) and the top two keys of the two adjacent columns. I've also noticed a small amount of cross-column interference on the same keys.

I feel like I missed something, because of the amount of overlap that I ended up with. Any suggestions / changes for avoiding this for others?

My personal solution will be to double check 3d-print residue, and the file down keycaps as necessary. Although I understand filing down key caps is probably not a desirable solution for others.

[veikman]

Hi! I am sorry about this nasty surprise.

If you have a look at my most recent finished DMOTE build here you can see that it’s mostly DSA, but also a few non-standard keycaps in the area where your keys collide. This is because I, just like you, could not get DSA to fit. That is to say, I tried spacing for DSA and found that my index finger had to stretch too far to reach all the keys, so I deliberately moved the switches closer together.

The non-standard caps I designed to solve this problem are in the minimal style, as modelled by dmote-keycap. They are printable, and you should find them as outputs of the application (at things/scad/keycap-minimal-*.scad).

The minimal style adapts to its switch. As shown on your screencap, minimal caps with MX get so wide at the edge of the skirt—wider than Matias—that they might collide. Then again they might not. Here is a shot of preview-keycap-clusters.scad with the bundled configuration files you used.

Here is a shot with a further adaptation to MX in mx.yaml.

Here is that adaptation itself.

@@ -15,8 +15,10 @@ keys:
       switch-type: mx
       top-size: [9, 9, 1.6]
       skirt-thickness: 2.4
+      skirt-length: 2
     minimal-tall:
       style: minimal
       switch-type: mx
       top-size: [9, 9, 3]
       skirt-thickness: 2.4
+      skirt-length: 2

I’ve added one line to each minimal type of keycap, to limit skirt length. This length (2 mm) is rather extreme and will not provide full dust protection. I suggest you experiment with other skirt lengths, printing caps until you find a good compromise. Let me know how it goes so we can amend mx.yaml and prevent at least that part of this nasty surprise for others. Of course, if you prefer to file down your DSA caps, that should work too.

A build guide should help prevent some surprises like this, but I’m sure some people would build first and read the guide later. I wonder if a less comfortable all-DSA version of the DMOTE would be friendlier or an even nastier form of surprise.

[VolatileDream]

Aha! So that's it! I hadn't noticed that in the build photos.

Since I've been working on this slowly, I actually had some of the keycap-minimal-short.scad printed while waiting for the DSA keys to show up from PMK. I think I did them poorly because they're really hard to get onto the switches. Any followup suggestions for that, or suggestions for printing another set?

And thanks for the help! I'll follow up as I experiment. :)

[veikman]

There are parameters available for adjusting the fit. Here’s a quick illustrated guide.

First, an isometric view from below of the bundled mx.yaml without adjustment. Notice the supports for printing upright on FDM.

The support structures are optional. Here’s with keys → styles→ minimal-* → supported set to false. Because the view is clearer this way, I’ll keep this setting for the next two changes.

Here’s with an adjustment to the dfm → error-general setting, going from the bundled -0.5 in config/base.yaml to -1. This setting is what I recommend you play with if the skirt of the printed key is too small on the inside to fit around the body of the switch. If the skirt gets too thin as a result, just add more skirt-thickness and subtract skirt-length as needed to prevent collisions.

Finally, here’s an adjustment to keys → styles→ minimal-* → error-stem-negative, setting it to -0.5. This is one of three DFM error parameters specifically for the keycap-drawing library. It makes the MX “plus-sign” (a.k.a. the Greek Misato-necklace cross) larger; perhaps too large. Play with this if your problem is the tightness of the stem.

According to my experiments, you generally need your nozzle size on an FDM printer subtracted with these settings for a good fit, but you could also try slicing with Cura; it has an advanced parameter for doing the same sort of adjustment with nominal dimensions in the STL.

There’s a corresponding error-stem-positive, in case your problem is the boss hitting the body of the switch on the way down.

I hope this helps. I’ll try to turn it into a proper document at some point.

[jeremy-asher]

I also ran into some similar issues with the base DMOTE config. Initially I missed that the base config file was using Alps switches. I think that was mentioned, but I must have missed it at first glance and just ran make. I think that with the MX presets it still appears that there might be keycap collisions with the minimal keycaps from eyeballing it in OpenSCAD.

I have also been wanting to use standard DSA caps as well. Since this definitely collides with the default settings as mentioned, I have been working on an adjusted version of the DMOTE config that doesn't collide with DSA before I do a first test print. Unfortunately, this has required more extensive changes to the config than I expected. While this has not dissuaded me yet, I can imagine it would be a barrier for some folks.

Maybe this belongs in a separate issue, but I think I haven't found a good workflow for testing keycap fit with a given config. I have recently started using lein repl to speed up generation and realized I should view the preview-keycap-clusters file since it renders so much more quickly than viewing the main body with preview: true in the keys section. While this helps, I'm not sure how to best check clearances with this view considering the keycap travel isn't visualized.

Is there a better way to check keycap clearance visually or programmatically? Maybe extending a cuboid from the base of the cap in the preview? Or if it can be easily measured, by emitting a warning during the build if anything gets too close? Even better, though I'm sure it's far too difficult, could the spacing of the switches be automatically adjusted to account for the keycap and its travel?

Thanks for your amazing work on this project!

[veikman]

Hi Jeremy.

While this has not dissuaded me yet, I can imagine it would be a barrier for some folks.

No doubt it would be. I’m not happy with the syntax of the by-key section of parameters, but I’m not sure how best to improve it without creating conflicting, parallel systems.

Maybe this belongs in a separate issue, but I think I haven't found a good workflow for testing keycap fit with a given config.

You’re on the right track. What I currently use is lein repl followed by a call to (def stop (watch-config! ...)) where ... is a map of arguments passed on to run. This causes the application to rewrite .scad when changes to the bundled configurations are saved.

Maybe extending a cuboid from the base of the cap in the preview?

It would be easy to expand the application to render caps both at rest and in a pressed state, since length of travel is codified by dmote-keycap. However, in the DMOTE design, all keys move away from their neighbours as they are pressed, because of progressive pitch. If they collide at all, they will do so at rest, unless you change the angles or bring caps on top of one another.

Or if it can be easily measured, by emitting a warning during the build if anything gets too close?

This would be hard. Neither OpenSCAD nor scad-clj offer collision detection.

Even better, though I'm sure it's far too difficult, could the spacing of the switches be automatically adjusted to account for the keycap and its travel?

Travel is already accounted for. The difference in travel between ALPS and MX is insignificant, but it’s part of the algorithm for curving rows and columns. To be honest, though, I don’t think it should be.

We’re talking about making it easy for users to choose freely between different types of switches. What that means to me is that the choice of switches should have minimal side effects, because side effects threaten other aspects of design. If I were to add something like Kailh’s low-profile switches as an option, without changing the algorithm, then key clusters would shrink and grow considerably upon changing types. The knock-on effects would probably be surprising and unwelcome. Placing switches as densely as possible is useful for the north-west corner of the DMOTE but is not a general rule of ergonomy.

This thread has confirmed my suspicion that the present state of affairs is unsustainable. Please let me know how it goes with your all-DSA build. If you succeed where I failed and make it comfortable enough for long-term use, I would like to canonize some form of it as a bundled configuration file, to make a free choice of switches and keycaps easier. Based on that, I will continue to ponder how to redesign by-key for ease of use. Suggestions are welcome.

[jeremy-asher]

What I currently use is lein repl followed by a call to (def stop (watch-config! ...)) where ... is a map of arguments passed on to run. This causes the application to rewrite .scad when changes to the bundled configurations are saved.

Nice! That is what I was looking for.

Maybe extending a cuboid from the base of the cap in the preview?

It would be easy to expand the application to render caps both at rest and in a pressed state, since length of travel is codified by dmote-keycap. However, in the DMOTE design, all keys move away from their neighbours as they are pressed, because of progressive pitch. If they collide at all, they will do so at rest, unless you change the angles or bring caps on top of one another.

Okay, right. I was modifying various angles after switching to all DSA and was having trouble especially with column-column collisions. Some of them would probably only occur when the keys moved. I did a quick hack to the OpenSCAD output to draw a cube down to see if it would be a bit easier to see. It helped, then I realized I could add transparency which made the overlap even easier to see. I have no idea what I'm doing with 3D stuff, so maybe there is a more effective solution. I think encoding something like this in the cluster preview might be the easiest way to help folks who start messing with the key placement.

could the spacing of the switches be automatically adjusted to account for the keycap and its travel?

Travel is already accounted for. The difference in travel between ALPS and MX is insignificant, but it’s part of the algorithm for curving rows and columns. To be honest, though, I don’t think it should be.

Oh, so the keycap / travel does factor into the algorithm beyond negative space? I wasn't aware of that.

We’re talking about making it easy for users to choose freely between different types of switches. What that means to me is that the choice of switches should have minimal side effects, because side effects threaten other aspects of design. If I were to add something like Kailh’s low-profile switches as an option, without changing the algorithm, then key clusters would shrink and grow considerably upon changing types. The knock-on effects would probably be surprising and unwelcome. Placing switches as densely as possible is useful for the north-west corner of the DMOTE but is not a general rule of ergonomy.

Gotcha, that makes sense.

Please let me know how it goes with your all-DSA build. If you succeed where I failed and make it comfortable enough for long-term use, I would like to canonize some form of it as a bundled configuration file, to make a free choice of switches and keycaps easier. Based on that, I will continue to ponder how to redesign by-key for ease of use. Suggestions are welcome.

Okay, I'd be happy to share what I come up with if I get to something usable.

[DrakeRichards]

I also ran into this issue when printing the default DMOTE, so I've been playing around with the code and came up with this: https://github.com/DrakeRichards/dactyl-keyboard/tree/DSA

The main issues were in columns 0-2, so I widened their spacing a bit. The draft prints I made seem to work well. I'm printing a full shell with these adjustments now and will share the results when the print finishes.

EDIT: And here is a maquette render of the keycaps:

[veikman]

Looking forward to your feedback as well, DrakeRichards.

I have now shortened the minimal-style keys’ skirts in the bundled MX-style configuration fragment (bee3be2). Since this should fix the existing design, reducing collisions, I am closing this issue for now. A future new variant for all-DSA keys based on your feedback will be a separate issue.

[DrakeRichards]

Thank you. Though this issue is closed, I thought I should follow up on my DSA print results:

DSA DMOTE Photos

The changes seemed to work and the keys are all still easily accessible. If anyone is looking to make a DSA DMOTE, this one should work nicely.

[veikman]

In ongoing work towards v0.7.0 (a29d20b), the basic DMOTE design now has only DSA-like caps, as it did in v0.3.0. Its key layout is no longer responsive to length of key travel.

The tighter design that was basic in v0.4.0–v0.6.0 (since 5322700) and had some non-DSA keycaps has moved to tight_keys.yaml, as an option for improved ergonomics.