MCS mode gets fewer channels than external channel advance pulses in some conditions

[MarkRivers]

In MCS mode the number of channel collected (CurrentChannel) can be less than the number of external channel advance pulses received under the following conditions:

1) The number of external channel advance pulses received on CLKI is less than the requested number (NuseAll). 2) The dwell time (DWEL) is set to less than 0.01 second.

For example:

• External channel advance pulse rate into CLKI is 1000 Hz.
• DWEL = 0.001
• NuseAll = 2048
• The actual number of pulses sent to CLKI is 2047

One would expect that the final value of CurrentChannel would be 2047. The MCS would not automatically stop, because it is expecting one more external channel advance. What is actually observed is that the final value of CurrentChannel is 2033, not 2047.

This is the explanation for this.

• The USB-CTR08 can transfer the MCS data to the EPICS driver in 2 modes:
  • SINGLEIO mode. In this mode the counts for each dwell period are immediately sent by USB to the EPICS computer.
  • BLOCKIO mode. In this mode the USBCTR buffers the data and sends it in blocks to the EPICS computer.
  • SINGLEIO mode is desired at long dwell times, so that the user can see the MCS array data without any delay from waiting for the buffer on the USB-CTR08 to fill up.
  • BLOCKIO is needed at very short dwell times because the USB bus cannot keep up with too many short transactions per second.
  • The USB-CTR08 always pushes MCS data to the host computer. It does not support pulling the data via a request from the host.
  • The EPICS driver transitions from SINGLEIO to BLOCKIO when DWEL is less than 0.01 seconds.

In general I recommend that DWEL be set approximately the period of the external channel advance pulses. In the example above with DWEL=0.001 it was thus using BLOCKIO. The problem arises because the USB-CTR08 was told to collect 2048 dwell periods, but only receives 2047 external CLKI pulses. It thus has a partially full buffer that it will push to the host when pulse 2048 is received. But because that final pulse is never received the final buffer is never sent, and CurrentChannel only gets to 2033.

This problem can be worked around by always setting DWEL to 0.01, forcing it to use SINGLEIO even for external pulse periods shorter than 0.01 seconds (100 Hz). Surprisingly I have found that SINGLEIO works reliably for dwell times as short as 10 microseconds, i.e. 100 kHz. This is true no matter how many counter channels are enabled, i.e. have CounterNEnable=1. However. above 100 kHz channel advance frequency SINGLEIO does not work, and one needs to decrease DWEL to switch to BLOCKIO.

Note that this problem only occurs when the number of advance pulses received is less than NuseALL. If the number of pulses is at least NuseAll then CurrentChannel will always reach NuseAll. This is true whether it is running with SINGLEIO or BLOCKIO.

[MarkRivers]

This behavior has been added to the documentation. https://epics-modules.github.io/measComp/measCompUSBCTRDoc.html#notes-on-external-channel-advance

[MarkRivers]

Closing this, because the documentation now explains the behavior, and how to potentially avoid it.