Leaderboard

Name: Circular Buffer Submitter: hooovahh Submitted: 24 Sep 2014 Category: XNodes LabVIEW Version: 2011License Type: BSD (Most common) Description This package contains functions for maintaining a circular buffer. Create the Circular Buffer using the Initialize Circular Buffer function. This makes a DVR, and the data type of the DVR changes based on the data type specified for the circular buffer. The data type can be any type as long as it is not an array. It must be a scalar. The size of the buffer is specified on initialization but can be changed using the Change Circular Buffer Size function. Add data to the circular buffer using the Write Circular Buffer function. Scalar values can be added, or a 1D array of data can be added. The data type of the values to be written is the data type defined in the initialize function. Read the data back out of the circular buffer using the Read Circular Buffer function. The data type of the read values will be the data type defined in the initialize function. Cleanup the program by destroying the DVR on exit. An example VI Circular Buffer Demo shows how a Circular Buffer can be used. XNode Disclaimer The Initialize, Read, Write, Get Status, and Change Size functions are implemented as XNodes. NI does not provide support XNode development. For an introduction to XNodes read Adam Rofer's "XNodes - A Crash Course" presentation (http://lavag.org/files/file/56-xnodes-a-crash-course-powerpoint). Dependencies LAVA Palette-1.0.0.1 How It Works The source is all open and the template VIs for each XNode is what is executed when the XNode is generated. This means you are welcome to try to further optimize these XNodes by editing the templates. A new instance of the XNode will need to be placed which will force the new code to be used. If anyone finds performance improvements for these functions please feel free to post in the support topic. Because the size of the buffer is practically unbounded, I wanted to avoid unnecessary data copies, which is why it is designed around DVRs. There exists 3 things in the DVR, the buffer size, a pointer to the current write location in that buffer, and the array of scalar values, whos data type is defined during the initialization. Click here to download this file

I've not added this feature in GDS yet, but why not, give me a day or so :-)

I used scripting to create a constant from a "RIO Device" type descriptor, using Flattened String to Variant. But now it's giving me some kind of I/O name control I've never seen before. The down-arrow on the right is disabled, and when I right-click it, there's a new menu item that says "Select User Defined Tag Type". I googled it and didn't find anything. That menu contains "crioRefnumTag", "Data Exchange", "Variable", several FPGA-related items, "RIO Resource", and "System Config". When I select one, it seems to change into an I/O name control of that type, and the menu goes away. Has anyone seen this behavior? I've attached a control that has that menu on it in case anyone else wants to mess with it. TagType.ctl EDIT 1/26/22: Here's a VI containing the user-defined refnum/tag controls, as well as four private nodes that look relevant. Useful Objects.vi

The InstanceDataPtr is basically what the GetDSStorage() and SetDSStorage() functions provided for CINs. It is a pointer value LabVIEW maintains for each Call Library Node in a diagram and in the cases of reentrant VIs with Call Library Nodes for each instance of such a Call Library Node. Your DLL can specifiy the three Callback functions ( I still think the name callback function is a mistake for this functionality) that all accept a reference to this InstanceDataPtr. These three functions Reserve(), Unreserve(), Abort() correspond somewhat to the CIN functions CINInit(), CINDispose(),, and CINAbort(). Usually you would in Reserve() check if the InstanceDataPtr is NULL and create it then or reuse the non-null value. In Unreserve() you should deallocate any resources that you created for this InstanceDataPtr. In Abort() you could for instance cancel any pending IO or other operations associated with this InstanceDataPtr to prevent the threaded Resetting.... dialog when your DLL function hangs on a IO driver call. The actual function associated with the Call Library Node can be configured to have an extra InstanceDataPtr parameter that will be not visible as terminal on the diagram. LabVIEW will pass the data pointer instance stored for the current CLN instance to this parameter. Please note, this is strictly for managing a specific CLN instance. It is not meant to pass around as a token between different CLNs or even different instances of the same CLN in case that the CLN resides in a multiple instantiated reentrant VI. It seems what you want is more a kind of token or handle you can pass between different CLNs to identify some resource. This has to be done by your library for instance by creating a pointer where all the necessary information is stored. You can treat this as opaque value as far as LabVIEW is concerned. Basically you configure the according parameter to be a pointer sized integer and pass this "handle" around in LabVIEW like this between the different CLNs. If you need to access content inside this handle in a LabVIEW diagram your library should export corresponding accessor functions that you can import with CLNs.