|
How's the entertainment on the sea? It any good?
|
#
?
Mar 24, 2019 23:44
|
|
|
|
| # ? May 3, 2024 03:05 |
|
|
I heard some rumors that the Avalon City sec actually bought a small batch of riot shotguns as well from Italy, so I think these targets can be easily modified to use those for both lethal and less-lethal.
|
|
#
?
Mar 25, 2019 00:59
|
|
|
Recommendation: Against Prediction Mr Haotian is trying very, very hard to make the future himself. Will he pull it off? Well, I can honestly say we've made the cat feeder of the future, the robot arm of the future, the stopwatch of the future, the dartboard of the future... Junpei posted:How's the entertainment on the sea? It any good? Well, we have quality internet - the city has its own honest-to-god undersea fiber-optic cable! (There is, however, no cell reception. People still use phones but connect to Wi-Fi.) So I can still get episodes of My Girlfriend Is A Lamia (Season 2 - they did change the title) and what have you. I don't think there's much of any fiction being produced in-house here in the city as an official project, though I saw a message about possibly forming an amateur theater group. Triple A posted:I heard some rumors that the Avalon City sec actually bought a small batch of riot shotguns as well from Italy, so I think these targets can be easily modified to use those for both lethal and less-lethal.  If that's true, that stinks. After all the trouble to have, y'know, actually kinda-nonlethal weapons, too.
|
|
#
?
Apr 24, 2019 04:05
|
|
|
Harvest Time! Avalon City's reaching its target size as I write this - which is a fancy way of saying that plate placement is mostly finished, and the industrial area buildings are close to being fully built. The streets seem busier and busier each day. But you want to know what the real good news is? Avalon Fishcakes are gradually becoming a thing of the past! Well. They will, at least, once the Ocean's Bounty project can get its kelp harvest in - and they need my help again.      I still can't believe the kelp beds are ready already. The time here has passed almost like a blur, looking back. Anyway... this would be a pretty straightforward design, except that one annoying requirement. "If at least one unharvested location remains, move towards the oldest location... activating harvest when over any unharvested location." That 'any' means that each time the robot moves to a new map location, we have to check the list of locations to harvest, to see if where we've moved to is one of them. It also means that the robot needs to know where it is after each move; we can't just say, "OK, hold these motors on for this long" and not keep track of the resulting position. With that in mind, here's my plan: Divide the robot into three 'parts'. The first part handles the memory chip that'll store the locations to harvest. If it hears that the robot's over a harvestable location, it'll remove that stored location and activate the 'harvest' output. The second part listens to the radio and sends new locations to the memory chip. The third part handles the motors, tracks the position, and will ask the memory handler if the current location is a harvestable location. I'll start with the easy-looking part: the motors, and maybe the radio chip. Here I go... [ ~ ]       Here's my first stab at the motor control units' design. The MC6000 is the main MC let's call it the 'motor management chip' to distinguish it. When cued on its x1 (not yet connected to anything), it takes a two-digit coordinate of the location to move to. Then it checks the small MCs attached to motor-x and motor-y to find out where the harvester actually is. The reason this works is because the motor-x and motor-y MCs keep track of their current X or Y positions in their acc - and update their output lines (p0) with this information so that the motor management MC can read it too. When pinged by the motor management MC, the motor-x and motor-y MCs will compare where the motor management MC wants the harvester to be with where they actually are, and pulse their motor outputs accordingly. So back to the motor management MC. Each time unit while it's active, the MC sends the destination location to the two small motor MCs, by way of the small MC in the top left. (The top left MC splits the location's coordinate, which is a two-digit value, into two single-digit values, then passes each digit on to the correct motor MC. We'll call it the 'splitter' from hereon.) The management MC then gets back an updated location from the small motor MCs - it'll check that against the destination to find out if the harvester has arrived at the target position and can go to sleep. Each time the management MC gets a location update, it'll also copy the location out on an output line I haven't decided yet. This is so that the harvester can check if it happens to be over one of the harvest locations, and can turn on harvest. As for the reason I haven't decided on an output line... There's a design flaw with this prototype, and it is this: there's no way to turn on the harvest output! harvest is a simple I/O line, and there's no way to run a wire from a simple I/O pin to the output with the various chips placed where they are. I'm going to have to rewire for this to work. So: That's my next task. I'll try and add more to the design as I do it, too. [ ~ ~ ] Behold, the rewired version! I've made a few minor improvements to this, but I'm starting to get worried about the design for reasons I'll get into in a moment.        First off, there's the rewiring itself, of course. The splitter MC is now above the motor-x and motor-y MCs, and the management MC has been moved up a space to run a wire from the harvest output along the bottom. This move also gives the management MC space to run wires on its two previously-unused XBus pins, which are used as an input line (to take note of new destination locations) and an output line (to notify where the harvester is at any point in time). Second: most of the MCs' code is the same, except for different pin numbers to account for the rewiring. In particular, the placeholder pin numbers in the previous version of the management MC have been replaced thanks to the extra free pin - now, x0 is the management MC's input line, and x1 its output line. Finally, there's a new MC in the design! This one's a very basic input handler for the radio, near the top left. All it does is, if it hears a new harvesting location, it'll turn that pair of values into a single two-digit value (a coordinate) and store it in the attached memory chip. I plan for it to notify some other part of the design eventually, but that part is yet to be written. The problem I was talking about up above is that I've used over half the free space on the board already - and so far, all we have is the part of the design that controls the motors themselves! The harvesting logic, which chooses where to go next and updates the memory chip as locations are harvested, would all have to fit into the remaining free space you see there. I don't think it's possible with the design as it is - which means I have to consolidate something. Back to the drawing board, as they say. [ ~ ~ ~ ]       One redesign later, we're back to having the motor control section take up less than half of the board. This design has some big alterations from the last one - the only MC that hasn't changed at all is the one connected to the radio. Apart from that: The motor-x and motor-y MCs no longer need to be pinged every time unit. Instead, they keep track of their destination in their dat, looping until they've reached the set location. They still output where the harvester is regularly over their p0 lines. Because the motor-x and motor-y MCs don't need to be notified every time unit, the motor management MC only lets the motor-x and motor-y MCs know where to go once. This is more efficient - every time unit, the management MC still checks where the harvester is and passes that information on to the rest of the device, but the update cuts down on a lot of inter-MC communication. Now that this is satisfactory, I need to make the core logic that will drive the harvester around. I have the first glimmer of it in the radio-handling MC - it'll write the new location to harvest to the memory chip. That leaves the parts that feed new locations to the motor management MC, erase harvested locations, and otherwise keep track of what's left for the harvester to do. I've spent a day on this project already, but I have the feeling the dive in has just begun... [ ~ ~ ~ ~ ] The core logic isn't at all done, but it's getting there. A quick summary of my changes so far is below.         I've got the first stabs at control MCs done. The new small MC attached to the radio-input MC is the counter; when it receives a negative value from the radio MC, it'll add 1 to its acc, which tracks the number of locations left to harvest. If there weren't previously any locations to harvest, and now there are, it'll notify the rest of the control logic MCs (specifically the new 'finder' MC - see below) to start moving to a new location. I'm planning to have the counter MC also be connected to another MC - maybe the motor management MC - on its input line as well. The difference is, the other MC will be there to notify the counter when a harvesting request is complete, by sending a positive value instead! In that case, the counter subtracts one from its acc instead - and will call for a 'move to new location' if there's any locations left to harvest. There's two other new, large MC6000s in the design, both of which aren't hooked up yet and don't have their pin assignments finalized yet. I've put labels next to each one, for my benefit as much as yours. The farther left of the new MC6000s is the finder. This MC will probably be what the counter MC notifies - when it's triggered, it looks through the memory chip until it finds any value. This will be the oldest location to harvest, because the finder MC always starts one memory cell after the newest location written, and the chip wraps around. The finder MC will pass the location it finds on to the motor management MC, and then start listening for a response that indicates the location has been correctly harvested. I'm not quite sure what it should do after that. Maybe nothing. The other new MC6000, only slightly left of center, is the tester. This MC is the one that receives the current location of the harvester from the motor management MC. The tester MC is also connected to the memory chip, and once it gets a location, it'll check to see if that location's in the memory chip. If it finds it, it'll erase that location and pulse harvest for a time unit. The next step in this is to wire everything up and see if it works. There'll probably be a bug or two to be polished up in the design. I'm thinking this project is going to take another day at most at this point - but only if I'm lucky... [ ~ ~ ~ ~ ~ ] I have not been lucky. There are times when a design almost works - things almost line up - but they're not quite there, and so you have to fix it or find a workaround. And that's before fixing the bugs in this design, which I am sure are there, but I haven't caught yet!!   (Click the wiring diagram for a zoomed-in version.) In this particular case, the 'almost works' is the wiring. Some of my changes since the last design required me to split the 'finder' logic across two MCs, and now I can't figure out how to wire it up and make everything fit! It might be simpler to go into detail about how everything's changed, and where it fits into this mess.   The radio MC hasn't changed since the last version. The counter MC has, and, well... it's indirectly the cause of all this trouble. Basically, in my last design, I'd planned to have the counter take positive values as input from a not-yet-chosen other MC. These positive values would subtract 1 from the number of locations left to harvest. The problem is, though, there's actually two types of "subtract one from the counter", which needs to be handled differently: Target location harvested: Subtract one from the counter. If there are any other locations to be harvested (counter > 0), call up the next location to harvest. Another location harvested on the way to the target location: Subtract one from the counter. Do not call up a new location, we're still moving to the last one. This means that both the tester (now renamed the 'eraser') and the finder MCs have to have a way to notify the counter, but with different values. Here's how it's set up now: New location to harvest: Negative value sent from radio MC. Counter will call up the location if there are no other pending locations (if there were, the harvester would already be running). Done harvesting any location: Zero value sent from tester/eraser MC. Zero value doesn't trigger any checks to call up a new location. Done harvesting target location: Positive value sent from finder MC. This will always arrive before the zero value from the eraser - so, the counter MC runs code that will wait for the eraser MC's 'zero' input and throw it out. Then, it'll call up a new location if any are left.    So far, so good - but when we last saw the finder chip, it only had a few lines of free space left. Not enough to actually wait for a response from the motor management MC that matches its acc, and then send a pulse to the counter MC. So: I split the finder into two. The first part (the smaller MC) loops through the RAM chip (starting where indicated by the counter MC), and sends every value it finds to the second part. It stops when it runs out of array or the value it sends isn't a '0' (the second part of the finder copies its input back so the first part can see it). The second part of the finder waits for the first non-'0' (empty) value from the finder ("xIN"), then sends it to the motor control MC ("xIN2"). It compares the locations broadcast by the motor control MC, passing them on to the eraser MC ("xOUT"). It'll also send a value to send on to the counter a -1 to subtract one from the counter (this really should be a +1, but it's a work in progress!), or a 0 to leave it where it is. This code isn't quite set up to work with the counter yet as it's shown above: right now, I'm only sending a single value to the eraser, and nothing from the finder second part itself. I'm thinking it might be best if only the eraser and the radio MC (but not the finder) send to the counter, which'd let me revert to the simpler counter code from the last version. The eraser MC (previously called the 'tester', as a reminder) has mostly the same code: given a value, it looks through the memory chip and removes it if it's found - which means the current location was harvested. However, there's also an extra line in the new version, which pings the counter with value (0 or -1, which is actually supposed to be a +1) sent by the finder. There's also a contingency clause that'll throw the finder's value out if the current location isn't in the RAM chip. Importantly, the eraser is still the MC that pulses the 'harvest' output, which is going to factor into the wiring snafu later.    The motor management MC isn't that different, but I've been experimenting with a more efficient design for the motor MCs themselves; one where they loop and keep outputting values until reaching the target location, without having to be cued by the motor management MC every time unit. It's... sort of going well. The tricky bit is that the motor-x and motor-y outputs might be on for different periods of time, but both MCs will need to output their current position each time unit until the target location is reached. The version I'm experimenting with above tries to work around that by having the motor-x MC output as simple I/O, while having motor-y output through XBus. If motor-y runs for longer than motor-x, the lower MC will keep outputting and there's no problem. If motor-x runs for longer instead, the motor-y MC will see that motor-x's output line is not 50 (neutral), and will output as long as motor-x is busy. It's efficient, but it makes the wiring a bit more complicated. Which reminds me... So at the beginning of this section, I mentioned that my problem was wiring up the second 'finder' MC. Because the eraser MC is on the far left, a simple output line has to go from its lower left or upper right corner (where the simple I/O pins are) and join up with the 'harvest' output on the far right. Unfortunately, the second 'finder' MC is directly between Point A and Point B, and it has three (possibly four) separate lines - one going to the eraser, one to the motor MC, and one from the first 'finder' MC. (Possibly also one to the counter. This is TBD.) I somehow have to route the eraser's simple I/O wire around/through this, along with the eraser's connection to the counter. I'm not sure it's possible with things in their current positions. There's nothing for it: I'm gonna have to shuffle components around until something works. Rewiring like this will take a while - maybe even a few days! "To Be Continued", as they say. [ ~ ~ ~ ~ ~ ~ ] I have now been working on this project for over a week... and I finally, finally have a working prototype. Even if it looks like the underside of a fish cake! I've annotated the wiring diagram like the last version, so you can see just how everything moved around.   (Again, click the wiring diagram for a zoomed-in version.) Aside from moving almost every part on the board, this version isn't too different from the last prototype - just cleaned up, by a lot. I'll list what is different from the last version below.   There was a bug in my last version with regards to the counter that I hadn't fixed at the time of screenshot. The way the conditional flags shake out, the counter is supposed to take a negative input to indicate a new location being added, and a zero or positive input to indicate an old location being removed. Some of the MCs that feed the counter (the radio MC, the tester/eraser, and the finder part 2) were sending negative values when they should have been sending positive ones, or the other way around. This is fixed. I also finalized my implementation where the finder and eraser MCs both send to the counter when a target location is being removed, including proper timing (the 'slp 1' in the middle).    The first part of the finder is mostly the same, apart from a bug fix to stop it from choosing the newest location instead of the oldest (the fix is the 'mov x2 null' to move the memory address pointer off of the cell with the most recent input). The second part of the finder is only different in that it's been properly wired up! The 'mov 0 to the eraser MC' line has been removed, as the eraser always emits a '0' on its own. The eraser's code hasn't been changed since the last prototype - only completed. The 'mov xIN null' line was removed, since the finder doesn't send any extra input to the eraser that might need to be thrown out.    My experiments with the self-sufficient motor MCs had to be abandoned when I rewired - in order for everything to fit, I had to go back to the earlier, smaller motor MCs from the first or second prototype shown here. Well... almost! Since the motor MCs only report their position on time units they're cued, I made the updated versions return their position over XBus instead of simple I/O - simplifying the wiring drastically. It's worth noting that the motor management MC has an unused 'loop' label as a byproduct of the experiments, but practically speaking, it's the same code as before. Send target position, get back actual position, report the results to the finder (which passes them on to the eraser). This version is ฅ32, and uses 6148 average power per run. Phew. Heady statistics! But I'm not satisfied with the design. For starters, splitting the 'finder' chip into two seems kind of wasteful - a lot of extra lines and board space lost to properly notify the counter. Maybe there's a way to reunite the two 'finder parts'? It'd simplify the wiring, at least. I'll play around with different versions - though I might have to start from older experiments - before I send this version off to the Ocean's Bounty team. Though it seems impossible, there could be some better-optimized version out there... I think. I'm not sure. [ ~ ~ ~ ~ ~ ~ ~ ] It took days. Again! And I kinda rebuilt the design from the ground up. But here it is: the much cleaner and less packed-in version.   (This'll be the last annotated wiring diagram. But you can still click on it to see a bigger view.) The reason I had trouble with splitting the finder into two in the first place is because the counter would need to be notified in different ways when removing a target location, versus removing a location that the harvester just ran into on the way. But then, I got to thinking: "What happens if the harvester doesn't subtract from the counter for on-the-way locations?" The answer is: it only presents a problem when we harvest all our target locations and the list of places to harvest is empty - if that occurs, the harvester would try to harvest the next location and get stuck reading the empty RAM chip. Because of this, the fix is simple: if the finder completes its loop and notices that the memory chip is empty, it can just notify the counter as if a target location was successfully harvested. The counter MC will subtract 1 from its count and go about its day. Problem solved! That's not the only change this design has, though. Here's a rundown of everything that's different:   The counter MC, now that it no longer needs to take input from the eraser MC, can be moved off to the far left. Its script is back to the simpler version from earlier prototypes, too - mostly. It now sends to the finder MC on the same line as it gets input from the radio MC, further cleaning up the wiring.   The finder MC is back in one piece! Previously, the first part of the finder received input from the counter on one XBus pin, and the second part of the finder sent pings back to the counter on a different one. These have been combined into one pin on the reunited finder - it only needed a little timing-based magic. When the finder's cued now, it waits a tick with nop (this is so that, if the pulse was the radio MC sending something to the counter, the counter will always respond first), and then looks for the oldest value in the RAM chip. It then sends that value to the motor management MC, waits for a reply (which it gets once the target location is harvested), and tells the counter that the location is done. The eraser MC is the same as it ever was - except, now it doesn't have to notify anyone when it's done erasing.    The motor management MC is, once again, a bit different than before. The biggest change is in who's responsible for preparing the location value that tells the motor MCs where to go. The actual motor MCs now separate their half of the target location from the two-digit target coordinate, instead of the motor management MC doing it. Because of this, they've been upgraded to MC6000s - and the motor management MC has space to notify the finder when the harvester is done moving. There aren't really any other changes of note. In particular, if we ignore the 'coordinate separation' part, the new motor MCs are about the same as the oldest versions of the motor MCs - they compare their current and target position, update their acc with the new location they're moving to and report that, and actually pulse the motor outputs to make it all work. This new design is a lot cleaner, but better yet - it's more power-efficient. The statistics this time are ฅ33, and 5055 average power per run. I'm pretty sure this is the design I'm sending off to the team - assuming I don't find further improvements in it! I'll just take one last look before I send it off. [ ~ ~ ~ ~ ~ ~ ~ ~ ] Found one improvement, actually!          I had originally moved the job of splitting the coordinate from the motor management MC to the motor-x and motor-y MCs because I thought there wasn't enough room on the motor management MC to do it. It turns out: There is. There just is. I had to use a trick I've never done before to get everything to fit, but I was able to make the motor MCs tiny again. Here's how it works: The motor management MC needs to split the target coordinate (in its dat) into a tens digit (the X coordinate) and a ones digit (the Y coordinate) and pass those along to the correct motor MCs. (The motor MCs take the input value and directly compare it using tcp.) If I did it the normal way, the script would look like this: mov dat acc - copy the value to acc so we can work on it. dgt 1 - get the tens digit. mov acc x3 - send it to the motor-x MC. mov dat acc - we overwrote the value when we got the tens digit, so copy it to acc again. dgt 0 - get the ones digit. mov acc x2 - send it to the motor-y MC. That's one line too many to fit in the motor management MC, with everything else it's got jammed into it. But here's the trick: the dst instruction lets you set one digit of acc to a specified value... but if you specify a multi-digit value to set the digit to, the instruction will chop off all but the last digit of that value. So, if you do dst 0 269, the target digit will be set to '9' - the rest of the value is discarded. This means I can use this to get the ones digit of dat and move it to acc at the same time! Here's the updated script: mov dat acc - copy the value to acc so we can work on it. dgt 1 - get the tens digit. mov acc x3 - send it to the motor-x MC. dst 0 dat - set the ones digit of acc to the contents of dat. This is trimmed, so only the ones digit of dat makes the jump. mov acc x2 - send the digit to the motor-y MC. Only five lines instead of six, so I can fit it in the motor management MC. As a result of this, the motor-x and motor-y MCs are now MC4000s, running more efficient code. The design's both cheaper, and once again more power-efficient; it's ฅ29, and 4829 average power per run. And with this, I'm really, really sure this is the final version. To be quite honest, this has been a mental workout like no other! The last time I did something that felt this hard was when I was a kid, playing an indie game called SpaceChem. One late-game level - "Ω-Pseudoethyne" - was almost the end of me, and was certainly the sandbagging of me for the three days it took to solve it. This assignment? Well, it was comparable. Or maybe a little worse. Time to hit SEND, and hope they don't want any changes. [ ~ ~ ~ ~ ~ ~ ~ ~ ~ ] The Ocean's Bounty Team liked the design! And, on top of that, I got to see the final harvesting robot. It looks like nothing so much as a UFO, actually - with a sort of... cage with a large number of sharp bits connected to motors, and a vacuum nozzle on the underside of the 'bot, above the 'cage'. As the harvester trails through the kelp beds, the 'cage' travels through the kelp and severs the harvestable bits; then it gets sucked up into a collection tank. (I think the idea is that the kelp beds regrow by themselves afterwards, but I'm NOT a biologist, so don't take my word for it.) Apparently there's a mechanism that disengages my guidance chips and floats the bot to the surface once the collection tank is full. Then, someone can go in a boat and gather the harvest.   Sweeeet. We did something worthwhile! Though there is that nagging question of 'what now', I'm looking forward to eating some new and different foods. And now I can proudly claim that Avalon's made the kelp farming technology of the future, too!
|
|
#
?
Apr 24, 2019 04:05
|
|
|
There was something I was wondering about during your explanation of this rather complicated robot. Assume the robot is the black circle on the top left, and the oldest location it needs to get to is the green square. Now, as you can see there are several ways to do this. The red way is probably the easiest to program, but purely considering the efficiency of the motor movements, it wouldn't matter whether you took the red or the blue way, it's three steps (2 diagonal and one horizontal) either way. However, if there happens to be another field waiting for harvest in the spot directly to the top right of the green one, the blue way would pick it up on the go, while the red one would have to make an additional movement afterwards. In the long term this would probably even out, so it really doesn't matter which design you use (except for chip efficiency but that's probably much less of a factor than the robot's whole energy usage). And the design requirements just say Since the harvester can move in both the X and Y axes simultaneously, diagonal moves should be made whenever possible to take the shortest path. Both the red and blue design do this, just in a different order. The thing is... I don't think the test simulations could be made smart enough to take this into consideration. So, my question is: is using the red way some implicit design requirement forced upon you by the test simulations?
|
|
#
?
Apr 24, 2019 07:14
|
|
|
Carbon dioxide posted:In the long term this would probably even out, so it really doesn't matter which design you use (except for chip efficiency but that's probably much less of a factor than the robot's whole energy usage). And the design requirements just say Since the harvester can move in both the X and Y axes simultaneously, diagonal moves should be made whenever possible to take the shortest path. Both the red and blue design do this, just in a different order. My reading of the requirements is that the "whenever possible" is an immediate requirement. In other words, if from where I am I can take a diagonal movement that takes me closer to my destination both in X and Y, then I must take that diagonal movement.
|
|
#
?
Apr 24, 2019 16:09
|
|
|
One thing to keep in mind is that there is no leeway in the problems at all - each test scenario has some input signals, and a set of output signals, and your design must produce that exact output. So yes, the harvester must take exactly the path that's written in the spec; it can't take a different path that reaches the same location just as fast, nor can it detour to take a different path that collects all the kelp faster.
|
|
#
?
Apr 24, 2019 20:17
|
|
|
Carbon dioxide posted:
I'd say it is an implicit requirement - if you look at the sample test case I listed towards the top of the post, you'll note that both motors are pulsed for 4 time units, then only the X motor is pulsed while the Y motor is inactive - in that order.
|
|
#
?
Apr 24, 2019 21:27
|
|
|
Quackles, this one totally stumped me and I had to set the game aside. Kudos for smashing through it! I'm really tempted to try again now, just so I can follow along.
|
|
#
?
Apr 24, 2019 21:37
|
|
|
Bobulus posted:Quackles, this one totally stumped me and I had to set the game aside. Kudos for smashing through it! I'm really tempted to try again now, just so I can follow along. This is the hardest level in the game by a lot. I have a massive Zachtronics friends list, and three of them have beaten this level. Did this level get changed at one point? I thought I remember an update making it easier...
|
|
#
?
Apr 25, 2019 01:06
|
|
|
GuavaMoment posted:This is the hardest level in the game by a lot. I have a massive Zachtronics friends list, and three of them have beaten this level. Make that 4! I just finished it now. My biggest annoyance was that test scenario 10 is the first time the machine harvests all the kelp and has to just sit where it is, so it's a pain to debug if you don't handle that case correctly. edit: Actually, it definitely changed at some point. Because I've played some of the puzzles beyond it... Jabor fucked around with this message at 10:51 on Apr 25, 2019 |
|
#
?
Apr 25, 2019 10:13
|
|
|
GuavaMoment posted:Did this get changed at one point? Funny you should mention that - apparently the Ocean's Bounty team originally had a prototype spec that behaved a little bit differently...    There's no harvest output to deal with (implying the harvesting tools would always be on), but the harvester would always have to go to the closest location (so the harvester wouldn't normally have to change destinations along the way... BUT if a new location came in, the harvester might have to interrupt its movement and set a new target location). There's also the matter of calculating the distance to a particular location. I dug this up from the Message Archive in the Control Panel - it was Message# 3113. I think the spec was changed to the version we have now because the team ended up altering the distribution of the kelp-growing racks underwater - putting them closer together, I think? - and the current design was more suited for it.
|
|
#
?
Apr 25, 2019 21:27
|
|
|
Sushi Robot! Barring potential further expansion, the last plate was bolted into place today! Avalon city is now at its target physical size. Up until recently, Avalon City has been a city, but it's been missing a lot of things that people might except to find in one. Creature comforts, basically. Now that the pressure's off on feeding the place and making it bigger, though, there's a bunch of people who've self-assigned to more 'quality of life' sorts of projects. This, as it happens, includes Derrick from the Ocean's Bounty team. He's come up with... well, take a look at this.       I was never much of one for sushi, but I can sink my teeth into this! This sounds like a fun project, and a good palate cleanser (ha) after that kelp harvesting robot. The actual design looks to be pretty simple - the 'sushi type' input value is passed directly to the 'fish' output, and the 'rice' output always takes the same output pattern. Add a RAM chip to queue orders, and this design should be in the bag. (On the plate, perhaps?) One possibly tricky part: there is a time delay between generating the order and triggering the gate outputs - but it still doesn't seem like it'll make things that hard. Time to get rolling 🍣 on the design! [ ~ ]       This would have been a working design, but I made a mistake in reading the requirements - if you look at the screenshot, you'll see that all the 'gate' pulses for an order are being sent on the same time unit, 5 time units after the start of the associated 'rice' pulse. What's supposed to happen is that the 'gate-a' pulse is supposed to be sent then... and the 'gate-b' pulse is supposed to be sent 3 time units later, and the 'gate-c' pulse 3 time units after that. I'll have to redo the parts of the design that send the 'gate' pulses - but I'll explain what everything in this design does, first. The main logic is actually performed by the center MC6000. It uses its p0 line to tell the MC6000 on the left (the input-handling MC) that it's ready to receive a new order. Once the input-handling MC responds with an order, the central MC sends the fish type to the fish-and-rice MC in the upper right. It then waits, sends the destination table number to the gate MCs in the lower right, and resets its p0 to tell the input MC it's ready for the next order. The central MC also precalculates the output pulse for gate-a, which it sends to the gate MCs as part of the destination info. The input-handling MC on the left (attached to the radio and the RAM chip) checks every time unit for incoming orders, recording them in the RAM chip. It uses its acc to keep track of the number of unfulfilled orders. If the simple input line from the central MC is on (indicating, readiness for the next order), and there's an order to send, the input MC will send the values from the RAM chip to the central MC, so that it can make the order. The input MC uses one memory pointer to write orders, and the other to read orders out, so orders will always be processed in the correct sequence. The fish-and-rice MC4000 on the top right has one job: when triggered, it saves the input value it got, then outputs it one time later to the fish output. It also pulses the rice output in the correct sequence. Finally, the lower right MC6000 and the bottom center MC4000 are the gate MCs, which send the values to the gate outputs. The bigger of the two MCs is the primary gate MC; it takes the pre-calculated gate-a pulse value from the central MC, and uses the table number to figure out the value of the gate-b pulse. It then sends the table number along to the secondary gate MC (the smaller one), which figures out the gate-c pulse values. Then, the MCs make the appropriate pulses all at once - which turned out to be the wrong behavior. (For anyone wondering about the details of the gate pulse calculation, it's sort of like a cut-rate division by two. If the starting table number is over 4, the MC subtracts 4 from it and sets the gate-a pulse to 0; otherwise, it doesn't subtract and sets gate-a to 100. The modified table number will be a number between 1 and 4; if it's over 2, the MC subtracts 2 from it and sets gate-b to 0 - otherwise, no subtraction and gate-b is set to 100. This will yield an even-more-modified table number, which will be either 1 or 2. If it's 1, gate-c gets set to 100, and if it's 2, gate-c gets set to 0.) Redoing the design will be fairly simple - in order to keep the delays properly lined up, I think I'll need to split the gate logic into smaller MCs. However, this does come with a bonus. I won't have to have the 'precalulate gate-a' code in the central MC any more, cluttering it up. The next design should be a bit cleaner. Here goes... [ ~ ~ ] Ta-da! First working version! My stomach's already growling with anticipation.        The gate outputs are now pulsed with the proper timing, and the design works - and there isn't that much that changed about it. The input-handling MC and the fish-and-rice MC are exactly the same, and the only change to the central MC is the removal of the gate-a precalculation code I mentioned above. The gate MCs are different, though. In order to maintain the timing, each gate now has its own MC. When a gate MC gets a table number, it'll check it against its threshold, and pulse its gate output after a delay. If the table number is higher than the threshold, it'll subtract the threshold number and output a 0; otherwise, it outputs a 100. It then passes the modified table number to the next gate MC, if there is one. The first gate MC has a threshold of 4; tables 1-4 yield a 100, and tables 5-8 yield a 0. If the table number is 5 or more, the gate MC will subtract 4 from it; this makes things easier for the next gate MC. The second gate MC has a threshold of 2; tables 1-2 yield a 100, and tables 3-4 yield a 0. Notably, if the table number was 5 or more, it will now be in the 1-4 range: so, tables 5-6 become 1-2, which yields a 100, and tables 7-8 become 3-4, which yields a 0. This gate MC also subtracts 2 if the modified table number is greater. The third gate MC is the end of the line. Because of the subtractions of the other MCs, it will always receive a 1 (tables 1, 3, 5, or 7) or a 2 (tables 2, 4, 6, or 8). If it receives a '1', it outputs a 100. If it receives a '2', it outputs a 0. That's it! This design is ฅ24, and uses 1127 average power per run. [ ~ ~ ~ ] I had a flash of inspiration while I was giving the design the once-over I do so I can write it up later. Quite simply: do we really need the fish-and-rice MC at all? Turns out, the answer is 'no'.       This version moves the fish-and-rice MC's functions into the central MC, which connects to the fish and rice outputs directly. The central MC handles the timing for the rice pulses, outputs the value it receives from the input MC to fish when the time comes, and cues the gate MCs. There are a few slight other optimizations: I removed some unneeded jmp instructions in the input MC, as well as making it so that the central MC sends '100' on its simple line to the input-handling MC when it's busy, not when it's free. These changes allowed me to save some power, and several lines of code - as well as cut down on the cost of the board. The new version of the design is ฅ21, using 1005 average power per run - but given that we only need one Omakase 9000, the big benefit is the decreased power usage. Before I send it off, well... I looked up 'Omakase'. It means, "I'll leave it up to you", and in the context of a sushi restaurant, can be read as ordering the "chef's special". Here you go, Derrick. Omakase.  Awww. Not much else to say, except - I've tried it too, and it actually was really good.
|
|
#
?
Apr 30, 2019 09:04
|
|
|
So with Avalon set up societally the way it is, and Ocean's Bounty theoretically granting food-independence... What's stopping everyone from deciding they want to eat from the Omakase 9000 instead?
|
|
#
?
Apr 30, 2019 09:46
|
|
|
bewilderment posted:So with Avalon set up societally the way it is, and Ocean's Bounty theoretically granting food-independence... I think that's kind of the idea. I mentioned that people were self-assigning to quality-of-life projects? Well, that wasn't just me and Derrick. With Lisa's recipes and peoples' desire for more food options, I suspect that a good number of people are going to have similar ideas... though hopefully it won't just be sushi restaurants. I'm kind of hoping someone makes a taqueria, actually...
|
|
#
?
Apr 30, 2019 10:22
|
|
|
I am an engineer and yet I never had any desire or inclination to pursue any "personal" project (i.e. something I am not paid to do). Am I in the wrong business?
|
|
#
?
Apr 30, 2019 19:12
|
|
|
AceOfFlames posted:I am an engineer and yet I never had any desire or inclination to pursue any "personal" project (i.e. something I am not paid to do). Am I in the wrong business? No, you're just one of the people with a healthy personal life/work divide.
|
|
#
?
Apr 30, 2019 19:35
|
|
|
AceOfFlames posted:I am an engineer and yet I never had any desire or inclination to pursue any "personal" project (i.e. something I am not paid to do). Am I in the wrong business? No, it's just a matter of personal temperament. I don't get paid to make this blog, after all.
|
|
#
?
Apr 30, 2019 22:25
|
|
|
AceOfFlames posted:I am an engineer and yet I never had any desire or inclination to pursue any "personal" project (i.e. something I am not paid to do). Am I in the wrong business? There are people who will say that you can't be a good engineer unless you're doing it in your spare time as well as at work. Those people have unrealistic expectations. One of the most critical aspects of engineering (or of any job, really) is maintaining your own mental health. You can't do a good job if you're burnt out or tired. And different people relax in different ways; relatively few will relax by working on personal projects.
|
|
#
?
Apr 30, 2019 23:07
|
|
|
You should take these two MC6000s plus the RAM chip, and do it all in one MC4000 instead.  I have no idea why you're using a RAM chip since the input is non-blocking.
|
|
#
?
May 1, 2019 00:34
|
|
|
Would Ghost ordered Sushi work hypothetically?
|
|
#
?
May 1, 2019 01:12
|
|
|
Post-Assignment Optimization: Omakase 10500GuavaMoment posted:You should take these two MC6000s plus the RAM chip, and do it all in one MC4000 instead. Hmm. I know the C2S-RF901 has an internal buffer, but I was under the impression it could only store one XBus packet (albeit of indefinite length) at a time. I'll try building it anyway, and see where it gets stuck...      Oh. It works perfectly. It seems that the C2S-RF901 buffer has no limits that I can run into, at least with a project of this scope. In case you're wondering, this is ฅ14 and uses 644 average power per run. I'll let Derrick know - given the decreased power consumption, I bet he'd be down with updating the Omakase's control board. Thanks.  Tombot posted:Would Ghost ordered Sushi work hypothetically? Probably! I can confirm the radio receiver is pretty short-range, though, to prevent interference from outside the restaurant. Quackles fucked around with this message at 07:54 on May 1, 2019 |
|
#
?
May 1, 2019 03:56
|
|
|
You're close! For your final trick connect rx and fish to the same xbus. rx will never trigger fish, and sending data down the xbus will not go into rx. That should allow you to replace the chip with an MC4000.
|
|
#
?
May 1, 2019 05:50
|
|
|
Post-Assignment Optimization: Omakase 12000GuavaMoment posted:You're close! For your final trick connect rx and fish to the same xbus. rx will never trigger fish, and sending data down the xbus will not go into rx. That should allow you to replace the chip with an MC4000. Done!      I also modified the gate-c MC to use mov / slp instead of gen, which wastes energy when one of its parameters is set to 0. The resulting design is ฅ12, as you pointed me towards, and uses only 618 average power per run. Updated design sent off again. I bet this version could beat some sort of world record, or something. Thank you! Quackles fucked around with this message at 10:49 on May 1, 2019 |
|
#
?
May 1, 2019 07:53
|
|
|
Carbon dioxide posted:No, you're just one of the people with a healthy personal life/work divide. I have no personal life either. I arrive at home utterly drained and do nothing. And yet I am definitely not as productive as my peers. I find myself procrastinating endlessly. I do have a love/hate relationship with these sorts of games: I enjoy them but those drat histograms at the end ruin me because my score is always so low even though I do this for a living.
|
|
#
?
May 1, 2019 12:31
|
|
|
AceOfFlames posted:I have no personal life either. I arrive at home utterly drained and do nothing. And yet I am definitely not as productive as my peers. I find myself procrastinating endlessly. Sounds like burnout then; if you're coming home with 0 energy to do basic life upkeep tasks (which just drain you further) you def won't have energy to think of any fun projects to jump into; I know I need to cut back on my Lamia marathons and get to sleep at a better hour now that I'm getting more involved as spring happens. Remember to take care of yourself, you're worth the time and effort friend.
|
|
#
?
May 1, 2019 13:27
|
|
|
AceOfFlames posted:I have no personal life either. I arrive at home utterly drained and do nothing. And yet I am definitely not as productive as my peers. I find myself procrastinating endlessly. I concur with RedMagus; this (work avoidance, exhaustion, no personal life) sounds like burnout. You might want to ask for advice in the Oldie Programming Thread.
|
|
#
?
May 1, 2019 15:59
|
|
|
Thanks!
|
|
#
?
May 1, 2019 16:05
|
|
|
Back on-topic: what I find strange about this whole thing is that you're still using MC chips for everything. They made sense back at the old company, where you were making cheap, mass-market products that had to keep the per-unit cost as low as possible. But surely when you're working with more specialized and one-off devices like a kelp picker or sushi robot, it makes sense to use a more generalized, flexible, and easier-to-program set of chips?
|
|
#
?
May 2, 2019 01:17
|
|
|
TooMuchAbstraction posted:Back on-topic: what I find strange about this whole thing is that you're still using MC chips for everything. They made sense back at the old company, where you were making cheap, mass-market products that had to keep the per-unit cost as low as possible. But surely when you're working with more specialized and one-off devices like a kelp picker or sushi robot, it makes sense to use a more generalized, flexible, and easier-to-program set of chips? There's actually a bunch of reasons for this. In no particular order: A lot of the Avalon City infrastructure runs on 诚尚Micro MCs. I know - I built some of it! So, having supplies of their MCs around for repairs/replacements is a natural fit - and from there, it's simpler to use them for new projects, too. MCs are versatile enough that, as long as you have enough board space, you can do quite a lot with 'em. Everyone and his brother, and his cousin, and her next-door neighbor, uses 诚尚Micro. They're common enough that Mr. Haotian could hire engineers without having to worry too much about if they know 诚尚 assembly language. I'm told this could change eventually, but Avalon City doesn't have a chip foundry. Our factories can make any sort of electronic circuit with MCs, but they can't make the actual MCs themselves. So, for the time being, they get imported from Shenzhen. (Well, pre-imported. We're running off our current stockpiles, which are actually quite a lot.) If we went with a different brand of chips, I'd need a different simulator for that brand, the factories would need new MC programming units for them, and so on. Follow-up to the above: Even if we did start making our own chips, they wouldn't be 诚尚Micro brand chips, and the issues with needing a new simulator/etc could still apply - unless we made MC4000/6000 knockoffs. I'm not sure how well that would go over back in Shenzhen. Most importantly: before the initial construction of Avalon City, 诚尚Micro was able to supply ungodly amounts of the things to Mr. Haotian, on what I suspect was short notice. By that, I mean lot sizes starting at one+ billion or so... I don't think we'll ever run out, at this rate.
|
|
#
?
May 3, 2019 00:28
|
|
|
I dunno about you guys, but I don't know that I want extruded rice sushi. Seems like it would have an unpleasant consistency compared to the sticky rice
|
|
#
?
May 4, 2019 00:20
|
|
|
mercenarynuker posted:I dunno about you guys, but I don't know that I want extruded rice sushi. Seems like it would have an unpleasant consistency compared to the sticky rice That reminds me, I had a Chinese exchange student living in my student house for a while. I suspect that guy lived rather sheltered at home and this was the first time he had to take care of his own food and stuff. We do eat rice dishes here but not nearly as much as in China, and usually when we eat rice, we put it in a pan with some water and cook it. The result is not bad but you usually don't get the stickyness of the rice that's common in Chinese food. So this guy really wanted a rice cooker. I told him to just go buy one. He didn't. Not right away. He first tried to cook rice in our electric kettle. You can imagine how well that went.
|
|
#
?
May 4, 2019 06:40
|
|
|
mercenarynuker posted:I dunno about you guys, but I don't know that I want extruded rice sushi. Seems like it would have an unpleasant consistency compared to the sticky rice Don't worry - it's fake rice (thanks Lisa!) anyway.
|
|
#
?
May 6, 2019 11:35
|
|
|
Reactor Status Display It's funny sometimes, how you can run into a person and not realize something really important and relevant about them. In this particular case, it's about Ms. Irina Kurchatova, who I made the cat feeder for back when Avalon City was still growing. At the time, she said she might have a "serious job" for me eventually, but she never said what. Once the cat feeder commission was over, well the thing is, I never really bothered to look up Irina's bio. If I had, I probably would have been able to figure out what sort of thing the 'more serious job' could be. Now, though, I have a very clear answer.      Yep. To be honest, my first reaction is actually, "I have some questions!" Why nuclear power? Avalon City currently has a remarkable crop of solar panels, which are supplying the majority of the city's energy needs already - and Avalon City isn't growing any bigger at the present time, as far as I know. Maybe it's for manufacturing use? Every so often, I do get emails about new types of factory being added to the industrial areas. Still, this project confuses me. Fortunately, though, the design looks fairly simple. The 'error' code basically writes itself, and the control rods... each time the control rod indicator moves in one direction, a segment at one end of the line is turned off, and another segment at the other end is turned on. Seems straightforward. [ ~ ]     Here's the first half of the design. The error code is handled in the top MC (which just sends any value from the error input on to the display); the bottom two MCs handle the display of the control rods. The left bottom MC checks, each time unit, if the control input is the same as last time unit (the previous reading is stored in its acc). If it's the same, it does nothing. Otherwise, it changes its acc by 50 to try and match the control input, sending a pulse to the center bottom MC to say, "move the rod indicator in this direction". The center bottom (control-rod display) MC takes pulses saying, "move the indicator one to the left" (+1) or "move the indicator one to the right" (-1). Its acc tracks roughly where the center segment of the 'rod' is right now. When the MC gets a pulse, it adds (or subtracts) 2 to get the ID# of the segment that needs to be turned on, to move the displayed 'rod' in the correct direction. It'll send that segment ID# to the display. Another add/subtract (by 3 this time) gets the ID# of the segment to be turned off, then the MC tacks on a negative sign (to indicate that the segment should turn off instead of on), and sends that to the display as well. Finally, the display MC resets its acc to the center of the lit 'rod' segments, and waits for the next pulse. I haven't got the power or temperature inputs handled yet, but those are the next step. Onwards. [ ~ ~ ] I found out more about the reactor plans. The reactors (plural) are to be housed on their own separate plate, away from the main body of the city as a safety precaution. There'll either be some sort of causeway to get to them, or you'll have to take a boat! I'm kind of relieved to hear this, to be honest. Nuclear energy makes me antsy, just by its nature. Anyway, I've finished the power-temperature reading MCs, and the design works.        The MCs connected to the error and control inputs are the same as the last version (well, except for a few once-only lines in the error-handling MC that turn on display segments when the device is started). What's new is the three (!) MCs that handle the power and temperature inputs. The left-center (input) MC6000 reads the values of the inputs, multiplying them by 5 and taking the hundreds digit as a simple way of dividing by 20. It sends each value along to the MC4000 in the middle, along with a '10' or '20' to indicate which set of display elements (power or temperature) needs to be updated. The middle MC4000 acts as a data cache. It passes the first value (indicating the topmost display element to turn on) it receives from the input MC to the right-center MC6000, and holds the '10' or '20' it receives in its acc. The right-center MC6000 will ask for this held value on a regular basis; the middle MC will provide copies of it until the right-center MC signals it's done. The right-center MC6000 (the power-temp display MC) is where this all comes together. Because the elements that need to be toggled on or off are always in the range 11-14 or 21-24, the power-temp display MC runs in a loop, with its acc going from 1 to 4. Each round of the loop, the display MC asks the MC4000 it's connected to for the '10' or '20' value, and adds it to acc to get the display element ID# to turn on. The value the power-temp display MC received before the loop started will be a number from 0 to 4; this signals how many display elements to turn on, and the MC will store this in its dat. When the value of acc as it loops is greater than dat, the MC will multiply the display element value it's come up with by -1 to indicate "turn this element off", instead of "turn this element on". Once the looping display MC has a display element ID, it'll send that ID to the display, and subtract the '10' or '20' from its acc to reset acc to a single-digit value. Then it jumps to the start loop, if there's more display elements to update. All of this sounds really straightforward, but there's one teeny-tiny problem with the design: power usage. The design is ฅ24 and uses a whopping 9906 average power per run. I get that this is going to be running in a nuclear reactor, but it shouldn't take a reactor to power it! I'm going to have to go over the design and figure out what's making it draw so much energy - and then fix it, of course. Further updates as designs warrant. [ ~ ~ ~ ]         I tracked down the source of the power problem. It turns out it was simple, for the most part: the left-center MC, attached to the power and temperature inputs, was sending updates in the direction of the display every time unit, whether the values of the inputs had changed or not. This new version fixes that. The large, left-center MC6000 has been replaced with two small MCs, each of which is responsible for one of the two inputs. Each MC uses its acc to determine if the input's value has changed since the last time unit. If so, it sends the input value (divided by 20 with mul 5, dgt 2) to the data cache MC in the middle, which passes it on to the right-center display MC to toggle the correct display segments. The active input MC also sends the '10' or '20' that identifies which line of display segments to edit, like before. (I was worried that the small MCs might cause a synchronization error by sending updates at the same time if the power and temperature inputs both change at once, so I checked with Irina. She said that for this application, it's possible to set up the MCs so that they wake from slp at slightly different times, which should resolve the issue well in advance.) I was able to make one other slight improvement to the power-temperature processing MCs - this one is to the middle cache MC and the display MC on the center-right. Put quite simply, the previous design had the cache MC remind the display MC of the '10' or '20' twice when cued: once so the display MC could add it to its acc to get the display element ID#... and once so it could subtract it again to use acc as a loop counter. The second reminder was unnecessary - I was able to remove it by replacing the sub instruction with a dgt 0, instead. This strips out all but the ones digit - same effect, but more efficient. The display MC was also reminding the cache MC one extra time when it didn't have to, so I rewrote the MCs' scripts to cut the redundant reminder out. The stats for the changed design are a lot better than before: ฅ25, but only 1219 average power per run. While this version is a drastic improvement, my experience tinkering with the power-temperature MC chain leads me to think there's more to improve on. Right now, any time the power-temp display MC needs to blank out a segment, it multiplies the value of its acc by -1 to negate it, then multiplies the value by -1 again so that the code that checks the loop works properly. Every. Time. If the MC had to blank 4 segments in a loop, that's 8 mul instructions! It feels like it'd be possible to make things even more efficient, and I'll look into this before I send the design anywhere. With luck, I should be able to give Irina something that's properly optimized once this job is done. [ ~ ~ ~ ~ ] The new design runs much better! Even better than I expected, in fact.        You'll notice that the middle MC - which was caching data before - is now gone. This is because I found a better way of toggling the segments efficiently, using two loops instead of one. To start with, the power and temperature input MCs on the left now add their '10' or '20' directly to the value, as well as an additional +1 - all the display segments with a lower ID than this number will be turned on. Sending this number to the display MC on the center-right starts the first loop. The display MC saves the loop-end value in its dat, and gets the loop start ID (either '11' or '21') by digit manipulation (setting the ones digit of the value to 1). Then, it loops through, adding 1 to the ID each time, and turns on all the segment IDs it cycles through. After that, though, it multiplies the end-point of the first loop by -1 (to indicate to the display to turn off the following segment IDs), gets a second value from the input MC, which will be the end-point of the second loop (either '-15' or '-25'), and continues from there, subtracting 1 to bump up the value of the now-negative acc. As an example, imagine if you had a power input value of 54. According to the spec, that should be 3 bars on the power gauge. The input MC divides 54 by 20, gets '2', and so sends '13' to the display MC. The display MC, with its loop, turns on display segments 11 and 12 by sending '11' and '12' (display segment 10 is always-on and can be skipped). The loop does this because the values are less than the '13' the MC received. Once the MC gets to '13', it multiplies it by -1 to get -13, gets -15 from the input MC as the new input, and turns off segments 13 and 14 by sending '-13' and '-14' to the display. (There's no segment 15 to target with a '-15', and the MC stops the loop once its acc is at the end value.) Finished! This version betters the previous design substantially, coming in at only ฅ22 and 814 average power per run. I think I've improved the center line (with the power and temperature inputs) as much as I can - but all this messing around with numbers has given me an idea for how to make the MCs connected to the control input more efficient. I think I'll test out what I've got in mind and see if it works - and then call it a day. [ ~ ~ ~ ~ ~ ]       And here it is - the pretty-much-final version. As promised, the only difference between this version and the last one is that I've reduced the control-input handling part of the device to a single MC. It turned out a lot of the old way to handle the control input was redundant, if you think about the 'control rods' displays segments as two pairs of segments apart from each other, along with a central segment that's always on. Segment 30 (far left) is always on when segment 33 (center right) is off, and vice versa. Segment 31 (center left) is always on when segment 34 (far right) is off, and vice versa. Segment 32 (dead center) is always on, and is turned on by the error-handling MC as part of its initial script (it's where I had free space). We can ignore it when changing the control-rod display. So, the new control-rod handling MC checks the control input to see if it's different than last time unit, then (if so) decides which segment of each pair should be on, and which should be off. It sends that information to the display, then goes back to sleep to wait for the next time unit. It's pretty straightforward. (A side effect of this is that I had to add a few more one-off lines to the error-handling MC, to set the control rod display segments' starting state when the device is turned on.) This version is ฅ19, and uses 761 average power - and compared to the first working version, it's a design I can really be proud of. Time to make it official.   Congratulations to Irina on her commendation! That said: More energy than we could ever need, huh? I still want to know what this is all for. If it's manufacturing, what's being made? If it's not, what sort of thing would create such an energy draw? I might have to look into this - I'll post here if I learn more.
|
|
#
?
May 16, 2019 00:37
|
|
|
Do I understand correctly that there's no way at all for the reactor to tell this display that an error is resolved? That seems like a rather serious design flaw.
|
|
#
?
May 16, 2019 06:35
|
|
|
Error codes come in over an xbus pin, so the reactor control board can just send a negative number when a fault condition is cleared.
|
|
#
?
May 16, 2019 06:40
|
|
|
Quackles posted:That said: More energy than we could ever need, huh? I still want to know what this is all for. If it's manufacturing, what's being made? If it's not, what sort of thing would create such an energy draw? The energy generated by the thorium reactors will be beamed via microwave to the orbiting satellite network 孙昊-VI (launched in 2022 ostensibly as a competitor to the EU's Galileo navigational network.) The 孙昊-VI(α) node over Avalon is configured to receive and retransmit power to nearby nodes, allowing for distribution to 98 孙昊-VI(ω) nodes scattered throughout the network, which serve as platforms for the 天矛 phased particle cannons. Soon the world will be yours! Well, Sun Haotian's, anyway.
|
|
#
?
May 16, 2019 09:39
|
|
|
The_White_Crane posted:The energy generated by the thorium reactors will be beamed via microwave to the orbiting satellite network Isn't it the other way around, usually? (Orbiting solar satellites beaming power down to earth)
|
|
#
?
May 16, 2019 10:17
|
|
|
Tamba posted:Isn't it the other way around, usually? (Orbiting solar satellites beaming power down to earth) Usually, sure, because we want to funnel solar-generated power down to ground-based uses, but with a geostationary satellite there's no reason you can't do it the other way. AFAIK, I'm not actually a physicist.
|
|
#
?
May 16, 2019 11:21
|
|
|
|
| # ? May 3, 2024 03:05 |
|
|
I'd say its just futureproofing, planning ahead seems like Sun Hoation's thing.
|
|
#
?
May 16, 2019 11:48
|
|