ShaunR

That is the old way. The EVP_Digest interface abstracts away the different hashes into unified set of functions. All that is needed is a while loop where they have two update functions in the example about 2/3rds of the way down in that link..

As I explained. The code I used is part of ECL so commercial IP prevents me from sharing. You should know or at least appreciate this! Correct. New, Init, update, final and free (the EVP interface). You will also need digestbyname. Once you have this you will also be able to do *all* the hashes, not just MD5.

I have a different solution... .. which is demonstrably an improvement. You can lead a horse to water but, this time, I guess I underestimated it's thirstiness.

Sorry. No can do. It's part of ECL but I've given you all the info to replicate it and proved it might be worth your while

This is fun Here are my comparative benchmark results for MD5 the NI SHA are abysmal.

Yuck. Cmd line Try using the EVP_Digest interface of the NIlibeay32.dll You can even have progress events if you want to be fancy I don't know why NI didn't use it

That's BS. MD5 is still the 2nd fastest checksum (SHA-1 being the fastest) and a checksum has little to do with security. They are obviously confused between security and integrity.

Hmmmm. They have removed MD5Checksum from the palette in recent LabVIEW versions?

Well. the output of the python hmac is a byte array and the output of the LV hmac is a hex string so I expect you have to convert the LV hmac output into a byte array before passing it to the encode like this: Generate Signature.vi By the way. None of your sources (message or key) are base64 encoded so you may run into errors when trying to b64decode normal text.

Well. If your key is greater than the block size (64 bytes) then the library you are using will hash it first to make it 64 bytes in length. If you are passing the hex-text representation of the key, it will probably be longer than that so maybe it's being hashed first.

There are some primitives but not easy to get to, so here they are. UTF8 LV80.vi

At a guess I expect it's because you are decoding with UTF-8 in your python. I checked the HMAC library you are using and it produces the correct hashes for test vectors.

Only the Widechar functions support it. The functions are listed at the end of the link I posted.

To use long pathnames you need Registry setting. Use the filename functions ending in W (not A) e.g. CreateFileW instead of CreateFileA. LongPath in the executable manifest. The native LabVIEW functions use the functions ending in A, under the hood, which is why I wrote drop-in replacements for the native file functions which uses the functions ending in W. When you create an executable, you have the option to define a manifest file so the replacements work in the built executable. So as long as the registry or policy enables long paths, the built executables work fine for >260.

Of course there is something they could do. I expect the use of the ANSI versions of the file operations is making them resistant. I've my own set of compane equivalent of the native file operations that do it just fine - it's the Path Control that is the problem.

I'd say it's a bug. If you uncheck the "Lock FP" for the "Do" case it works as expected. Clearly the FP locking is being triggered when it shouldn't. Changing the compiler optimisation has no effect so maybe it's something else. Rather nasty IMO. Congrats for isolating it. Also does it in 2009 so I suspect it's been around for a while.

I can't account for your experience but for this library it is fine.

Windows handles are always 32 bit. It should be fine in 64 bit LabVIEW unless there are pointers in there - but didn't see any.

A.K.A. Not gonna fix so will memory-hole them. Was just looking at the SFTP from the beta link you provided. VI's invoking Command Line? Really? I've had SFTP for ECL for a while now but never put it in because no-one asked for it. I've been procrastinating about putting in SFTP, SCP, Websockets and MQTT for some time but decided I wanted a better HTTP client first (more configurable than the NI one). I've so many new features I could implement and so little feedback about what people would like to see I've only been updating with things I would find useful which, at this point, is very little than it already supplies.

They must be the newbies. Here are the apprentices.

I'm an apprentice, apparently When I finish my apprenticeship, I might be able to write some useful software.

We agree to disagree. Both VI's I supplied answer the question. The first VI you can apply to your existing calibration fiddling whilst the the second VI doesn't require any calibration fiddling. It's up to you.

Are you sure they are redundant? Looks to me like you have two lines - high pressure and low pressure. It's highly unusual to have a cal cert with "redundant" information in it and it would explain why a polynomial fit would be used instead of a linear fit-which would also get rid of your "glitches". I would be contacting the manufacturer for clarification at this point. But you know your devices so maybe I'm wrong. You have two examples of a poly fit so I guess the first VI I posted is where you want to start and incorporate it into all your data fiddling.

Looking more closely at your data snippet. Since the left column has 2 data points very close together (certainly within measurement noise) you could have 2 lines/curves which maybe max/min. You might get that sort of file, for example, if you want to test the linearity of analogue output device with a 110v supply and a 240v supply. You may set an output, measure at 110V then change the supply to 240v and take another measurement before moving on to the next analogue output level. Anyway. the analysis method is the same, you just need to de-interleave to get the two lines/curves and maybe subtract one from the other before doing the poly fit. Later.... Ah yes. Makes more sense now when you said "pairs of rows" and why you want a poly. Polyfit2.vi For some reason the decimate arrays crashes LV so I had to use a while loop.