ShaunR

A good one would have been that NI are releasing a "Home/Hobby" edition and service packs for LV 2010 and down.

I like using 2 monitors (when they are availabe-I just use the inbuilt windows extend desktop). However. I still maintain that diagrams greater than one screen is shoddy. I use them in a slightly different way in that I will have diagrams on one screen and FPs on the other. It saves a lot of hunting through the myrriad of windows and moving FPs from over diagrams when you switch to a VI (if you aspire to one digram being less than 1/4 of a screen , you can work on 4 VIs at a time with no fuss )

In principle it's a good idea. However...... 1. All "patches" that I want can only be supplied by NI and, after one year, I have to lump it (I still use 2009 through choice). 2. Isn't most of what you are proposing exactly what the JKI thingy is for? (and I still argue that NI should have their own) 3. One mans meat is another mans poison so what some might see as "valuable" another almost certainly will not (all the items you list in No.1 for me). 4. If I see "useful stuff" it goes on my "G:\" drive which has 3 directories (2009, 2010 and 2011). Each is an exact duplicate of arbitrary "useful stuff" downloaded from forums, bits and pieces I've written and other miscellaneous bits and bobs (2009 is the "source" and gets copied accross to the others now and again). Each installed version on the dev machine(s) has it's search path pointing to the appropriate verson on the G:\ drive (the 2009 dir is backed up in SVN). Very little gets installed in the palletes above and beyond the vanilla install except my own re-use code (there are only 2 of them) and others on an as needed basis for that project (which are uninstalled after completion). This is the way I avoid dependancy and "compiled for later version" hell. I should perhaps also add that most of my work is on machines that are intentionally not internet enabled so "whoops I forgot to download and install that package" is not a viable proposition (sometimes machines are in different buildings or even in different parts of the country). The 2009 directory copied to a usb stick solves all that.

Depends whether it was run from within a project or not

OK. I get 1ms accross the board (even 2011f2). This is just loading it straght up and running. However. Add the file to a project, dbl click and run-> 256 ms.

Yeah. Sorry. Not much for you to go on All 1ms (LV2011x32SP1 andr 2011x64SP1 Win7 x64 and Win8 x64) About time you put in a capital req for a new PC

They are all 1ms for me (including the first one).

Using OpenG Zip Tools On 64-bit LabVIEW I think they are waiting for Rolf to find some time

Well. "the company purchases the license to use at work" isn't really what they do. They buy a license to enable them to produce product. Where its produced is irrelevent. I suppose an analogy (albeit a poor one perhaps) would be you don't need a different insurance policy to drive a company car out of work hours. However the arguement would be along the lines of "if they (the company) hadn't bought the software/license. Could you have legally produced the code?" The answer is only a difinitive "yes" if you have a license in your name, that you have bought. Otherwise you have used a company resource as they have the payment receipts, license and inventory ledger stating that they have it, You, on the other hand, merely have access to it whilst you are in their employ - under their license). Combine that with the work for hire clauses and you really don't have a leg to stand on.

All the NI licenses allow installation on a home computer. This is the "trap" that many people fall into when creating 3rd party LabVIEW software outside of their working environment (using employers resource to create the code) and gives the employer very strong arguements to claim the code as theirs.

Well. The glib answer is find a company that doesn't implement slavery (we own you, everything you do, everything you think and everything your cat thinks!). But pragamatically I don't think there is a particular recipe because it depends (on which country, who they are, whats in your contract, whether you used their resources etc). Perhaps this will at least point you towards the right questions and some of the issues involved. http://answers.onsta...-st/20136#20136 I've generally found, most companies don't care until you produce something they want. So they would let you do it then want to take ownership citing your contract etc. In terms of contracts, the bit in your contract that says they own you has to be mitigated, but that may be an "unfair contract" clause in some western countries anyway. The biggest problem with LabVIEW is that not many people can afford to buy the software outside of thier working environment (the classic arguement for stating ownership). But I understand some people have negotiated with thier emplyoyers that the employer buys the software for them rather than the company (and they keep the license when they leave). However. I would hardly say that was usual.

The structure of file paths in the exe layout changed after 8.x. You could try checking the 8.x layout to see if your problem goes away and, if it does, it will confirm it is a file path problem.

I've not come accross Quad-tree but I have come accross R-Tree

An AE is already a singleton (thats the whole point of them). It might also be worth noting that the AE is synonymous with class methods.

Well. Some are better than others. But a single byte (max 256 permutations) coupled with 2's compliment yields many more collisions than is useful.

As an aside....... 2's compliment as a CRC really sucks. For example, just try entering the string PLPARM01:0500000000:0400=32 [/CODE]

Dare I say it? This is one of those cases where you would probably be better to go for a class and use the run-time polymorphism. That would allow you to have overrides for each en/dequeue type without having to worry about checking and casting and (assuming you only have one of each type) you wouldn't need a "database".

Well .this isn't a new phenomena. And the accepted way is to create a LV2 style global to get the reference. In fact. I supplied exactly that solution for this thread (although it was for events). I've also noted that JGCode uses this method in his classes. KISS.

Sweet. The padding length (in most cases) is dependant on the size of the block (16=128 bit block) so it really needs to be configurable. I've modified your padding VI (to account for the block length) and added the ANSI, ISO and PKCS5 (Ver 2.0) methods.

Rather than register et al. Wouldn't be more appropriate to use "add mapping" and "delete mapping"? (in a similar vein to add to list, delete from list). That semantic is fairly universal and you yourself used "add" to describe the register.

Give this a try

This Shawn bloke obviously knows what he's talking about

Hmm. So are you saying it is data tracking rather than interfacing (like different comms interfaces, different functions etc)? Maybe a DB would be a better way forward and could simplify your heirarchy to series 1,2,3 etc.

There are a few of the NI example exams coded in LVPOOP here. That'd be a good place to start since NI have equivelent examples in "proper" labview .

Operator Error