infinitenothing

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

I believe what you described is extrapolation and I think you've under defined your system (or you actually want 1d interpolation). What would points (1,2 and 2,1) correspond to? It's not totally clear how you would want to determine that 0.5,0.5 corresponds to 0.5. A naive approach would be to use the slopes of 1,1 to 1,2 and from 1,1 to 2,1.

I don't quite recognize that node. It looks a bit like a delay node. Regarding the transfer function, you can always use something like the central difference to approximate the derivative and simpson's rule to approximate an integral. Once you have those, you can take the derivative of the derivative to get the higher order derivatives and so forth. Here's an example using slightly simpler approximations:

You have the right idea. You can add the DLL to your exe build spec instead of your installer though.