ShaunR

When the compiler doesn't care, why should I? The view I take is that "Style Guides" are just that. GUIDES, not LAWS. If "boolean" was chosen, what do you do about capitalisation at the beginning of a sentence? There are arguments for grammatical considerations but I'm "meh" when it comes to programming type names, classes at. al. These things are just a distraction - form over function. Read it and weep:

This is a historical "problem" due to compilers being case sensitive. This was one of the reasons that I went for Pascal compilers over C since Object/Open/Turbo Pascal is case insensitive and boolean or Boolean are synonymous (as a type). I've always maintained that there is no excuse for case sensitvity as it only introduces errors, obfusicates and increases foot-shooting but has zero benefits (unless you consider obfusication a benefit which is arguably a security risk). I've had many conversations with C/C++ programmers over capitalisation of types and function names (initial caps vs camel case vs lower case etc) and my response has always been "whatever". Do we really need to bring this problem to a wiki, of all things, about a language in which case is irrelevant?

SOAP also defines a specific "message" pattern. These are all product specific

I can't substitute terms because you defined a specific architecture as the generic "message" - with which I disagree. OP: Just for fun and giggles. Turn on "Synchronous Display" on the indicators.

I disagree with this characterisation. The losslessness is not a citeria for being a message-based system or not - nor is central handling. Put simply. Messages are just descriptors with or without data and a "tag" is just a message without data.

Transmittion of data at a rate (Hz) is not very conducive for ethernet. It is intended to move large amounts of data efficiently. Typically, ethernet connections use the nagle algorythm where data is transmitted after the accumulation of a certain number of bytes or after a timeout (typically 250ms). This is to solve the issue of small data packets flooding the connection (which is what happens at high rates with, say, a single double in the packet) If the nagle is turned off, then packet overhead comes into play and the network can start to behave irratically at high data rates. This is where ethercat comes into it's own. At least one week if you don't already have a solution in your toolkit.

One aspect of reflective memory architectures is determinism. For that reason and without a full detailed spec, I would err on a reflective memory network solution (option 1). You may have to start looking at ethercat and synchronising asynchronous systems depending on the reasoning for the insistance of the reflective memory in the first device since you get that for free with a reflective memory network.

I'd be interested to see a comparison with SQLite (Altenbach didn't post his code). Those times seem really slow for the number of entries.

xControls are at timestamp 1:01:51

In todays censorious climate (and YT copyright trolls). The trend seems to be to use Bitchute as an alternative backup.

As everyone else is suggesting. Simulators are non-trivial and product specific. You pretty much end up reverse engineering the software in the device you are simulating. One method I have used in the past though is message capture. This works with TCPIP, serial and other similar devices. Basically you capture/record the message strings for specific control messages and play them back to your software-usually used for testing. If your software architecture is message based, then it's trivial to switch out the endpoint just by redirecting to the comms interface instead of a play-back VI and you don't suffer from the "bug in simulator vs bug in device" problem.

That's unfortunate as I've just released one xControl and am about to release another

Nope. You may want to extend that courtesy but it isn't required for BSD.

Perhaps this makes it clearer. What you are doing: What you want to do:

The FP control is set to "Include Data Type" if the property node is "strict" and will be a boolean output from the property node. You will see a red cross in the bottom left corner of the control in this state. If "Include Data Type" is unchecked, there will be no cross and the output of the node will be a variant as no type information is defined for the control..