If there is nothing wrong with my rather spaghettoid script (admittedly, a big if) then there is no complete solution. The best my computer finds is two cycles.
It finds essentially three such solutions plus a few minor variations. Interestingly, the split is always 3-13.
[FEN "1Q6/3R4/NB2P3/1P3P2/2P3P1/1N1P3P/P4KB1/R7 w - - 0 1"]
[FEN "R7/BP6/2PK4/6R1/2N3BP/1N1P2P1/P3PP2/Q7 w - - 0 1"]
[FEN "6R1/6BP/1N4P1/P4P2/BP2P1NK/2PP4/7Q/3R4 w - - 0 1"]
Strategy / computer implementation
From the assumptions follow a handful of constraints that enable an exhaustive search.
- There are no more than 4 chains of Ps. That is because Ps can only attack other Ps or Rs or Ns and each separate chain has a P at the base that is not available to be attacked by another P. Each chain is capped by a R or N.
- The major pieces each have a rank to themselves. That is because there is at least a P on their file, so they must spend their attack on that file. The Q, in particular, must also have her diagonals to herself.
- The Q must be attacked by a N.
- At least 1 chain of Ps must be capped off by a N. There are at least two Ps on the same rank and their respective chains cannot be both capped by Rs because then 1 chain would have to cross the private rank of the other chains R.
Using these constraints makes the code rather verbose and ugly but keeps the number of candidates below a million or so.
Relaxing the rules
If we lift the one pawn per file rule it becomes untractable for my computer program, but we can solve manually
[FEN "6R1/1R6/1BP3BN/3P2P1/2P2P2/1P4P1/P1N2K/Q7 w - - 0 1"]
Last word: The i files
We can actually achieve a full solution with no doubled pawns by ever so slightly bending the rules. All we need to do is rip out the f file but relax we are putting it right back: as the new i file. Job done: