Hardware Developers Community - NI sbRIO & SOM
Clip node synchronization
MMO832,
If your ADC provides any sort of signal that a convert is done you can use a while loop to block on that assertion. This will allow your code to only finish running until the value has been asserted and given yourself a chance to read the value.
The other option is handling requrests on a timed interval, Any requests received will only be fulfilled on the next available sample time.
MMO832,
This is what we essentially do under the hood. You can either wait long enough to ensure you have new data or wait for a signal to assert data is valid.
We do this behind the scenes of the IO nodes that you add to the block diagram.
CLIPS run in parallel to the fpga block diagram so you'll need to implement a mechanism to tell LabVIEW FPGA the data is valid. If you see section 4 that describes the behavior differences between CLIPs and IP Integration Node.
Hi MMO832,
I threw together a quick example of what I believe could work for your situation. You stated that you would like a blocking call, similar to what we have with our I/O nodes that correspond to C Series modules and if we have any internal hooks or XML file changes to enable a CLIP node or other block diagram component to block until data is ready.
We do not have any internal hooks or XML changes as LabVIEW does not know when your data will be valid from your ADC; In other words, there is no XML tag to set 'blocking' to true. You, as the developer, are responsible for knowing when the data will be valid. As mentioned earlier, having a data valid bit or signal from the ADC can be leveraged to achieve the behavior that you require, although it will not look exactly like a C Series I/O node, but it will provide the same behavior.
In my example, I used the sbRIO CLIP Generator to combine 8 single-ended signals and bring them into LabVIEW as a U8. I also imported a clock into LabVIEW that represents a Data Valid signal. Through the CLIP Generator's user interface, you can only import a pin from the SOM's connector as an external clock source. If you do not have a Data Valid pin on your ADC, you can also modify the CLIP VHDL and XML to perform some additional Data Valid logic and use the output signal of that to be imported into LabVIEW. Of course, this is assuming that the data is always valid when Data Valid asserts.
One of the many great features of the SOM and the newly-released sbRIOs is the ability to use an imported signal as a clock source for a Single-Cycle Timed Loop (SCTL). In my example, I am using the Data Valid pin from an imaginary ADC to clock the data of a parallel interface into a Target-Scoped FIFO. This ensures the data being read from the CLIP node is valid as it is synchronous to Data Valid. This is the first important thing to note about the example.
The second important note about this example is in the lower loop. I have the other end of the FIFO set with an infinit timeout. In a While Loop, this means that the FIFO Read Method will block for an infinite amount of time until the upper loop pushes an element of data into the FIFO. As long as your consumer loop is being clocked faster than the producer loop, the FIFO should always be underflowing and have ~1 element or less. The great thing about FIFOs are that if the producer loop is sending bursts of data, the FIFO will not be lossy as long as it has a sufficient number of elements. For your case, the upper loop will likely be clocking data in at a consistent rate so make sure it will be slower than consumer loop. Having an infinite timeout on the FIFO means you have a the same effect as a C Series I/O node would. The block diagram element is a FIFO so you could wrap it in a subVI to give your API a more custom look.
If you are instead operating the consumer loop as an SCTL rather than a While Loop, you will need to peek at the FIFO and see if there is one or more elements before actually reading it. This is because SCTLs require a FIFO timeout of zero.
Alternative Approach:
A potentially more intuitive and LabVIEW-centric way of solving this is to import both the Data_U8_in and Dat_Valid signals as a CLIP node. You could then read these values in an SCTL that is sufficiently fast to always catch the Dat_Valid edge. You could then implement and edge detector that only pushes data into the FIFO on a rising edge of Dat_Valid. This shouldn't be a problem at lower speeds but if you are sampling much faster, it may be difficult to generate a sufficiently fast SCTL clock to ensure that you are always catching a Data Valid edge.
Here are the two examples described above using the same vhd code. It is not fully tested for glitches but you can use this as a guide to synchronize data between CLIPs and the FPGA block diagram. This is not taken from a specific module and this should not be a guage for how the actual code was written for IO nodes.
The first is providing a clock signal to trigger when samples are fresh. In the screen shot we can use a Timed loop to import this clock so the loop only executes with the clock ticks. I've simply imported my data valid line as a clock. This way the loop is blocking on the actual data.
If you choose to only use the data valid flag as a boolean you can use a similar structure to read the data and push it to a fifo for analysis later.
For more complicated clips it may be necessary to implement 4 wire handshaking where LabVIEW in the clip each signal when data is ready as well as verifing that data has been clocked in.
