Hey folks, hope all is well out there! Still not ready for the brew demo, but there are now only three remaining tasks until we will be good to go.

stop_mech:

One of the more annoying things to coordinate currently is how the pour weight per step relates to the timing of the total mech moves that a user has programmed for a step. To work around this while keeping it simple, we use the weight per step parameter to determine if moves should continue. So if you program 30 moves, but the pour weight is reached after the 28th move is completed, the remaining moves will be canceled and the brew service will process the next step. The reverse is also true, if you create 20 moves, but the pour weight hasn’t been reached yet, it will replay those moves until the step weight is reached.

I ran into an issue when trying to cancel these moves because the mech control service was batching an entire steps worth of moves to the Arduino in one shot. I was having trouble getting the Arduino to recognize that a stop command was a higher priority than a move command, primarily due to the back and forth timing of requests and responses. Things were getting jumbled. I also had trouble getting the Arduino to recover back to a ready state for a new batch immediately.

It was looking like I might have to refactor the microcontroller code a bunch and add a lot of complexity to resolve it. Then I realized I’m dumb and we could just stop sending all of a step’s moves to the microcontroller in a single batch. Then we could check a stop_mech flag before sending the next move. If stop_mech = true, and the reason is due to the step weight being reached, we can just say ok and process the next step. Easy peasy.

I think I originally batched the entire step in one shot for speed. But the reality is that we are attempting to recreate a human movement, so even if this does add some amount of processing time, it will still be within acceptable ranges by a huge amount. At the speed these services are handling things, it just doesn’t matter.

Now, getting the move timing linked with the pour weight is not really all that complicated. We know the speed of the steppers, how far they are moving, and we are able to get real time flow rate data from analyzing the mech scale and the cone scale while brewing. But this functionality really relates to recipe creation and the front end, so will be handled on that side.

Mech Control Service

The mech control service has been integrated into Operator and is now running on the Pi along with all the other services:

This has not yet been merged into the primary branch but you can check it out in the integrate-mech-service branch here: https://github.com/MugsyOS/Operator/tree/integrate-mech-service.

You will notice a temp call in the execute_command function that checks for a weight and then clears the command queue. This is a just a small helper so I can test the queue clearing. You can see the real time mech control logs responding to the weight limit being hit here:

This functionality will actually live in the brew endpoint, which leads nicely to the remaining tasks until I can do the production code brew demos.

Remaining Tasks:

Convert the mech control helper file into the actual Operator Brew endpoint: Super easy, pretty much just some boilerplate additions.
Add calls to sensor services to the Brew endpoint: This is just integrating the real time sensor values in the brew processing’s conditional logic. All the sensor services are already up and running.
Add pour weight parameter to command schema and command processing: We are not currently sending pour weight values along with the step commands. Need to update the schema and the logic in the brew endpoint to read this value.

So I don’t want to keep saying 2-3 days to completion but the remaining work is very basic. The only blocker currently is that I’m super burnt out after the last several days and need a couple early nights to clear the brain out. I’m beat.

I will be away from my desk for the holiday on Thursday, and on Saturday I will be finishing the storage move discussed a few updates ago. My best chance to wrap these three tasks will be Friday as I am off from the day job. That will leave me Sunday to actually do the brew demos. This doesn’t leave much buffer to get things wrapped and get an update out, especially if there are any hiccups.

The next update will have a brew demo. So if it’s Sunday night, and I need a little more time, then I’m gonna hold off on the update until Monday or Tuesday. I also know that the last couple of weeks of work have impacted time lines a bit, so I will discuss that part once this is wrapped and we can get realigned on DECAF and the UI.

Ok, that is all for now. I hope everyone celebrating Thanksgiving has a great holiday and I will see everyone again in week or so.

Cheers!

Update!