[Feature Request / Enhancement]

On previous hangouts for the Hand-o-Matic, I mentioned that for our project PrintToPeer we have been building a print button that can send the STL file directly into a 3D print queue from any website.

This print button is now ready to be used. It would be great to see how useful the button could be for you. The inital documentation is on this page: https://printtopeer.io/api

The print button allows any 3D printer owner to send the STL file directly from Hand-o-Matic to their 3D printers. I'm excited that by automating the whole process it will be faster and easier to print prosthetics.

Our printing system has been in development for over a year and a half, and is now capable of sending prints from the web to any Marlin 3D printer or Makerbot. There is webcam support, SMS notifications, and realtime feedback. We will be adding plating and multi-file uploads in the near future. You can request the Raspberry Pi software for free by sending me an email (on my profile).

روت دستگاه من پاک شده

Add Augenmass to site, link to it.

Add a process for guiding users to a selection of different hands and arms etc.

روت دستگاه من پاک شده

The page is slightly too wide for the iPad in landscape. Supposedly 1024x768 is the size the iPad wants. Or perhaps there's some CSS magic that will make it fit?

Add Augenmass to site repository, link it into measurements page, opening in a new window.

The web app should probably have downloadable hand assembly manuals. Possibly as an additional button next to Preview and Generate STL that would go to the manual for the hand that's selected in the interface. Or just a link to each hand's guide under Help.

This could just be a link to the enablingthefuture.org page for the hand or it could have the assembly guide stored in Markdown or something to make it easier to keep track of in version control along with the hand itself.

To add the Cyborg Beast, Talon, etc., we need to enhance the UI to only allow option combinations that work together. There are a few ways to do this:

For each design, have an options.json file that contains only that design's options.

Or have one options.json file, and add a way to express allowed combinations (or excluded combinations).

http://www.labnol.org/internet/email/track-gmail-with-google-analytics/8082/

I've done a few upgrades to the production mirror at https://e-nable.youmagine.com to have the recent fixes in there and host the "master" branch version.
I used git update-index --assume-unchanged config.php to ensure my local version wouldn't get overwritten with each upgrade or would block the upgrade process.

[Enhancement]

If/when the eNable webapp uses a camera to make measurements, you may be interested in in this measurement app that I discovered by Henner Zeller on Google+:

https://github.com/hzeller/augenmass
https://plus.google.com/+HennerZeller/posts/UvKbmfKZj16

I hope that this is useful in the coming months to avoid reinventing the wheel :) Hopefully I'll be on the hangout this week to discuss this some more!

I think a few aspects can be improved:

• Suggest SSL in setup docs
• Write right in directories and on files should be limited as much as possible
• Separate UI and OpenSCAD nodes.
• Absolute minimal privileges for PHP CLI that will launch OpenSCAD
• Chroots/jails in which OpenSCAD will run. We can probably wrap OpenSCAD?
• Authentication

These are meant to inventarize work, not to ask for code improvements. I plan to contribute where I can. If you beat me to it I won't mind though!

If Assembly reports an error when asked for a preview, display the error instead of the preview.

Example errors: invalid inputs, incompatible options.

The communication channel would be the output log, with lines like:

Echo: ERRORMSG: [Knuckle width must be at least 55]
Echo: ERRORMSG: [This design does not have a Gauntlet.]
Echo: ERRORMSG: [Hand is too wide. Width must be at least 67 for length 84.], ERRORLINK: [wide.html]

The message would be displayed in place of the preview, and the link would be presented, if provided, for the user to get more information (in a new window).

Call Yourls service, get short URL, pass as label to Assembler.

Web interface should address this, but the PHP should account for missing variables as well before tossing them over the shell to openscad.

Let's move the services app code into the services repo, so they can be deployed independently from the front end.

This is a "meta issue" where we can reference other issues that are concerned with high-availability and scalability.

The following is based on this Google+ Hangout and the discussion following it.

The Hand-o-Matic should be available independent of individual spikes in usage and individual server problems. Performance should degrade gracefully and be compensated by adding more hardware, but this should require minimal human intervention and be kept in balance with the load/demand at the time.

• Devise a protocol for back-end and front-end nodes
• Separate the back-end processing "install package" and the front-end "install package" that serve customer requests (if both installed on the same machine, they should still work together well)
• YMMI: Create a processing job routing system
  • YMMI: Determine availability and server load of processing nodes
  • YMMI: Node discovery

I propose to just start developing basic "0.1" versions of each sub project and keep this preliminary architecture in mind.

I was thinking of implementing a way for the Service Station to read the possible parameters for the models dynamically from a JSON (or maybe XML?) file, instead of being hardcoded in several places like they are now. The app could use the JSON data to build the form dynamically based on the user's selections.

The JSON would contain a definition for each category (i.e. palm, gauntlet, fingers), parts within the categories (i.e. the Karuna Gauntlet, David's Fingers, CB Parametric Palm, etc.), and any special parameters that part requires (padding, bolt hole sizes) and the acceptable values for those parameters.

This approach could make it easier to add/modify models and provide flexibility in what kinds of models can be taken – e.g. if one model had customizable bolt holes and another didn't, the bolt hole fields could be shown or not based on the selection.

It would also allow:

• easy fix for #6 as the acceptable values could be defined in the JSON file. Both PHP and JS can parse it easily, so both server-side and client-side validation would be simple to implement
• easy fix for #9 as the location of the documentation could be defined in JSON
• would be a flexible framework that could potentially be adapted for other parametric designs (not just prosthetic hands)

Thoughts?

The instructions at raptorFollowupInstructions.txt are really good, as long as your setup is not like mine. I've been trying to upgrade the e-nable hand-o-matic over at e-nable.youmagine.com and it generates files, but my e-mail setup was different. I'm using postfix on this ubuntu system and it does come with the mail command, but it's apparently not entirely compatible with the usage in the shell scripts that get executed:

mail  -a 'Content-type: text/html' -a 'CC:[email protected]' -a 'From: e-NABLE' -s 'e-NABLE Model' [email protected] < /var/code/Service-Station/ticket/2663516195-1015839576-3980356043/README.html

This returns just Content-type: text/html: No such file or directory in my case. This error was hard to find, I could get it by finding the shell script and executing that line myself. This is no objection to the code written!

I ended up fixing my setup by seeing what mailclient binary actually was used.

root@enable1:/var/www/html# sudo update-alternatives --display mailx
mailx - auto mode
  link currently points to /usr/bin/heirloom-mailx
/usr/bin/heirloom-mailx - priority 60
  slave Mail: /usr/bin/heirloom-mailx
  slave Mail.1.gz: /usr/share/man/man1/heirloom-mailx.1.gz
  slave mail: /usr/bin/heirloom-mailx
  slave mail.1.gz: /usr/share/man/man1/heirloom-mailx.1.gz
  slave mailx.1.gz: /usr/share/man/man1/heirloom-mailx.1.gz
/usr/bin/mail.mailutils - priority 30
  slave mail: /usr/bin/mail.mailutils
  slave mail.1.gz: /usr/share/man/man1/mail.mailutils.1.gz
  slave mailx.1.gz: /usr/share/man/man1/mail.mailutils.1.gz
Current 'best' version is '/usr/bin/heirloom-mailx'.

This was changed by the command sudo update-alternatives --config mailx

There are 2 choices for the alternative mailx (providing /usr/bin/mailx).

  Selection    Path                     Priority   Status
------------------------------------------------------------
* 0            /usr/bin/heirloom-mailx   60        auto mode
  1            /usr/bin/heirloom-mailx   60        manual mode
  2            /usr/bin/mail.mailutils   30        manual mode

Press enter to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/bin/mail.mailutils to provide /usr/bin/mailx (mailx) in manual mode

I have a few suggestions though, it would help if:

• the errors that result from the shell script would be visible. Possibly we just need to add 2>&1 to where it gets executed to allow stderr tot also reach the logs.
• the use of heirloom-mailx is discouraged explicitly in the install documentation.
• the zip file was downloadable from the final page without having to look for an e-mail. The service.php script is a great interface to have a checker running that will tell the user about the "in progress" and "done" states and if there's a link, no reason not to display it too, right? E-mail adds a dependency on the setup, as you see in my case that's a problem. I've no problem with changing my setup, but I wanted to get this working with minmal changes to the host.

Pass in prostheticHand=0; // [0:Left, 1:Right] to indicate which hand needs the prosthetic. The measurements from the other hand will be used to scale the prosthetic so that the hands match.