ShaunR

Doh. that's what happens when there are several different VI's with the same name. Should be fine now (and neater).

Done.

I modified AQ's test to include moveblock so we can see. array-typecast-benchmark.vi

Indeed....but! We are looking at a 0.1% case so it's things like this we have to bear in mind. Error messages not being reported. My money is on it being used. You are probably in the 0.00001% of LabVIEW programmers that don't use it.

Without knowing what the problem (error) is with the underlying socket, you are on a hiding to nothing. The fact it is rare and affects other software points to a hardware or OS issue, not your code (except that your code doesn't report an error). That doesn't mean to say other software or the OS isn't responsible for crowbarring the socket underneath you but you need errors to figure out what is happening and what the state of the socket is when it fails. Another technical detail. The LabVIEW Listener uses SO_EXCLUSIVEADDRUSE and assumes it has sole ownership of the socket. It then uses the "Internecine Avoider" to choose ports. If no net address is defined it binds to all network adapters. Does the device have multiple network interfaces? What is the OS?

What's the error?

I'll preface this with "I have never used that software" and I don't know of any standard fixes. I would be putting on my Sherlock Holmes hat and taking a big toke on the Meerschaum. Maybe someone else has a standard fix but this is how I would approach it... First I would check that the new server.key and certificate format is the same as the old one (probably PEM but just could easily be DER). It's easily done just by opening in a text editor. Jibberish is DER. PEM is "-----BEGIN CERTIFICATE----" (maybe this software only supports one format). Same for the private key - which would be gibberish or something like "-----BEGIN RSA PRIVATE KEY-----". Then I'd create a self-signed certicate and load that with it's key to see if the software had the same complaint. Then I would be taking a closer look at the new certificate and the old one and see what's different about the new one - paying particular attention to the type of Public Key, the Key Extensions and the signing method. (if there is no TLS Webserver Then I would check that the public key of my private key matches that in the certificate. The above would mainly be to verify that the certificate is indeed for the key I think it is for, and that the private key is the same/similar type to that which was used previously. If they are not the same type then I would generate a self signed certificate with the new type and see if I again get the error. Note that this is before we get to what the CA has done so buckle up or use some other software Here is googles cert and what I'd be looking at on the first pass.

Start here and then Google specifics. Good luck Generally though, you choose a licence and then mark the software as being covered by that licence (about box, licence file, etc) . Commercial offerings a bit harder though since you need to stop people using it if they have not bought a licence. Two ways you can look at it. A single piece of software that the user can choose from multiple licences (hard) or multiple, discrete, pieces of software have their own licence (easy). Non commercial is easy-just distribute a licence with the product. Commercial is harder-you need to cripple the software somehow when distributed and only become fully featured after a licence is purchased. You can either go it alone (web page and download) or via NI who have a couple of options. You would need to contact NI since they recently changed their sales model so I don't know what they are offering now, Depends on the licence-there are many. Not that I'm aware of. VIPM is an installer and distribution platform. If it's a commercial product then you will also need to look into the Third Party Licensing and Activation toolkit If you want a completely managed sales solution then speak with NI.

In PEM format?

Hang on. That error seems to be saying it requires the private key. The certificate from the CA is a signed version of that private key's public key. Is that "server_0.key" the private key that you used to generate the Certificate Signing Request (CSR) for the CA?

Yes. But was it in the same location? "National Instruments" has a space in it. Try it in a short path without any spaces like c:\tmp. Try the simple stuff first.

It's not something silly like it can't handle spaces in the path, is it?

Well. LabVIEW 2022 is shipped with OpenSSL 1.0.2u 20 Dec 2019 so don't get your hopes up. That said; if it's an RSA or EC certificate you should be fine. I would be looking at other issues especially as there was no Alert complaining about the certificate or ciphers.

Is there no "Alert" before the RST?

All of the synchronisation primitives use occurrences under the hood. Occurrences are the most efficient but hardest to use since they don't carry any data. On a side note (and people will hate/flame/badger me for this). If you have a write one and read many architecture then the most efficient for task switching is a global variable (but memory suffers).

It's been a very long time since I did any real-time stuff but If I'm reading your charts right... The Linux nisysapi-mDNS is a bottleneck? Is that due to your code looking up addresses or an artifact of the system in general? I also noticed the variable publisher in your first image. Are you using network variables?

The hardest to figure out will be booleans which in JSON can be true, false or NULL. While you can get away with converting null to NAN for output to LabVIEW, be aware that NAN is specifically excluded for encoding as a numeric. RFC4627 section 2.4

Kawaii?

Then you might want to take a look at Express VI's. There is an Express palette where many of the acquisition and signal analysis fundamental uses are available so that you can see how they operate. You would be able to create create VI's that operate like your marketing guys portray. The user could then configure each node in a pop-up design-time dialogue. Express VI's are for novice users and those that have minimal programming expertise who you seem to be targeting.

Is that some marketing guy's idea of what it would probably look like to use or do you actually have that interface?

Oooh. Scary. Perhaps I should stop using LabVIEW 2009 and get a subscription? Your budgetary arguments to management have no power here

You know NXG has been discontinued, right? Then Bitman is what you want. The native LabVIEW image tools can be very cumbersome but Vugies toolkit allows layering, advanced processing and filtering (if you want to try it) Then you are almost there by the sounds of it. As I have said in many other threads, I have dispensed with LabVIEW UI's completely in favour of HTML/Javascript. I use a proper web browser (not the LabVIEW UI or embedded browser widget) and use LabVIEW as a back-end linked with websockets.

Oooh. Is that NXG? I don't think there is a lot off-the-shelf. You can interface to GIMP via TCP or ImageMagick as command line but that's probably just as much hassle as writing a simple one of your own and probably too restrictive except for the standard things of cropping and resizing for on-the-fly. It looks like you use ROI's so maybe the NI Vision toolkit would be the best option (if it works with NXG) By the looks of it, you don't really have that much functionality to implement. I, personally, would bite the bullet and implement it either as LabVIEW code (probably using Vision Toolkit or Bitman) or as HTML/Javascript (there are quite a few Canvas drawing API's and toolkits). For .NET there is also a few examples for simple editors and drawing on Winforms. You could call the same functions from LabVIEW nodes to draw on an image control in the FP .NET container. All of that is not what you really want to hear though. If you listed the requirements for your image editor, you may get really lucky and someone might write one just for giggles. But it's unlikely to be in .NET unless they are really a glutton for punishment as few of us use it.

It's a skill we are born with over here. Along with back-handed compliments and damning with faint praise.