role restart failed:failed XDAB internal loopback test

The message that says:
packet send took 2 tries to take
and:
packet receive took 2 tries to take
are both messages that exist on account of the new CM-1J or rev4 CobraNet cards. These messages are meaningless and we are removing them from the next version of NWare. Do not worry about them, do not fret that they exist in the Remote Log. Also in the upcoming version of NWare (1.6.2) the available size of the log has been increased to about 10x what it is now.

The one thing that does give me pause is the failure of the XDAB internal loopback test.
You should stop or erase the role on the NIONs in this project and use NWare:Tools>Target Diagnostics...>OK
Then select the NIONs in this project and choose "Run Diagnostics"
Check "external XDAB, clockwise" and "external XDAB, counter-clockwise"
Note that since this checks XDAB communication between NIONs I think you are required to have more than one NION running this test. After all, if you are only using one NION, or it is a single NION by itself as an edge device in a larger system, you do not need XDAB so it is not initialized.

I know this test specifically says "external XDAB..." and your failure is specific about internal loopback. I'm offering this as a method to test if the XDAB is actually working.

Also, you need to pay attention to when these error messages occurred. If you are looking at errors from the beginning of time, but you are not seeing those errors today, your system is working fine and you do not need to worry about it.

I hope this is helpful in getting you on the right track. Please ask if you have more questions.

You while it is not absolutely necessary, it is a good practice to specify one NION in each XDAB stack to be both the XDAB Master and CobraNet Conductor. Obviously, the CobraNet network can only have one Conductor, but you NEVER want to be in a situation where the NION that is NOT the XDAB Clock Master is the CobraNet Conductor. This will create a clock loop and your system will be unstable.

So, your primary processing stack of NIONs should have the XDAB Master and CobraNet Conductor while the backup processing stack of NIONs should have its own XDAB Master and the secondary or backup CobraNet Conductor.

An alternative to this is to have some device other than the NIONs be the CobraNet Conductor. You can adjust the Conductor Priority of any CAB device to make any CAB the CobraNet Conductor.

Regarding the XDAB test, are you using the factory supplied XDAB cables? The XDAB interface operates at a much higher speed and passes a lot more data than an Ethernet interface so the cables must meet a much higher specification than what is typical for standard Ethernet cables. Also remember that the XDAB interface is limited to three (3) meters. Using longer cables will cause failure. So, check the cabling on your first set of NIONs to make sure it is all good. The cabling is critically important.

So all is working well now?

In your situation, with two stacks of two NIONs, the XDAB for each of the NION stacks should be separated.

So, NIONs 1 & 2 should be cross connected together and NIONs 3 & 4 should be cross connected together, but these two stacks should be kept separate. Likewise, the two stacks should have separate project files running on them because in the case of a failure of your primary stack, you would not want your backup stack to mute.

I expect that you know this, but I just want this to be clear for anyone else who may read this thread.