From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
09-22-2021 02:31 PM
How do I get the number of available samples for niDigital Fetch Capture, or get all available samples without having to know how many there are?
I am controlling 2-3 PXIe-6570 digital pattern instruments through LabVIEW 2020. This program loads patterns and waveforms created with Digital Pattern Editor so it is relatively generic. I am able to execute a pattern burst (using niDigital Burst Pattern (Synchronized)) and see the output on an oscilloscope so I know the system is basically working.
At this point I want to read back a capture waveform. I do not necessarily know ahead of time how many samples to read back because those will depend entirely on whatever pattern and waveforms the user loaded.
The niDigital Fetch Capture VI has a required "samples to read" input. Looking at documentation for LabVIEW 2018, it says "A value of -1 specifies to fetch all available samples." This is exactly what I want. However, starting in LabVIEW 2019, the comment about sending -1 has been removed.
I tested sending -1 to this input in LabVIEW 2020 just in case, and it produces the following error:
Error -1074135021 occurred at niDigital Fetch Capture Waveform (U32).vi
Possible reason(s):
IVI: (Hex 0xBFFA0013) The enumeration value for the parameter is not supported.
Parameter Name: samples to read
Value: -1
Just in case it was actually supposed to be an enumeration, I tried to create a constant from that input and it just created an integer.
It seems strange to me that this capability would be removed since it breaks backward compatibility. I was hoping that it was replaced with something else that would be obvious, but I can't find anything that works. For instance, I thought that if I tried reading more samples than I expect, perhaps it would return what it had up to that point, but that creates an error:
Error -1074097965 occurred at niDigital Fetch Capture Waveform (U32).vi
Possible reason(s):
Attempted to read a sample beyond the final sample acquired. The acquisition has stopped, therefore the sample specified by the combination of position and offset will never be available.
Specify a position and offset which selects a sample up to, but not beyond, the final sample acquired. The final sample acquired can be determined by querying the total samples acquired after an acquisition has stopped.
Note that this says I can query the total samples acquired after the acquisition has stopped, but does not say how. Any ideas?
I have looked for niDigital Property Node options to access the number of samples available but did not see anything that applied.
I tried using the niDigital Get History RAM Sample Count VI but this always seems to return zero.
If I put in a positive value that is within the number of samples I know to be available, I do get data back so I know the VI works otherwise.
Without being able to easily get all available samples regardless of their actual number, I am left with two options:
Surely there has to be a better way and I just haven't found it yet. Does anyone here have any suggestions?
09-23-2021 08:33 AM
In short, not possible, I am not aware of any API that tells you the number of samples available in memory.
you must be running the pattern for a predefined duration (not like an infinite loop) and you will definitely know the number of samples that will be captured (by knowing the structure of the pattern).
It is expected that you know the number of samples to request to fetch, what makes you want to fetch until the last sample?
You could fetch in multiples of 1000 samples with a timeout value which is a little larger than the time to capture these 1000 samples, when the pattern stopped, fetch will error out whenever there are less than 1000 samples and you can just disregard the lesser than 1000 samples, instead of fetching every single pending sample.
I would consider this analogous to using a hand soap dispenser, when you don't get any soap out of the pump, you assume it is empty, typically you don't try to extract even the last drop from the soap dispenser.
Maybe your application is very specific, it would be good to explain why you need to extract even the last available sample.
09-23-2021 08:41 AM
Here is a streaming example - https://forums.ni.com/t5/Example-Code/PXIe-6570-1-Capture-Memory-Streaming-LabVIEW-Example/ta-p/3869...
It uses the same error concept to determine the number of samples available, interestingly they parse the error description to extract the available samples, not sure if this has changed in the new driver releases.
09-23-2021 08:56 AM
Thanks, I saw that example before I posted my question. I noticed that they explicitly passed in the number of samples to read which didn't give me much hope. I didn't investigate far enough to see where they were parsing the errors to determine how many they actually got. The error message I got (which I posted earlier) when trying to read too many does not indicate how many were there, so I doubt this would parse anything useful -- the message has probably changed.
09-23-2021 09:32 AM
In my experience with 657x, always the samples to capture are pre-determined and even in the worst case, I can still run the pattern longer than required and discard samples at the end.
09-24-2021 03:04 PM
Sorry I could not reply sooner -- as a new forum user, I was limited to how many posts I could create in 24 hours.
Think of it like testing how quickly flash memory wears out as it is repeatedly written. Suppose that I want to fill up a flash chip, read it back to verify data integrity, erase, repeat, etc. In this case, it is important that I be able to read back every single value. And while yes, the pattern will define a particular fixed number of samples, patterns might need to focus on different performance criteria (accelerating wear on a particular page, attempting write-without-erase and reading back, random access, etc.) so it isn't always just a simple linear pass through the chip. Each chip may also have its own capacity (maybe one variant has bits reserved for ECC where another hides them).
For each particular flash chip and test objective, I'd like to be able to create a pattern that takes care of the details. I then want someone else to be able to take my patterns and my LabVIEW program, and be able to go off and run some tests for me without having to know what the pattern is doing. They should be able to just run the program and save the results to a file for me to review.
What I'm trying to avoid is either having the readout take forever because the software can only safely read back one value at a time, or to require the operator to manually enter a sample count that I've pre-calculated for every single pattern, and hope they get it right every time.
I am quite surprised that there isn't any programmatic way to do this. About the only thing I can think to do is to embed the sample count in the pattern itself and have it written to a register that LabVIEW can read. Still, this can easily get out of sync with the rest of the pattern if I make some trivial change.