ShaunR

Hmm. The quick reply seems to screw things up. Here they are again: Websocket demo Examples

Websockets were created to resolve this sort of problem since browsers do not allow incoming connections (websockets create a bi-directional TCPIP connection). Some of what you describe is a little confusing to me since you talk about "discovery" and "polling" but that has little to do with TCPIP since you must know the IP address and labview isn't event driven (so must poll). You can try it and see if websockets do what you need by running the demo on the server and using your browser to .connect ala these examples. When you have installed the Demo on the server, just navigate to the examples website and change the IP address in the example pages for that of your server.

The fix has already been pushed to bitbucket. The others will review it then, if it's acceptable, drjdpowell will fold in any other changes and build a VIP package for the CR (only he can update the CR).

Answered in the Support thread.

Added Path case to "Variant To JSON.vi" and updated example. (See this post) Variant To JSON.vi Example JSON Variant Tools.vi Because the intention is (was?) to remove OpenG dependencies completely...

It's not a complete replacement, though, is it? I think this algo can fail with certain numbers so you'd have to fall-back to the printf and incur the overhead of running two in series. Maybe those numbers cropping up are statistically insignificant though.

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