Given that mechanisms once outfitted can't be traced you're going to have a lot of fun debugging that thing.
I posted an idea for a hard-wired computer-like clockwork task (scrolling message via floodgate pixels) but it was done as a joke.
Too much of the data you need for diagnostics is either unobtainable once put in place or very hard to get at. You'll need to take notes and take great care that you keep your notes synchronized with what you actually build. (Documentation of things that aren't so can be a source of terrible frustration when debugging.)
You probably already know "The Rules", but here they are for review:
1. Switches signal when and only when they change states.
2. Devices respond to switches when and only when they are "listening" and in a state different from the new state of the switch.
3. Devices responding to a signal ignore subsequent signals for some period of time. Even spikes have a signal response latency.
These rules taken together make for some serious design hurdles. I solved my latency and synchronization issues by setting my pressure plates to "0/0". This takes advantage of the natural latency of water evaporation -- and of my profligate water usage (if I didn't use enough water the valve control plate might get wet right after it dries, and there goes the fort. Instead my water usage guarantees that when the VCP dries its adjacent tile will be safely at level 0-1 as well. In fact the VCP is at the end of a corridor -- very safe indeed. The VCP buffering corridor drains well before the VCP dries. The length of the corridor is actually a means of controlling how much water is added to the system per VCP drying event -- the longer the corridor, the more water goes in.)
You can't use evaporation to prevent signal overruns in your computer because it would be horrendously slow.
Good luck.
Author
Topic: The Dwarven Computation Project (Read 1805 times)