Backup (fallback) sensor
Added a fallback sensor: a sensor which falls back on a backup sensor if the main sensor is unavailable.
This is now used for input for the chamber heater/cooler. If the fridge sensor is not available, it will take its input from the beer sensor instead.
This can be used to run with only a beer sensor in beer constant and beer profile mode.
For a glycol setup or single vessel mash:
- set the beer to fridge PID to 0, 0, 0 (Kp, Td, Ti). This will make sure the fridge setpoint equals the beer setpoint.
- configure the cooler and heater (Kp, Td, Ti, period and minimum ON/OFF time).
- Started with firmware developer documentation on ReadTheDocs. Combination of Sphinx and Doxygen.
- Various changes in the code that will reduce overshoot:
- Increased anti-windup gain
- Take derivative from input error, instead of input. This means that the derivative is zero on well tracked ramps. When it was not zero, it reduced the output, but the integrator increased it again, causing more windup.
Slightly improved control algorithm tab
'Simplified' control algorithm tab to only show PIDs (and their sensors/actuators). Sensors and actuators are not shown separately anymore, which was confusing.
- Fixed that DS2413 (SSR expansion board) pin state could not match controller. It is now checked every second to make sure the cached value is valid. Will also print a warning when connection is lost now.
- Setting for Kp was incorrectly scaled by 5/9 when temperature was in Fahrenheit.
- Fixed that the controller reported it was cooling without a cooler installed in certain cases.
the derivative was not zero on ramps, the integrator would increase extra, only creating extra windup.
- Reinstated Readme
- An actuator which cannot go active cannot block another actuator in a mutex group.
- Hopefully fixed initialialization of filters with wrong data (85C), because sensors were read before a conversion was started. A lot changed in the init sequence and I don't see this problem myself anymore. Please report you still encounter it.
Under the hood
The changes under the hood are mainly towards a more flexible setup, where objects can be created on the fly, instead of the current static implementation. This was needed to start changing how we persist, read and write objects in the future, so you can control multiple processes, instead of just one beer.
We have split the code into independent objects, in a lib directory, which are unit tested separately and application code, in the app directory. When the objects need to be customized for the app, this is done through mixins. This required refactoring the project structure and many files, which is too in-depth for these release notes.
- Continuous integration moved to Travis CI.
- Upgraded Particle framework to 0.4.9.
- Now building with GCC 5.1, which drastically reduces the size.