Mads

I was asked privately by ShaunR what I disliked/missed about the existing alternatives, and go through the strong/weak points of each of the solutions. To answer the question in part at least (it has been a while since I tested some of these options so I do not want to revisit to do a comparison etc...), I think the best starting point is to draw up two extreme scenarios: Extreme A: No web support in LabVIEW at all. We develop applications that run on a given OS, and the only way to let web browsers view and interact with the applications is if we add a client-server interface to the application, and then use different tools/languages to develop a web client for it. Extreme B: Web server and client side applications are available as build options or defined as "targets" in LabVIEW. You can develop, build, deploy and run such directly from LabVIEW. With the target option, just like with LabVIEW RT targets, you would get a different set of functions available when working towards the web server or client as a target. Some functions are no longer supported, while other functions are added (compared to the regular desktop target). So, where are we (the currently available solutions) between these two extremes today, and where do people want to be? (And/or are there other extremes going in a completely different direction...?) Scenario A is obviously already available; and with web services etc. available, we do not need to develop this all from scratch. To get a complete client side application we can get a lot of help, either by getting controls or front panels on a web page, but we still need to use other tools to sow a complete GUI together. And if multiple users are supposed to work on the system in parallell a lot of the available solutions fail. Somewhere between A and B you have a scenario that many add-on makers seem to love; namely "put a front panel in the web browser". Great to have if that is all you need... Having seen too many of the latter solutions though I might have fallen into a habit of dismissing new solutions as soon as I see that the examples the developers have used is just that; get a front panel into the web browser/on your iPhone...So I'm waiting for something that presents itself closer to scenario B (which is where I would love to be, although I do realise that that might never happen...). National Instrument's got me interested when they launched the Web UI Builder - It was not integrated into the regular LabVIEW IDE, but it allowed us to code in G etc...so that was close, but not quite a sigar after all...

In our case the client-server solutions are all message based, so the client could be made in a different language to run in a web browser yes. But how fun is that As you know good engineers are lazy , so anything that would allow us to develop a GUI right there in LabVIEW, and deploy it as an interactive rich web site, handling multiple parallel connections, would be sweet...No need to stop anyone from playing Doom then (reminds me of two girls behind me in the movie theater that suddenly realized that the film they had bought tickets for was *not* a bright and sunny story...- Whaaat? )

Web interface solutions would be interesting for us if they were multi-session (that is - support many users working on the same system in parallel), and handled multiple VIs/windows elegantly. If there was an out of the box solution for *that*, then we would definitely use it. Basically we would really want the client to be replaced by the web browser...(Controlling single front panels is in the "man look at this sweet thing I can do" category. We have only used such solutions occationally, to control internal test equipment. Most of our commercial systems are client-server based, and one serious drawback to that is that the user interface has to be implemented in the client. - It cannot be dynamically loaded from the server side. So if we have some complex functionality that requires a new user interface on the client side we actually have to modify the client (we could transfer Vis from the server on demand and run it on the client side, but then that would break if the run-time engine differed between the server and the client, so it becomes a mess. A web-based solution could solve this, but it should work in a way that minimizes the need for extra development (even today's solutions can be made to work in a web client, but then you need to design the web interface using separate tools, and just link it to the server side using web services. It easily becomes a bigger part of the development, and is a hassle to get flexible/dynamic enough).

You have to install it on the RT target using the customized software install from NI MAX. It is mentioned in the solution in this thread. Make sure you have the latest version too, there has been one additional beta release since the aforementioned thread, it's here.

Unless you need to run this on a target that does not have SQLite support I would use that (the performance of Shaun's API in particular is impressive). TDMS is fine if you can write the data as large continuous blocks. If you need to save different groups of data frequently, in smaller write operations, I would use separate files for each group if using TDMS, otherwise the file will be too fragmented, and the read performance gets really really bad. - We use proprietary binary formats ourselves due to this, as we a) need to support different RT targets, b) frequently write small fragments of group data into one and the same file, and c) need to search for and extract time periods fast...(It is 1500x (!) times faster than the equivalent TDMS-solution).

I'm doing all new development in 2015. It has been stable and trouble-free so far (since it came out). Every time I go back to a previous version now (LV2009-), I Ctrl+Alt+Drag to tidy things up and expect to see the diagram move...What, arrgh...bring me back to 2015!

Recreated here as well, in LabVIEW 2015. My first question was whether the loop was in fact still running in parallell, and it definitely is. So this gap in the "block probes in parallell for loops" logic seems to give access to the values processed by one of the parallel instances...

Did you ever post such an idea? I could not find it...andwould like to have this feature too. Right now I have a file type class where I wanted different versions of the file format to be children. These would have dynamic dispatch functions that would be part of polymorphic VIs for read/write operations (handling different data types).

I have not chosen yet...(although one strategy is already there in the draft of course...). Here are some of the alternatives as far as I see it: We keep it simple/lazy and leave it up to the programmer to avoid problems; basically this is how the native queues (user events too in many ways) do it (you can set a maximum size, you can use a timeout on the enqueue/dequeues, or use a lossy insert, but you have to choose a compromise suitable for the task at hand). Enforce a "fool-proof" solution with whatever drawbacks that will have (basically pick one of the startegies a programmer could go for in alternative 1 and close the door). Try to be smart about it by adding health monitoring to the core of the system; if a publisher/subscriber or group of such seems to be misbehaving, shut it down before it affects the system...So the distributor in this case would say that if a subscriber queue is full on n occasions for example, it is assumed to be dead, and the subscription terminated...or the queue is automatically flushed by the distributor (kind of like the friendly neighbor deciding that you must be on vacation..better empty that mailbox before the burglars arrive...). Implement all 3 above, and allow the user to decide a "profile". (makes the API more messy). I'm leaning towards alternatives 1 or 2. Any other strategies?

Yes Shaun, you have understood everything correctly (although all subscribers in this case can also produce data on the channel. -They can only opt out of subscribing to the data (preventing a non-used subscription queue from flooding). I was actually just about to write that your Dispatcher is very similar to a networked (cool) version of MultiQ, when I saw your post. I like the simple API of the Dispatcher, very nice :-) I was sure I had looked at it before, perhaps I was too focused on a non-networked solution back then.

You can have multiple producers on the same "MultiQ" (there is really no access control built in (at least yet) so anyone who knows the name of a MultiQ and subscribes to it can also publish), but a subscriber cannot choose to bundle multiple subscriptions (to separate MultiQs) into one subscription reference. If that is what you are thinking of? You can build a lot on top of MultiQ though, so you could extend it with a "single subscription to multiple separate MultiQs" set of Vis, to make it look like one subscriber line at a higher level. You could also make a "Topic" solution. I am not sure how much such functionality should be implemented directly at the lower level, and how much should be added as a higher level, utilizing the basic MultiQ (as it is now) at the core. A networked solution could be made on top of the current implementation too.

Hi Mark, Thanks for the feedback. While searching for an existing solution a long time ago I found your message routing code. At the time I thought the API was a bit daunting. I could not figure out quickly how to set up exactly the mechanism I was looking for, so we made something much simpler for the project at hand, and moved on (I still have it installed though so perhaps I should revisit it). The core functionality you describe is also covered by MultiQ I think, except for the added functionality that comes with OOP. As MultiQ only operates on strings (like the old queues, TCP/IP functions etc.) the interface is (intended to be) very simple, but needs an overlaying protocol to handle messaging, data types etc... There are several issues with MultiQ that I hoped to get feedback on. The main question is what people think about the concept itself (I am using LAVA as an idea exchange here, at the risk of getting most eyes on the bad parts of code :-)), could it be useful (perhaps not if you are already using JAMA/your message routing solution for example). -But there are other things; like how full queues should be handled. Regular queues can go wild if no one is consuming the data and the length has not been limited, or you can block new production by setting a maximum number of elements. However, with a pub-sub design such behaviour becomes an even bigger problem; do you really want to halt publication because one subscriber is not consuming? Probably not, but sometimes you might...So should the solution support both, or simplify by choosing one of the two? How does the message routing solution deal with message flooding (I'll have another look at it later)?

I am not sure you have understood the whole concept/goal; namely to have lossless broadcast channels, with a simple interface (made to resemble the regular "consume only once" queues). Perhaps the demo makes it unclear as it focuses mostly on how simple the API is, and not on real use cases? Here is an old thread that discusses the issue. User events are now the closest existing and yes, simpler alternative (many can generate the events and all subscribers (which have registered for the user event) get their copy of the event. MultiQ tries to remove some particular drawbacks of a user event based solution though - as mentioned in the original post. Other similar solutions are I would say much more engineered and have a more complex interface (because they typically aim to solve additional issues), but maybe I am wrong. Implementation-wise this is a sloppy sketch. I use a class just as a fancy cluster/way to bundle functionality for example, and the notifier used to send feedback to the create/destroy funtions can be replaced by something easier and more robust for example, sure. I can get around the non-persistence/link to the original creator of user events by having them all generated by a separate process (as MultiQ does with its internal queues), and then only the flush/preview/status functions remain for such a solution. The access to the internal event queue is more limited though, although it opened up a bit in 2014 (I have made a sketch of something like that already, but have not published it yet).

I have added a 2012 version to the original post now.

Attached is a sketch of a publish-subscribe solution inspired by the design of the native queue functions. Open the project and launch the Simple Demo.vi to get an idea of the concept (or create a few instances of the example templates and run those). As you know there are *lots* of messaging solutions out there that also support many to many communication, many of which are much more advanced. They are often based on user events, and LVOOP. I have still been missing a solution that is as easy and intuitive to use as queues though. I also wanted to overcome a few other issues with user events: - I do not like to always have to have an event case for each subscriber. - I want each subscriber to be able to preview or flush its incoming data stream...(not fully implemented yet, but logically simple to do) - and I want to be able to keep a channel open for as long as anyone is interested in using it, not die when the process thathappened to create it goes idle(which is what happens with queues and user events...). I am publishing this to get some feedback on the concept (as it is now it has lots of missing logic and the design is not thought that much through). Do you find it useful or just silly? Are there other solutions out there that are just as simple? PS - The original attachment was LV2014, I have now added a 2012 version as well. MultiQ - a sketch of a many to many (pub-sub) messaging solution.zip MultiQ LV2012.zip

Rolf - are there parts of the toolkit that could be pre-released already for Linux RT, if you disregard the outstanding issues for the overall toolkit (like deflate/inflate I can live without the file functions as they are easier to replace)?

The regular global will definitely get into trouble with writes yes. It depends a bit on the write frequency, but with one write per read the functional global is still fast enough. With writes on the regular global too, the speed relation increases to about 17500x on my machine :-)

If global access is a requirement you might want to use a functional global or DVR instead. Here is a crude example that is about 9000 times faster in LV2013 on my machine, and 4500 times faster in LV2014.

I got around it by (seemingly at least) by clearing the browsing history.

I had forgotten that I also need to do deflate/inflate in memory on strings. When do you think a new release might come about Rolf Perhaps I can use some of these tips to do it until then though...

Thanks Rolf. Until then - I've began playing with alternative solutions, and have posted a description of it on the Linux RT forum.

Having been using the Open G Zip Tools on both Windows and VxWorks targets for a long time I just ran into the issue of compatibility with Linux RT... I'm sure I can find an alternative on Linux RT, but the otpimal solution of course would be to have the existing toolkit also support Linux RT Has anyone compiled and modified the kit already for Linux (or set up a nice replacement)? Are there any plans to add such support in the official version? MTO

I'm lucky to be the one that decides our upgrade strategy, and the philosophy is basically that we "Evolve or Die". This way we learn and adapt continously, making each step small and manageble (if we need a feature from 2015 it is likely that the transition is simple if we are already familiar with 2014). And perhaps most importantly it keeps the developers happy (who likes to be "stuck" in the old days). That is a major contributor when it comes to productivity, creativity and the quality of the work people do. Sure, I would like to see more news between the different versions than we have done lately - yearly upgrades are a bit too frequent, but the frustrations we get from that have been outweighed by the positives.

The first report of it was actually 1 year earlier - back in 2009... I do not see why we should need to set a Focus property to get this right...So instead of fighting to get that property made public (not that that's not nice as well), I would prefer it if no such property setting was needed (if that is made available it could instead be used to override what is then the default behaviour - in the rarer event that you would not want to focus on the current value).

I would show them (optionally just parts of) ...and then link that to graphical programming and LabVIEW. Showing them how a number of organizations, like CERN, SpaceX...or smaller companies, like the one I'm from - ClampOn!) utilize LabVIEW could also bring in some motivation. There are a lot of text-coders out there, LabVIEW experience is less of a commodity.