ShaunR

Looks great. I get the following error when trying to download the free version (after entering details).

Wrong. Your specification actually states: TDMS is not a "fully featured" database system. None of this is "easy" in LabVIEW. 1. LabVIEW doesn't support QR codes. There are some threads on this forum for some 3rd party solutions 2. You will not find an "off the shelf" solution as this is a specific requirement that many would outsource - you will have to write it.. 3. If you have the Database Connectivity Toolkit - use that (you probably do as you are a student). 4. If you don't have the Database Connectivity Toolkit - use SQLite. 5. You will have to learn SQL.

Check the VI Server: TCP/IP Access permissions.

Just to expand.......... TDMs is a flat-file database. Basically a data table with a look-up table (by name, index etc) with no relationship between entries .MySQL, Postgres, SQLite et. al. are relational databases. A simple way to decide which is preferable for your requirements is to think about what questions you want to ask of the DB. : If you just need to look up data based on a single criteria, e.g. channel names. Then TDMS.. If you need to ask "open" questions such as "How many", "What has" or "When did". Then relational database.

I think the only person that could help is probably AQ. It's been known for some time that LVOOP takes a long time to compile (I have commented before to those that think hours to compile is acceptable). However. I actively avoid LVOOP so my experience is limited for applications. Some might say I have softened a little since I do on occasion use it for trivial APIs to save connectors. The kind of advice I would proffer would involve converting to classical LabVIEW. I expect that isn't an option for you, though, if your whole architecture is OO.. There was some discussion a while back about mutation history getting very large and bogging down load times. Daklu was moaning about it; I believe. You might try and find it on this forum (I couldn't after a cursory look) and try experimenting with deleting the mutation history (see the conclusion and make sure you have backed everything up) for a class or two and see if things improve. But that's just a wild stab in the dark.

They have identical issues to removing diagrams from VIs. i.e. not cross platform or cross CPU arch.For most developers that create tool-kits, utilities or reusable components that are distributed to other devs; they are not a good choice. If you only have one product and only ever use one OS of a single bitness and that will always be the case then that's fine. - welcome to Labviews version of DLL hell I personally avoid them like the plague-little upside, huge downside. A LLB is superior IMO. However. In your case. I can't help but feel the only reason you are considering them is through desperation - to cure the symptom of a much deeper problem.

You already have the code-it is shipped with LabVIEW

I've never used "Data Finder" but I just load csv files into a SQLite DB. The SQLite API for LabVIEW has a VI to do this for you, but you can do it yourself and once in there, it just boils down to how you want to view the info using queries.

Yes. See the "Noise Statistics.vi" or "Probability Density Function Estimation.vi" in the LabVIEW example Finder.

Search the labview examples for "Histogram"

Just a bit slow, that's all

Crypto-G Project Probe Windows API

Sounds to me like Dispatcher.

You could create a VI to service requests and set the VI priority that services your TCPIP to "real-time" to see if that helps. I'm skeptical that it does much re: the OS, but it may be effective within the labview environment.

From my point of view. It's no better and a little bit worse than the hierarchy window since it hides "depth". What I would really like to see is a 3D version of the hierarchy a bit like the firefox "layers" (we could zoom in and out then,too )

Actually. Looking closer. My initial "thought" was wrong. Event registrations aren't equivalent to "Dequeue" (i.e. destroy the element) since you get multiple elements in multiple Event Structures. So if your "semantic awesomeness" is advocating they do behave as I described. Then we are in agreement.

Your in danger here of becoming an architecture astronought. So. Breaking it down. OK. Lets changed make a little change here. -- the event enqueuer and the event dequeuer of that Event Registrations queue. Lets not get confused by extra abstraction layers. So you are 1/2 right. Queues do access a single object. But so do events which have access to their own queue which just happens to get populated indirectly rather than directly by the enqueuer. Not really. You can only have one dequeue as dequeue destroys the element (readers and dequeue confusion here) and sure you can "peek" the queue, but that does not destroy the element. So having "multiple dequeuers pulling out of the same queue" is unpredictable and results in unwanted behaviour on the most part. In fact. It is a common bug by rookies. This is encapsulated by the axiom that queues are "many-to-one" and if you keep to that, you will be fine.. Why is that? Is it because the Event Registration primitive is, in fact, the symantics for a unique queue? If you do add multiple handlers, do you not end up with the problem I described previously about multiple dequeuers? I would say they have exactly the same semantics as Queues.(just different primitives) and you can only have one outbound (aka dequeue) at any one time. The difference arises from the way the Registration Queue is populated. Of course we can. Come back down to the troposphere for a second. A fairly good approximation for Events in LabVIEW are a queue (lets call it "event queue") to a number of queues (lets call them the "handler_queues") where "event_queue" re-transmits the enqueued element to the other queues before being destroyed. In this approximation, we need a VI that adds a queue reference to the "event queue" and registers a unique ID for a "handler_queue" so that when an element is enqueued to the "event_queue" it copies the element onto each registered handler_queue (iterates through all handler_queue0-N). Each handler_queue (just the usual while loop, dequeue element and a case structure), is waiting and dequeues from its respective queue. So we can create event-like behaviour using queues, but have to do a lot more programming to realise it. So we have one (event_queue) - to - many (handler_queues). This is essentially the Event system in LabVIEW. We do exactly this all the time with TCPIP servers where events would be a much better solution but, sadly, lacking. I will counter argue that if you are trying to use queues for anything other than many-to-one (one-to-one being one of the intersection edge cases I mentioned in my previous post); use something else. I have already outlined how you can use queues for event-like behaviour. But whats the point when it is handled by the language for you in Events? Just because you can, doesn't mean you should - the right tool for the job. Many-to-many: Only practically relisable with architecture. One-to-many: Events. Notifiers. One-to-one: Anything you like, (Queues, Events, Notifiers, FP terminals, Globals et. al). Many-to-one: Queues. As I have said already. They behave exactly like queues which is why you cannot have multiple dequeuers (Event Handler Structures) attached to the same registration just as you cannot have multiple dequeuers for a queue without unpredictable and unwanted results. I think the issue here is confusion between reading (aka peek) and dequeueing which has been lost as you've gone further up the abstraction thought process. The destruction of the element is a key attribute of queues and once omitted you need other mechanisms to either filter or remove elements.The difference between the events and queues isn't how they are consumed (events uses queues too). It is how they are populated and this gives rise to the ability to create "one-to-many" (events) from multiple "many-to-one" (queues),all wrapped up in a nice, neat package.

Whilst there is an intersection of edge cases They are not synonymous. Queues are many-to-one. Events are one-to-many.

Prepare to be shouted at

Interesting. Wouldn't work in the UK as software is considered the same a literary work. So the analogy would be like writing a book or chapters with the same title (but titles, slogans and phrases are un-copyrightable in UK law - this seems to be how the judge in this case sees it). Of course, they could trademark all the function names Then everyone would be stuffed.

Until you've lost it forever then realise, "bugger!". AQ hasn't stated what the "return" is. It could be that it just removes some part of an internal document that someone doesn't like.. Until I know why it is being considered and what the gain is. (and the caveats), my default position is "anti" as I am with any removal of working features without good reason - especially if they have been around for many years.

I've only read the white-paper, but I think this is a new slant on a very old idea. In the prehistoric days,(before events and queues) we used to use "Data-pools". We'd have a 2D array global variable as a main repository of all data values and any part of the application could read from it. It was very flexible and very fast and it enabled on-the-fly configuration and was great for debugging. Of course, it had one caveat. - write races. For single writers, multiple readers it was great, but for multiple writers it had issues.. For UI updates it didn't matter as all indicators would only read. For controls it also wasn't too much of a problem since you just have 2x2D arrays. One for controls and one for indicators and it was impossible for the user to click 2 buttons fast enough to overwrite. But you could only have one writer updating the read array asynchronously. The next "innovation" (I call it that loosely) to address this was more 2D arrays. One for each writer and a mapping system to map the indicators to the global arrays. As long as the naming remained the same from project-to-project; this worked fine and was reusable. This however had the downside of fixing the implementation. So people would put, say, 10x2D arrays into the global even if they weren't all used since it was rare to have more than 10 asynchronous process. As you increased the number of arrays, things obviously got slower as the execution time is dependent on the size of the global and the data it contains Then. Since most projects are of a similar nature within a company, People used multiple globals of one 2D array and called them things like AI AO, DI, DO. When Queues, events and the like came along, they were abandoned since the new technology required less maintenance and were less rigid.. Looking at your LV2 global storage. It doesn't seem to address the multiple writers (READ/WITE, SET/GET is just as bad as a global, but a lot slower) but apart from that, I think it looks very much like the "Data Pool" idea with LV2 globals instead of real globals. Am I missing something sneaky?

I'm surprised people still bother with it. I did have a quick look around since you linked to it and it seems this years fruit are so low hanging they'd be classified as tubers.

I can do without extra event structures as long as we get an event structure that we can wire TCPIP,UDP, Bluetooth and VISA refnums to.

Especially as he marked his answer as Best Answer" to his own question. Now. Where are all my posts .