By Max Joseph
I have a question about high level system design with FPGA-RT-PC. It would be great if I can get some advice about ideal approaches to move data between the 3 components in an efficient manner. There are several steps; DMA FIFO from FPGA to RT, processing the data stream in the RT to derive chunks of useful information, parsing these chunks into complete sets on the RT and sending these sets up to the Host.
In my system, I have the FPGA monitoring a channel of a digitiser and deriving several data streams from events that occur (wave, filtered data, parameters etc). When an event occurs the data streams are sent to the RT through a DMA FIFO in U64 chunks. Importantly, events can be variable length. To overcome this, I reunite the data by inserting unique identifiers and special characters (sets of 0's) into the data streams which I later search for on the RT.
Because the FPGA is so fast, I might fill the DMA FIFO buffer rapidly, so I want to poll the FIFO frequently and deterministically. I use a timed loop on the RT to poll the FIFO and dump the data as U64's straight into a FIFO on the RT. The RT FIFO is much larger than the DMA FIFO, so I don't need to poll it as regularly before it fills.
The RT FIFO is polled and parsed by parallel loop on the RT that empties the RT FIFO and dumps into a variable sized array. The parsing of the array then happens by looking for special characters element wise. A list of special character indices is then passed to a loop which chops out the relevant chunk and, using the UID therein, writes them to a TDMS file.
Another parallel loop then looks at the TDMS group names and when an event has an item relating to each of the data streams (i.e. all the data for the event has been received), a cluster is made for the event and it is sent to the host over a network stream. This UID is then marked as completed.
The aim of the system is to be fast enough that I do not fill any data buffers. This means I need to carefully avoid bottle necks. But I worry that the parsing step, with a dynamically assigned memory operation on a potentially large memory object, an element wise search and delete operation (another dynamic memory operation) may become slow. But I can't think of a better way to arrange my system or handle the data. Does anyone have any ideas?
PS I would really like to send the data streams to the RT in a unified manner straight from the RT, by creating a custom data typed DMA FIFO. But this is not possible for DMA FIFOs, even though it is for target-scoped FIFOs!
Currently working on VeriStand custom devices, I'm facing a 'huge' problem when debugging the code I make for the Linux RT Target. The console is not availbale on such targets, and I do not want to fall back to the serial port and Hyperterminal-like programs (damn we are in the 21st century !! )...
Several years ago (2014 if I remember well) I posted an request on the Idea Exchange forum on NI's website to get back the console on Linux targets. NI agreed with the idea and it is 'in development' since then. Seems to be so hard to do that it takes years to have this simple feature back to life.
On my side I developped a web-based console : HTML page displaying strings received through a WebSocket link. Pretty easy and fast, but the integration effort (start server, close server, handle push requests, ...)must be done for each single code I create for such targets.
Do you have any good tricks to debug your code running on a Linux target ?
I would like to use programmatic access to manipulate shared variables on a computer and an NI cRIO 9033, but cannot get programmatic access to shared variables on the cRIO.
I have boiled the situation down to a simple example to try to explain what I am seeing. The shared variables are hosted on the cRIO. I am using the same VI to perform the accesses on the computer and the cRIO. On the computer, access to the shared variable via a shared variable node and programmatic access both work. On the cRIO, access to the shared variable via a shared variable node is functional, but programmatic access to the shared variable does not work.
The error code received when trying to to a Read Variable or Open Variable Connection on the cRIO to the shared variable is -1950678943. The error text reads "Timed out while attempting to open a connection to the variable."
I'm quickly becoming confused as to why the cRIO should have trouble reading a shared variable programmatically that is hosted on itself. The web searches I have done haven't turned up such a simple scenario causing this error, so I'm wondering if I've stumbled into a beginner mistake. I have attached the source code to this post, so if someone could please take a look that would really help!
Result of running on computer (programmatic and shared variable node access both work):
Result of running on NI cRIO 9033 (programmatic shared variable access does not work, shared variable node access does work):
Test Access to Shared Variable from cRIO.zip
I'm working with a contractor on a cRIO-based test system, and we are arranging a shared version control scheme so I can work on the code as well. One issue is that there are 2 different cRIO systems operating in completely different network environments, and there are currently 3 different locations where we have to change the IP address between environments:
1. RT controller properties in project
2. A front-panel control on a UI vi that connects to the RT controller
3. A constant in an RT Main vi to set the target for the FPGA BitFile
I'd prefer to make this more portable and more easily maintainable in this shared satting under VCS, ideally just popping up a panel that offers controllers to connect to so the operator just clicks on a system to connect to. Desired features would be:
1. Dynamically identifies connected cRIO controllers
2. Offers choice of controller to connect with
3. Remembers last choice with ini file and automatically connects if there is only 1 possible target
Thank you for any help.