Guess its time to talk about the SCU!
There must be one per system, no more, no less. It’s the panel itself, much like the BMFC for the FC-72. So similar in fact that they share many features and specs, such as a number of electrical test points (the white triangles on the board), jumpers being used to set several settings, no piezo, no zones or initiating circuits on board, a city box connection, 2 NACs rated for 1.75 amps each, and separate alarm and trouble relays.
Unlike the BMFC though, it has a bunch of ICs, including a CPU! Specifically an Intel P80C31BH1, a member of the MCS 51 family. In fact, every unit in ours has one all to itself! I’m not sure if every unit does, but I wouldn’t be surprised. You’d think every part of the panel sharing the load would make it fast and responsive, but nah, this panel is slow as balls. Both the SCU and KDU take about half a second to respond to any button press. The acknowledge, silence, and reset buttons all have to be held down for however long to register as a press. I’m not sure if this was an intentional choice or not, but I suspect it was somewhere in between. I suspect that they didn’t connect the buttons to interupts like you would normally do for a micro controller as the CPU has to juggle a bunch of timing sensitive tasks like the serial port, with the FCINET bus that I speculate is also very timing sensitive, and coding every NAC, all while the code for every unit was written in C instead of assembly. I really wanna figure out how the units talk to each other in the future beyond what I can gather by watching them work.
Continuing the theme of weirdness, the NACs are set to be coded or continuous with two jumpers, W5 and W8. The coding pattern is set in the software FCP-7200. Now, with a panel this big, you would think you could set seperate cadences or coding patterns for each NAC, but NOPE! The SCU doesn’t have time for all that, nor does FCINET! There is only one coding pattern for the entire system, globally. If I read the manual correctly, every DSU and DIU NAC extender is wired back to the SCU to follow a coded output just like any other NAC extender. This also means that you can’t have certain inputs or events change the cadence of outputs, only on / off control. Something really nice though is the NAC trouble LEDs will flash in time with the NACs if they have a trouble. Really cool and handy IMO.
The distinctly labeled Programming Diagnostic Center on the left has a 2 digit 8 segment display used to show the status of the system, albeit in a very basic way as each other unit either has its own LEDs or the KDU to show its status. Its important but doesn’t do that much, being used for auto configuration, walk testing, and fire drills. When doing so, you use the display to enter a code that can only be 2 digits long, but the KDU seemingly uses the same codes appended with 4 zeros to make them 6 digits. I have no idea why they’re different lengths or what happens when you set them to be longer than 2 digits.
Finally is the serial port. It serves not only to connect to a computer for programming, but also as a built in printer interface! Its always printing whether anything is connected to it or not, at a fixed 1200 baud, 8 bits, 1 stop bit, with no parity. Earlier revisions used a standard DB9 connector, but newer ones like ours use a RJ11 connector with a non standard (afaik) pinout. Luckily the pinout and wiring diagrams for making your own cable are provided in the manual with plenty of detail, making it very easy to connect to! Instead of connecting a printer or FCP-7200, you can also not only use a terminal to read the printer output, but also send it commands! The ONLY place any of these are documented is the “front panel programming unlocking procedure” in the troubleshooting guide, where it just tells you to enter some random commands without explaining what they do. Don’t get excited though! Just like a ton of other panels, “front panel programming” is only referring to auto programming, which is even more ridiculously limited and useless than what you’re expecting, as you’ll see once I get talking about FCP-7200. Ugh. Luckily though, there is an EVEN MORE ENTIRELY UNDOCUMENTED program included with FCP-7200, called OTP-7200, that uses a bunch of commands! That though, is a HUGE topic on its own, and I’ve been writing for 3 or 4 hours straight, so I’ll leave talking about that for later.
I’ll leave this with some never before seen photos of the SCU with the plastic bit removed. Not much going on back there besides the LED driver.
