NOW OPEN SOURCE!!! swill's plate building tool [builder.swillkb.com]

[IBNobody]

Once the dust settles with the hole additions, you might want to consider adding another case design. I plan on bending the edges of my plate downward with a finger brake. Think of it as the Preonic Case with bends on two or four sides.

The case would need corner cutouts if folding four sides (think of a + shape).

[swill]

Once the dust settles with the hole additions, you might want to consider adding another case design. I plan on bending the edges of my plate downward with a finger brake. Think of it as the Preonic Case with bends on two or four sides.

The case would need corner cutouts if folding four sides (think of a + shape).

Yes, this will be possible with the addition of the polygons which skullydazed and I have been discussing.  I would also like to add both 'Cut' polygons and 'Keep' polygons.  A Cut polygon would be removed from a plate.  A Keep polygon would be added to the plate.

The order of operations would be:
- Union standard cut polygons (switches, holes, usb cutout, middle layers, etc...)
- Difference standard cut polygons from standard keep polygons (remove the cut polygons from the plate)
- Union custom keep polygons with resulting difference (merge any overlapping custom keep polygons with the resulting standard keep polygons)
- Difference custom cut polygons from the resulting union (remove the custom cut polygons from the resulting custom keep + standard keep polygons)
- Draw final results...

This would allow you to cutaway and edge of a plate, but then modify the middle layers so they still have material inside the case which would follow the cutaway contour.  We are getting into much more complicated scenarios, but there will be some very cool things we will be able to do with this...

[bubblebobbler]

http://imgur.com/a/RrNoB


maybe hard to see, the alps stabiliser clip spacing doesnt seem to match the wire size, the wire cant be 'rolled' down from this position as the spacing of the clips is too narrow

[swill]

http://imgur.com/a/RrNoB


maybe hard to see, the alps stabiliser clip spacing doesnt seem to match the wire size, the wire cant be 'rolled' down from this position as the spacing of the clips is too narrow

I will fix this. I have had mixed reports on this. I will make the 2u stabilizer cutouts closer to the switch cutout.

As a small fix for this. Clip the corner off the alps stabilizer and it will be able to rotate. Let me know if that is not clear.

Sent from my A0001 using Tapatalk

[bubblebobbler]

http://imgur.com/a/RrNoB


maybe hard to see, the alps stabiliser clip spacing doesnt seem to match the wire size, the wire cant be 'rolled' down from this position as the spacing of the clips is too narrow

I will fix this. I have had mixed reports on this. I will make the 2u stabilizer cutouts closer to the switch cutout.

As a small fix for this. Clip the corner off the alps stabilizer and it will be able to rotate. Let me know if that is not clear.

Sent from my A0001 using Tapatalk

the fix worked, thanks

however, the same still applies for the right shift for example, and the difference in that case is enough that even clipped stabilisers will not turn. (I pulled a rshift stabiliser from a dell at102 just now, so I know it's not my stabilisers)

[swill]

http://imgur.com/a/RrNoB


maybe hard to see, the alps stabiliser clip spacing doesnt seem to match the wire size, the wire cant be 'rolled' down from this position as the spacing of the clips is too narrow

I will fix this. I have had mixed reports on this. I will make the 2u stabilizer cutouts closer to the switch cutout.

As a small fix for this. Clip the corner off the alps stabilizer and it will be able to rotate. Let me know if that is not clear.

Sent from my A0001 using Tapatalk

the fix worked, thanks

however, the same still applies for the right shift for example, and the difference in that case is enough that even clipped stabilisers will not turn. (I pulled a rshift stabiliser from a dell at102 just now, so I know it's not my stabilisers)

Ya. I need to adjust those widths. What width keys are you having problems with?

[bubblebobbler]

http://imgur.com/a/RrNoB


maybe hard to see, the alps stabiliser clip spacing doesnt seem to match the wire size, the wire cant be 'rolled' down from this position as the spacing of the clips is too narrow

I will fix this. I have had mixed reports on this. I will make the 2u stabilizer cutouts closer to the switch cutout.

As a small fix for this. Clip the corner off the alps stabilizer and it will be able to rotate. Let me know if that is not clear.

Sent from my A0001 using Tapatalk

the fix worked, thanks

however, the same still applies for the right shift for example, and the difference in that case is enough that even clipped stabilisers will not turn. (I pulled a rshift stabiliser from a dell at102 just now, so I know it's not my stabilisers)

Ya. I need to adjust those widths. What width keys are you having problems with?

rshift is 2.25u.

I haven't looked at my 5.5u spacebar yet.


this was my design (the gap between spacebar and ralt was because of my mistake)
http://www.keyboard-layout-editor.com/#/gists/15c003ced176049524258fd31dc3d941
http://puu.sh/qt77d/bfd3e7c384.png

another thing is that you need to sacrifice the 'poker case' screw on the left if using alps stabilisers, due to this
http://puu.sh/qt7e3/9b79619640.png

previously, I think the left hole and left stabiliser mark would 'blend into eachother', so I made the mistake of not realising until I tried to install stabilisers.

I'm having problems with my enter key (but that's because I have too 'wide' stabilisers due to using an AEK enter to salvage the mismatched placement of the switch itself)



I'll likely end up desoldering and making a new plate with these issues resolved

[emdude]

rshift is 2.25u.

I haven't looked at my 5.5u spacebar yet.


this was my design (the gap between spacebar and ralt was because of my mistake)
http://www.keyboard-layout-editor.com/#/gists/15c003ced176049524258fd31dc3d941
http://puu.sh/qt77d/bfd3e7c384.png

another thing is that you need to sacrifice the 'poker case' screw on the left if using alps stabilisers, due to this
http://puu.sh/qt7e3/9b79619640.png

previously, I think the left hole and left stabiliser mark would 'blend into eachother', so I made the mistake of not realising until I tried to install stabilisers.

I'm having problems with my enter key (but that's because I have too 'wide' stabilisers due to using an AEK enter to salvage the mismatched placement of the switch itself)



I'll likely end up desoldering and making a new plate with these issues resolved

No need to remove the left screw cutout, just shorten the length.

@swill, I recommend that, for Alps plates, the length of the cutout be shortened as in the screenshot below.  I also recommend that the center screw cutout be removed as well; you cannot place a screw there when the switches are mounted anyway.



Not sure how the radius of the screw cutout ended up being 2.5005, oh well.

[skullydazed]

@skullydazed I still don't like the idea of creating different sections for each layer because I feel like I am limiting my flexibility that way.  If I do any features that are expected to span layers, that model makes things really hard.

I disagree with it limiting your flexibility, in my mind it's increasing flexibility. However, it's your software and I'm not trying to push that point very hard.

So lets take an example.  I want to create 2 more holes.  One is a 2mm hole in the open and closed layers and the other is a 3mm hole in the switch and top layers.

In both your idea and my original idea, you would have to create 4 distinct line items.  The exact same details for the 2mm hole would have to be repeated in two layers.  The exact same details for the 3mm hole would have to be repeated on two different layers.

Now lets say you change your mind and you want to move the 2mm hole a couple mm one way.  Now you have to figure out which layers it is on and then update each layer independently.  This just feels wrong to me...

I see where you're coming from, but by the same token it's harder for a naive user to understand what is going on when you add so many parameters. There's nothing wrong with targeting advanced users, but I like to speak up for the naive users as well.

So here is a new proposal.  Instead of picking the layer (or having the layer sections pre-populated), you pick which layer(s) you want the cutouts in using a multiselect.  This way, if a specific cutout is expected to be on more than one layer, you can handle that cutout as a single item.

This would reduce the 4 line items in the example above to 2 line items.  If you wanted to move the 2mm hole, you would only have to move it once and it would be moved on all associated layers.

This seems like a reasonable compromise, although I'll note that it makes it harder to move one hole without moving the other. When you enumerate them all you'll probably keep "like holes" together, making it easy to change in a few places. When I have 2 holes but want to move only one it means creating another item and copying settings over. To borrow your expression from earlier, "this just feels wrong to me."

I honestly don't know which situation (moving a hole on multiple layers vs moving a hole in one but not another) is more likely, and without any data or user testing we'll likely never know (like we have the resources for that. ) I also wonder if there isn't a way to make neither of us feel like something is wrong. Variables would be one way to handle that, but the added complexity may just be too much for a project like this. In the end I think you should go with whichever option leaves you feeling better.

[IBNobody]

To weigh in on the hole discussion...

I agree with having a layer selection that let me toggle which layers a hole is on.

Usability-wise, I can see that the biggest annoyance for this would be an extra step in creating copies of the hole. If I have 10 holes that pierce through the top, bottom, and middle and I have to select each layer for each hole, it would take some time. This is especially true if I wanted to recreate a case pattern on another computer. There should be a way to clone holes and also to save progress. (Or for us power users, tell us how to generate raw code.)

To answer the question of likely usage... If I have holes in the top and bottom and they line up, I will rarely move one without the other. I can't think of a case other than a copypaste error correction where I would ever have two aligned holes that I would want to split apart.

How is the progress coming?

[swill]

To weigh in on the hole discussion...

I agree with having a layer selection that let me toggle which layers a hole is on.

Usability-wise, I can see that the biggest annoyance for this would be an extra step in creating copies of the hole. If I have 10 holes that pierce through the top, bottom, and middle and I have to select each layer for each hole, it would take some time. This is especially true if I wanted to recreate a case pattern on another computer. There should be a way to clone holes and also to save progress. (Or for us power users, tell us how to generate raw code.)

To answer the question of likely usage... If I have holes in the top and bottom and they line up, I will rarely move one without the other. I can't think of a case other than a copypaste error correction where I would ever have two aligned holes that I would want to split apart.

How is the progress coming?

This is why I will go with a multiselect, so you can pick which layers the cutouts go on and if you change your mind and remove a layer or add a layer, you just change the multiselect and don't have to mess with the hole details.

I have been working on a different feature, so I have not had a chance to look at this yet.  The other feature is an integration with lasergist.com (link) so you can order your case with a single click (well not quite, you need to specify what you want) from my UI.  They offer free worldwide shipping, and have very competitive prices, so this should be a pretty sweet integration for you guys.  I just found out that their team has some scheduled holiday in the middle of this month to get some much deserved R&R, so we will wait to launch the integration until the end of the month.

I will start looking at fixing the alps stabilizer issue, the poker plate size, adding a top plate and adding the additional UI for adding polygons soon.  Keep in mind, I only get an hour or two to do this at night after I get my family to bed, so I don't have a huge amount of time to pump out features.  I have been busting out quite a bit recently, but I have to be careful not to get too run down or I will be useless to everyone.    I do work a full time job, have my own company on the side and do this in my "spare" time... 

Edit: BTW, regarding your concept of 'saving'.  I will be adding the concept of Presets to handle a lot of the standard layouts.  With that, I will let you "Save" and download a JSON file of your settings.  This saved files can then be uploaded as a custom preset and it would populate the UI with the details saved in the file.  I think that is the plan for now.  This way, I can at least do the basic validating in the UI that I already do and not have to worry as much about totally bogus raw data getting sent to the backend, resulting in completely incorrect plates generated.

[IBNobody]

This is why I will go with a multiselect, so you can pick which layers the cutouts go on and if you change your mind and remove a layer or add a layer, you just change the multiselect and don't have to mess with the hole details.

Sure, but that could still require a bunch of extra clicks. Cloning / copying may be useful. Keep it in mind while you develop, but it doesn't have to be a day 0 feature. Saving is more important.

I have been working on a different feature, so I have not had a chance to look at this yet.  The other feature is an integration with lasergist.com (link) so you can order your case with a single click (well not quite, you need to specify what you want) from my UI.  They offer free worldwide shipping, and have very competitive prices, so this should be a pretty sweet integration for you guys.  I just found out that their team has some scheduled holiday in the middle of this month to get some much deserved R&R, so we will wait to launch the integration until the end of the month.

Are they going to be able to autoquote keyboard layouts greater than 300mm long? That is roughly 15 columns, which will handle 60% but not TKL or full size. Their system had a hard break at 300mm. Maybe that is the size of the laser bay. (Seems small compared to the Trotech Speedy 300's I use with a lower watt laser.)

It looked like it would be about $70-$80 for a 15x6 top, and an extra $30 for the bottom. Seems kind of expensive...

How are you handling the kerf for this one?

I will start looking at fixing the alps stabilizer issue, the poker plate size, adding a top plate and adding the additional UI for adding polygons soon.  Keep in mind, I only get an hour or two to do this at night after I get my family to bed, so I don't have a huge amount of time to pump out features.  I have been busting out quite a bit recently, but I have to be careful not to get too run down or I will be useless to everyone.    I do work a full time job, have my own company on the side and do this in my "spare" time... 

Sure, sure. We all have our day jobs.

Edit: BTW, regarding your concept of 'saving'.  I will be adding the concept of Presets to handle a lot of the standard layouts.  With that, I will let you "Save" and download a JSON file of your settings.  This saved files can then be uploaded as a custom preset and it would populate the UI with the details saved in the file.  I think that is the plan for now.  This way, I can at least do the basic validating in the UI that I already do and not have to worry as much about totally bogus raw data getting sent to the backend, resulting in completely incorrect plates generated.

Sounds reasonable. I would want anything I reloaded in from a JSON to be revalidated and syntax checked. I would recommend that you keep a versioning field in the JSON file and also iterate on your parser rather than just overwrite the parser code. (If file is v1, use parser v1. If file is v2, use parser v2.)

[swill]

This is why I will go with a multiselect, so you can pick which layers the cutouts go on and if you change your mind and remove a layer or add a layer, you just change the multiselect and don't have to mess with the hole details.

Sure, but that could still require a bunch of extra clicks. Cloning / copying may be useful. Keep it in mind while you develop, but it doesn't have to be a day 0 feature. Saving is more important.

I can keep that in mind.  Could be possible to do a clone including all of the fields already entered.

I have been working on a different feature, so I have not had a chance to look at this yet.  The other feature is an integration with lasergist.com (link) so you can order your case with a single click (well not quite, you need to specify what you want) from my UI.  They offer free worldwide shipping, and have very competitive prices, so this should be a pretty sweet integration for you guys.  I just found out that their team has some scheduled holiday in the middle of this month to get some much deserved R&R, so we will wait to launch the integration until the end of the month.

Are they going to be able to autoquote keyboard layouts greater than 300mm long? That is roughly 15 columns, which will handle 60% but not TKL or full size. Their system had a hard break at 300mm. Maybe that is the size of the laser bay. (Seems small compared to the Trotech Speedy 300's I use with a lower watt laser.)

It looked like it would be about $70-$80 for a 15x6 top, and an extra $30 for the bottom. Seems kind of expensive...

How are you handling the kerf for this one?

I think they are still working out the pricing, we will see.  They only do stainless steel too, so you can't choose cheap materials (which makes a difference).  They are cheaper than BBS though from what I can tell by quoting both.

You will be able to do pieces bigger than 300mm.  That is a soft limit imposed because they are working with any random thing a user sends to them.  Because our use case is pretty consistent they will let me send larger objects without a problem.

Also worth noting.  If you are prototyping, you can specify padding on two opposing sides at -0.005mm and the tool will automatically remove those sides.  If you do this on the top and bottom for example, the resulting piece will be something like two pieces with "edge width" x 100mm (keyboard height) dimensions.  So if edge width = 6mm, then it would produce two pieces that are 6 x 100mm.  Because I know when this is going to happen, I can quote the overall size of that as being 22 x 100mm for that layer (both 6mm pieces with 10mm between).  They will automatically account for that, so we can get a lot more middle layers cut for very cheap.  I would recommend this approach for prototyping layouts using their service.

Testing has shown they cut my designs with exactly 0.2mm kerf.  When you try to order I will be checking the kerf the plate is drawn with, if it does not have a 0.2mm kerf, it will automatically add it and redraw the CAD before showing the order screen and use the newly generated files for the order.

I will start looking at fixing the alps stabilizer issue, the poker plate size, adding a top plate and adding the additional UI for adding polygons soon.  Keep in mind, I only get an hour or two to do this at night after I get my family to bed, so I don't have a huge amount of time to pump out features.  I have been busting out quite a bit recently, but I have to be careful not to get too run down or I will be useless to everyone.    I do work a full time job, have my own company on the side and do this in my "spare" time... 

Sure, sure. We all have our day jobs.

Edit: BTW, regarding your concept of 'saving'.  I will be adding the concept of Presets to handle a lot of the standard layouts.  With that, I will let you "Save" and download a JSON file of your settings.  This saved files can then be uploaded as a custom preset and it would populate the UI with the details saved in the file.  I think that is the plan for now.  This way, I can at least do the basic validating in the UI that I already do and not have to worry as much about totally bogus raw data getting sent to the backend, resulting in completely incorrect plates generated.

Sounds reasonable. I would want anything I reloaded in from a JSON to be revalidated and syntax checked. I would recommend that you keep a versioning field in the JSON file and also iterate on your parser rather than just overwrite the parser code. (If file is v1, use parser v1. If file is v2, use parser v2.)

I don't know what you mean by a version in the file and in the parser.  For the parser, either the code is right or its not.  Only valid input will be applied to the UI.  I could potentially show elements which did not apply because they were invalid, but only valid options would be added to the UI.  You would then draw based on what is in the UI, allowing you to modify the details before you draw.

Maybe I didn't understand you.

[skullydazed]

Edit: BTW, regarding your concept of 'saving'.  I will be adding the concept of Presets to handle a lot of the standard layouts.  With that, I will let you "Save" and download a JSON file of your settings.  This saved files can then be uploaded as a custom preset and it would populate the UI with the details saved in the file.  I think that is the plan for now.  This way, I can at least do the basic validating in the UI that I already do and not have to worry as much about totally bogus raw data getting sent to the backend, resulting in completely incorrect plates generated.

This is a great solution. I've just pushed a pretty big change to my own format that should make sharing a common format somewhat easier in the future, and there's more I want to do in that vein (for example, supporting your "middle width" setting rather than the "pcb padding" I use now.)

As a thought, could we setup a wiki somewhere that starts to collect and document common settings? As you add more features like this I could see something community driven being immensely helpful. Plus, it lets you spend your time hacking rather than documenting.

[swill]

Edit: BTW, regarding your concept of 'saving'.  I will be adding the concept of Presets to handle a lot of the standard layouts.  With that, I will let you "Save" and download a JSON file of your settings.  This saved files can then be uploaded as a custom preset and it would populate the UI with the details saved in the file.  I think that is the plan for now.  This way, I can at least do the basic validating in the UI that I already do and not have to worry as much about totally bogus raw data getting sent to the backend, resulting in completely incorrect plates generated.

This is a great solution. I've just pushed a pretty big change to my own format that should make sharing a common format somewhat easier in the future, and there's more I want to do in that vein (for example, supporting your "middle width" setting rather than the "pcb padding" I use now.)

As a thought, could we setup a wiki somewhere that starts to collect and document common settings? As you add more features like this I could see something community driven being immensely helpful. Plus, it lets you spend your time hacking rather than documenting.

I will have to look into how to best offer a Wiki without opening myself up to a **** load of spammers and *******s.  User generated content is a PITA to maintain...

The easiest way (for me) would be to create a Github repo with the content in markdown and people could submit changes or new content with pull requests.  I would basically just expose the 'content' folder of a Hugo site.  I am sure there are easier to use options, but harder for me to manage.  I will have to see what is possible there...

[IBNobody]

I don't know what you mean by a version in the file and in the parser.  For the parser, either the code is right or its not.  Only valid input will be applied to the UI.  I could potentially show elements which did not apply because they were invalid, but only valid options would be added to the UI.  You would then draw based on what is in the UI, allowing you to modify the details before you draw.

Maybe I didn't understand you.

A better way to say it... Don't break file compatibility for previously generated JSON files when you decide to add new features. If I generate a JSON file, I would hope that 6 months to a year down the road that it still works. If you save a version field and clone your parser method rather than ripping out the guts of it every time, you can preserve the older formats.

[skullydazed]

I will have to look into how to best offer a Wiki without opening myself up to a **** load of spammers and *******s.  User generated content is a PITA to maintain...

The easiest way (for me) would be to create a Github repo with the content in markdown and people could submit changes or new content with pull requests.  I would basically just expose the 'content' folder of a Hugo site.  I am sure there are easier to use options, but harder for me to manage.  I will have to see what is possible there...

The github idea is pretty good. I don't think you even need Hugo, just a repo with files and README.md 's would be plenty. If you give a few people access to that repo who can handle day to day stuff (accepting PR's, responding to issues (hopefully not many,) etc) it could even free up your time.

[swill]

I don't know what you mean by a version in the file and in the parser.  For the parser, either the code is right or its not.  Only valid input will be applied to the UI.  I could potentially show elements which did not apply because they were invalid, but only valid options would be added to the UI.  You would then draw based on what is in the UI, allowing you to modify the details before you draw.

Maybe I didn't understand you.

A better way to say it... Don't break file compatibility for previously generated JSON files when you decide to add new features. If I generate a JSON file, I would hope that 6 months to a year down the road that it still works. If you save a version field and clone your parser method rather than ripping out the guts of it every time, you can preserve the older formats.

Fair enough.  The problem though is if I make breaking changes to the UI, it is unlikely I will be able to make the new features backwards compat.  We will see.  For example, the old padding vs the new padding + edge width.  I will keep that in mind though...

[swill]

I will have to look into how to best offer a Wiki without opening myself up to a **** load of spammers and *******s.  User generated content is a PITA to maintain...

The easiest way (for me) would be to create a Github repo with the content in markdown and people could submit changes or new content with pull requests.  I would basically just expose the 'content' folder of a Hugo site.  I am sure there are easier to use options, but harder for me to manage.  I will have to see what is possible there...

The github idea is pretty good. I don't think you even need Hugo, just a repo with files and README.md 's would be plenty. If you give a few people access to that repo who can handle day to day stuff (accepting PR's, responding to issues (hopefully not many,) etc) it could even free up your time.

I have a whole bunch of Hugo sites already and I am able to host them for free on object storage, so that is the draw there...    I have also built pipelines to automatically apply changes and deploy the sites with a single command line.  I can set it up as a post commit hook to automatically re-deploy on successful commit.

[emdude]

rshift is 2.25u.

I haven't looked at my 5.5u spacebar yet.


this was my design (the gap between spacebar and ralt was because of my mistake)
http://www.keyboard-layout-editor.com/#/gists/15c003ced176049524258fd31dc3d941
http://puu.sh/qt77d/bfd3e7c384.png

another thing is that you need to sacrifice the 'poker case' screw on the left if using alps stabilisers, due to this
http://puu.sh/qt7e3/9b79619640.png

previously, I think the left hole and left stabiliser mark would 'blend into eachother', so I made the mistake of not realising until I tried to install stabilisers.

I'm having problems with my enter key (but that's because I have too 'wide' stabilisers due to using an AEK enter to salvage the mismatched placement of the switch itself)



I'll likely end up desoldering and making a new plate with these issues resolved

No need to remove the left screw cutout, just shorten the length.

@swill, I recommend that, for Alps plates, the length of the cutout be shortened as in the screenshot below.  I also recommend that the center screw cutout be removed as well; you cannot place a screw there when the switches are mounted anyway.

Show Image

Not sure how the radius of the screw cutout ended up being 2.5005, oh well.

@bubblebobbler, I apologize, I was incorrect here.  I only realized this as I was working on a plate design.  Simply shortening the length of the screw cutout will not solve the issue of the overlap with the stab.  Even at this shorter length, there will still be an overlap.  My alternate solution would be to simply remove the stab cutouts completely; a non-stepped Caps Lock key should still work properly even without stabs.

[swill]

rshift is 2.25u.

I haven't looked at my 5.5u spacebar yet.


this was my design (the gap between spacebar and ralt was because of my mistake)
http://www.keyboard-layout-editor.com/#/gists/15c003ced176049524258fd31dc3d941
http://puu.sh/qt77d/bfd3e7c384.png

another thing is that you need to sacrifice the 'poker case' screw on the left if using alps stabilisers, due to this
http://puu.sh/qt7e3/9b79619640.png

previously, I think the left hole and left stabiliser mark would 'blend into eachother', so I made the mistake of not realising until I tried to install stabilisers.

I'm having problems with my enter key (but that's because I have too 'wide' stabilisers due to using an AEK enter to salvage the mismatched placement of the switch itself)



I'll likely end up desoldering and making a new plate with these issues resolved

No need to remove the left screw cutout, just shorten the length.

@swill, I recommend that, for Alps plates, the length of the cutout be shortened as in the screenshot below.  I also recommend that the center screw cutout be removed as well; you cannot place a screw there when the switches are mounted anyway.

Show Image

Not sure how the radius of the screw cutout ended up being 2.5005, oh well.

@bubblebobbler, I apologize, I was incorrect here.  I only realized this as I was working on a plate design.  Simply shortening the length of the screw cutout will not solve the issue of the overlap with the stab.  Even at this shorter length, there will still be an overlap.  My alternate solution would be to simply remove the stab cutouts completely; a non-stepped Caps Lock key should still work properly even without stabs.

Removing the stabilizer for that specific switch can be done by simply adding this code to the object associated with that key:  _s:0

Sent from my A0001 using Tapatalk

[swill]

Someone asked me about this recently, so I thought I should post these details (since I don't have a wiki yet).

Here is how you handle multiple key layouts on a single layout...

Result looks like this:



Keep in mind that the normal Right Shift will require a PCB mount stabilizer in order to function.

Here is the raw code for this layout.  Basically what I am doing is placing "additional" keys in the layout and I am then moving the default keys to be placed on top of the other keys.  If you paste this code into the KLE raw layout, you will not see any of the keys because I have defined them before the normal keys, so the normal key covers the additional keys.  I do this to make it nicer visually, but you could change this behavior by changing the override keys to after and changing all the offsets accordingly.

So without any further ado.  Additions in bold and underlined...

Code: [Select]

["~\n`","!\n1","@\n2","#\n3","$\n4","%\n5","^\n6","&\n7","*\n8","(\n9",")\n0","_\n-","+\n=",{w:2},"Backspace"],
[{w:1.5},"Tab","Q","W","E","R","T","Y","U","I","O","P","{\n[","}\n]",{w:1.5},"|\n\\"],
[{w:1.25},"Stepped",{w:1.75,x:-1.25},"Caps Lock","A","S","D","F","G","H","J","K","L",":\n;","\"\n'",{w:2.25},"Enter"],
[{w:2.25},"Shift","Z","X","C","V","B","N","M","<\n,",">\n.","?\n/",{w:1.75},"ShortShift","Fn",{w:2.75,x:-2.75},"Shift"],
[{w:1.25},"Ctrl",{w:1.25},"Win",{w:1.25},"Alt",{x:3.25},"Offcenter Spacebar",{w:6.25,x:-4.25},"",{w:1.25},"Alt",{w:1.25},"Win",{w:1.25},"Menu",{w:1.25},"Ctrl"]

Make note of the following sections:
- {w:1.25},"Stepped",{w:1.75,x:-1.25},"Caps Lock"
- {w:1.75},"ShortShift","Fn",{w:2.75,x:-2.75},"Shift"
- {x:3.25},"Offcenter Spacebar",{w:6.25,x:-4.25},""

Hope this helps people.  Let me know if you have questions...

Edit: I may have put the Off center Spacebar in the wrong place.  I don't actually know where that key actually is...

[Eszett]

Are these stab cutout extensions a recent innovation I missed?


update: I've read about it, question answered :-)

[swill]

Are these stab cutout extensions a recent innovation I missed?

Show Image

update: I've read about it, question answered :-)

Show Image

Yes. The default cherry 2u stabilizer cutout had some complaints about stuff not seating nicely. I basically just used the same cutout as the space bars and just updated the stab to be 2u.

I think it is an improvement for sure.

[Eszett]

Hi swill! The stab cutout extensions are an interesting change, I appreciate it. However, I'm sceptical if these little nibs may be abit too small (0,6mm) for the laser cutter.  What do the experts think about it?

[swill]

Hi swill! The stab cutout extensions are an interesting change, I appreciate it. However, I'm sceptical if these little nibs may be abit too small (0,6mm) for the laser cutter.  What do the experts think about it?

Show Image

It depends on the material. Stainless or aluminum, no problem. Acrylic may not be all that strong, but I don't think it is worse than it was before. The size and shape of that piece depends on the switch cutout as well.

[Eszett]

It depends on the material. Stainless or aluminum, no problem.

alrighty, then i was abit over anxious.

[kawasaki161]

I have another feature request. Maybe cutouts for PCB mount cherry stabs with 5mm plates would be nice to have. I've got a rough example here, the cutouts are on the bigger side in this example, but I didn't want to have a plate I can't use as my first prototype. If everything goes to plan I'll have the plate next week, I should be able to correct and share the measurements by then.

[swill]

I have another feature request. Maybe cutouts for PCB mount cherry stabs with 5mm plates would be nice to have. I've got a rough example here, the cutouts are on the bigger side in this example, but I didn't want to have a plate I can't use as my first prototype. If everything goes to plan I'll have the plate next week, I should be able to correct and share the measurements by then.

Let me know how it goes.

Sent from my A0001 using Tapatalk

[xondat]

It depends on the material. Stainless or aluminum, no problem.

alrighty, then i was abit over anxious.

Can confirm, Aluminum works absolutely fine.

[Eszett]

I'd like to talk about fairing layers. Usually, when building a sandwhich
layered case, a fairing layer is added to avoid the ugly "floating keys style".
That would be a rim around the key matrix (picture 1), but there is one
downside: you can see through the gaps of the keycaps to the lower
stage, ie. the plate, which might be abit ugly. So i came up with a
additional auxiliary "ceiling" layer (picture 2), which goes between the
keycaps and the plate. First question, what is your opinion on that? And,
second question, which measurements would be ideal?

1) Height: I calculated the value for the layer's height as 2mm, you can't
take more since it will collide with the keycaps then.

2) Switch cutouts: The Cherry switches allow a cutout not smaller than
15,9 * 15,6mm. With a little safety clearance added, perhaps something
like 16,5mm*16,5mm would be a good medium between too large and too
small.

3) Stab cutouts: Here comes the tricky part. I don't have courtyard
dimensions of stabs at hand, can someone help out?

[swill]

This is a feature that is on the near term roadmap.  I plan to work on it as soon as I launch an integration which I am almost finished with.

My initial plan was to use the 19.05mm boundary of the key as the cutout size.  As you point out, this will not leave any space between the keycaps and will essentially cut out the entire middle of the plate.

I could potentially let the top plate cutout boundary be a configurable value between 16 and 19.05mm.  This would let users configure how they want this top layer to be cut.  Of course, this gets a bit tricky.  For MX, pretty much all the cutouts (including stabilizers) would work inside a 16mm boundary.  However, things are a bit tricker for Alps.  First, the cutout is not square, so we have to know how we expect the cutout to look there.  Next, you can't get away with anything less than 19mm with a stabilized alps key for a boundary because the alps stabs are so displaced from the switch.

I will have to do some more thinking about the configurability of the top layer cutout and how much control I want to give over it.  For alps, I could potentially have two different types of cutouts depending on if the key is stabilized or not, but then I start getting into more complex logic.  Did the user flip the stabilizer to the other side (eg: {_rs:180} )?  How do I account for a configurable sizing in these cases, etc...

I will definitely be digging into this more soon, but right now, I can't commit to any specific details yet.  I need to think about this more first...

I'd like to talk about fairing layers. Usually, when building a sandwhich
layered case, a fairing layer is added to avoid the ugly "floating keys style".
That would be a rim around the key matrix (picture 1), but there is one
downside: you can see through the gaps of the keycaps to the lower
stage, ie. the plate, which might be abit ugly. So i came up with a
additional auxiliary "ceiling" layer (picture 2), which goes between the
keycaps and the plate. First question, what is your opinion on that? And,
second question, which measurements would be ideal?

1) Height: I calculated the value for the layer's height as 2mm, you can't
take more since it will collide with the keycaps then.

2) Switch cutouts: The Cherry switches allow a cutout not smaller than
15,9 * 15,6mm. With a little safety clearance added, perhaps something
like 16,5mm*16,5mm would be a good medium between too large and too
small.

3) Stab cutouts: Here comes the tricky part. I don't have courtyard
dimensions of stabs at hand, can someone help out?
(Attachment Link)

[ideus]

My grain of salt on fairing layers is that there is no need for fairing layers, for a sandwich case. I like the floating key caps.

[Eszett]

Hi swill! I'm looking forward to your coming fairing feature! A Question: You wrote a 16*16mm courtyard will be sufficient for Cherry MX & stabs. Does this include costar stabs too? Or just Cherry & cherry stabs?


Changed topic: I noticed a bug(?) in the plate builder. Or isn't it a bug?
See picture.

[swill]

Hi swill! I'm looking forward to your coming fairing feature! A Question: You wrote a 16*16mm courtyard will be sufficient for Cherry MX & stabs. Does this include costar stabs too? Or just Cherry & cherry stabs?

Both, but that has not been validated.  That is by the numbers, not by measuring the plastic overlap beyond the cutout.

[Eszett]

Ye, the plastic overlaps are the essentially tricky part! Thats why I call it "courtyard" ;-) The problem is, I can't find any datasheet about the courtyard measurements of Cherry & Costar stabs..

[swill]

Ye, the plastic overlaps are the essentially tricky part! Thats why I call it "courtyard" ;-) The problem is, I can't find any datasheet about the courtyard measurements of Cherry & Costar stabs..

PCB mount cherry stabs will be fine.

Plate mount cherry stabs will be tricky because of the bar and the clip in plastic.

Costar will depend on the clip in plastic.

[duynguyenle]

This is a feature that is on the near term roadmap.  I plan to work on it as soon as I launch an integration which I am almost finished with.

My initial plan was to use the 19.05mm boundary of the key as the cutout size.  As you point out, this will not leave any space between the keycaps and will essentially cut out the entire middle of the plate.

I could potentially let the top plate cutout boundary be a configurable value between 16 and 19.05mm.  This would let users configure how they want this top layer to be cut.  Of course, this gets a bit tricky.  For MX, pretty much all the cutouts (including stabilizers) would work inside a 16mm boundary.  However, things are a bit tricker for Alps.  First, the cutout is not square, so we have to know how we expect the cutout to look there.  Next, you can't get away with anything less than 19mm with a stabilized alps key for a boundary because the alps stabs are so displaced from the switch.

I will have to do some more thinking about the configurability of the top layer cutout and how much control I want to give over it.  For alps, I could potentially have two different types of cutouts depending on if the key is stabilized or not, but then I start getting into more complex logic.  Did the user flip the stabilizer to the other side (eg: {_rs:180} )?  How do I account for a configurable sizing in these cases, etc...

I will definitely be digging into this more soon, but right now, I can't commit to any specific details yet.  I need to think about this more first...

Could this potentially be used not as a top plate but as a sandwich layer between the plate and surface of the PCB? Kinda like the sandwich layer you commonly see on full Acrylic layered cases to improve on rigidity? That could be neat!

Not that I really care about sandwiched layers, but I was thinking the pattern could be used to cut a 3mm thick layer of low density foam or neoprene to be used as a sound dampener, glued to the back of the plate. Just a thought!

[Eszett]

If someone needs it and for the sake of documentation, here I draw a info sketch of the exact measurements.
[ Specified attachment is not available ]

[IBNobody]

Hey Swill... Can you check my logic...

Lasergist said that they recommend a kerf of .15mm. If I didn't want to regenerate my keyboard layout, would I resize the diameter of my cutouts by .3mm inward (around the center) and the edge of the board by .3mm outward?

[swill]

Hey Swill... Can you check my logic...

Lasergist said that they recommend a kerf of .15mm. If I didn't want to regenerate my keyboard layout, would I resize the diameter of my cutouts by .3mm inward (around the center) and the edge of the board by .3mm outward?

Trust me, you will want to just set the kerf setting in the builder and regenerate the layout.  It will be WAY less work.  I have been working with lasergist to sort out these details and we actually came to 0.2mm as the ideal kerf to use.  I will use that in my description because it makes things easier to represent.

The kerf is the width of the material removed when making a cut with a tool.  That means, that if you are making a cut and you keep the center of the cutting tool on the line you are cutting, you will be removing 1/2 the kerf on one side and 1/2 the kerf on the other side (in this case 1/2 of 0.2mm => 0.1mm).

So if you visualize this, outside boundary of the plate would have to be 0.1mm BIGGER than what you want because when the cut is made, it will be cutting an extra 0.1mm inside the actual line drawn.

The opposite is true for cuts made inside the plate since you are cutting away material.  On cuts inside the plate, the dimensions have to be 0.1mm SMALLER because the final cutout will be bigger because the tool will cut a bigger hole than what is defined by the line because the tool will cut out an extra 1/2 kerf (0.1mm) outside the line drawn.

So in summary, the cutouts need to be adjusted by 1/2 the kerf size (0.1mm in this case).
- Cuts to the outside boundaries need to be made bigger by 1/2 the kerf (0.1mm) since the resulting piece will be smaller than the lines drawn.
- Cut outs inside the plate need to be smaller by 1/2 the kerf (0.1mm) since more material will be cut out of the plate than what is drawn.

I hope that makes sense.  If you are using something like the MX H style cutout or the Cherry MX stabilizers, be careful, the adjustments are not obvious to account for kerf.  Some lines get longer and some get shorter.  You have to visualize the cutting tool making the cut to understand what needs to be changed.

I highly recommend regenerating the plate with a kerf value of 0.2mm if you are going to be using lasergist.  Doing the adjustments by hand after the fact is going to be very hard and will take a long time (and you could make errors).

Let me know if you have any questions. 

[swill]

If someone needs it and for the sake of documentation, here I draw a info sketch of the exact measurements.
(Attachment Link)

thank you for checking my work.  i have adjusted the 2u stabilizer to reflect the 11.9mm distance from switch center to stab center.  Not sure how I messed up that calculation by 0.05mm, but it was still in the Cherry tolerance.  The calculation was not wrong before my last release.  In the last release I removed the static cherry 2u cutout in favor of the 'winged' cutout for a more structured stabilizer cutout (like the spacebar cutout).  In that change I introduced the 11.95mm variable to the spacebar cutout to represent the 2u stabilizer.

Thanks for reviewing this for me. 

[IBNobody]

You had better luck with a .2mm kerf? They had recommended a .15mm kerf to me. Good to know, and I am glad I asked. I will regenerate.

How does your kerf affect the manual padding added to the edges? If I have 10mm padding on the top and bottom, does the kerf setting extend that beyond 10mm?

[swill]

You had better luck with a .2mm kerf? They had recommended a .15mm kerf to me. Good to know, and I am glad I asked. I will regenerate.

How does your kerf affect the manual padding added to the edges? If I have 10mm padding on the top and bottom, does the kerf setting extend that beyond 10mm?

They told me to use either 0.15mm or 0.2mm. Then they cut a 2 key test plate with 0.2mm kerf and showed me pics of the caliper measurement and it was perfect. Honestly, 2.5 hundredths of a mm will be completely un-noticeable.

They may have suggested 0.15mm because their precision will range between 0.15 and 0.2. If that is the case, then if the cut is 0.15 and the kerf is set to 0.2, then the cutouts would be slightly smaller than intended. In that case it is better to error on the cutout being slightly bigger than intended rather than too small (only by 0.025mm).

So in that case their recommendation may actually be right.

As for padding and such, Yes, my tool adjusts for kerf on anything it draws so you don't have to worry about that.

[ideus]

Is there a generally accepted rule for Cutting shops regarding kerf? Or we should ask each time if they add it, or the customer should do it?

[swill]

Is there a generally accepted rule for Cutting shops regarding kerf? Or we should ask each time if they add it, or the customer should do it?

No there is not. It depends on the shop. Some will account for kerf for you and you won't have to worry about it. Some expect you to account for it, but you have to ask what their kerf is for the material and thickness you are cutting.

There are a lot of different machines and cutting types, each with different kerf. A single machine will have different kerf values based on; material, thickness and tool speed. Because if this you really need to be checking with the fab shop to know how to get the best results given your material details.

[IBNobody]

They told me to use either 0.15mm or 0.2mm. Then they cut a 2 key test plate with 0.2mm kerf and showed me pics of the caliper measurement and it was perfect. Honestly, 2.5 hundredths of a mm will be completely un-noticeable.

They may have suggested 0.15mm because their precision will range between 0.15 and 0.2. If that is the case, then if the cut is 0.15 and the kerf is set to 0.2, then the cutouts would be slightly smaller than intended. In that case it is better to error on the cutout being slightly bigger than intended rather than too small (only by 0.025mm).

So in that case their recommendation may actually be right.

As for padding and such, Yes, my tool adjusts for kerf on anything it draws so you don't have to worry about that.

Ok. 0.15mm it is...

One thing that I think I may run into trouble on, though, is tabs. I want to add enough padding to the top and bottom so that I can fold the metal down with a finger press. The act of bending lengthens the metal, but there are calculators for that. I also am adding some portals in the bend for USB. That's why I was reluctant to rebuild the keyboard SVG. I am afraid I am going to goof and not get a precise length bend.

What I may do, then, is generate an SVG with and without a kerf, overlap them in AI (making one guides), and make any edits I need.That way, I have a visual representation.

Your hole tool can't come soon enough!

[swill]

They told me to use either 0.15mm or 0.2mm. Then they cut a 2 key test plate with 0.2mm kerf and showed me pics of the caliper measurement and it was perfect. Honestly, 2.5 hundredths of a mm will be completely un-noticeable.

They may have suggested 0.15mm because their precision will range between 0.15 and 0.2. If that is the case, then if the cut is 0.15 and the kerf is set to 0.2, then the cutouts would be slightly smaller than intended. In that case it is better to error on the cutout being slightly bigger than intended rather than too small (only by 0.025mm).

So in that case their recommendation may actually be right.

As for padding and such, Yes, my tool adjusts for kerf on anything it draws so you don't have to worry about that.

Ok. 0.15mm it is...

One thing that I think I may run into trouble on, though, is tabs. I want to add enough padding to the top and bottom so that I can fold the metal down with a finger press. The act of bending lengthens the metal, but there are calculators for that. I also am adding some portals in the bend for USB. That's why I was reluctant to rebuild the keyboard SVG. I am afraid I am going to goof and not get a precise length bend.

What I may do, then, is generate an SVG with and without a kerf, overlap them in AI (making one guides), and make any edits I need.That way, I have a visual representation.

Your hole tool can't come soon enough!

Soon™ 

[Eszett]

thank you for checking my work.  i have adjusted the 2u stabilizer to reflect the 11.9mm distance from switch center to stab center.

Good to know, swill. Another question... is it a bug that the Cherry&Costar compatible miss this rectangle here? See picture.

[swill]

thank you for checking my work.  i have adjusted the 2u stabilizer to reflect the 11.9mm distance from switch center to stab center.

Good to know, swill. Another question... is it a bug that the Cherry&Costar compatible miss this rectangle here? See picture.

(Attachment Link)

That is intentional. The costar stabilizer has slightly different characteristics, so the cutout had to be slightly modified to adapt to being compatible with costar as well.  That is why that small piece is different.