Omar Mussa

SSL was added with LV2009. I have yet to upgrade to the new version. Once I do, I will investigate how SSL integrates into this tool and post a new version. Hopefully, I will get to this in the next few weeks...

Elijah Kerry created a great post about how to setup SSL for Web Services here.

I'm using Data Value References to my LVOOP objects and finding that one major pain point is that I can't dynamic dispatch using Data Value References. This results in me creating a lot of public byRef VI method wrappers to protected byVal methods in order to get the dynamic dispatching benefit of LVOOP.

I asked Stephen about this at NIWeek and he mentioned that the rationale for not allowing dynamic dispatching was going to be updated on the 'Decisions Behind the Deisgn' document -- but I couldn't find the rationale so I'm basically asking again here for public benefit. Is this a feature that could be implemented in the future or is there something fundamental that prevented this from being implemented?

Whooo Hooo, it came through!!

Congratulations!

Anyone have other ideas? Or has this one already been solved and I just wasted a half hour making pretty screen shots?

I have some suggestions.

• One thing you may want to look at is Endevo's UML modeling tools. They have some interesting ways to document state machines, but this is more useful for modeling state transitions as opposed to state inputs.
• Another thing you should consider is the design of your actual states. I may have just not looked hard enough, but it looks like you evolved into a pattern where you are passing your entire state machine data cluster in/out of each state VI. This is actually contributing significantly to the complexity of documenting your API. I would suggest that you consider changing your API to VIs within each state in some way such that you are no longer doing that.
• You might consider moving to a different state machine template. I will make a shameless plug for our own JKI State Machine as its free and has received a lot of praise by the LabVIEW community (although it may not help you solve this particular aspect of documentation, you will find it has a lot of nice self documenting aspects related to state organization and it integrates with the Endevo UML tool as well).

That was only the start...

Nice work!

Just to prove that it is technically possible:

You actually could make a RCF plugin for this one

I discovered this when my executable wasn't working. I opened the VI and found that somehow some string constants in arrays in a cluster got wiped out (the arrays were emptied). This has happened a couple times now so I'm sure it wasn't a goofy slip on my part. There's no way I could have cleared 5 arrays without knowing it. Has anyone had something like this happen.

It depends... Is your cluster also a type def? - if you edit the type def, you may lose the string array constant data. Even if it is not part of a type def, editing the cluster could result in your string data being lost. You may want to change the way you are initializing the data -- either loading it from a file or manually bundling in the data to prevent changes in your cluster from affecting the string array values.

This sounds extremely interesting! Are you able to elborate, give a sneek peek or show us a demo vid (jing)?

Unfortunately, we don't have anything to show yet because mostly we have design patterns that still need to evolve a little before they can become 'tools'. Generally, what we have done is utilized Windows API calls for keyboard and mouse emulation and used control references to validate the properties of UIs that we care about.

I would like to see some designs/implementations that allow for hardware simulation for automated Unit Testing.

Part of test driven development will always come back to design. One of the key benefits of unit testing in general is that it forces you to think of your code in terms of APIs. Your unit tests are actually testing the API to your internal code. If you can't test your code without hardware, you don't have a good API to your application logic code. There are different ways to enable simulation: Adding a simulation input (or property), using LVOOP and inheritance to create a simulation implementation of an abstract class, etc. Creating unit tests forces you to think about your code's interface at an early stage (or even at a later stage when you may need to refactor code and want to validate that it isn't broken).

One thing that I think works particularly well in VI Tester is the ability to use the test harness (VIs that are called before and after each test) to do things like set a simulation flag so that your tests run your VIs in simulated mode.

Appart from the hardware issue, I wonder how to deal with UIs.

At JKI, we currently are able to do UI testing using VI Tester and are running these tests to validate certain VIPM features. Adding UI testing capabilities to VI Tester is on our roadmap.

I was experimenting with Unit Tests without any framework yet, just to understand how it works.

I really recommend that you investigate whether VI Tester would meet your needs, trying to create unit tests without a framework is a fairly arduous task and will ultimately cost you more time than investigating tools that already exist. You may as well leverage the years of effort that have gone into the existing tools rather than start from ground zero. Besides that, VI Tester is free, so there really isn't a barrier to entry

PS - Unit Test? What's a Unit Test? We don't need no stinkin' Unit Tests! (I misread Mr. Mussa's poll as "NO Unit Test Framework" and voted for that. I've since fixed my answer.) That feels like another purchase request that would be shot down. At least there's an alternative.

Maybe I should have had 2 options -- 'None' and 'What's a unit test?' ... polling is a tricky thing to do right I guess.

Would you explain it better?

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.

P.S. the really problem what I have is to extract a testing unit from a whole project for testing. I use many hardware and parallel loops with QSM, so...

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.

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

Do anybody know how to put a picture into the middle of message? I want to implement smilies now.

Looking at the Skype model, the user only enters text into the input box, the graphic is only rendered in the chat/history.

And I can’t wait till the NEW RCF (Right Click Framework) Comes out.

And now you're waiting can end

http://decibel.ni.com/content/groups/jki-right-click-framework-for-labview

I just got my CLA results back today and I PASSED!!!!!!!!

Congratulations!

Your best bet may be to use a listbox instead of a string indicator. This would make coloring each line trivial. Check out our JKI tutorial based on how we alternated colors for VIPM.

I never really posted in the LAVA Lounge before, but since its LAVA 2.0, I decided that I need to reinvent myself as well

http://www.collegehu...m/video:1913584

QUOTE (Val Brown @ Jun 5 2009, 11:00 PM)

Is this tool separate from OpenG or does it require OpenG?

It is a JKI Product, it is separate from OpenG. You can find the requirements here. The tool does require that you have VI Package Manger installed. The installation instructions for the TortoiseSVN tool are here.

QUOTE (Ic3Knight @ Jun 5 2009, 12:55 AM)

Hi All,

Thanks for the comments. The Jury's still out for me on the "lock-or-not" argument. I'm going to have a sit down with the other two guys who will potentially be working on the code on monday and we'll make a decision then. For the moment, I'm still just playing with SVN. I've got a project that only I will be working on as well, so I've set that up in SVN, currently for merge rather than lock, so I'll see how I get on with that too...

We don't use locking at JKI and we haven't had any issues - whenever there is a conflict (which is fairly rare), we manually resolve the conflict. Generally, the best way to avoid conflicts is to be careful about doing mass compile save all type of operations that result in a ton of VIs that have *changed* because it may interfere with other developers when you commit.

Also, in case you haven't noticed, we just released a new http://www.jkisoft.com/tortoisesvn-tool/' rel='nofollow' target="_blank">TortoiseSVN tool for LabVIEW. It provides really tight integration of TSVN with LabVIEW and is really well suited for the update/commit SVN model.

QUOTE (Yair @ Jun 4 2009, 11:23 AM)

While we're at it, it would probably be nice if the JKI presentations also did this. I've told NI people a few times that it would be nice if they did this too not just for the keynote, but there's no reason why the outside presenters shouldn't be able to do this for their presentation.

JKI started recording our presentations last year and will definitely be doing so again this year. Here's a link to last year's (2008) JKI presentations at NI Week:

http://jkisoft.com/niweek/2008/

There is actually a method for updating cell data for a table. Use an invoke node and you will find it. It allows you to update a single cell without updating the whole table.

I added my response on the JKI Software Forums.

QUOTE (ShaunR @ May 9 2009, 03:37 PM)

And (from what I can tell) to use the class abstraction, I need to wrap every function that is already supplied by the manufacturer just so I can use it for that project. Take the Agilent 34401 example in the examples directory for instance. If I want to use that in your Architecture, do I have to wrap every function in a class to use it rather than just plonk the pre-supplied vi's into my app which is pretty much job done?

While you can choose to wrap every function into class methods, that is not usually an abstraction method that works well. What you should do is consider what things you tend to do over and over again and create abstractions for those items.

For example, let's say you want to create a DMM class that supports Agilent and NI DMMs in your application. Both of these DMMs have completely different drivers required for configuring a voltage measurement, but essentially, they both perform the same operations. You can create a DMM.Configure Measurement method with an Agilent (Agilent.Configure Measurement) and NI (NI.Configure Measurement) implementation (and Simulator, and future hardware you haven't yet purchased, etc). What's nice is that you separate your application logic from your instrument specific drivers that 'implement' that logic.

This is what object-orientation is all about -- irrespective of Daklu's 'Extraction Architecture'.

Daklu's architecture is trying to go one step further -- so that if you have other instruments that have overlapping functionality, you can implement an interface (exterface) that both of the instrument classes would implement (feel free to correct me if I'm wrong). I'm not sure how succesful his implementation is, I briefly looked at it but did not look long enough to fully understand it.

QUOTE (hooovahh @ Apr 16 2009, 05:37 AM)

It seems that alot of the things they make are aimed at beginners and usually aren't the kinds of tools I would use. That's not saying I don't use NI toolkits, I'm just saying that I realize NI would probably rather make things that bring in new customers rather than making tools to help their existing customers.

I'd have to say that NI has done a decent job lately (last few years) of creating tools that are aimed at their existing customers. I'm not actually using these toolkits right now, but if you look at the state-charts, execution-trace, unit-test, etc. they are not targeting any of those toolkits at "new" users of LabVIEW.

The easiest way to do this is to use the JKI EasyXML toolkit. You will save yourself a lot of time.

You can find more info here:

http://jkisoft.com/easyxml/

Let us know if you have any other questions.