ShaunR

I wouldn't. HTTPS is just one protocol. I personally use secure websockets which is much better suited to this sort of thing IMO, Most of these use TLS though and more recently I've been playing with DTLS. If I don't use those sorts of protocols then I use SSH but that's nothing to do with what the OP is asking as it doesn't use X.509 certs (which is,as you know, just a standardised certificate format). I think that's just middle-management phrasing. I wouldn't be surprised if the device already supports this method of updating and they were told it uses X.509 certificates "for security". but we diverge..... The main thing to ascertain is whether Certificate Authority certs are required or if self-signed certificates can be used. They both allow "securely writing"; the difference is authenticity. This dictates whether things work out-of-the-box (in the same way as your web-browser works out-of-the-box) or you have to add pub key certs to root bundles. Personally I prefer self-certs for this sort of thing as it provides greater granularity for who can access the device, I don't trust Certificate Authorities, and when IT get a whiff of you requiring company CA certs, they usually try to get involved. It really depends on whether you have control over the server though.

This is quite a common requirement nowadays, especially within the IoT sphere. Many embedded devices come with libraries for what is called OTA (Over The Air). A multitude of devices are then monitored and configured (including software/firmware updates) via a web server. I wouldn't be surprised if the NI Systemlink uses something similar (via either HTTPS or MQTT). TLS is quite burdensome for constrained devices, specially if you have to put a webserver on the device to upload rather than using OTA libraries. To be honest. This isn't something I would use LabVIEW for. There are much better solutions available specifically for this purpose.

You will have to re-architect that if you want to.... By the way. The TCPIP I described earlier is a layer to break cohesion - meaning that the VI's can be controlled by anything, in any language, including Test Stand. So if you want the "on demand" aspect, then that is probably the easiest way forward.

Another thing I did with the aforementioned was to add TCPIP (a later version). It meant you could launch a VI and then communicate with it via strings sent from Test stand - even on remote machines. The wrapper was only slightly more complex than the pure launcher but it meant you could configure the devices on-the-fly, abort or reset devices and query state information with simple strings from Test Stand (I used SCPI-like commands). Anyway. I diverge. You've probably guessed by now that the choice you had was to have an instance per device which you control and sequence from TS, which is what I was describing, or an application that does it and reports back to TS, which is what you are designing. The others have given you options for the latter and I was just giving you a method for the former.

A very complicated reporting tool. Some things are better for scripting/sequencing than others. Take the step response of an oven, for example. You need to step change the setpoint (SP) and monitor the temperature until a certain value has been achieved as it changes and note the time taken. To determine whether it has finished it's step, you detect the plateau in rate of change. In an application this is trivial and the test time is the time it takes to achieve get within +-% for n secs of SP or when dtemp/dt < x for n points (depends on specification). It is usually also monitored to determine whether it overshot before it got there (which may be a fail). In Test Stand it is orders of magnitude more complicated to achieve the same process and you will probably try to wait x amount of time and hope that the temperature is achieved. However. You will miss the overshoot and that's not the test anyway. So you will write some software to do the state monitoring and calculate the rate of change and, now, you are using Test Stand just as a reporting tool. Test Stand is good for "stateless", pass/fail testing and suffers the same problems as any other scripting/sequencing environment when state and/or continuous monitoring is introduced. It may be that it has served you faithfully for the most part in your testing but it is not a test panacea which, I think, is why you are asking the question.

The trivial answer is the launcher can be run re-entrant so you can run it from multiple scripts with different configurations etc But what you are trying to achieve, from your description, is a poor fit for Test Stand, period. So I expect there will be other things that that perhaps you haven't mentioned (like the background tasks) that will make it difficult to use from Test Stand regardless of the solution. It sounds like you really need an entire application rather than a simple Test Stand integration.

What about VIRefPrepNativeCall and VIRefFinishNativeCall? They sound interesting but maybe a red herring.

I wrote a simple "connector" for test stand a few years ago. It was just a VI launcher which had a standard calling convention (from Test Stand for configuration of the called VI) and a standard output back to Test Stand. It would call any VI with the appropriate FP connectors, dynamically, with parameters supplied from Test Stand. You could call any VI's (DVM, Frequency generators etc) which were wrapped in a normalising VI which created a standard interface for the launcher to call and formatted data to the standard format to be returned. All configuration, reporting and execution was in Test Stand. It took about 5 mins to write the launcher and about 5 mins to write a wrapper VI for each device. The caveat here is that there was already a device VI to wrap. This a similar technique to VI Package Manager which runs the pre and post install VI's.

hmmmm.

This is sweet. I think we can use this information to create LabVIEW callbacks for C/C++ functions like we do with .NET.

SQLite does not support concurrent writes.

That's because it is, to all intents and purposes, an internal restructuring (possibly a political one) and the outward effects aren't tangible or possibly even unknown.

this is a little ambiguous. Header Type Length Report ID Data Check Sum...Makes sense if you put commas in the right place Header Type, Length, Report ID, Data, Check Sum. If that was the case then a msg with no data would be something like 7E 03 02 18 9B Is this your interpretation or is it stated as such? Usually a checksum is a CRC. if it is a CRC-8 (there are a number of 1 byte CRCs) then the last value would be 0x29 rather than 0x9B, for example.

I haven't seen that error message for years. If I run a debugger, LabVIEW just dies and the debugger reports an error in the LabVIEw exe. This has been the same through Windows 7-10 on the various machines I've had over the years. Maybe the difference when debugging is because I use the the gdb debugger but the sudden disappearance is consistent; not only on my machines but customers' too.

No need. I will explore this. From experience; a misconfigured CLFN usually results in LabVIEW disappearing without a whimper (either immediately or at some random moment) so i don't see much of a reason to have error checking and wrappers enabled at all. Especially if there is a performance benfit, no matter how minute. It doesn't seem to have a scripting counterpart. Is that correct, or have I just missed it? Is the setting sticky, or does distributed source code require the INI setting too?

Interesting. How does this feature compare with disabling the error checking on the Error Checking tab?

Oh. Sorry. Missed that bit. That's a different kettle of kippers then.

it clearly states that LV 2015 isn't supported and says to forward save it to 2017. It's not really a useful test for it's conversion capabilities.

Your argument is inconsistent. If it's not a priority then making a change to remove it is allocating resource to "the least important". Leaving it in would be the least impactful. However. If you are going to change it then you might as well make it a "Preference" since that is clearly what it is. You don't seem to have a preference or, at least, are indifferent. So why advocate taking away a feature that other people obviously feel strongly about?

Just make it an ini/preference setting. The main tenor of that thread seems to be "I'm not very precise so please remove it" which, from that low point, then devolves into "my work-flow is better than your work-flow".

I've never used the toolkit; I'm just aware of it. I don't know of the limitations or capabilities outside of that page. I would suggest sending them an email explaining what you plan to do and they should be able to tell you.

150 samples @ 50ms is about 24K/s if the samples are double precision. The default TCPIP buffer in Windows is 8K IIRC and if NAGLE is on, you maybe filling the buffer too quickly. I would try U8, if you are currently using doubles, to reduce the data amount and see if the problem perists. If it resolves it, then I would try turning off NAGLE and increasing the buffer to 65K to use doubles again.

How about the Arduino™ Compatible Compiler for LabVIEW

There is a LabVIEW RIO Evaluation Kit which is a fraction of the cost (has FPGA on board). Alternatively you could use the Arduino with Websockets or HTTP and use LabVIEW to communicate with it. There is also an Arduino toolkit, IIRC.

You have to be logged in to see the SQLite software. The main performance criteria for SQLite is the number of rows and/or columns returned/inserted, although there have been significant improvements in recent versions (~15% over 5 years). If you look at the performance graphs, you will see that 0.6 seconds equates to about 450k rows (with 2 columns). The performance test in the Sqlite API for LabVIEW library is based on 10k rows so that you can get repeatable figures and that typically yields 10s of milliseconds. Less than that, and LabVIEW timings become dominant for the purpose of that test. If you are dumping entire tables and performance is a requirement, then a relational database is the wrong tool.