View source for PYOT03 (Dec 30, 2023)

<span style="font-size: 40px;"><strong><center>PYOT03</center></strong></span>
__TOC__
<h1>Summary of Receipt</h1>
<span style="font-size: 20px">Summary</span>
<h1>Transcript</h1>
<span>[Date | Dec-30-23]<br>
[Barista | Vanilla]<br>
[Subject | Business as Usual]<br>
[File Reference | PYOT03]<br>

What. The. Hell. I have been trying since yesterday to update the CaDCom-A, and it’s like it won’t accept any of my changes at all. It won’t even allow a simple console print test. It’s like it clears any custom code with every boot. I’ve tried flashing it to an earlier version, one from before the Original Cafe burned down, but no luck. Whatever Hibiscus did to get these CaDComs working must’ve seriously messed up their integrity. What a pain.

The good news is that I found No. 614’s repository for the “customer menu” software and a few schematics for the hardware. It won’t be as easy as I hoped, and we’ll need to source a few parts from Canada, but I think I can get it working. Though the customer menu software is the least of my concerns now. If we can’t change any of the code in the CaDCom-As, we might need to make a whole new set of CaDComs from scratch. That’s a bit of a project. More painful would be finding a new Data Core to hook our CaDComs into.

I’ll see if Hibiscus remembers what she did to these CaDComs first. And I can start putting together a menu program and building a basic menu reader in the meantime. Even if I can get the built-in menu working on the CaDComs, it still wouldn’t have all of the functionality of a fully external menu reader. It might be nice to have both in the long run. Plus, we should be able to take the reading generated by the CaDCom and run it through the external reader for better precision if we need to know more than just which region a customer’s taste preferences are from.</span>