rudenick's build

[doordormeta]

Hey, I still do not have the skill to do it myself but for all these months one of my wants is to use single-switch pcb's for the modular benefits. Main thread:
https://deskthority.net/viewtopic.php?f=7&t=11420&start=

Some sell 30 pieces for 5$ which is nice investment at least for not dirtying/damaging the switches with solder
https://keeb.io/products/amoeba-single-switch-pcbs=

Have you seen these? What are your thoughts?

[20lives]

hi @RudeNick1, I will definitely try this in my next build.
I am not really sure if this is cleaner/faster solution than my method, but it will be nice to have some switch leds and smd diods.

taken from my build log

[veikman]

Have you seen these? What are your thoughts?

I have. I don’t believe it would help with the problem of dirtying switches since it would be necessary to desolder the switch from the PCB every time you move the switch (e.g. to another prototype). It doesn’t seem like it would simplify the installation as a whole either, since the main problem with wiring up a DMOTE is to reach inside each thumb cluster; it has to be easier to wire up a switch before sticking it in there than to solder it to an Amoeba that is somehow already mounted in place.

Amoebas would help with backlighting and would probably make it slightly easier to wire up the rows and columns of the finger clusters, but this would come at the cost of reserving space for PCBs on the inside of the case. In some configurations, particularly where adjacent columns differ in z displacement, I find it likely that negative space for Amoebas would either overlap other Amoebas or poke through the case, or both. If you only use Amoebas for some less-sensitive keys, their utility drops proportionately. In my estimation, it’s not worth it, unless you really want a strong key-specific backlight.

@20lives’s copper foil looks like a better general solution. Personally I like to strip single-core wire in multiple places; it’s laborious but it allows for colour coding and saves having to solder multiple wires to any one leg. Some use flexible PCBs. All of these solutions are adequate for private needs and unsatisfactory for serial production, which is why a Maltron still costs $400 after decades of mass production. Flexible PCBs will get better over time, and dual-head conductive filament could improve to the point that it’s worth incorporating into the DMOTE, but single-switch PCBs? I remain skeptical for now.

[doordormeta]

@veikman thank you for your recent update! I got most parts ready and I will assemble the keyboard soon. I have to print it again because I didn't adjust the first model at all. While adjusting I tried to set it for MX switches as alps are impossible to get. In keys> switches> I set MX for minimal short and again for tall. But after rendering the case it did not work on all switch mounts.

How can I do it better?

I have one other change left to go and I got it partially solved:

• ghetto adjustments for 4p4c socket. I changed the dimensions to 12.6, 6.8 12.6
  6.8 and ghetto because my socket has two weird mounting bolts
  https://c.allegroimg.com/s720/01141a/3ec6c9284dc4affdcd2dc4ca8ccc
  https://2.allegroimg.com/s1024/013ff4/874332d44200bc0a2a82509e7ee2

Do you think it's enough to fit?

[doordormeta]

@20lives I just noticed that with your soldering method it's easy to burn switch cases with soldering tool. I think I will stick to basic wires

[veikman]

In keys> switches> I set MX for minimal short and again for tall. But after rendering the case it did not work on all switch mounts.

In addition to minimal-short and minimal-tall, config/dmote/base.yaml now also makes implicit use of a third key style, called default. I suspect more people will fall into this trap, so I’ve prepared a configuration file that converts everything on the DMOTE to switch-type: mx. It’s in the latest commit.

Give it a whirl:
$ lein run -c config/base.yaml -c config/dmote/base.yaml -c config/dmote/mx.yaml

On a related note, I suggest you make careful use of config/visualization.yaml to see what the printable minimal-style caps look like in place. They’re densely arrayed. Since Matias is broader than MX, it should work, but I haven’t tested it.

my socket has two weird mounting bolts
https://c.allegroimg.com/s720/01141a/3ec6c9284dc4affdcd2dc4ca8ccc
https://2.allegroimg.com/s1024/013ff4/874332d44200bc0a2a82509e7ee2

Those are for snap-fit through-hole mounting on a PCB. It looks like they would make for an awkward fit in a cuboid socket. I suggest you either cut off those legs or design and print a tiny adapter that sits beneath the 4P4C socket inside the hole to give it a cuboid profile. If you then get a poor fit, a slightly larger or smaller version of the tiny adapter should do the trick.

You can also test print just the metasocket (the DMOTE case socket for the 4P4C socket) by adjusting the settings for mask until only that part of the case is rendered.

[doordormeta]

@veikman On Saturday I've had 3L of beer since noon to 4PM at the pool (I did not swim) and then slept till 9PM. My functions were severely impaired by hangover at 2AM when I wrote the message. I have read about default in documentation but after few hours I gave up. I couldn't find it or figure out how default is being defined. I have opened config/base.yaml multiple times but still missed it. Yay, the trips.

I could live with a belief that it's not in the config/base.yaml for some time because of this.

Foremost you helped me understand how to keep my personal configuration file based on the mx.yamlthis is amazing!

I've been playing with code for 14 hous today. In short some of my code looks like this now:

`keys:

styles:

default: #23 pieces per base

  style: minimal 

  switch-type: mx

  skirt-length: 3.57

  top-size: [10, 10, 3.3]

minimal-short: #6 pieces per base

  style: minimal  

  switch-type: mx

  skirt-length: 3.57

  top-size: [10, 10, 1.6]

  skirt-thickness: 2.4

minimal-tall: #2 pieces per base

  style: minimal 

  switch-type: mx

  skirt-length: 3.57

  top-size: [10, 10, 3]

  skirt-thickness: 2.4`

skirt-length: 3.57 because I can print keycaps without support and they do not overlap with mx
top-size: [10, 10, because because

I have printed default key and it's nice. 65 keys print now. When I get back from work I will take care of the base.

I used visualization.yaml but I don't know what you wanted me to do with it later, I used preview-keycap-clusters.scad only

[doordormeta]

@veikman I have completed the first keyboard a month ago!

But keycaps are an issue for me. How do you remove supports? I tried supported: false but I get an error

[veikman]

Looking good! 😁

Your problem with supported is due to a bug: Although the dmote-keycap library exposes validators for its own parameters, the DMOTE application still has to define parsers for each of those parameters. There was none for supported. I’ve added one in version 0.5.1. This should fix your specific problem, but there may still be other parameters going unparsed. I should fix that problem at the source (dmote-keycap) in a future version; I am also working on making that library more friendly to SLA printers.

Please let me know if you have any further problems.