ShaunR

Well. The adult way to go about it is to furnish NI with the exploit so they have the chance of evaluating whether they want to expend the effort in plugging it before you release it into the public domain. This would allow you to gain a moral position rather than just looking like a petulant script kiddie. Careers have been made this way and the skills are usually prized rather than punished. White hats and black hats come from the same milliners, however they are viewed and treated very differently both in the community and in the law courts.

Resolution isn't that important for Iris recognition (labview can achieve sub-pixel accuracy and the relative proportions of the eye are quite large). Focus and noise is more of a consideration. Therefore it is important you don't buy a webcam with a fixed focus (mobile phones have auto-focus which makes them extremely useful, webcams don't tend to) You've probably seen the simple ones with the annulus (Find Circles) that do some distance measurements (Caliper), but you can achieve better than that with LabVIEW and detect the number and sizes of "dark spots" (Particle Analysis Report) and changes in color, shading and discontinuities (ROI Profile).

You'd better hope that NI don't take you to task over the licensing of their closed-source, proprietary software then. (you admitted earlier that you are attempting to breach their licensing conditions )

Softice is the tool of choice. However. There are easier ways that don't require "cracking" the file or finding the "branch".It's a bit of a moot point with regards to LV though. Most of the time it's just used to prevent critisism of messy diagrams and there are no real secrets hidden. If IP is the problem it's buried in the exe. So apart from the exercise or the challenge, there isn't a lot of point in cracking diagrams. You're better off spending the time going out and getting laid.

Why don't you write one as you seem to think it is indispensable?

Indeed. Ever since lavag.org went off and came back again. The reply editor has been kind of screwed in Firefox (well Waterfox actually) for quoting (using Chrome now ) Then my statement stands. It is in violation of dataflow.

In the previous example, closing the VI reference immediately before or in parallel to the second Open VI Reference function creates a race condition Surely this is a "bug" that violates dataflow.

Quite right. Poor terminology on my part. Done. Agreed.. All LV arrays are "rectangular" arrays, however this is inefficient for large data-sets. We could actually handle non-rectangular arrays by using arrays of DVRs internally (again, the premise being that we would only convert to "rectangular" when necessary on extraction).......just a thought!

A local variable will be the fastest except for putting the indicator outside (and won't kick in that particular optimisation as long as you read it somewhere I think). The queues, however will have to reallocate memory as the data grows, so they are better if you want all the data, but a local or notifier would be preferable as they don't grow memory.,

Yes. That's what you want, right? Fast? Also. LV has to task switch to the UI thread. UI components kill performance and humans cant see any useful information at those sorts of speeds anyway ( 10s of ms ) . If you really want to show some numbers whizzing around, use a notifier or local variable and update the UI in a separate loop every, say, 150ms.

Some people have successfully back-saved to earlier versions of LabVIEW. There are certain features of the API that use methods that weren't available in older versions of labview but, if I remember correctly, there were only 2 or 3 of them (mainly using recursion) HDF5 is a file format. SQLite is a database. Whilst SQLite has it's own file format it has a lot of code to search, index and relate the data in the file. You will have to write all that stuff to manipulate the data contained in a HDF5 file yourself. Not sure what you are asking here. Can you make an exe? Yes. Do you need to add things to an installer? Yes-the sqlite binary. Yup. Looks really easy Now decimate and zoom in a couple of times with the x data in time (lets compare apples with apples rather than with pips) What I was getting at is that you end up writing search algos, buffers and look-up tables so that you can manipulate the data (not to mention all the debugging). Then you find its really slow (if you don't run out of memory), so you start caching and optimising. Databases already have these features (they are not just a file structure) , are quick and really easy to manipulate the data with efficient memory usage. Want the max/min value between two arbitrary points? Just a query string away rather than writing another module that chews up another shed-load of memory. Having said that. They are not a "magic bullet". But they are a great place to start for extremely large data sets rather than re-inventing the wheel, especially when there is an off-the-shelf solution already. (TDMS is a kind of database by the way and beats anything for streaming data. It gets a bit tiresome for manipulating data though)

You'll end up writing a shed-load of code that realises your own bespoke pseudo database/file format that's not quite as good and fighting memory constraints everywhere Much easier just to do this:

The easiest (and most memory efficient) solution is to pre-process the file and put the data in a database and then use queries to decimate. Take a look at the "SQLite_Data Logging Example.vi" contained in the SQLite API for LabVIEW. It does exactly what you describe but with real-time acquisition..

Done. Agreed.. All LV arrays are "square" arrays, however this is inefficient for large data-sets. We could actually handle non-square arrays by using arrays of DVRs internally (again, the premise being that we would only convert to "square" when necessary on extraction).......just a thought!

Move the indicators out of the for loops.

Well. Decoding an N dim array is not that hard (a 1d array of values with offsets). But I'm not sure how you envisage representing it internally .

N dim arrays don't have a "type" but they are represented e.g. Array:[[1,2,3,4,5],[1,2,3,4,5]] This causes us a problem in the way we convert to type from a variant (recursion works against us due to the fact that it is not a recursive function. it is iterative). If we were just dealing with strings, then it would be fairly straight forward. For example. Using the "Set From Variant" in a for loop works fine for 2D arrays. But for 3D arrays it will give incorrect results (try with the "Example Creation of JSON string.vi"-bug). One way forward is to detect the number of dims and have a different "Set JSON Array.vi" for each (max 4 dims?). But this is ugly (POOP to the rescue?).

Without

I could argue many aspects of that. The windows API is a much stricter license however (Creative Commons Non-Commercial Share-Alike). More importantly. In the case of the code that's taken from the windows API, an attempt has obviously been made to pass it off as original work (plagiarism in academic circles) otherwise, why change the icons, the distribution format, remove the attribution notices in the revision info and license file. That's just "not cricket" and should annoy you in terms of your code as much as it does me. I'm not saying that the person that posted it on NI.com did this (although they have opened themselves to the issue). They could have innocently picked it up from somewhere else. It does however highlight the importance of licensing and the validation. if not commercial gain, that some seek from the efforts of others. Maybe a MOD can move these comments to the licensing thread so as not to gum up this support thread?

Well. in my defence. They were originally written in about 1997 before all the new fangled icon bitmap editing. When a customer complains about icons rather than bugs; maybe then I'll change them

Indeed. He has been a busy ;little squirrel. This drives info is taken from my windows API (windows_api_Drives.llb).

I ran the updater on that machine (had to drag it over to the offices to get an internet connection), updated everything and the problem seems to have gone away. It solved the problem, but I can't tell you which patch/update/package was the one that fixed it and I can't now replicate the problem-just needed to get it working.

Yup. I think lvanlys.dll is installed with the Device Drivers CD (the machine also has 2012, but the lvanlys.dll seems to be from 2010). That would also explain why it affects all versions. Just downloading the latest Device Drivers installer to see if that cures it.