get_status()

Returns the status about the background operation currently running.

Prototype

get_status(board_num, function_type)

Parameters

board_num (int)

The number associated with the board when it was installed with InstaCal or created with create_daq_device().

function_type (FunctionType)

Specifies which scan to retrieve status information about. Refer to the function_type parameter values section below.

Returns

• status (Status) – Value indicating whether or not a background process is currently executing.
• cur_count (int) – The number of points that have been input or output since the Background process started. Use it to gauge how far along the operation is towards completion. Generally, cur_count is the total number of samples transferred between the DAQ board and the Windows data buffer at the time get_status() was called.
• When you set both the CONTINUOUS and BACKGROUND options, the cur_count behavior depends on the board model. Refer to the board-specific information for the behavior of your board.
• With recent MCC DAQ designs, the cur_count parameter continually increases in increments of the packet size as Windows&146; circular data buffer recycles, until it reaches 2³¹. Since the count parameter is a signed integer, at 2,147,483,647 + 1, the count rolls back to a negative number (–2,147,483,647). The count parameter resumes incrementing, eventually reaching 0 and increasing back up to 2,147,483,647.
• The cur_index value is usually more useful than cur_count in managing data collected when you set both the CONTINUOUS and BACKGROUND options.
• cur_index (int) – The cur_index value is an index into the Windows data buffer. This index points to the start of the last completed channel scan that was transferred between the DAQ board and the Windows data buffer. If no points in the buffer have been transferred, cur_index equals –1 in most cases.
• For CONTINUOUS operations, cur_index rolls over when the Windows data buffer is full. This rollover indicates that "new" data is now overwriting "old" data. Your goal is to process the old data before it gets overwritten. You can keep ahead of the data flow by copying the old data out of the buffer before new data overwrites it.
• The cur_index value can help you access the most recently transferred data. Your application does not have to process the data exactly when it becomes available in the buffer - in fact, you should avoid doing so unless absolutely necessary. The cur_index parameter generally increments by the packet size, but in some cases the cur_index increment can vary within the same scan. One instance of a variable increment is when the packet size is not evenly divisible by the number of channels.
• You should determine the best size of the "chunks" of data that your application can most efficiently process, and then periodically check on the cur_index parameter value to determine when that amount of additional data has been transferred.
• Refer to board-specific information for specific information about your board, particularly when using pre-trigger.

function_type parameter values