ShaunR

You should speak directly to an NI Application Engineer. I have worked with the PXI racks (PCI backplanes rather than PICe) and they had stipulations that there were slot boundaries so that you could only get the specified throughputs from certain slot configurations due to the backplane bus. They supplied me with with internal documents that detailed performance tests of the different configurations so they should have something similar for PCIe.

I think the main problem is that most people confuse frameworks with architectures. People tend to pick one framework then try to shoe-horn in incompatible features. The obvious one is the difficulty in sequencing actors in the actor framework. It's a concurrent paradigm so is very resistant to sequencing and all sorts of contortions have to be realised to make it useful in certain circumstances. This is why I like SOA. A service can use any of the frameworks that fit the requirement for that service and the system state is external to the services. Many, if not all, of the frameworks embed the system state inside the framework and therfore you run into problems when, for example, you need to sequence concurrent operations (AF) or concurrently execute sequential operations (QMH). Because of that you end up with silly things like "Promises".

I agree totally with this. The use of scripting is, more often than not, used as a copy&paste re-use tool which is the antithesis of re-use.

I use service oriented architectures. Modular, self contained services that can be transplated from one project to another which interact via string messaging APIs (kind of like SCPI). An execution engine (also usually a service) orders and drives the messages which is usually custom for a particular project. If anyone remembers the HAL demo for Vims, it used this architecture with an Event Driven State Machine as the execution engine.

NetDMA was removed [depricated] in Windows 8. NetDMA would definately make a difference but probably not as much as you need (up to about 800MBs) and it requires BIOS support.

That's why you are paid so much. Or if you aren't; you should be.

Well. If you've turned off all the M$ malarky (like QOS and Nagle) and tried the fast path then you are CPU bound. There isn't really a lot to tweak.

He confuses OOD with OOP. Again. OOD.

For windows, you only need to replace the file open with "CreatefileW". That also gives you the long path names. LabVIEW read/write/close are fine after that. I got a popup warning after installation on LabVIEW 2009. Something about a dialogue error cluster being replaced. It was only a warning and made no difference to the operation, though. I'm guessing it is due to back-saving rather than being built in 2009.

His arguments are a bit woolley. There are much better articles about the deficiencies of OOP in general (fat pipes, the view-port problem etc). But all of them are for non-dataflow languages and one of my main arguments is that LVPOOP solves a non-existent problem due to inherent state control. If you want to upset some people, just say that a normal subVI is inheritance by composition There are reams and reams of posts on here (Lavag) somewhere with me arguing about LVPOOP. Nowadays I use it for mainly two reasons. Custom Wires. Session memory. But that's more to do with the implementation in LabVIEW that anything OOPy.

He only wants to "snapshot" rather than streaming images, from what I understand. 15 is theoretically feasable for single images with gigE (1920x1080 @ 12 bits/pixel ~ 3.2 MB per image). I'd use a hardware trigger to make sure they are all triggered simultaneously in spite of congestion. It might take a couple of seconds to get them but the biggest issue I see is that the OP is using Matlab

Raw TCP. Make your application respond to SCPI commands and the other engineer can treat it like any other instrument. Can even be over a network (remote). It's a simple method which is programming language independent and can be added to existing applications without much problem. Also has no additional installation or distribution requirements.

I don't know what the original file was but you are more than welcome to use the mine, if it is similar. Rolling Average.vi

Well done for volunteering I look forward do testing it

Nice. It's screaming out to be made into an xControl, IMO.

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.