ShaunR

You can use TCP for MySQL but for SQL Server I don't know of any non ODBC LabVIEW solution since the backend protocol is proprietry. What you can do is install the SQL Server command line tools for Linux then use the LabVIEW Exec VI to execute "sqlcmd".

Indeed. But I was asking who is the maintainer? Who is it that vets the code, makes the OpenG package for VIPM then uploads it to the Tools Network? How does the VIPM OpenG package get up issued with Rolfs (or anyone elses) code? It used to be JGCode but he went a long time ago.

Who would that be? The maintainer used to be JGCode but when Rolf wanted to update his Zip library, he was pretty much left to do it himself and make a spur. Who is the maintainer of the distribution and where are contributors expected to go with updates?

I looked at it briefly a while ago and came to the conclusion that it is really a stateful HTTP protocol framework. The underlying cryptographics are very simple (in 2.0) but there are a lot of HTTP states that are different for each method (6 methods in total with varying privlieges, IIRC). So you have to identify which method is being used then have an application go through the the appropriate HTTP process with various redirects. This means that a complete LabVIEW library could be quite unweildy and confusing rather than just using basic HTTP GET/POST in an application to achieve the one instance you are interested in-especially as you may have to use another 3rd party JSON library for responses as the NI one is useless. It's not difficult to create the HTTP messages, it's just the process logic is cumbersome. You can get away with a couple of HTTP POSTS and string stripping if you want quick and dirty but for proper and secure, you need the full stateful operation.

To add to this. This document states that the maximum throughput of the bus is dependent on the number of links, each being 250MB. So a 16x slot shoud be capable of about 4GB/s. However it goes on to state that this is not the limiting factor for most NI products.

IMO. For the API he has the cost and benefits reversed. The interface is the benefit. The hidden functionality to achieve the interface is the cost.

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.