ShaunR

First point is it looks like it is a 32 bit DLL. Are you using 32 bit LabVIEW? (LabVIEW 64 bit for 64 bit DLL's) If you are using LabVIEW 32 bit for the 32 bit DLL then check all dependencies are available using something like "Dependency Walker". It will tell you what is missing or cannot be found for LabVIEW to load the DLL.

The Russian Reversal

Nope. All structure, no content.

I'm surprised it works at all tbh. The Intialise is in side the while loop but the close is outside. Either move the initialise to outside the loop or the close to the inside. You start to read when there are greater than 0 bytes (1 or more), but you want 23 bytes. Either accumulate bytes as they come in until you have 23 and then decode into the numerics and strings or wait until there are 23 bytes at the serial port (rather than greater than zero) then decode. See how far those changes get you.

How about giving us the ability to define right side terminals (like "Panel Close?") and give us the ability to allow an event case behave like a callback? That'd be a fantastic improvement.

Should they? How about this? I have expected this argument to be made (for events) for a few years now. It would break almost all event structure code if it were changed to be in line with the other structures.

quick straw poll.... What's the difference in behaviour (connected dynamic terminals vs unconnected)?

I'm not really sure what we are arguing about here. I like events as they are (and have said so) and only said that I hope they don't change it the more general view of the LabVIEW API's. If you want me to seethe with indignation about implementations, then talk to me about reading an end of file as an error

It is indeed. But it doesn't have to be They could have decided it should behave like Queue's and an Event Reg merely creates a reference to the internal queue. IMO, Darren's nugget is a side effect of an implementation peculiarity (which you have explained in exquisite detail) rather than a philosophical design - a peculiarity I hope never changes .

Oh I don't know. They could delete the registration queues of any registration that referenced the event that was destroyed - they have to delete the registration queue at some point, right?. Luckily, that hierarchy isn't implemented and hopefully it would be too tiresome to implement. I love LabVIEW events. I rate them alongside Dataflow, sliced bread and putting men on the moon.

I fixed the link. Not sure what happened there.

I don't post on the dark-side but I thought Darren's Occasional Nugget 08/07/2023 was a nugget well worth commenting on over here. I have used this behaviour for a very, very long time. Every time I use it, I always have to convince myself that NI will not "fix the bug" like they did with events and tunnels. I always thought it was an anomaly when compared to the other API's-but a very welcome one which, as Darren rightly says, "this behavior makes event programming more straightforward than other APIs". Darren's example may seem a bit contrived and convoluted so I would like to add a real-world, concrete, practical example which would not work correctly without this behaviour. The example (which is one of many that use this behaviour) relies on the "On Status" event being fired after the the event reference is destroyed in the "Close" function. Actually it is fired twice. Once for "Closing" and once for "Closed". If the event on the structure's queue was not retained and actioned after destruction, then the "Closing" and "Closed" events may never reach the loop - it may not terminate. There would be a high probability that a "Closed" status may not be received and it would be a race between the event structure executing and the "Close". A specific "shutdown" event would have to be added and managed - greatly increasing the diagram complexity. (this one reason why "Tunnels" and "Actor Framework" are so complex). But it gets better. Regardless of the Destroy primitives, all data and status' from the "Get" function, in the executed order, are also maintained independent of the speed of execution of the event structure. This means that when in debugging mode we can see all the events' data and execution even after the Destroy function has been executed in the "Close". As Darren has pointed out, a queue reference would not behave in this way and report "Refnum No Longer Valid" making debugging a much more difficult task.

Try asking on a Python forum. This is a LabVIEW forum.

Uninitialised shift register.

Mine is similar. Bigendian.vi

CBOR isn't a protocol so wouldn't fit with ECL. While there are a couple of encoding schemes like Base58 and Base64, they are one-shot enc/dec functions and not really an API. I think you already know what I'm going to say next. The request would fit better Dr Powell's JSONtext (as you suggest) since it' already has the API and just needs to swap out the parser.

Well. I got a rudimentary CoAP API working (over DTLS). It's a much better protocol than MQTT, IMHO. I'm beginning to run out of protocols to implement.

You need to preserve the width (2chars per byte) otherwise your concatenated is incorrect (you have 4 1/2 bytes represented instead of 5 because of the 0x06 - see also the guy that wanted to insert 0's). This is a common "bug" that occurs in drivers.

I think he's alluding to memory alignment/packing but getting confused with unions.

Tor is a much cheaper solution both in money and resources. Technically, The DNS issue is the IT depts problem. But usually they, all of a sudden, plead ignorance on the topic and can't understand what you are asking for.

Simple, huh? That is a symptom, not the problem. You get that error because if there is a read error (your server shuts down the connection, read timeout or whatever), you still enqueue a message even when there is no data (and you have zero error handling). Wire the error terminal on the "Producer" to the enqueue and it will reveal the real error (probably 66). This will ensure when there is an error, no data is enqueued to the upper loop which should be named the consumer-you have them switched. The TCP read Produces the data and your upper loop Consumes the data.

4.4.0 released with DTLS and Pre-shared Key support. You can try Phase Shift Keying with it but don't contact me for support.