Besides configuring and interacting with hardware, the VMUSBReadout program parses the raw USB buffers read from the VM-USB into a series of NSCLDAQ ring items. The raw USB buffers are composed of data produced by at least one stack execution, normally many. There is a header for the entire buffer and then a header word for each chunk of the buffer that corresponds to a single stack execution. Those latter header words identify the index of the stack that produced the data. VMUSBReadout uses the index in each header to generate NSCLDAQ ring items of the appropriate type before emitting them to the outside world. For example, if that stack index is 1 the data in the buffer is used to fill a ring item of type PERIODIC_SCALER. If the stack index is 0, the data in the buffer is used to fill a ring item of type PHYSICS_EVENT.
For all stacks whose index is different than 1 and 7, a PHYSICS_EVENT is created. The body of that PHYSICS_EVENT will begin with the 16-bit long event header containing the index. The lower 12-bits of this header word is the number of 16-bit words that follow in the body. The most significant 4-bits of that header identify the stack index. For example, if the data corresponds to stack index 0 and contained 10 words, the header would be 0x000a. On the other hand, if the stack index was 6 and contained 10 words, it would be 0x600a. Unless you defined some stacks in your daqconfig.tcl that would trigger on interrupts, you should not expect any data labeled with an index different than 0.
The data corresponding to stack 1 is treated specially as scaler data. The approximate time of readout is attached to scaler data and some other useful information for later processing, such as the readout period, is added. The scaler data is then stuffed into an array of 32-bit integers. The event header in this case is discarded because the stack index is uniquely 1 for the scaler stack and the size of the data is well determined by the size of the scaler data item.
Data from stack index 7 is not outputted to the destination ring buffer. Rather, it is interpreted as data from a monitor list and passed to the slow-controls server for handling. Clients of the server can then gain access to that data.