Attached is a minimum working example in LV2019 that reads 4 AI from a 7851R, packs it into a 64-bit integer and and pipes through a Target to HOST DMA FIFO.
Issue #1: I can't seem to shake out a strange GPIB error message (attached).
Issue #2: Decimation works (elements are reduced), but the TDMS file size does not reduce correspondingly. I assumed defragment TDMS should take care of the redundant headers.
Project attached. All suggestions to clean up the VIs are welcome!
PS: On an unrelated note, I am using Bob Schor's "empty array condition" with great success (also in this Host VI). A big thank you Bob!
I hope this isn't a "silly question", but are you running a PXI system whose Controller (in the first slot) is running Windows, instead of a Real-Time OS? If so, I'd say "Don't do that, let the PXI do what the PXI does best, namely run a Real-Time OS and let a Windows PC run the Host Code. In some sense, the ultimate Producer/Consumer Design is a PC with the User Interface and RT Hardware with all of the time-critical stuff. When I do this, I use LabVIEW's Network Streams to create (over TCP/IP) a Communication Path from Producer to Consumer.
HOST is the PC, which handles the User Interface (both Controls and Indicators) and does the I/O (including TDMS). TARGET is the PXI, which does the Real-Time stuff, including the FPGA and handling the FIFO Transfers from FPGA to TARGET.
I usually have at least three Network Streams (they are one-way). I usually use a design similar to a State Machine for the Host, with an Event Loop to catch changes to Front Panel Controls, and a "Tell Target to Do Something" State which sends a Network Stream "Message" to the Target with enough parameters so the Target knows what to do.
The Target tells the FPGA to gather data (because the Host told it "Time to get me some data"). How does the Target get the Data to the Host? Well, the Host "knows" when it told the Target to send some data that it was going to have to read that data. You could just have the Host go to its "Listen for Data from Target" State, or (what I do) get the Target to send a Network Stream Message to the Host saying "I'm sending you some data, do something sensible with it". The Host, of course, "knows" (because you told it) whether you want to plot, average, decimate, invert, whatever the data before saving it, and because it has the Front Panel Controls, you can control all of these variables.
Now you have one (smaller) program running on the Host that will probably fit on a single Laptop screen (especially if you use a few sub-VIs), making it much easier to read and understand. And on the Target, no worries about Controls or Front Panels, as the Host "tells all", just worry about getting the data when the
Boss Host say "Go!" and sending it all (unprocessed -- let the Host do that messy part).
P.S. -- I might not have been clear on the three Network Streams. One is "Message, Host to Target" (basically telling Target what State, with parameters, to do), "Message, Target to Host" (same thing in reverse), and "Data" (also Target to Host, getting data ultimately from FPGA to Target to Host to Disk, with the Data Stream being Target to Host).
Bob: I am running a PXIe system (1062Q chassis) controlled by a PC (Win10_x64) running LV2019-32bit with a PXIe/PCIe 8370/8371 controller pair. At the moment, due to other constraints I am limited to this setup.
From a higher level view, my architecture is as you describe. HOST handles controls/indicators/data logging. TARGET (FPGA) reads the AI and pipes them to the HOST via a DMA FIFO. On the HOST, the data from the FIFO is enqueued, dequeued, unpacked and written to a TDMS file. I am not familiar with Network streams, but I will investigate them. What is the advantage over simply writing to a watch variable (HOST side) via the FPGA read/write control? If you can, please point me to an appropriate minimum example to learn more.