Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read Hardware Config from File #3

Closed
brandonrobertz opened this issue Dec 22, 2016 · 1 comment
Closed

Read Hardware Config from File #3

brandonrobertz opened this issue Dec 22, 2016 · 1 comment

Comments

@brandonrobertz
Copy link
Contributor

Issue by TheDukeZip
Sunday Aug 21, 2016 at 02:15 GMT
Originally opened as https://github.com/TheDukeZip/4tvc/issues/3


The services should pick up the hardware config (such as the number of syringes, and which GPIO pins are associated with the motors and the switches) from one config file.

This allows us to have one place to configure the hardware GPIO pins (later on, we could have a UI that allows the user to configure them.)

It also allows us to have a variable number of each hardware device. You could add another syringe to the config and the service would automatically show it as available, and it could be controlled through the interface.

We should probably do this after #2 so that we know exactly what properties each device contains.

We also may want to speak to #Chemistry about whether we would ever need to support two heaters running off the readings from one temp sensor... or using two temp sensors with one heating element.

@brandonrobertz
Copy link
Contributor Author

Comment by TheDukeZip
Sunday Aug 21, 2016 at 02:56 GMT


@MichaelSLaufer mentioned "Looking at the concerns on Github, I just want to add that the only time we would need to support multiple heaters or temp sensors is if we were running a volume of liquid so large that we were concerned that the stirring wasn't sufficient to eliminate temperature gradients in the vessel. It seems unlikely. " "Of course aesthetically, it's always nice to have things be expandable, but I don't think it's necessary. And less so at this stage."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant