ShaunR

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 .

Well. If datasocket isn't quite doing what you need. Perhaps try network streams? They have a property node whereby you can retrieve the datatype of the endpoint. I've never used them, as I have Dispatcher, but from what I can tell they can operate in a number of configurations (one to one, one to many etc).

Change you SQL query control to "" codes display by right clicking on the control and selecting it.

Nope. Shows up with a big letter A for me denoting a string.

Hang on. I missed this in your first post. Are you sending control refs? Control refs are integers and have no meaning outside of the application instance (they are basically pointers, but not quite). Have you tried,using the Variant To Flattened String. That will give you the type info that you can send and examine the other side. No messaging system can help you with that. It is a serialization issue.

I think you misunderstood. I didn't proffer it as a solution. It was a retort to Yairs dig at me and classes (a kind of in-joke). You should instead take a look at the Dispatcher (that I highlighted in a previous post) which is very similar to your requirement, but native labview.

Ssshhhhh. Don't look closely at the MDI toolkit either

Transport.lvlib is just a protocol leveler (it just means that you can send data via UDP, TCP, Bluetooth etc transparently). Dispatcher, however, is a Pub/Sub implementation that uses Transport.lvlib and is probably closer to what you are looking for. Woohoo. Links are working again!

It's interesting that they use a length header which is the same as the transport.lvlib so they could be compatible (or at least made to be compatible-transport.lvlib has a compression and encryption byte). I don't think it really brings that much to the table over native labview implementations. From my cursory look. Pub/sub seems to be it's main "killer" property and there are native labview implementations which are safer and x-platform, This is probably the reason for NIs lack of enthusiasm. I'm not being dismissive, I think I just need to spend more time looking at it and maybe something will jump out as being an advantage. for my use cases - there has to be a really, really good reason to rely on 3rd party compiled binaries. I think the library could be improved by allowing binding to the labVIEW event system (a big bugbear of mine with VISA).If an intermediate binary is used, (as it is in this case) then adding events so that developers can hook into the event structure is trivial (even more so than in native labVIEW). I find event driven asynchronous comms, vastly superior to the normal methods ( )..I had a few issues with the library but I don't think they are insurmountable. I kept getting an error (too many sockets) and pressing abort in LV x64 causes it to hang (on the Multi example, without a stop button). But the person who wrote the wrapper seems eu fait with binding to labview, so I expect the latter will get worked out.

Indeed. Mobile dynamic display of graphical data is constrained and very browser dependent. Firefox especially seems to be very resource intensive since for something like the following demo which is using 2 channels @ 100 ms each; most mobile browsers can cope, but Firefox glitches often http://37.235.49.79/example_gauges.html However, the following demo chokes all mobile browsers as there are a lot of graphics to update and there are 4 channels @ 100ms each and one channel @ 1sec.. Additionally, the datapoint stack for the graphs is in the browser (the server is sending single datapoints) with each line having a history length of 100 datapoints once the graphs start scrolling. http://37.235.49.79/example_dash.html If you turn off the graphs then even Firefox can keep up, so the data rate and number of channels isn't the restriction. It's the graphical rendering that brings mobile devices to their knees. The demos aren't doing anything special though (like your matrix of data). The server is just spewing data out and the javascript redraws happen when each piece of data arrives. Desktops can cope with the redraw rate, but mobile devices can't.

I agree. The only purpose of an enum is to code improve readability. Granted LV takes it one step further by linking to case statements. But again. The benefit is readability.If you want a run-time extensible numeric type, use a ring.

I'm also a very visual person (hence my preference for LabVIEW). Combine what you are saying with Taguchi analysis and it takes a lot of the intuition out of it. https://controls.engin.umich.edu/wiki/index.php/Design_of_experiments_via_taguchi_methods:_orthogonal_arrays Damn. What is it with links?

Well. My 2p. It's the best since 2009, but there have been some real dogs (yes 2010, I'm looking at you).