ShaunR

Don't!

[rant]

Yes IT has a duty to protect the precious data of your company, however they should feel the pain when they screw up. Not you!

Recently our IT department has enablde User-agent filtering....

[/rant]

Ton

Thats ok. Just write a quick proxy filter to modify it on the fly (if your not using firefox). Make sure you add to the version info field "IT ARE ANALLY RETENTIVE NUMB-NUTS " (in capitals so it's easy to spot in their logs)

Oh the joys of local admin privileges

All I said above is that I 'hope' NI can't do it and if they can then IMHO I think it means it's not 100% secure - which you just agreed with above??

The point is. Under windows. No dialogue based password system is 100% secure whether it's from NI or not (although I bet NI wouldn't have to spend as long as me circumventing VI passwords ) Password protection is like a key to your front door - it only keeps out law-abiding citizens Of course. I'm a law abiding citizen, so I would never consider circumventing NIs protection .

To return to a point I made awhile back, if you UI and core engine cannot be on separate computers on a network, then you are not decoupled.

Well. I think that's a bit extreme. That's like saying it's not programming unless it's POOP .

Whilst a network interface can be used to achieve decoupling. I don't think it's a requirement - just an implementation method,

Well I simply assumed that someone resorting to API export applications for a DLL would certainly not do that for an open source library.

I thought exactly the same until I had my 4th cup of coffee

Password protected VIs definitely get recompiled on load when they are not in the current LabVIEW version. I'm also not understanding why Open VI Reference should fail to return a VI reference for a password protected VI when you don't provide a password. The password really only is required to make the diagram visible, so the Open BD method and some other operations are all that should fail on such a VI reference, but not the Open VI Reference itself. Have you tried to play with the flags parameter to Open VI Reference?

And jgcode can you enlighten me what would be the security issue with allowing to get a VI reference on a password protected VI and being able to execute the Compile method on that? I totally fail to see any security issue with that.

The open vi reference will supply valid reference (ignoring projects for now). But the "compile" property will fail with 1040.

(See attached)

Happy to stand corrected... Well wouldn't LabVIEW need access to your block diagram in order to compile it? Meaning password protecting your VI's isn't completely secure? If I PP a VI - I want no one to access it - not even NI!

Nothing is password protected with time and soft-ice It just depends on how badly you want it (in most cases for me....not badly enough...lol)

Hii everyone,

I want to perform image stitching on a set of four images taken from 4 camera (mounted 90° apart), for image stitching.

For this, I found an algorithm on internet (pano tools, Pano12.dll). Now the problem is, as there is not enough documentation/examples available, I'm unable to use the dll.

I tried using DLL Export Viewer by NirSoft to list all of the exported functions, but still unaware of parameter lists.

And also I'm new to 'calling external code' in LabVIEW.

Please help in this regard.

Thank you.

Well. It's open source is it not? You only need to download the source and look at the function prototypes. It will also give you all the header files that you will need for passing structures.

Hi,

Thank you for this useful library/API.

You may want to change the representation of numeric indicators in "GetDiskFreeSpace.vi" from U-32 to U-64 as if the size of available free space is more than 4 GB, there will be overflow error.

Apart from this, I've a doubt, when I opened the project, in the "Files View", it shows that the all dll files (dependencies) are in D:\ drive... but actually there is nothing in D:\ drive.. refer the picture (attached).

Regards.

I'll make a note and update the indicators- if/when I revisit them. As I say in the description, they were written in 1998 (many years before x64) and you are getting them "warts-'an-all".

If you collapse the directory structure you will see that the windows DLLs are in the Root.. They are automagically added to the dependency tree by the project manager.

Hi all,

I have been developing some applications in LV 2010. I have a lot of backup files on our server . Suddenly all my VIs have been rolled back to very old version(date) of my application. It is opening the same old- (' template' )VI again and again no matter which file I open. This problem is driving me crazy. It is LV or some kind of Virus? Is there a solution for this?

Please help...

Sharon

Probably the IT virus . Speak to your IT dept and ask hem if thy have done a restore recently.

Turning off "Loose fit" and "autoscale" not working for you? (since you are specifying the scale)

The for loop will execute the number of times of the elements in the smallest indexing array regardless of what you wire to the N terminal. The N terminal is only of consequence if you have no array indexing or if the value you wire is less than the smallest indexing array.. I expect one of your data arrays is only 1 element in length.

This, for example, will only execute 3 times because the shortest indexing array is 3 elements long.

I think Eric has made one important point. the solution you are looking forward can give you better results if you CALCULATE the sun position instead of MEASURE the sun position.

For calculating the position you will need to have GPS co-ordinates(you don't need to have GPS device, you can feed them as constants) of your location and time.

Also consider following points when you consider vision based solutions Vs Time location based solution

• Accuracy (~100% Vs 100%)
• Cost of hardware
• cost of software development
• Cost of installation and commissioning
• maintainance (need to clean camera lens/ enclosure glass, calibrations etc.)
• etc.

Also there is one more advantage of using time location based solution "It can even work in night"

see this: http://pvcdrom.pvedu...IGHT/SUNPOS.HTM

also Google a bit and you will get all the required formulas.

Naaah. 4 LDR's (2 per axis) driving the motors in proportion to the difference in intensity. Doesn't get simpler (or cheaper) than that and is self calibrating for lighting levels (ok. I'll give you the night , but the device will be pointing at the ground since its tracking the sun )

But the OP wants to use a camera with a pencil stuck through a piece of paper. So I would suggest a concentric rake which will give you the position (quadrant) and length in 1 measurement.

Hey, its better than NI's search function right now

Don't tell me. Let me guess. You can only use their search if you have a paid subscription

WARNING: If you install LabVIEW 2010 Service Pack 1 without an SSP membership, the new version will not work and you will need to reinstall LabVIEW 2010.

Making customers pay for bug fixes is indefensible. Making a bug fix release that trashes your installation because you haven't paid is just plain boorish.

Also crashes on LV2009 SP1 x64 but not on LV2009 SP1 x32. (both Win 7 x64)

Hope we didn't scare Cat off! (I am going to blame you if we did)

Why not?. I get the blame for everything else

Fantastic. Knew it had to be simple.

I think the speed of the xnode stems from (apart from being an xnode) that its polymorphic. I wanted to use i in the SQLIte API but it was far to slow. But now I can add some more features.

Many thanks.

Who is Loopy? And doesn't she mind?

given the OP's question (and that the topic is interesting).

So interesting that the OP (Cat) hasn't returned

I disagree with the statement as it is written, but I suspect we agree on the bigger picture.

Possibly

I think the developer should write unit tests for the code he has developed. (And I know this is common in some software dev environments.) As you said, it helps verify the 'positive' requirements have been met. Well written unit tests also help communicate the developer's intent to other programmers. The very act of writing tests puts me in a different mind set and helps me discover things I may have missed. Requiring at least a basic set of unit tests keeps the developer honest and can avoid wasting the test team's time on silly oversights.

Perhaps it was worded ambiguously since I did not mean to imply that the developer should never write any code to verify his software. But that it should not be used as the formal testing process. Most developers want to develop "bug free"software and it's useful for them to automate common checks. But I am promoting that this is for the developer to have confidence in his code before proffering it for formal acceptance. The formal acceptance (testing) should be instigated by a 3rd party that designs the test from the documentation, and that reliance on the developers test harness for formal acceptance is erroneous for the previously stated reasons.

However, that set of unit tests should not be blindly accepted as the complete set of unit tests that verifies all (unit testable) requirements have been met. When the component is complete and checked in, the test team takes ownership of the developer's unit tests and adds their own to create a complete unit test suite for that component. And of course, in a "good" software development process the developer never has the authority to approve the code for production. I'm pretty sure we agree on that.

I think this is probably where we diverge

My view is, "that" set of tests is irrelevant.. It is always the "customer" that designs the test (by customer I mean the next person in the deliverables chain - in your case, I think, production) The tests are derived from the documentation and it is the principle that you have two separate and independent thought processes checking the software. One thought process at the development level and - after RFA (release for acceptance) - one at the acceptance level. I think I should point out that when I'm talking about acceptance in this context, I just mean that a module or identifiable piece of code is marked as completed and ready to proceed past the next gate.

If the the test harness that the developer produced is absorbed into the next level after the gate, then you lose the independence and and cross check. If it didn't pass the developers checks (whether he employs a test harness or visual inspection or whatever) then it wouldn't have been proffered for acceptance - the developer knows it passes his checks.

.Complicated requirements require complicated solutions.

Thats probably why we disagree so often. Complex requirements cam be broken down into many simple solutions that together solve the complex one.

For the "active object" part, I would suggest having a single shift register with a "LB 1, LB2, Other" enum and just set it whenever you make a selection in one of the LBs.

Or just pass the refnum since they are all the same (only have to be similar).

Raw USB in LabvIEW is very "trixie". There is no real defined standard and the process for actually getting something usable is fraught with problems. If you need USB it's much better to go for one that supports a virtual serial interface. Raw USB in LV is (IMO) to be avoided at all costs.

However.

I think from what you re saying that you have read the NI tutorial (you talk about creating a driver in the wizard) and I will add the caveat that generally. a USB driver cannot exist side-by-side with VISA (i.e you must uninstall and completely remove the vendors driver).

But your problem has been discussed here before. I'm not sure that a resolution was every found but here is the link in the hope it provides something useful.

Thats about all I can offer, I'm afraid.

The GetValueByPointer XNode is just a way to deal with native pointers, when you have no way or don't want to modify the DLL itself to deal with LabVIEW handles directly.

I find it far too slow It's a shame it's an xnode.. It's password protected and I wanted to find out how it determines the length of a string before it dereferences (iterates 1 char at a time and checks for null?) They don't mention how to do that in the move block documentation (dereference a variable length string).

Lastly, you need to consider if you will build a client server model where multiple UIs can interact with a singe engine simultaneously. That is a harder nut to crack...

Naaaah.

Dispatcher 1.0 does 90% of that. Dispatcher 1.2 does 100% (including to and from browsers after a very nice little thread a couple of weeks back )

Final thought: In the past I've naively viewed unit testing a bit like a magic bullet. Turns out... not so much. It's good at catching certain kinds of bugs, such as when an interface is implemented incorrectly. Ultimately it will only catch bugs you're testing for, and if you've thought to test for them chances are you wrote the code correctly in the first place. Unit testing is only one part of a good test process. User-driven scripted tests (a written list of steps for the tester to do) and exploratory testing are valuable techniques too.

Indeed. It is more risk management than a no-bugs solution. The mere fact that you are writing more code (for the purpose of test) means that even your test code will have bugs so you can consider that software, testing software, actually introduces the risk that you will expend effort to find a solution to a non-existent bug in the main code.

Unit testing (white-box and black-box) has it's place. But it is only one method of a number that should be employed. Each to a greater or lesser extent. We mustn't forget systems testing which tests the interaction between modules and the fitness for purpose, rather than that an individual module actually does what it s designed to do.

The main issue for any testing though is that the programmer that created the code under test "should" never be the person who tests, or writes any code that tests it. The programmer will always design a test with an emphasis on what the module is supposed to achieve, to prove that it meets the design criteria - that's his/her remit. Therefore the testing becomes weighted to proving the positive rather than the negative (relying on error guessing alone) whether it's a software testing solution or not. It's the negative (unanticipated) scenarios where the vast proportion of bugs lie and, to expect the programmer to reliably anticipate the exceptions when she/he is inherently focused on the operational aspects, is unrealistic and (probably) the biggest mistake most companies make.