I have several linked (trunked) frames and after one of the frames came back online after being powered off for several days I cannot download a map to one of the active frames.

Solution 

One customer had this problem fixed in a v8 patch (2018) and included in later versions of V11 EHX NID problem, the new patch 8.8.0.11 seems solve the problem, but the custom command 175.2 seems not say which matrix cause the NID problem.

The solution is to check the status of all Remote matrices (including the one that was powered up after several days of being powered down.) 

From our active matrix we can use custom command 175.2 and it will list the LAN status of how other frames see us.

In summary, if we are part of a linked set and one of the remote frames cannot see us as being up for some reason, like it has the wrong IP address for your frame or it has not received a updated map of all frames, it can indicate that it does not see you and therefore reject map data from you.

Because it rejects the map data you frame cannot complete the NID process.

EXAMPLE

Your frame is matrix-1 , matrix-5 has been powered off , during that time you changed the IP address of matrix-1

When you try a download to matrix-1, it trys to send updates to all frames in the linked set.  However matrix-5 never acknowledges receipt of the map updates and hence matrix-1 says it cannot complete the download because of the remote frames is not acknowledging the map updates.

The new software allows matrix-1 to complete the download by ignoring the status of matrix-5

The fix that any frame which comes online after being powered off for several days and is part of linked set should have a black reset map download sent to it. This will provide the matrix will all new updates from the other linked frames.

The main things we are looking for are UP, DOWN and UNINITIALIZED in the Remote section.

If UP, the system knows we are there and can find us. This is a good state.

If DOWN, the remote frame thinks it should be able to see us, but cannot see us (likely as it has the wrong IP address for us.

This DOWN scenario is also accompanied with a second message at the end of the report saying that we are ignoring this frame for download purposes

If UNINITIALIZED, the remote frame thinks that we are either not supposed to be there (i.e. we are not expected in the map). Please note that there is an extra case here - if we are requesting logs AT Matrix ID 4, we will always report ourselves as being up locally, but uninitialized remotely.

There is a difference between frames on older and newer firmware when located on a different subnet.

Frames running older firmware will show 'DOWN' when they have the wrong IP address set. Frames running the new patch will show as 'UNINITIALIZED'.  Both should work fine, but it will give you an idea of the firmware in the remote system.