Vessel Roles

[mattreba]

Create an array of vessel objects and store per vessel variables and code here. Four total vessel objects should be supported.
Create an array of vesselRole pointers that point to the vessel that holds a particular role.
Update UI to be process rather than vessel specific and use role pointers to obtain process values. As an example, Fill HLT and Fill Mash would be changed to Fill Sparge and Fill Strike (or if filling both at the same time in the same vessel maybe just Fill Liquor).
Vessel Roles: Heat Strike, Heat Sparge, Mash, Boil, HEX

Sparging is optional so the Heat Sparge role is optional.
HEX is an optional role used for RIMS and HERMS systems.
All other roles must be assigned but multiple roles can be assigned to the same vessel. For example, a single vessel system would use a single vessel holding Heat Strike, Mash and Boil roles.

SMART_HERMS_HLT now becomes a HEX controller. This controller should allow the configuration of the offset and error gain. The gain basically determines how much to compensate for the deviation between mash temperature and mash setpoint.

[AllanMar]

Do you have a prototype for what your thinking for a vessel class? I'm hoping we can tie the PID/setpoint/manual mode/etc together better.

[mattreba]

I'll commit and push up a work in progress.

On Fri, Jul 24, 2015, 5:53 PM AllanMar notifications@github.com wrote:

Do you have a prototype for what your thinking for a vessel class? I'm
hoping we can tie the PID/setpoint/manual mode/etc together better.

—
Reply to this email directly or view it on GitHub
#25 (comment).

[mattreba]

I would suggest that the Boil Control logic be pulled out as a new class with a single object owned by the BrewTrollerApplication singleton. The BoilController should have a pointer to the vessel holding the Boil role (currently hardcoded to vessel index 2 via VS_KETTLE). It would be separate from the vessel object. The vessel object only needs some flag to know that normal setpoint logic should not be applied. This could be done by setting the setpoint to 0 whenever the boil control logic is in a non-setpoint mode. Alternatively, the PID mode could be set to Manual instead of Auto. Or a new flag could be set to override normal control. I would suggest option 1 or 2. It was good to decouple the boil control logic from using the setpoint variable for non-setpoint control but i don't think there is an issue with forcing the setpoint to 0 in non-setpoint modes.

[mattreba]

Moving brewCore() and setup() and loop() code into the app class was probably premature and required a bunch of extern declares to allow compiling. I think it will be easier though to target extern variables and figure out how best to move them into the class structure.

[mattreba]

Multiple fixes in commit fa51bfa

[mattreba]

Merging changes to this point (app and vessel objects) to develop to avoid more time with diverged branches.and allow parallel development efforts without significant refactor. Commit e1c1fc3