Update!
Hey folks, hope all is well out there! Here are the bits:
DECAF recipe step moves: I have finalized and completed the schema and shape for storing, sending and replaying moves. Here is a basic example:
A single recipe can have many steps, and a step can have many moves. Here is the breakdown:
start_step: the cone position where a pour move will start
end_step: the cone position where a cone will move to during the pour
pour_lane: where to point the spout
total_pour_lanes: how many subdivisions to create for spout position calculations
lane_right_of_center: tells the control code which side of the cone’s center the pour falls within
I’ve been stress testing this functionality over the last 48 hours with really great results. No issues with the API losing connection to the microcontroller after extended periods of time with no communication.
This leads to the release of the microcontroller code. Which is just about ready. The only thing left to test is the handshake, error states and making sure the connection manager on the Pi side is correctly rebuilding connections on failure. The status display UI for this info is already handled. So if there is a problem that can not be solved programmatically, the system will let you know.
The overall structure of the microcontroller code has also changed significantly. It has been refactored into something resembling state machine, with a limited number of possible function states. There is also now a command queue to buffer commands, and report back to DECAF on when it is ok to send more commands. this prevents us blowing out the limited memory on the controller, resulting in ignored commands.
Im hoping to have the controller code published in the next few days with DECAF following shortly after that.
Other DECAF bits:
Fixed some bugs
Started the process of hooking into Operator, another couple of shifts on this before completion.
PCB stuff:
Since the spout mech and the weight sensors both use TRRS jacks they can use the same PCB for their connections. I think I can also squeeze the cone mech’s RJ45 jack footprint in there. So this single board will be able to be used for three components depending on how it’s configured. If not, no biggie, the existing cone mech PCB is fine as is. Just trying to minimize unique part counts when possible.
The Pi side PCB design is in flight. Probably another 2 shifts before it will be ready for fab. Working to have this out to fab by the end of next weekend.
ETAs: Looking good to release some shipment date info at the end of this month.
Next update will be out next weekend, but will push out a short update if I get any code released.
Cheers!