ShaunR

There are a myriad of ways you could realise this. It will depend on your preferred architecture (TCPIP RESTFUL API, Pub/Sub, TCPIP streaming, Websockets, UDP multicast...the list goes on). The 15 VIs are presumably all on localhost so are they just launched from one process (they all have access to each others data or are they separate processes each with TCPIP to be connected to? I have a (very old) pub sub architecture in the CR. Dispatcher might do what you need with little effort but if not, you can use it to frame and demonstrate why it is not the right solution - your images are pretty generic and only say "write and read some data through miscellaneous intermediaries" Also, as a heads up.... You can't make a Windows Service in LabVIEW like you can in C++. Only an executable/DLL. So you either put a shortcut in the Start Up folder/registry or there is a program that can launch any program as a windows service (the name escapes me for the moment)

Convincingly random? Confidently random? Deceptively random? Indecernably random? Random looking? Good enough? They were all others I toyed with Don't forget it's not at all random - just looks like it statistically

You and I have very different ideas about beautiful art Are random[ish] patterns beautiful? This is what some bytes look like for a SQLite database. Here is the same data with AES128 ECB encryption. And here with AES256 CBC

Yes. Notifications and emails. There are only 3 things that interest me and they are all emails I receive a PM Someone replies to a topic I created Someone likes a post of mine. Two out of those three are disabled by Admin so can we have them back please? I have no interest in websites bugging me with in-in band notifications so that's just a wasted feature on me but it does show how acceptable remote code execution has become when it used to be considered malware .

Michael addressed #2 but as for #1 I think it won't matter in the not too distant future. Layout and styling are becoming more client side and you will see more things like Stylish appearing-probably being offered from the websites themselves as "templates". I use TamperMonkey and GreaseMonkey to intercept and modify a websites CSS and JS so I no longer get annoyed with website layouts. The effort I would put into moaning about it, I just write a quick script and make it exactly as I want then move on. I don't think I need to do that for the new Lavag.org but fiddling with the background colour in TamperMonkey shouldn't be too hard for a seasoned programmer. This is also my solution to the abysmal LabVIEW user interface

Not in my toolbar there isn't. But the "Quote this" is awesome so I won't need it any more anyway

You are really talking per customer project (AKA per order), rather than projects. I envisaged a VM for every LabVIEW project file, however trivial, so even something like the Spell Check that I recently created would have had a VM-which would be silly. A VM per customer project doesn't resolve versioning updates. It just compartmentalises and freezes the customer software as a deployment. When you up issue a component in the customers software or fix a bug do you then create a new VM? I doubt it. You probably use the snapshot feature as a version control for that customers entire system.. Whilst a VM is a good method for snapshotting, VIPM is an installer and mainly for toolkits rather than entire projects. So it's not really solving the same problems. When you create a VM you use the NI installer for LabVIEW, Right?. , After that, how do you get all your toolkits on there? VIPM, right? Once on there you then write your solution and then snapshot the VM so you can reconstitute it as a whole right down to the specialist instrument drivers that were written in China by a blind man with a lisp.:) But that VM can only be used for that customers project otherwise you get into huge problems with licencing and copyright. Most of the software toolkits and helper apps that I have written were not intended to be written as such. I have a lot of stuff I have written over the years - snippets, scripts and miscellaneous programs - and much you see on my website is either just productionising something I wrote an age ago or grouping a number of already written snippets into something more friendly. This is the case with the Project Probe and the Install Manager. I had all the bits and pieces but no easy interface for them and got tired of opening 10 projects and running them manually from the dev environment. The Wizard was a little different in that it started as a cross platform installer when VIPM was windows only. So that was a definite need but today, for this thread, it is already written with many of the bits and pieces that would be necessary.

I like it. Different enough to be fresh. Not different enough to force us to learn new workflows.and interfaces. The only thing I haven't figured out (yet) is how to break quotes so I can reply in sections. I used to just change it to text and then split it up inserting the markup but I can't see a text/html button in the new editor. I expect it can be done another way, just that I was using the brute force method

No thanks. That's putting the cart before the horse. Software works *for* me to make *my* workflow easier/simpler/productive. If some software doesn't work for me then I'll write some that does - even in another language if the fancy takes me Are you really suggesting that every project should be in it's own VM? That would mean I would have 523 VMs (and counting) just for Windows without even considering Linux, Mac, RT, VXWorks or test machines .

I only half agree with this. To replicate VIPM, yes. To make an installer, no. (Are you still using a modified the modified OpenG Pakager) As you are probably aware, I use a Wizard style installer for SQLite API for LabVIEW because VIPM can't handle selective 32&64 bit installs. It can also integrate into a global "package Manager" which is SQLite based rather than the "spec" inifile . In fact. It was the reason I added the capability to import an ini file to the SQLite API for LabVIEW so as to import the VIPM spec files The downside to the wizard is the size of the deployment but it suffices for isolated installs and it can be retrospectively integrated to the global manager. The upside, however, is that, in addition to the standard pages, you can add custom pages for your install and that makes it much more flexible-if a little more effort. So the wizard has all the bits and pieces to install (pallet menus, recompiling etc) and I did start to make a Wizard Creator where the Installer was an example. Just one of the many half finished projects. The global manager (which is the other side of VIPM) would take a lot to productionise and I'm, not currently interested in stepping on anyone toes. It works great for me and I don't have to produce help documentation which takes me longer than writing software . It will ultimately also handle my own licencing scheme too (which we have discussed previously) but even then it will be limited to only my products as there are a few now. So yes. It is totally doable (and has been done) with enough effort but I would do it slightly differently to VIPM.

This is really a source code control issue rather than an installer issue. The two are related in that an installer usually installs a particular dependency version but the goals are different. In NIs refusal to give us a proper source control system that is fit for purpose, the VIPM software is the best of a bad situation for simple version control but it isn't really a version control tool any more than an RPM package installer is (on which it is based),

I was emphatically with you right up until the "train tracks" (my OCD prevents your version and there are genuine reasons for pass-through for optimizations) and palettes.(time and motion studies on placing primitives is ridiculous - you can make mistakes faster? ). Nice to see a fellow heathen picking holes in accepted dogma. Beginning to think I was the only one

Why not ask on the support thread then so that the developer gets a notification.to answer your query

I have no idea what toolkit you are using but if it is the OpenOffice RGT addon then...... Support thread is here.

Is that still an issue? (it says version 3.3.1 and was last updated in 05/05/2011)

That's a partitioning argument but more importantly it's just that sort of thinking that means we have an error emitted reading an entire text file which is a glorious pain in the backside .

Yawn. We are back to the beginning of the circle then. Every few years someone decides that this or that is a bad idea so as to be "progressive" then a few years later another person decides it is the opposite again. It's a non argument in the same way as how many different types of errors should we have? I use warnings to tell users/developers that data is being dropped and an error is not appropriate for that.as it is a designed feature to protect the server/client.

Yes. the "advanced" or dependent configuration is not easily catered for by just blindly loading and saving FP controls.It would be a mistake to try and add logic to a generic API to cater for application specific dependencies. I chose to have the basic load/save behaviour which is fine 8 times out of 10 and then use a query to update specific controls so it is a two step update for corner cases. It is very simple but does require a little bit of thought about naming your controls. The current query function only interrogates label names as a partial match so adding "Avanced_" to a control, for example, means you can achieve that behaviour. A slightly more complicated query would be nice across dialogues and in my personal version the default query string can be overriden but since I never get any feedback as to features people want or bug reports to drive another release; I haven't implemented it as yet.

I think if you move to a DB, it will supply the decoupling and still give you all the same capabilities. A while ago I added a "Settings" library to the SQLite API which, I think, does exactly what you're describing - almost direct replacement. You just place the VI on the diagram and you can load and save the FP controls to the DB. It also gives you "Restore to Default" and has a "query" function so you can return as many or as few parameters as you like (see the Panel Settings Example). I was also thinking about adding the "Update" event broadcast similar to your system since for Data-aware xcontrols it would be a very nice feature to have them all update on a change and would only be a couple of minutes to add.

The issue I have with most unit test frameworks is that they effectively double, triple or even quadruple your code base with non-reusable, disposable code - increasing effort and cost substantially and often for minimal gain - more code = more bugs. This means you are debugging a lot of code that isn't required for delivery; for a perceived peace of mind for regression testing. I skeptical that this is a good trade-off. I couldn't install the VIP since it is packaged with VIPM 2014+ (I'm still livid at JKI for that). I did, however, extract the goodness and look at it piecemeal but couldn't actually run it because of all the dependencies that were missing.So if I've missed some aspects, I will apologise ahead of time It looks like early days as you find your way through. Some things you might want to look at...... 1. Instead of creating a VI for every test with a pass/fail which you then scour for that indicator Look at "hooking" the actual VIs front panel controls' (there is an example on here I posted a long, long time ago) and comparing against expected values and limits. This will move the "pass/fail" into a single test harness VI, much like a plug-in loader, and for non iterative tests-will give you results without using a template or writing test specific code.. 2. Consider making the "Run Unit Tests" a stand-alone module. This will enable you to dynamically call it from multiple instances to run tests in parallel, if you so desire. 3. Think about adding a TCPIP interface later on so that you can interact with other programs like Test Stand (forget all that crappy special Test Stand Variable malarkey ). This means that your test interface is just one of a number of interfaces that you can bolt on to be the front end and doesn't even limit you to LabVIEW. (how about a web browser ? ) With a little bit of thought, this can be extended later into a messaging API to cater for iteration, waiting and command/response behaviour. This, along with #2 is also the gateway to test scripting (think about how I may have tested the Hal Demo as both a system and as individual services). Edited: 'cos I can

OK. so what am I missing?

Like this

I merely meant that scientist and engineers sat in laboratories really don't care about this sort of stuff. They just want their experiment/machine to work. They choose LabVIEW because they don't have to worry about pointers, memory, stacks and registers - all the crap other languages have to deal with - so the mindset of "how do I break/exploit this?" isn't there. With the introduction of the academic licences - not that long ago - LabVIEW has been exposed to more of those with exactly that mind-set and many are polyglots - not only on Windows but on Linux. I'm not saying you are in academia, just that because of the academic exposure we should see more black, white and grey hats targeting LabVIEW where previously there were next to zero.

d) Nothing to do with LabVIEW. I think this is very valuable work but useless from a LabVIEW for Engineers point of view. This is really just showcasing a (zero day?) exploit that will hopefully be addressed in the next update and the "feature" will disappear. I would have preferred a responsible disclosure of the exploit and I expect this will get very little love from the community as I would guess that outside NI R&D the number of people that even understand it, let alone could leverage it, can probably fit in a small family car. It is, however, a splendid example worthy of DEFCON and CeBIT for demonstrating attacks on the niche language called LabVIEW. Hopefully we will see DEFCON videos of LabVIEW RT and PXI boxes being pwnd and machines taking peoples arms and legs off. Maybe then the malaise and complacency around security in the LabVIEW community might be eroded somewhat. To be honest, I expected this sort of thing a while ago but I guess we are only now reaping the benefits of the academic licences Keep exploiting while I go for some more popcorn . I'm sure there are a couple of eyes on this work just itching to marry it with self expanding VIs