Leaderboard

Just wondering what kind of unit testing frameworks LAVA members are using.

Hi, I use this when I need to open the BD of a specific VI. I think you can then use the property "BlockDiagram.OSWindow" to get the ref and then use it with the user32.dll to make the window frontmost. See attached VI who does the same for a FP. ViBox_860_User32_BringVIsFPToFront.vi Hope this helps

I just got my grades for the Certified LV Developer exam. Passed! Woot! But even more exciting: I turned in a pure OO solution to the problem. No naked VIs -- meaning every VI in the hierarchy was a member of a class, every ounce of functionality in my application was delegated to one particular object to manage. All objects were passed using dataflow -- the queues of objects that I had were mono-directional, for communication, not for data storage. I obviously cannot discuss what the exam question was, but the heart of the application was a message passing interface like the one described by Yair recently on LAVA. I am very pleased with how the OO features of LV responded. Under standardized conditions, such that we can directly compare against a traditional solution, in the same time, I was able to generate an application with better than traditional flexibility (able to plug in new messages into the system without modifying the framework) and with accepted run-time performance. And the single biggest time sink that I had is being worked on by an intern even as we speak. ;-) I am fairly certain this is the first pure OO solution submitted for the CLD, and I was a bit worried about the solution being accepted given that part of the CLD is to grade knowledge of the accepted standards of LabVIEW programming methodology. Apparently, three years since its release in LV8.2, OO passes that test. The clock now begins, counting down until the day when a non-OO solution is not accepted. Not everyone is as much a believer in OO as I am, but OO has slowly consumed every other programming language it has been introduced into. It will definitely be years away from today, but I believe it will happen. For those who have not joined the faith, I'll be serving Koolaid at NI Week. ;-)

Click Shift+Enter when you get to the end of the area and the string constant will become a multi-line string. Unfortunately, that doesn't work with comments, where it's much more commonly needed.

That must be the hWnd in other languages. By specifying "0", it's effectively the same as "null" is text languages, thus creating a new one. Under Windows, it's "h" for handle... I guess it is called "host" to be more cross-platform.

Because that's not unit testing, and you can't get traceable results from that style of adhoc testing. What you've described is debugging, not unit testing.

Of course you have it if you have a recent Windows machine. How to use it I wouldn't know myself. As to the OGIC supporting SSL: Forget it! Implementing SSL is a very serious project in itself, with many implications. Doing that in LabVIEW is a complete nogo, not because it would not be possible but because of a number of other reasons, two of the most prominent are: 1) It is a huge undertaking that would require man years of work. 2) Encryption software is a difficult business that can only work if there is peer review by a broad community or at least by a panel of real experts on this subject, and guess what those experts wor mostly for profit within specific companies. The only feasable option would be to use an existing software such as OpenSSL and link it into LabVIEW. However the OpenSSL API is not really meant to be linked into a system like LabVIEW, requiring things like callbacks and such which makes an interface to LabVIEW a lot more complicated than just implementing some Call Lbrary Nodes. The easiest thing I have found to do (still not trivial) is to actually use an external application like putty to implement the SSL connection and then connect to it through the OpenG Pipe library from within LabVIEW. Rolf Kalbermatter

There is a whole world of difference between the LabVIEW Probe and Highlight Tools and Unit Testing. The former are aids to help you find and debug problems, the later is the basis of a whole software methodology. I have not yet used and Unit Testing in LabVIEW but I have see extensive benefit's of its use to other projects. One key benefit is Regression Testing, how do you check that what you change today does not break something that was working yesterday. I once worked on a very large C/C++ project (100+ developers) that was was run under the Agile Software Methodology. Before any code was written the Unit Test Software for that code had to be written. When a developer finished some code and checked it into their source control system we used Curise Control to automatically do a build and run the full test suite on the software, if any tests failed automatic emails were fired off. With this system we know within an hour that something that used to work had been broken, and it was easy to find out what changes cause that break. So as I said at the start there is a whole world of differnce, between these tools. Dannyt

Hello, I'm using Labview 8.6 and Labview Vision, with a AVT Marlin camera that should be capable of getting a frame rate of >60FPS. I wrote a simple program in labview to grab the images from the camera with IMAQdx and display it on the front panel. I used a stacked sequence to measure the frame rate. When I set the frame rate of the camera in the Measurement & automation explorer to 25FPS or lower the framrate in the labview program is correct. But when I set it to 30 or higher, then the labview program stayes on 25FPS. But the mode I selected is correct acording to the labview program. What am I doing wrong ? See attachment for the program Greetz,

Hi Ammar I think what you want to do can be achieved with a vi like the following. Each time the date changes a new data file is generated.

I've used VI Tester for various side projects--mostly to learn how to use it and what it can do. I haven't applied it in a structured way to any real world problems though. Because the Probe and Highlighter are very slow debugging tools with large complex applications. If you have a good suite of unit tests it will help you quickly find bugs.

Here's a reference on what unit testing is all about: http://en.wikipedia.org/wiki/Unit_testing My summary is this: unit testing is a software engineering process for validating that your code functions as expected. You basically write tests to validate that your code works as expected, if your tests fail then you update your tests or your code until they pass. If all of your unit tests pass, then you have a level of assurance that your code works as you expect (as defined by the unit tests). What is useful about unit testing is that if you need to change your code (say, to make a sequence into a state machine), and you have created unit tests, you can validate that none of your changes have caused you to 'break' your previous logic simply by re-running your unit tests. In order to make you application logic more easily testable from your hardware interfaces, you may need to consider how you will test your code when you design your code. For example, you may want to create a simulation mode or abstraction layer that lets you test your application logic with unit tests, independently from your hardware interface code.

Hi Bjarne The Open Source GOOP Templates that GOOP Developer uses to build classes was developed by SciWare and JKI before LVOOP was around and doesn’t use LVOOP in any form. The differences between the two are. Advantages You can develop OOP systems for RT platforms.Building your system to an exe is really easy, just add your top level vi and then build. Building a system that includes LVOOP is a more complicated process. It’s a by reference implementation, LVOOP is natively is by value, although there are LVOOP frameworks that will give you by reference implantations see Endevo's GOOP Development Suite (GDS). You can create Active Objects, i.e. each instance has its own process running in the background. However there is a Design Pattern in GDS that I contributed to with Mikael Holmström that will allow active objects. You can develop in LabVIEW 6.1 and up.The GOOP Templates are open source under the BSD open source license. Disadvantages You have to be vigilant about keeping your interfaces between parent and child methods the same, there is no development environment mechanism that will warn you, like LVOOP does. You cannot easily shift inheritance from one class to another. In GOOP Developer you build a child from a parent. Super Messaging is more elegantly implemented in LVOOP.You have the ability in LVOOP to make methods private or protected. A method call in LVOOP is faster than that derived from an existing Open Source GOOP Template.

Ummm, the code that I'm writing for the presentation... Yes, it'd be great if there was a central replacement for the current error handling schema, but I'm presenting a method of extending the current native implementation into something more comprehensive. NI doesn't have to do it, although I'm hoping that the result of my presentation will be community discussion and perhaps the design of a new schema that NI might want to adopt. NI certainly isn't against the idea of us helping them grow their product, and this is an opportunity for us to tell them what we don't like about the current implimentation and give constructive ideas on how to make it better - I figured the best way to do that was to build something ourselves that will either be leveraged directly by NI because of how awesome it is, be a catalyst for something else due to how okay it is, or be a warning on what not to do based on how crap it is.

Done! There's been an OO training course available for a year now. Ask your local sales engineer to sign you up! We have a really really really good Fundamentals of OO document that is part of LabVIEW's online help -- and has been since we first released in LV 8.2... the tech writer won awards for that bit of documentation. It is both a "why should I do this" and a "how do I do this" manual. Online, we have the LVOOP FAQ and the Details Behind The Design documents, both of which have been updated for each LV release. The Design Patterns document on the community forums was developed specifically to bridge text programmers into LabVOOP. Go ye forth and learn! :-)

Congrats on the CLD and I want to underscore the book idea. This is something that NI should consider to be a priority IMO. After all the biggest criticism of LV is that it's a "toy" and that's largely because it isn't seen as a real support of OO. The status of LVOOP is now directly challenging that belief and writing the book on it would be a good opportunity for NI to communicate clearly just how capable LV really is. It would also give me a really nice running start at getting on board with it.... Seriously you code develop the code (as you've done) and someone on NI's staff to ghost the text and/or you could team up with someone (like Jim Kring) and do "LVOOP for Everyone".

Impressive! I see something ... it's cloudy ... getting clearer .... I see ... A BOOK! Yes! A BOOK in your future. "Object Oriented Programming in LabVIEW"