Darren's Weekly Nugget 07/19/2010

[DFGray]

JackDunaway has some valid concerns.  However, I agree with previous posters that individual accessor functions are the way to go despite the increased number of subVIs because the ease of maintenance they bring overwhelms the disadvantages.

For FTP deployment, I would recommend using LLBs.  This would allow dramatic reduction in the number of files.  However, it does not solve a couple of other issues a large number of small VIs introduces - larger code size and slower launch time.  I wrote a nugget on solving this awhile back, but the solution (inlining) cannot be applied to LabVIEW objects since if you inline them, they break (you cannot access member variables in a nonmember VI).  LabVIEW R&D is aware of this issue and is working on several approaches to mitigate it.  Even so, the ability to precisely define an API and update individual item access makes using objects almost required for large program development (meaning more than one developer).  This ability has saved me on more than one occasion and caused endless headache when I did not have it on other occasions.

[Ben]

So why wrapp up NI functions?

Super-Robust Code!

If we are anal-retentinve about doing file I/O "RIGHT" we should be check if file paths are valid track if a file is alrady open before trying to open it and many other task of that type. For "one-off" apps we can often skip the robustness and code it to work. But becuase I built all of the checks and error message into the class "File" the Config and TDMS Class inherit these atributes and I NEVER hHAVE TO CODE THEM AGAIN".

But then the next project cam e along and it needed to right to a tab delimted spread sheet. This let me add "Text" and "Spreadsheet" to my hierachy. Similar the next project had a custom file format for its "Cal Data" and since the reference file had a very similar format, the "Ref File" (Note: "Ref_File" only has 6 unique methods !).

But it did not end there.

I neede to acquire from a NI USB DAQ widget. So I needed a new hierachy for Hardware. But alost all of my DAQ apps require some type of configuration that is specific the the widget. So I started the Hardware Hierachy that supports Configuration files as well as being able to run in "Simulate" mode.

 

So the Hardware hierachy takes advantage of the Config Class functions from the File hierachy and it realizes all of that functionality.

Next I had to be able to interface with a Cheetah interface to talk to some SPI slaves. The Dll branch was cloned from the "DAQmx" class and simliarly with its childeren.

So I hope the personal experience with LVOOP helps convince others that

"The more I LVOOP, the more powerful my library becomes and the less I have to code."

Ben

[Ben]

---

@JackDunaway wrote:

I'm carefully watching this conversation because it addresses one of my primary hindrances for not choosing mainstream LVOOP in my development: the relatively low node-to-file ratio.

...

---

 That is a plus in my book.

LVOOP implements dynamic dispatching at the VI level so the more granular the code is the the greater oppertunity for LVOOP to shine.

Ben

[Intaris]

Jack,

what do you mean by "node to file ratio"?

[Ben]

---

@shew82 wrote:

... 

It also makes it a whole lot easier to add bugs into your app - I'm sure I'm not the only one who has changed a type def cluster to later find at least one or two bundle/unbundle by name nodes got confused with the change.

Shaun

---

Agreed and using LVOOP the oposite is true in that re-using the Classes for other apps result in the code getting better.

Example:

My Config Class was fine until I started implementing the third party dll. All of the example VI's for that drtiver used rings to control settings. My Config Class was not used for many of these so no speial functions were implelented to help out. But after coding up one ring translator (with error checking of course ) I realived this was a handy method and it got added. So once again, the more I use the Classes, the more powerful they become.

Ben

[JackDunaway]

---

Intaris wrote:

what do you mean by "node to file ratio"?

---

Generally speaking, the number of "things" on your block diagram. An accessor has got just a few nodes... class data in and out, an Unbundle by Name, an indicator for the data, and perhaps 'error in' shorted to 'error out'.

On the other hand, to find some block diagrams with (absurdly) high node-to-file ratios, visit the Rube Goldberg thread.

Coding on either side of the spectrum introduces workflow problems, and Darren has pointed out the flaw that LVOOP operates on the low-end of the spectrum. There is a happy medium, and I would like to hear some brainstorming on how to address this issue. If the consensus is that his solution is not the best, could you suggest an alternative?

(Thanks DFGray for the suggestion about the LLB's, but now we're introducing another construct that is shrouded in controversy over advantages/disadvantages. I'd like to hear more ideas along these lines....).

[Ben]

---

@JackDunaway wrote:

---

Intaris wrote:

what do you mean by "node to file ratio"?

---

Generally speaking, the number of "things" on your block diagram. An accessor has got just a few nodes... class data in and out, an Unbundle by Name, an indicator for the data, and perhaps 'error in' shorted to 'error out'.

On the other hand, to find some block diagrams with very high node-to-file ratios, visit the Rube Goldberg thread.

Coding on either side of the spectrum introduces workflow problems, and Darren has pointed out the flaw that LVOOP operates on the low-end of the spectrum. There is a happy medium, and I would like to hear some brainstorming on how to address this issue. If the consensus is that his solution is not the best, could you suggest an alternative?

(Thanks DFGray for the suggestion about the LLB's, but now we're introducing another construct that is shrouded in controversy over advantages/disadvantages. I'd like to hear more ideas along these lines....).

---

Node to file ratio:

When I was a rookie we had a developer that had been published in "LabVIEW Technical Resources" who had a magic number of 10-12 objects on a diagram. Above that it was hard to understand.

Advantage: One file to transfer.

Dis: Large files sometimes have trouble getting transfered to the RT targets. During development, a sinlge file corruption can loose a lot. Can't just grab one file to re-use but LVOOP does not encourage that.

Ben

[Ben]

And to explain my post flurry in this thread...

My wife left me home alone with a case of beer, LV and my laptop this past week-end. I imersed myself in LVOOP and was coding until 3:30 Sunday morning. There is nothing like total imersion to get new stuff into my head.

Ben

[Intaris]

Ah, thanks for the clarification.

So for you the fact that the accessor VIs are essentially doing very little that the need for their existance is questionable?  But each and every accessor VI is doing something very important which is not expressed as LV nodes.  It's giving tailored public access to private (or protected or public) data within an object.

I actually find the fact that the accessor VIs required being largely pre-defined (Override VIs mostly) coupled with the relatively simple content of the VIs makes debugging much easier.  But an accessor VI does not HAVE to be so simple.  It's completely possible to build a class which does some crazy things when calling its accessors.  It's normally not the case, but who knows what we'll dream up in the next few years as LVOOP (or at least our usage of it) matures a bit more.

VIs let us break up our code into bite-size (or nibble-size in the case of LVOOP) chunks which can be individually tested (A great inherent feature of LV).  I don't see how having little code in the VIs is inherently a problem unless you want to address the aspect of overhead for a VI call versus an unbundle-by-name.... As payback you get a much cleaner interface to different parts of your code.

For me at least the advantages hugely outweigh the disadvantages.

Shane

[Intaris]

---

@Ben wrote:

My wife left me home alone with a case of beer...... There is nothing like total imersion to get new stuff into my head.

Ben

---

Lemme guess.

You took a bath in the beer?