LV class instead of big cluster?

[J-M]

In the early version, I utilized a big cluster to carry data for my PDF report.  The size of this cluster increased and after a while I switched to a  Xcontrol (mainly to minimize the size on front panel - probably not a really good reason).

I read some tutorials and posts and it seems for me that LV class will be the best way but I am not totally convince (and I have no experience with LV class).  Any advices  will be appreciate.


Regards


Jean-Marc

[DFGray]

Using classes instead of a cluster is certainly possible, but, since you have a working system, and your interest seems to be almost purely cosmetic, I am not sure it is worth the effort.  If you were planning on supporting several classes of documentation (e.g. PDF, Microsoft Office, Open Document, HTML, etc.), or several operating systems, then it would definitely be worth the effort.

Note that you can reduce the size of a cluster on the front panel by simply not showing all of it.  You can debug much more easily if you create a custom probe with a tab control to cycle through the different parts of your cluster.  This would also allow you to stop using the XControl.  There is no real reason to use it, other than version control (which may be important).  LabVIEW objects will also give you version control.

For a new development, I would probably break the cluster up into several classes, and use a top level, aggregator, class to contain them.

[tst]

Even if you do use classes, you might want to consider voting for this idea - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-clusters-to-have-quot-pages-quot/idi-p/1481862

[Ben]

If this project is on-going and you expect more changes and you have the time/funding then I suggest you go fo rthe LVOOP route.

I have found that introducing LVOOP has helped with changes and modifications (provided I pay attention to OOP rules) since I don't have to re-test old stuff and only have to test the new stuff that I recenetly added. OVer-Ride VI's also give the option to change only a part (of what would have been a monlith in non-LVOOP) of the fucntionality while keeping previous uses un-touched.

Quick example:

Today I am harvesting code from a LVOOP project with many of the classes re-usable in future apps. The Classes and hierachy in this app started out doing simple DI using NI DAQmx. I included a lot of error checking and reporting along with some extensive configuration options( to allow for quick re-use in another hardware configuration) as well as simulation mode.

That same hiarchy was modified to add DO to the mix (ho-hum) AI, AO (still not impresive) GPIB (note:Same code used as in the previous Classes) as well as SPI utilizing Chetah interfaces as well as virtual devices that are agregates of some of the previoulsy mentioned Classes.

To add the addtional support I created new braches of the Class hiarchy with over-ride methods as required for the new versions.

Yes there are some methods that are unique, but generally speaking everthing from "Run" through initi config and start are all the same to the VIs that use those classes.

Ben

[J-M]

Thanks for those informations. I think I will go with LV Class. It is a personnal project and I have all the time I want...

Jean-Marc