FGVs, Action Engines and DVRs: a rif on Nancy's NI Week presentation

[Rolf Kalbermatter]

I'm completely on the page with you in most everything you say on this topic; however, I might use the word "prejudiced" instead of, or perhaps in addition to, "ignorant".  One thing I would disagree with is you last point.  IF you come from an OOP background -- eg having grown up in a contemporary CS program, THEN FGVs become an additional tool; however, IF you don't have that background and/or are a domain specialist THEN my strong suggestion would be to begin with FGVs.  They are a much easier starting point given the history of LV and the multitude of legacy examples that are available from a number of sources.

 

If you're not from an OOP background AND you're a domain specialist who just wants to get the bloody thing done, FGVs are the way to go.  In any event, you and I are good examples of that, as are many, many others.

 

Maybe I was a tadbit to modest here.    Thinking about it you are of course right. FGVs are powerful and are easier to learn for someone not knowing much about OOP. The problem is that without some OOP knowledge such a person is likely to either get stuck at the "set/get FGV with a little extra functionality level", or starting to create FGV monsters at least in the beginning. So while the initial learning curve to start using FGVs is fairly easy, doing the real powerful designs is just as a steep learning curve than learning LVOOP, with the difference that LVOOP comes with some tools right in the LabVIEW IDE to ease the more automatic tasks and FGVs generally have to be created each time manually. Also the separation of methods and data is a definitive advantage and thanks to the project integration also easy to manage.