infinitenothing

In my experience SQLite will be much slower than TDMS. My recommendation is to reshape whatever array you have into a 1D array and then that can be your waveform. Store the image dimensions in metadata. Indexing is not challenging. You can get the the waveform size out of the channel properties (NI_ChannelLength) and divide that by how many pixels are in each image to get how many images are in your TDMS. You can pull out a given image index by multiplying the image index by the image pixel count and feeding that into the offset input for TDMS read and using the pixel count for the count input. Everything takes in i64s so you don't have to worry about large indexes. You just reshape the 1D array the read.

The analog input nodes won't be able to compile in a SCTL regardless of the rate you set. On the inside of the AI node, they need multiple cycles for the low level communication to the ADC chips. Like crossrulz says, the limiting factor is that chip. OP might be able to hit their target with an NI-9223. https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Km2SAE&l=en-US

In the COVID supply chain shake up, we saw some of the dangers of being so dependent and locked into NI and the blackbox that is LabVIEW so we're trying to do more custom design on our own. I've been doing some cool stuff with Python and Verilog. One of my co-workers is doing more with micro-controllers.

Yes, as a general rule, it is fairly unusual to stick an equal sign on a floating point number. This applies to most programming languages, not just LabVIEW. So, I would never stick an equals zero on the output of std dev but I have once or twice broken the rule like this:

The problem is that some day the customer will buy a new Apple laptop and that new laptop will not support LV2023. We need maintenance releases of LabVIEW RTE to keep it all working.

Most customers use Windows and that is the primary target. We want to support all our customers though.

There's a PXI based hardware system that generates TDMS data logs and the project is a viewer/analysis tool for those data logs.

I was about to build an executable for a OS X customer when I noticed that it won't be possible for much longer: https://www.ni.com/en/support/documentation/compatibility/18/labview-and-macos-compatibility.html This surprised me because I know the founders were hard core mac enthusiasts and also because usually large companies will put something like this on their road maps so that people can plan better.

You want to read out what voltage? How does RS232 fit into any of this? Why not go directly to I2C, which should be a more common interface?

Option 1: Find your 2 nearest W points (minimum Euclidian distance) Find where on the line between those two W points that's perpendicular to your unknown point Use 1D interpolation between the two W points to estimate the W point's value. Option 2: Because W1,W2, and W3 are not colinear, you can define a surface between them. The approach would be somewhat similar to the above: Find the 3 nearest points and use them to define a surface. Find the cross product of the two vectors give you a normal to the surface Find the cross product of the normal and your unknown point. That should give the point on the surface that corresponds to your unknown point. Based on what you drew (your points were nearly colinear), I expect the second method to be very sensitive to noise and thus somewhat unstable and inferior to method 1.

Yes, I think that should work fine for positive numbers. It's probably less efficient than my method though.

It's the same as 1D interpolation except you repeat it a few times. So, if you have data at 0,0 0,1 1,0 and at 1,1 and you wanted to get (0.7,0.3), you could start with finding the values at 0.7,0 0.7,1 and then interpolate between those two values. https://en.wikipedia.org/wiki/Bilinear_interpolation (see repeated linear interpolation)

That part that's still confusing is that it looks like you have just one independent variable (time). If that's the case, that's just 1D interpolation. Also, your time vs x and your time vs C look like it has one slope so potentially, that's even more simple in that it's just a simple Y=m*X+b calculation. Also, it's not clear how much of this is calculable offline (no real time required). Also, your original example used extrapolation and it's not clear if that's a requirement.

No, that probably doesn't work how you expect for negative numbers. Fortunately, for fixed point numbers, the decimals are just the least significant bits. The cool thing about that approach is that the code is just a wiring operation and thus uses ~0 resources and 0 time to calculate.

Can you post your example? 300-400 points per second should be no problem at all and quite fast