I did some testing with dual EtherCAT masters on my X5 with 3.04.
XF50 = EthercatMaster_1
XF52 = EthercatMaster_2
Each master gets its own I/O Engineering project, and their cycle times can be set independently. But only EthercatMaster_1 (XF50) is associated with the ctrlXAutomation scheduler task that runs Motion. So only the drives connected to that master can be connected to an Axis in the Motion app. Drives connected to EthercatMaster_2 can only be operated with fieldbus interface similar to Profinet or Ethernet/IP. ctrlX DRIVE Engineering can connect to drives on both masters for configuration purposes.
Use case: put all the drives on EthercatMaster_1 with standard cycle time (2ms or 4ms) and put high-speed I/O on EthercatMaster_2 with fast cycle time (500us for X5, 250us for X7). I don't have any high-speed ctrlX IO at the moment, but I did a test using the onboard I/O of ctrlX DRIVE and 500us EtherCAT cycle. I added P-0-0307 digital input image to the AT and P-0-0313 digital output image to the MDT. I imported them into DataLayer Realtime in the PLC and made the PLC task synchronous to EthercatMaster_2. I connected the digital output XG31.8 to to a digital input XG31.1. In this case I can toggle the output TRUE for one scan, FALSE the next scan, TRUE, FALSE, TRUE…etc. and detect every rising edge on the input side. When I tried this test with ctrlX IO standard digital input and output modules I had to go up to 4000us EtherCAT cycle time, otherwise the rising edges could not be detected (input appeared to be always TRUE).
In the future (3.06 or 3.08) it will be possible to have both EtherCAT masters synchronous with each other. Will it also be possible to assign an Axis to either master? Then you could put the high-performance axes (e.g. cams, complex motion paths with high point density) on the faster one and other axes on the slower one. But to really support this we would need 2 motion path planner clocks - one for each EtherCAT master. I see this use case for printing and converting machines with high axes count. Most of the axes would be fine with 2ms or 4ms cycle time, but a few could benefit from faster cycle time for better resolution of cam profile at high velocity. Currently all axes must run with the same cycle time, resulting in unnecessary CPU burden.
Both masters in OP state:
EthercatMaster_1 devices and Scheduler configuration:
EthercatMaster_2 devices and Scheduler configuration:
