Data from the CoBo does not have run start/end delimeter records. It's therefore not reliably possible for the nscldata router (which turns CoBo frames into ring items) to know when to emit NSCLDAQ begin run and end run records.
ringmerge is therefore employed to produce a ringbuffer that has properly formatted NSCLDAQ runs. The idea is that the readout GUI knows when to emit begin and end run items. It therefore emits these to a state transition ring, while the data router emits PHYSICS_EVENT ring items to a data ring. The ring merge program glues all of this together into a single output ring.
This scheme works around the fact that ring buffers can only have one producer. The ringbuffer parameters of the get parameter dialog therefore mean the following:
This specifies the host and name of the ring buffer that will receive PHYSICS_EVENTS from the GET data router. The host part of the URI must be the name of the spdaq as producers can only produce into local ringbuffers.
This specifies the host and name of a ringbuffer into which the Readout GUI will push BEGIN_RUN and END_RUN records. The host can be remote as the ReadoutGUI can run the appropriate producer program via ssh in a remote system.
The data source provider runs the ringmerge program in the host in which it is running. Therefore, only the ringbuffer name needs to be provided not a URI.