ShaunR

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.

Your CLFN's are running in the root loop (that's why they are orange). You really need them to be set to "Run in any thread" but for that, your DLL has to be thread-safe. If it is thread-safe then change it. If not, you are stuck with what you have.

I don't think so. this should be (byte) grouped as 28 D5 00 00 B5 70 that's 6 bytes. I expect the last 4 bytes are the value so the first two (28 D5) are some sort of header. 00 00 B5 70 = 46448 so that seems reasonable. So. doing the same for your arbitrary insert... 28 D5 00 00 (but what about the B?) 05 70. since 722288 = 00 0B 05 70 we have [with our arbitrary insert] 28 D5 00 00 0B 05 70. But that means we how have 7 bytes and have a 3 byte header instead of 2. Adding a 0 arbitrarily is not the solution here. You need to look at how you (the human) are understanding the data from the Arduino again.

Apart from the last one, that's pretty much my normal work-flow.

The problem is that what you described is too plausible - solve the symptom rather than the problem and automate the rigmarole work-arounds we normally go through instead of giving us the language construct that is needed. Look what they (not NI) did with C++ and templates

Great idea. I'd prefer the second one with a slight modification - It has the icon (the bulb in your example) but you double click on it to view the suggestion. The suggestions are only displayed if a button in the toolbar is depressed (like the "Retain wire Value"). Oh. And a cancel/close button in the window.

I respectfully disagree. We should be able to use callbacks for DLL's just like the .NET callback node. However, that isn't an AI solved problem which is why I was laughing.

I expect you could hear Marconi's original transmission with that set-up

HTML Help files (manuals). Documentation is by far the greatest resource hog and we should be able to get away from programmer created VI descriptions. But I don't just mean documenting VI's though. I also mean generating API references, menu layouts, including external references and collating examples with descriptive comments about their function and what they demonstrate (from the code in the diagrams). A far better DLL importer. The one we have currently is next to useless for 80% of DLL's. I'd like an AI that can do what Rolf does . It should be able to import the DLL and create the VI's containing CLFN's for complex structures (e.g strings nested in structures), callbacks (he, he), events and error handling.

So I guess you have a Ham Radio licence? It's exactly what my Ham Radio buddy said.

I was mesmerised by the cheesy forced grin of the guy demonstrating. Why does AI type so slowly? I agree it's looking promising. It's at the level if an intern but actually listens to you. Linear coding is never the final solution. I expect it was tuned for very specific requirements but I was more impressed with it reading the emails and specs and interpreting them in context. Would suffice for Unit Test cases and feasibility prototypes. Looking forward to getting my hands on it.

I was thinking more of not having to support (or make new releases) of my software anymore.

So I can retire in October?

It's all gone a bit quiet on the acquisition front. Was supposed to be concluded in early April but we're nearly in June. Trouble at t' mill?

While I was faffing around with callbacks. I also implemented PSK.

It might be interesting to see what it comes up with for DLL interfacing to LabVIEW (PostLVUserEvent, passing structures to CLFN's etc). On second thoughts. Maybe we don't want to give it any ideas!

SNDCSDLM.dll depends on cvirte.dll. You can check it's deployed on the target machine with Dependency Walker. It's always deployed on development machines so maybe that's the issue. Something easy to check and eliminate.

Are any of the DLL's dependencies (if any) missing on the troublesome PC?

Me neither so I'm stealing that snippet.

What are you queueing? The image array or the U64 reference? (then reading the image in the consumer). You'll need to post your code so we can see what you are doing.

What do you mean "fails"? You are not consuming fast enough?

OK. So I now have a 2D array (2x264 bytes). if the IDX==0; the bytes are copied from the first row to the second and the random bytes in the first row are regenerated. If the verification fails with the random bytes in the first row, it looks in the second row. If that fails then they are hammering the connection and don't deserve to be let in. It means that every 255 client hello's we might have the overhead of an extra SHA1 hash to calculate. We can easily live with that. Any other ideas?