mhenz

It was fixed a view days later (f1 or f2 patch). I actually use the f2 patch (version 21.0.1.f2). edit: bug was in 21.0.1.f1 and fixed in 21.0.1.f2

As far as I know, the initial PCRE in LabVIEW in 2021SP1 was a 6.3 or 6.4 version. They updated to a newer version. Named groups with "(?<name>...)" no longer return an error in LabVIEW 2021.

The regex termination is a nice feature, but be carefull with it. Using complicated PCRE expressions can take a longer time. Keep it simple. Then it is faster than processing the data packet with several VISA read calls and parsing the data in labview.

This VI also iterates nicely on precise 500ms intervals, why? Solution: there is a delay behind the case structure:

you can use an XY graph and draw the edge points by yourself. Change the plots to fill base line "-Infinitive" and the plot interpolation to 6. The NXG style graph is not perfect for what you want to do. It allways shows a small line with the color of the first plot at the bottom.

Shame on you 🙂 I did it and I'm still active, even not on the frequencies, but making videos, mounting antennas for the contest, painting the truck, climbing on the mobile tower ... here it goes...

Some ideas: Create an installer including the runtime engine and select only the components you really need. Instead of the .NET for serial communication, you can use the lvserial driver. Basically it is a DLL calling the windows API with a minimal footprint. The labview API is very similar to what you know from VISA.

Has anyone tried to generate a client/server certificate for the NI OPC UA toolkit using the Encryption Compendium? I had no success, but it seems, that it has somethinh to do with incorrect attributes. BTW: The hexadecimal output of the ECL Sign.vi seems to have a final/additional 00h character at the end in the "Signature[HEX]" output. The "Signature[BYTES]" output is correct. The problem is located in RSA.lvlib:RSA_sign.vi, DSA.lvlib:DSA_sign.vi and ECDSA.lvlib:ECDSA_sign.vi. I can correct this, but don't know if this is a bug or a feature 😉

here tested with LabVIEW 18.0.1f4 on windows 10 - no hang or crash and on LabVIEW 20.0.1 the same - no hang and LabVIEW 17.0.1f3 - no hang

I've never done somethig like this. I used the LevenshteinDistance to compare a lot of smaller strings (between 8 and 12 characters long). Because each of the strings was more or less significant, I used an additional factor for each of the strings and finally generated some king of an overall coefficient.

Thanks for the 2019 VIs. I compared the three algorithms. Levenshtein works different. For better comparison, I normalized the value with: 1 - LevenshteinDistance / (Length(a)+Length(b) Dice: Sørensen–Dice coefficient CSC: Compare String Confidence.vi Lev.: Levenshtein

Regarding Levenshtein: Wladimir Levenshtein developed 1995 an algorithm for this. It is called the Levenshtein Distance. Some years ago I developed a VI to calculate the Levenshtein Distance. Here it is (LabVIEW 2016). Can you post your VIs in LV2020 or 2019, please. Levenshtein Distance.vi

LabVIEW also caches DST. That's not funny if you measure some data at 1500 local time in USA (with or without DST), then go to europe (with or without DST and with or without restart of the program). Then load your data and want to see the correkt measurement time in all possible cases.

now in LabVIEW 18 2400 swI Linear Stair MeasV.llb

You created a couple of global variables. This is not thread save. double *Re_zArr, *Im_zArr, *RelErr_Arr, *Re_wArr, *Im_wArr; double complex z, w; int Npts; int i;