It seems I was running into two different issues in my testing: CPU limits and attempting to operate with a EtherCAT task period that was faster than the cycle time of the installed modules. This caused Rx Frame Count and Frame Lost Count to increment and the EtherCAT CPU load would reach 100%. This is a known limitation with the ARM processor I was using and was functional after increasing the task period from 1.25ms to 5ms. I will be looking into different intel processor controllers that are capable of running faster EtherCAT taskrates.
As for the ELM3002 configuration, it seems that the distributed clock settings do not need to be explicitly configured in the “General” tab. Instead, when selecting the channel number of samples in the “Process Data” tab the device will automatically configure its internal distributed clock accordingly based on the EtherCAT task period (DC_period=ECAT_period/num_samples). If the user attempts to set a DC_period faster than the minimum (100us in the case of ELM3002) then the EtherCAT_Master Log will show an invalid DC Settings message during PreOP.
In addition, it is not explicitly stated in the manual, but in order to reduce the EtherCAT CPU usage and increase the number of oversampling then the “Process Data” must specify the data in Integer format (16b) as opposed to DINT (24b) or real (32b). The measurement linearization must be changed accordingly.