Part 73: Assignment #AC3: Cat Feeder
Cat FeederThey used to say that if you built a better mousetrap, the world would beat a path to your door.
I haven't actually seen any mice in Avalon City— perks of bringing everyone in by boat, and making sure there's no ratty stowaways in the motor launch for the last step— but work has been slow since I moved into my new apartment, so now I'm working on a better mousetrap feeder.
The 'mousetraps', in this case, being a pair of cats.
Perhaps I should provide a little more background on how things are going before discussing the current job. The Ocean's Bounty project is progressing well. They've been working on a lot of recipes in the cleanroom, and also sent a submersible carrying some gnarly-looking support structures down into the ocean near the city, to set up kelp beds they can use to get the raw materials to feed the city in massive bulk. (I looked up kelp - apparently, it grows very fast.)
The residential areas, as I mentioned, are more fully built - at least, mine is. I see new buildings still going up on a regular basis. My apartment is actually really nice - it has a view (of some city buildings and a rooftop, but a view is a view), one bedroom, a small kitchen, and basically everything you'd expect to see in a living space. I get to work by electric car, and yes, it is self-driving. Mr. Haotian's plan seems to be to structure the city with the majority of what you'd call 'service jobs' pre-automated.
I'm still not sure the concept could work elsewhere in the world - economic inequality is a hell of a thing, and part of what biases towards this system working out here is that the great majority of the residents of the city are scientists or engineers of one kind or another, or barring that, already had some sort of fulfilling, non-automatable occupation (such as the construction workers who work to expand the city every day).
The catch is: Sun invited all of us. I don't think such a system could be easily imposed on any other city on Earth without massive disruptions and potential generalized misery from people who had their jobs replaced by bots - at least, not without significant ways of supporting the place's people to make the transition.
Anyway, back to cat feeders. Even though there's a lot of things going on in Avalon City, I've been experiencing a bit of a work drought. The Ocean's Bounty project is progressing, but hasn't needed my help for anything for a while. To be honest— I've been pretty bored!!
This is where Irina comes into the picture. I'm not sure what team she's on, but she's Lisa's friend, she needs help, I'm not busy, and she seems nice enough. So: time to build a cat feeder.
The basic idea is pretty simple. On getting the collar ID (1-3) dispense size units of food type type for that ID ... unless the cooldown for that collar is still running from last feeding, in which case do nothing.
I can see two decently-sized problems ahead of me with this design. Problem number one is the sheer number of inputs this design has: in addition to the tag reader, there's three simple I/O switches and six XBus dials. All of them are going to have to be connected to something.
Problem number two is similar to the issue I faced on the handheld timer: if you have a MC waiting for a long period of time, either with a loop or with a slp instruction, the MC can't feasibly respond to XBus input (at least, not without a design that checks the value of a received XBus pulse every time unit, where one is always sent regardless of circumstances. But such a design would probably be horribly inefficient, and I'm not gonna try it).
So, step one for me is to figure out a way around both issues that's at least reasonably efficient. I'll update this post once I come up with something.
[ ~ ]
This is my preliminary solution to both problems. The project isn't done - rather far from it - but the most important parts are in place.
The idea is that, when the MC attached to the tag reader gets a tag, it'll send the tag ID (minus one) down to the two big MCs clustered around the memory chip in the bottom left. The memory chip records how long is left on each pet's cooldown timer, and the two MC6000s act as its attendants.
The more centered of the two big MCs responds to input from the tag reader MC. It checks the memory chip to make sure that the pet's cooldown timer is '0' - then sets the cooldown to its full amount, using the value it gets from the small MC at the bottom, just to the right of the board's centerline.
(The small MC's job is to serve as a hookup point for the three 'time' dials, and it will yield the correct dial's value when given a tag ID.)
The timer-checking MC6000 will eventually report back to the tag reader MC whether the feeding is 'go' or 'no go', and the tag reader MC will send signals out accordingly - but that's not in yet.
Meanwhile, the MC6000 on the far bottom left is the timer MC. Every time unit, it will go through the memory chip, subtracting one from each pet's cooldown timer. (It turns its p1 on while it's doing this - the timer-checking MC will wait while this MC sends on p1, to prevent the possibility of it reading the wrong value.) This MC operates independently, allowing the timers to run freely.
This is a good start, but I'll have to get the rest hooked up. There'll have to be another small MC for the 'size' dials, like there's one for the 'time' dials right now. On top of that, the small, blank MC4000 on the right will get the information from the tag reader MC.
It'll be tricky to fit it all, but I'm not worried. I can do this!
[ ~ ~ ]
Some reorganization and coding later...
Here's the finished design. The timer MC is the same, and the tag reader and input checker MCs haven't changed much from the previous prototype - the input checker MC is now done, and properly notifies the tag reader whether or not it's OK to dispense food. If it's OK, the tag reader sends the tag's ID to the MC attached to the 'size' dials, in the top center, to get the correct food size, then sends the size and the tag ID along that big wiggly wire leading to the MC on the far right.
The far-right MC (responsible for actually doing the feeding) uses the received tag ID to get which food type to use - A or B - from the input expander above it, which is attached to the 'food type' switches. From there, it sends the 'size' value to the correct food output for one time unit, then turns the food outputs off and waits, letting everything start over again.
There's just one fly in the ointment with this design: the timer MC on the bottom left, always running in the background, weighs the statistics down a ridiculous amount. This version costs ¥25, and uses a whopping 3723 power per run, on average. I'm not sure you could run the design properly on even the largest battery!
So: I'm left with the job of coming up with a better alternative, if I can find one. This may take some time...
[ ~ ~ ~ ]
Sometimes, the solution is blindingly simple, and that means you don't see it.
I'd said up above that it was hard to make XBus work with long timed waits. I hadn't said anything about simple I/O. It took a chance remark from Derrick to get me pointed in the right direction (something about 'turning the MCs off'). The new version is a lot simpler, a lot cleaner, and most importantly, a lot less power-intensive.
When a pet activates this version of the feeder, the new tag reader MC (which has only two lines of code!) sets a simple output line to the ID# of the tag. The simple output is attached to three MCs (in the middle), each coding for one separate tag.
When a center MC sees the tag number it's coded to respond to, it'll send an XBus message to the MC on the far right (which does the feeding), indicating the tag ID, as well as the type of food to dispense. Then, the tag-handling MC will sleep, for a period of time equal to the 'time' dial attached to it. This prevents duplicate feedings - the tag reader MC still sets the simple output to the ID#, but the associated center MC won't listen until the cooldown period is over.
Once one of the center MCs notifies the new feeder MC, on the far right, that there's an incoming request, the feeder MC will use the received tag ID to determine the right amount of food to dispense (from one of the three attached 'size' dials). It uses the received food type to send that value to the right output, and so whatever pet is outside the feeder gets fed.
I'm a lot happier with this! It's not crammed for board space, it's only ¥17 instead of ¥25, and it uses 545 average power per run instead of 3.7K. What's not to love?
The design was a good lesson in when (not) to use XBus - and I bet Irina will be happy, too.
Aw, aren't they cute? And I only noticed now, but each cat has their own email address (look at the CCs in Irina's first message)!
I wonder what the 'more serious project' could be...