If any run on a tower is working, it normaly knows that board is on the system. The whole board on a tower will seldom fail. However, if the 4 pin connection on tower 1 had a poor connection for example, it will want to change tower #2 into #1, because that is now the first one on the left.
There would then be a whole tower of runs not showing in the configuration. Here is the tricky part, if you press (accept configuration) at that point, it will never try to sense those missing runs. The only way to get them back, is get running components all in place and working before you (accept configuration).
It is possible on your machine that the wrong configuration has been accepted, but it is also probable that you have boards with a few circuits for given rows that have failed.
On one of your configuration pages it will show the number of primary's being sensed and the row numbers on each one. Work on your connections to the #1 primary and the row connectors on that board first. If it refuses to show what you want, physically exchange in one of the other boards that is showing that it's working, and continue across the drill working the problems.
I like to grip the connector pins at about 1/2 their length with needle nose pliers and put a slight bow on the flat side of the pin to get rid of resistance in the connector, along with some WD40.
I would walk you through the pages but I don't have access anymore to one of those units. It should be in (setup) / (aircart) and so on.
If you do get the right number of primary's and rows accepted you can then press the (info) key then (blockage monitor) move along and find (hit counters). You can select any primary one at a time. There will be big random numbers for each row anywhere from 0 to around 60 000 I believe. Have a helper tap each row sensor 10 times with a small tool and see that it registers 10 more hits. You can do this alone but its time consuming.
Once they are all counting that's all you can do while parked. As you start planting, some rows will register blockages that are not. Rework those connectors, because the sensor is redundant, I believe, and will count even when one terminal has a poor connection, but the system senses this to alert you to trouble. If it will not stop alarming, put a new sensor in place and leave the other hanging and see what that does.
If its still not solved, check the configuration again, to see if that row is sensed. It is possible for the tower board to have an intermittent poor connection on a row in the beginning of its failure. That usually gets worse quickly and takes a couple of rows off line.
brs is correct about false alarms, this system will have more stop time to keep it serviced than stop time for actual blockages. It's the nature of the beast and the vintage.
.