Block Transfer Instructions stopped executing

It's hard to say if you've committed any sins without seeing a confession; can you post the *.RSP program ?

It's hard to use up the PLC-5/20's stock of block transfers; it can handle 128 of them.

I'll bet there's an accidental overlap of block transfer control blocks, or there's something writing into block transfer control block memory.

I'm not very familiar with data file protection; you could try to write-protect the BT data files to be sure that nothing can write over them. You won't be able to modify them, though.

Check carefully also to be sure no block transfers are set for Continuous mode.

Everything looks very much by-the-book; all the block transfers are self-retriggering, with the conventional Read/Write alternating logic and BTW's that are sent when the analog Input modules power up.

There are only 20 block transfer instructions, so they should only use 20 of the 128 available command blocks.

I would try to write-protect BT9 and N10 to make sure nothing on the DH+ network is writing over the command blocks.

N10, especially, is the sort of address that some HMI device might inadvertently write to.

Were any other logic changes made in the system recently ?

One thing I might consider is putting some logic at the end of this ladder file; ADD 1 to a register for every /EN and SUB 1 from the same register for every /DN or /ER. If the value is ever anything but 1 or 0 you've got something messing with the control words.

I have seen at least two or three recommended "standard" rungs for BTR and BTW over the years.

The one I use is this: (cb is the control block address)

I have never had problems with this, and its in some of the manuals, for what its worth.

If this doesn't work then you will have to consider Ken's suggestion that you have an overlap. There is no way around just brute force careful double checking, except perhaps to just clean the slate and re-create them. I have had some problems go away when I deleted objects and recreated them, most recently a PID instruction. They look clean in the ladder but under the hood in the compiled code they can get corrupted.

The only logic changes have been the last few rungs.
I'll put the ADD and SUB logic in on my next trip. Hopefully this will allow me to tell when the BXFR memory is being eaten away instead of having to wait days for it to fail.
Again Ken Thanks for all your help.