Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Functional Programming / Immediately Testable VIs

swatts
Active Participant

Hello Lovelies

Out of all the presentations I have produced I like the immediacy one the best. In it I talked about functional programming and what I now call Immediately Testable VIs (ITVI). Thanks to James Mac for the terminology clarification.

 

The thing for me that makes LabVIEW stand out from the software crowd is how close you are to the final running bit of software.

 

Let's look at a simple VI.

SimpleVI.png

We can tinker with it, probe it and change stuff. If you program in text based languages this is pretty fantastic stuff.

 

Now we stick a framework around our code, giving us all sorts of useful stuff. But with every benefit, there is usually a cost.

 

As an example I'm going to pick on Actor Framework but I imagine this applies to any framework (including our own SSDC templates). All of the Actor framework projects I've been exposed to have a very low percentage of VIs that you can just run and experiment with. To clarify it means that a VI cannot run on it's own, it needs the whole or part of the framework to be running to be able to run itself. I call this Framework Coupling.

 

Variant.png

Here's our queue component and it is a non-ITVI, to test this VI I would need a teststub or to run the entire application.

 

As we design we need to think about framework VIs and ITVIs and we need to keep them separate. That way we can get all the advantages of LabVIEW in the parts we need it and the carrier VIs etc for your framework just get on with their work.

 

So here's an example from a client, they had an actor that talked to a VISA instrument and the comment was "I like Actor Framework but it's hard to debug", my response was to suggest putting all the VISA stuff in a standard VI that you can just run to completion. I then suggested that they should then separate out framework VIs from VIs that do stuff. And magically it wasn't so hard to debug any more.

 

I know it's a pretty simple concept, but I've described it to enough experienced programmers and it's been helpful to them, maybe it will help you too.

Lots of Love

Steve

 

 

 

 

Steve


Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop


Random Ramblings Index
My Profile

Comments