Mads

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.

I just did a quick test for you. Updating the background color of all 200x50 cells (with panel updates deferred) still takes 1,1 seconds in LabVIEW 2013 (on my relatively new PC)... But do you really need to update them all, and in one go - or could you update them individually on changes in the cell content *only* instead? Checking if a change is actually required first would take no time, so (unless most of them are likely to need a change) you could reduce the number of actual updates enough to make it seem "instant".

The *asynchronous* call pool is only required for synchronous calls? Was it not introduced with the async call by reference node in the first place?

That is an interesting tidbit. I've so far thought that the only way to avoid getting blocked by the root loop was to populate the asynchronous call pool (and hope that the pool is large enough to meet the demand during a blocking event...). Populating the call pool is only required for a speed gain then, or?

Microsoft has been messing a lot with the GUI lately. I think this article sums it up quite nicely: http://www.nngroup.com/articles/windows-8-disappointing-usability/ Most programs I make have multiple windows, but they also have a main window, which is the one that is shown after startup (once the splash screen has disappeared). The main window then has File>>Exit (Ctrl+Q). If I had an application with multiple windows that could all be perceived as "main" (meaning for example that it makes sense to have the app running with just one of them open), I would add the exit option to each window. It should be possible to shut-down the whole app without having to close each window individually, and the File>>Exit option is a well established and hence intuitive way to to that...

It's not really about long term data logging. If you have a huge data set you will have to write it to disk and reload data from the source (DB or other alternative) dynamically anyway. In such cases the user expects, and will therefor accept, that he might need to provide input and perhaps also wait a noticeable time for the new data. However, if you have e.g. 50 MB of time stamped doubles you can dump it all into a .Net graph without any worries. The GUI will run smoothly, and you do not need to bother handling events from the user's interactions with the data. The user can zoom and scroll with instant access to the underlying data. The graph will handle that amount of data fine on its own. That's not the case with the native LabVIEW XY graph. On a standard PC of today LabVIEW can easily hold much more data than that in memory (and in other types of controls/indicators on the front panel), just not in a graph. It is obviously much heavier to draw a graph than an array indicator, but if done right the native graph should at least be able to match the alternatives.

A *really* old thread, but not much has happened since 2006 as far as I can see (LV2013), and perhaps the reason is that the problem is (as Jason wrote in the last entry here) still not acknowledged(?). The graphs decimate the displayed data, as Jason describes, but you still get a serious performance hit above a certain number of points (the GUI slows down to a halt...). For XY-graphs that number is very easy to hit. We have to use non-G alternatives to get proper performance with bigger data sets. So there seems to be something that slows things down even though, if the decimation worked, the number of points actually drawn should not grow. I could perhaps understand it if the software had a problem holding the full data set in memory (in the background), or if the slowness was only noticable when the user did a change to the GUI that actually required the graph to recalculate which points to draw, but that does not seem to be the case. And obviously, code written in other languages *is* able to cope just fine, so there really is no excuse.

See the reply from NI on my idea to implement native support for this...it turns out it is supported, just not very obviously: http://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Support-industry-standard-time-server-NTP-e-g/idi-p/2340392 Here's an implementation using the System Config API: https://decibel.ni.com/content/docs/DOC-26987

Good idea. It is a bit sad that we have to resolve to such tricks though. In 2004 a typical installer from us would be about 4 MB. The same builds now take about 140 MB. I still use LabVIEW 7.1 every now and then if I need the small file size, and/or do not want an installer, but just have the RTE-files in the same folder as the executable. Same source code mostly, just older and more compact wrapping

Not a direct answer to your problem, but in similar situations I've solved the issue either by making the file producers use temporary names when they write the file, then rename them afterwards to something that the copier is looking for, or I've made the copier read the modification time/file size, and only copy those that have not changed for a certain time. This only works if the file producers write and close just once, or at a slow pace, and/or if the copiers can extract a valid content and copy that while the file is being updated.

It should work as you describe it yes, but even when it is done like this, LV often fails to re-link everything. I've ended up with corrupt class errors (it might ask where the class file is, but fails to recognise it even though I know it is the same file, just in a folder that has gotten its name changed). That's why I posted this on the idea exchange.