dactyl-keyboard
dactyl-keyboard copied to clipboard
joshreve
Wilderbuilds Trackball
Hi, Josh. As I mentioned on Etsy, here's the PR for my trackball changes and several other tweaks.
Almost forgot, just set thumb_style to TRACKBALL_WILD to get my version of the trackball build.
Nice, thanks. I'm going to get on merging this in a week or two when I have my PCB work settled or I need a break, whichever comes first.
Hello, wonderful people. @bullwinkle3000 's trackball let me to investigate this project, and I'm trying to build this branch.
I've altered the default src/run_config.json thumb_style to TRACKBALL_WILD but I get an empty hole in the STL when I look at the .scad it generates. Here is my diff:
$ git diff
diff --git a/src/run_config.json b/src/run_config.json
index 3f17d94..d55c18d 100644
--- a/src/run_config.json
+++ b/src/run_config.json
@@ -19,7 +19,7 @@
"column_style": "standard",
"full_last_rows": false,
"keyboard_z_offset": 11,
- "thumb_style": "DEFAULT",
+ "thumb_style": "TRACKBALL_WILD",
"default_1U_cluster": true,
"trackball_in_wall": false,
"tbiw_ball_center_row": 0.2,
$ git log -1
commit 9f0407fdb700c9728fab973f4fa9e1cb39d02205 (HEAD -> wilder, bullwinkle/wilder)
Author: bullwinkle3000 <[email protected]>
Date: Wed Nov 10 13:33:17 2021 -0500
Slight clean
Writing this comment showed me that I was behind by two commits, so I did a pull and grabbed the latest commits, but now it will not build (via the ./dactyl.sh shell --session docker image):
(base) root@60d3fc3007e8:/app/src# time python3 dactyl_manuform.py
NO CONFIGURATION SPECIFIED, USING run_config.json
Traceback (most recent call last):
File "/app/src/dactyl_manuform.py", line 60, in <module>
with open(os.path.join(overrides), mode='r') as fid:
FileNotFoundError: [Errno 2] No such file or directory: ''
real 0m0.134s
user 0m0.271s
sys 0m0.333s
and it looks like it's 38a02c8598f0088eb7385547af3ea9b4b32da447 because if I change overrides to null instead of "" it builds again, but I get a slightly different empty hole in the .scad file:
Is there a sample run_config.json that will generate correctly, and/or is there something missing that wasn't committed? Thank you very much for your work, and any help you can provide!
Ah, that's right... I've been updating that branch heavily since submitting this PR. Forgot it was awaiting approval/merge. I'll update and fix the conflicts this week. I might need to pull out this PR if I can't get to it and resubmit later.
Otherwise, that's an issue with .scad files I've had for a while and I haven't addressed yet as I always do my full generation in cadquery (which now exports STLs in addition to STEP files).
I've been focused mostly on my own workflow for my store working smoothly so, yes, some bits may not work out-of-the-box for users just downloading. But feel free to ping me for help and I'll either fix the code or help you get it working. I never use the docker or the dactyl.sh scripts so I'm unsure if those CAN work with that branch. I'd suggest using my fork and not Josh's. We'll eventually sync up, but there's a slew of differences now.
As for the null/"" thing, I'll fix that this afternoon and update. I now always specify an "overrides" parameter pointing to another json config file which simply has a subset of the run_config.json params to override for a particular customer (so as not to dirty up the run_config.json). Here's an example:
`{
"ENGINE": "cadquery",
"override_name": "TEST",
"save_dir": "/some_dir_for_exported_things",
"iteration": "please_god_just_work",
"show_caps": false,
"nrows": 6,
"ncols": 6,
"plate_style": "NOTCH",
"tenting_angle": 0.32,
"keyboard_z_offset": 13,
"full_last_rows": true,
"thumb_style": "TRACKBALL_WILD",
"other_thumb": "DEFAULT",
"ball_side": "right"
}`
Lastly, I should mention my version also spits out a "freecad.py" script that, when copy/pasted into FreeCAD's python console, will import the STEP files and export STLs into the same target directory. I generally use these for my prints as they're more lightweight than the Cadquery exports and seem to be free from errors.
Very interesting. The feedback loop using cadquery is very very slow, which is why I was using solid/openscad (I can see changes within ~2 seconds)
When you say "your version" are you referring to https://github.com/bullwinkle3000/dactyl-keyboard/tree/master or https://github.com/bullwinkle3000/dactyl-keyboard/tree/wilder ?
What command(s) do you use to generate the output that includes the freecad.py script?
It looks like resetting to 9e314772161a1f0ac45161f425481dd160b8470c allows me to correctly generate .stl's from openscad (for anyone else following along):
$ git reset --hard 9e31477
HEAD is now at 9e31477 added trackball_shapes.py and generated_holder.stl for start of code generated trackball parts
And edit so that
$ git diff
diff --git a/src/run_config.json b/src/run_config.json
index 5259f0d..8400298 100644
--- a/src/run_config.json
+++ b/src/run_config.json
@@ -1,10 +1,10 @@
{
- "ENGINE": "openscad",
+ "ENGINE": "solid",
"save_dir": ".",
"config_name": "CARBONFET_TEST_6x6_no_hotswap_notch",
"show_caps": false,
"show_pcbs": false,
- "nrows": 6,
+ "nrows": 5,
"ncols": 6,
"alpha": 0.26179916666666664,
"alpha_CUSTOM": 0.283,
@@ -22,7 +22,7 @@
],
"full_last_rows": true,
"keyboard_z_offset": 11,
- "thumb_style": "CARBONFET",
+ "thumb_style": "TRACKBALL_WILD",
"default_1U_cluster": true,
"minidox_Usize": 1.6,
"thumb_plate_tr_rotation": 180.0,
I set up miniconda (I think the conda.sh script should work fine?) and then, within the its dactyl-keyboard conda environment, I either run it natively within my IDE (PyCharm) or at the command line from within the src directory: python dactyl_manuform.py
Interesting re: that commit. I'll check that out, thanks!
And, yes, the scad version is great for fast iteration. Even now, with that bug, I'll leave it on for quick general changes and then switch to cadquery for my final builds.
Oh, yes, "my version" is usually the wilder branch on my repo. I put all my latest changes there, though I did recently pull them into the master there. I need to merge in Josh's recent changes as much as I can still.
Just did another merge from a feature branch, bulk_build, into wilder. It allows for batch processing of multiple board sizes and options at once (rather specifically geared towards my print shop).
Also, the two issues that @elliotf found should be fixed: The crash on "" instead of null, and the completely absent trackball socket in openscad.
I'm going to retarget this to a refactor branch (based on dev) and start the merge. I like the cluster separation and may even extend to trying to eliminate globals. Even if I pass all the variables in a big pile, it at least makes them IDE visible. I also want to remover my * imports. Another PR has some of this work and I am going to try to combine and clean up the concepts to bring them together. I still have to sort through all the changes as it looks like you have some other things going on as well. I think I'm going to start moving some of the extra stuff like the FreeCAD script generator to a contrib folder.
I like a lot of what people are doing with added features, but just can't maintain them and need them in an area that designates them as unsupported features that people can try, but may or may not work long term. I've had some similar requests from others and am already having issues maintaining the current workflows.
Merged with refactor branch. Doesn't seem to want to update here. I may close with comment and we can reopen a PR against refactor to continue working. Let me know what you think about that approach. It didn't make sense to push this to master since there it will need a bit of work to align with changes there. We can move it to dev once major refactoring is done and to master when it is clean and running smoothly.
Moving bits into a contrib folder is totally fine with me. A lot of the side bits from my branch are mostly focused on my store or print reliability and haven't always been geared towards keeping a clean repo for others to check out.
Along those lines, I'm also fine with reopening the PR on refactor and keeping the tectonic shifts there.
I've written a bulk_build.py to build about 40 or so different feature combinations as I'm setting up a queuing system for incoming orders that should just pluck the needed STLs for printing rather than run a full build. In putting that together, I had to rework the main script into a single function, so it's now vectoring towards its own class and I hope to have that in place by the beginning of next week and may have a bunch of the globals reined in. Might be interesting to discuss possible architectures for all the various options and features since they soon needn't sit in a single massive file (I hope.).
I have this urge to wholly shift the code into a more modular, clear, and maintainable setup if for no other reason than to entirely transition alway from the Clojure origins. Those origins are pretty damn cool, but awfully hard to expand upon. So many stale forks with good intentions.
FYI, I have completed the first round of refactoring and have the whole lot generating again. I'm going to look at your new additions since I pulled for merging. After that, I should be aligned with any new features you have. In addition, I'm planning to pull the OLEDs and probably switch plates to packages similar to the clusters. I managed to eliminate all globals from the code which is far more stable and predictable.
Now that I have removed all globals and have scoped class and instance variables, refactoring has become much easier since the IDE actually knows where it is getting information and the normal refactoring tools can properly inspect the code. The refactor branch is still changing so it is probably not a good choice for use yet, but I am getting close.
@bullwinkle3000 I would like to catch up in a week or two to see if we can realign the branches to make cross-PRs feasible again. Some of the changes I made are drastic enough that a simple diff won't be sufficient. If you prefer to keep yours fully independent or don't like the other modifications, I understand, but it would be good to be able to take advantage of each others work without extensive manual operations. At that point I would close the PR and we can reopen new ones for specific upgrades.
I just reviewed the latest and it seems like primarily file controls and the USB / controller external holder so I think we are close. I will try to pull the holder in and make it match. For the files, I changed a bit and I am going to look at what we both have and compare.
One thing I am targeting is that the config JSONs only need parameters they want to change and I plan to actually lock down the default config, possibly with a version in the name so if I need to change it, the old one can still be referenced. Good news is that it looks like I caught the majority of your updates with my last pull.
I still have to look at reattaching the new code in refactor to the workflow functions, but it should be relatively similar so I don't think it will take a lot to fix.
I just saw this so figured I'd respond while I'm nose in the code.
About three weeks ago, I got about halfway through a first pass at merging my changes with the latest on yours and then shelved it all during a rush of orders. I've since been digging deeper into cadquery and that's taken most of my current focus. Given all the changes you've made, I think a solid merging would need to restart prior to my batch run code or we'd sort of be merging two reinvented wheels. Any of the changes I've made since to the dactyl_manuform class have been for efficiency and to support my workflow. Ultimately, YES, I'd love to catch up in a week or so to try to keep things workable.
I dove into the cadquery rabbit hole by starting in on some programmatic supports to ease 3D printing issues. The supports, I think, might work out well to limit print times, filament usage, and, I hope, even bump print quality up a notch. Might even be exportable as a separate model for soluble supports. Now that I'm more familiar with cadquery's api, I'm looking to bump up the quality and appearance of the models and that has me wondering if keeping the code happy for multiple engines would be feasible? Could farm out some of the generation to engine specific scripts, but what I'm considering could diverge things even further, though I'll try to minimize the impact and keep the code clean. There's a point at which the everything-plus-the-kitchen-sink approach goes exponential.
I saw a lot of the work you've been doing on PCBs, skeletons, modularity and separable thumb clusters (which I've hoped to get to at some point.) I need to check them all out more thoroughly when I have time, but they're all intriguing!
Ah, the holder isn't actually working yet. I'd just very roughly converted it from an openscad source from Derek's code here: https://github.com/dereknheiley/dactyl-manuform-tight/blob/master/things/usb_holder.scad
I've had a couple of people reach out about running under Windows and I may put together a .bat file script to build a conda environment.
On the engines, I keep mulling that over. My one big concern is that cadquery is not a major project and could be dropped at some point. I like the generally agnostic commands, but it doesn't work everywhere. I already had to go engine specific with the base plate. My intent is to at least keep an abstraction layer to the engine, but I think if there were clear reasons to make one "supported" and the other fall behind it may be worth it. Worth further discussion once a branch exists that shows one engine has a huge advantage.
For the looking nicer, I think cadquery may be the way to go if the mesh smoothing tools work well. I'm thinking something similar to the blender dactyl. It would require generation reordering, but I already converted a lot of the geometry to do that. I'm also going to revisit the blender version, but it has a bit of an odd construction with a lot of function arrays that will require some time to break down.
I think it makes sense for us to finish our current workstreams and evaluate. I agree that doing so in the middle will make a mess. Even if you diverge further, we can look at merging, but I think it will be easier when both are essentially feature complete.