I have no idea why it worked but perhaps the explanation below will give you some ideas.
The original Q series PLc we did this on had MX4 Scada (actually MX4 is an IFIX scada re-badged by Mitsubishi), it had two things going on, first of all was the built in driver for Mitsubishi plus a utility program using Mitsubishi's own MX component for communication.
The Scada communicated with the master PLC via ethernet, the utility program (actually a recipe handling system) built in Visual Basic for getting recipes from an SQL server & downloading to the PLC, so in effect the scada & the recipe handling were two totally seperate programs running on the PC, the only settings on the PLC for the Ethernet card were about 10 Melsec connections this is usual for Mitsubishi software to communicate i.e. not for other applications like Kepware. The Scada system was poorly designed regarding the graphics there were over 70 pages, graphics were very poor & the diagrams incorrect as far as flow, the company that did it eventually gave up supporting us, so we decided to upgrade, I had already done extensive mods on the PLCs 8 of them networked by NETH another coms link.
As this was a working system the new scada had to be tested thoroughly off line, I modified the plc's i.e. temporarily remove calls to the I/O, wrote a simulation package, as time was short, another company did the new IFIC scada, it was a big system nearly 1500 valves, 50 odd motors ASI sensors for the valves 22 tanks a very big system, The told me they had problems with the Kepware driver communicationg to our spare PLC so I went to their offices, talked to Kepware & they said UDP is the way to go this worked as per the UDP configuration I posted. We tested everything & it worked like a dream, on the day of the changeover, the idea was to connect the new scada to the live system, leave the existing Melsec connections and add the UDP connections to the Ethernet card on the Master PLC, we plugged it in as the plant was already running (I was going to wait for a slot to modify the PLC card), but it worked straitaway so we left it, no idea why it worked, the other firms engineer had tried TCP on the trial PLC with the same connections as per the running system but could not get it to work.
From that point I did not bother to modify the Ethernet for UDP as it was working.
As for the ethernet encapsulation this was to get data from 8 packaging machines, these all had FX2N PLC's there was no room to fit the Ethernet module on the FX's, so I fitted the 232 BD coms boards (fits in the expansion connector on top of the PLC but does not require any space as it sits on it not at the side like the Enet-ADP. We used Ethernet to 232 converters to take the Kepware via Ethernet to the machines, the converters just converted it to 232 for the PLC's, this used the Kepware encapsulation a tick box when you set up what would be 232 connection, this worked well, I was testing on a spare FX3U with the Enet card for another project, loaded the settings I had by mistake for the ethernet encapsulation & it worked, so that is why I suggested it, not that you should need it hopefully you will get it to talk using the UDP settings. I have an FX3U with the Ethernet card, but this is not the same as the ADP so the settings are done via Ethernet utility not in the PLC parameters, If I get time I will try some other methods like TCP etc.
howevr, not having the ADP type board I'm not sure that it works in the same way, but my guess is it must be similar, or perhaps in effect the ADP board acts a bit like an ethernet to serial converter as it plugs in to the same connector as the other add on boards like the 232 or 485 adapters.
Thanks for the details mentioned above so i will be cautions as figuring out this stuff myself could be both time consuming and paintful.
