Mads

I assume you are thinking about the static access here (where you always will be requesting the same value so that you can skip the lookup after the first call)? With no lookup you get into a different league of course. For random access there is no break-down; it will perform faster or comparable to the alternatives I guess you are thinking of. Personally I see more value in dictionaries in the random access scenario, so that's probably why I do not have the same focus on that bit as you.

I've run some preliminary testing of 2016 and the Variant attribute IPE for key value pair lookups now, and have compared it with 2016and 2015 without the IPE: Without the IPE, 2016 is equal in speed or negligibly slower than 2015 (so there is no instantly free lunch in just upgrading to 2016). With the IPE the speed of dictionary read and write operations are considerably faster, on my machine they were 1.7x faster than without/in LV2015. This was with only an array index in the attribute (value of key-value pair stored in separate array). I also did a quick test where I stored a DBL directly in the attribute, which turned out to be even faster (1.4x) for writes, and equal for reads. That's probably not the case for more complex data types, but the gap will definitely be smaller than before. The CVT for example then will in most cases be better off using attributes to store the actual values instead of keeping separate arrays for them. That would also allow it to be made more flexible when it comes to adding or removing tags.

The Current Value Table is one tool that used to have the actual values of its key-value pairs stored as attributes, but ended up only storing type specific array indexes in the attribute to (vastly) improve its performance. I wonder how much of that difference (if any) could be removed with the new IPE feature... Has anyone checked that already? I've been evaluating different dictionary solutions lately and this might change the picture slightly. I'll download 2016 and do some testing later this week.

Editing the file like that causes the file to be invalid as the cryptographic hash in the file is no longer correct (introduced in 3.0). So unless you know how to update the hash (stored in the file ID probably) correctly you will not be able to produce a valid update. The Pro version might allow you to open them anyhow just to have a look at it to see what has been going on, but I would think that it should still at least give the users a warning that the file has been tampered with(?).

What version of OpenG Zip library did you try to install (it has to be done using the Custom Software Install feature in NI MAX by the way...)? I'm using it on NI Linux RT targets (cRIO-9030 and sbRIO-9651) without any problems (thanks a million Rolf Kalbermatter). Here is a thread where my initial request for Linux RT support was discussed.

When you say that you want to add the first three rows and add the elements together I assume that the sum you are after is not the sum of all the elements in those rows (which would be just one number), but the sum of each subcolumn, or? If so, in your example above the first row in the output array will be: 10, 13, 13, 57, 21, 11 There are a lot of ways to do that, and the different ways have different speed and memory efficiency depending on how many columns there are, and how many rows you want to sum. Attached is one alternative (made in LV2015, back-converted to 2012) that seems to be an OK compromise between code simplicity and speed...I'm sure someone will take the challenge and improve it though ArrayNthRowSum.vi

Chrome is complaining about the security of lavag.org. It has an invalid certificate (encrypted with an outdated cipher)....

I normally use the window state to determine if the function is running already or not here. So i make sure the pop-up window will always close itself when completed, and the calling code will just check if the window is already open to determine if it should initialize and run the VI. I have attached an example here. Now, this does not work if you really want the Furnace control to continue running even if the window is closed, but in such cases I would separate the GUI (only runs when window is opened) from the Furnace control (runs continously in the background), and just send adjustments to the latter from the former when they occur. Init, run and open if not already running. Open only otherwise.zip

I think you will have to attack the problem by making the header(s) in a way that will allow you to place it at the end of the file (or at multiple locations..). You can see an example of this in the way the zip file format is structured. I recently developed a chunk based log file format myself where the data to be logged is placed in pre-allocated (on demand) sections which each have a header that allows the readers and writers to locate the other sections (chunk headers declare its chunk size and current write position. They can also have pointers to the previous and next chunk, making it easy and quick to traverse the file structure). Another example of a chunk based file format is PNG.

Thanks, I had not discovered the SFTP option. Now I found a little user guide on it too.

On Linux RT there is no FTP server in the standard installation, only WebDAV (which many of our customers have never heard of unfortunately, so we have some trouble getting some of them to switch to cRIO w LinuxRT). You have to do a custom install of "Legacy FTP server support" to have FTP. To make that option even worse it only supports anonymous logons (so you do not really have an equivalent to the "old" solution available).

My doctor ended up suggesting I should remove a tendon when he was unsuccessful treating my LabVIEW-induced tennis elbow with drugs and massage a few years back....I tried all kinds of mouse replacements only to make things even worse. The immediate solution it turned out was to stretch the hand upwards and downwards tens of times a day to get rid of the inflammation (thanks Google(!)). Since I switched to the Microsoft Arc mouse (which everyone else here hates) I'm not bothered with it much anymore though (if I feel anything I just do some stretching and I'm fine again).

I talk about writing code that can run *in* a web browser. NI's Web UI tool basically solved this by making us develop Silverlight applications in a variant of G, which most people with a web client would have and therefor be able to use. The decision to base it on Silverlight proved to be rather bad...but the concept would be the same. In scenario B the Web client (and/or server) is in many ways the target OS.There has been some talk lately about NI having plans to port the run-time-engine to javascript. That would constitute a move towards scenario B.

Who's talking about language? This is in a context of toolkits/general system design solutions available in or tightly supported by LabVIEW, the IDE and ecosystem. If I say it is an extreme you might need to evaluate it as such and see what light that sheds on the scenario I never talked about the NI web server, and in scenario B (the true extreme one) you would probably never care about it at all. You would write code that can run on any web server or client.

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.