Joe Jasniewski Posted June 9, 2003 Report Share Posted June 9, 2003 I have not "kept up" with the latest advances in how to structure a program in LabVIEW. My greatest evolutionary jump was to embrace the state machine form and force myself to think in terms of a state queue and state variable cluster. So I have been coding away watching versions 6, 6.1 and now 7 go by. I seem to be doing just fine, without using any of the alternative archetecture functions. By these I mean basically ALL the program structure functions under Advanced- -Semaphore -Occurrences -Notification -Queue (NI's implementation) -Rendezvous -First Call Does anyone have an opinion on what the NEXT evolutionary jump would be after the embracement of the state machine archetecture? If more than one, what would be the order of importance, from your own experience or in general? Does anyone have or could recommend a course, book titled something like "LabVIEW Advanced programming - Beyond the state machine"? Subtitled: "How not to let your technique sink right out of sight, as LabVIEW evolves" or "For those who have neither the time nor inclination to tinker with every single element provided on the Functions palette, until they have a clear understanding of what it does and how to use" Best Regards, Joe Jasniewski Quote Link to comment
westj Posted June 10, 2003 Report Share Posted June 10, 2003 I believe that the next evolutionary step for Labview will come from better design techniques. The programming language has all of the elements necessary. Labview programmers need to embrace Object oriented design techniques. (OO) In mainstream software projects, OO design has proven to be a flexible method to accomodate requirement changes and provides a organizational dividing line for members of the development teams. Labview developers have not needed these design techniques since they typically are working on small applications. For many Labview developers, functional design techniques are comfortable and arguably appropriate. Functional design techniques began to fail when they were applied to large applications which require more than a few programmers. Unfortunately, OO development requires a certain level of domain expertise; that the average Labview programmer may not have or need. The GOOP toolkit is a step in the right direction. The toolkit provides some building blocks for OO design. I encourage you to study this toolkit and think about how would you describe your software in terms of objects and their lifecycles. The books I was trained on are vintage now. Newer books may be more appropriate. "Object-Oriented Systems Analysis..." and "Object Lifecycles..." by Shlaer and Mellor. Jim West Quote Link to comment
Joe Jasniewski Posted June 10, 2003 Author Report Share Posted June 10, 2003 Jim, Thanks for the reply. I'm certain that it is the small project aspect of what I do that has enabled me to get by with less than an optimal technique. Generally, I am going it alone. However, I would like to leave a legacy of readable, maintainable code, by anyone minimally trained in the art. This has actually led me to avoid the use of "the latest and greatest" functionality available. On the other hand, I dont want to be crippled should I come across code where someone used all the latest stuff; I look at it and realize I have no idea what's going on. So to all the advanced LabVIEW programmers out there, what's the next step, generally, past the "state machine" in general program archetecture? Can anyone say "well, I'd make use of notifiers, then semaphores, then rendevous and I think the value of "first time run?" is obvious" this might help me with the next set of specific LabVIEW functions to study. As far as the Object Oriented stuff, at this point I dont know the difference between a Function and a Life-Cycle. I'm sure I could guess by analogy, but my question was more directed at the specific "Advanced" functions provided by NI on the Functions palette, relative to programming methodology. If these are the elements that allow OOP and you have to know or have studied OOP to be able to grasp what they do conceptually, knowing that would help me too. Best Regards, Quote Link to comment
Jim Kring Posted June 14, 2003 Report Share Posted June 14, 2003 I have not "kept up" with the latest advances in how to structure a program in LabVIEW. My greatest evolutionary jump was to embrace the state machine form and force myself to think in terms of a state queue and state variable cluster.So I have been coding away watching versions 6, 6.1 and now 7 go by. I seem to be doing just fine, without using any of the alternative archetecture functions. By these I mean basically ALL the program structure functions under Advanced- -Semaphore -Occurrences -Notification -Queue (NI's implementation) -Rendezvous -First Call Does anyone have an opinion on what the NEXT evolutionary jump would be after the embracement of the state machine archetecture? If more than one, what would be the order of importance, from your own experience or in general? Does anyone have or could recommend a course, book titled something like "LabVIEW Advanced programming - Beyond the state machine"? Subtitled: "How not to let your technique sink right out of sight, as LabVIEW evolves" or "For those who have neither the time nor inclination to tinker with every single element provided on the Functions palette, until they have a clear understanding of what it does and how to use" Best Regards, Joe Jasniewski Joe, Regarding the question of "What's the next step after state machines?", I believe that it is component-based architectures. These use the OOP principles of encapsulation and modularity to aid in application design and maintenance. Although components may utilize highly complex messaging, internally, this complexity is not exposed to the users of the components. If you are interested in looking into using OOP techniques in LabVIEW you might find the links, below, useful. Graphical Object Oriented Programming (GOOP) OpenGOOP - OpenG's GOOP framework I would also take a look at the examples of each of the tools on the Advanced >> Synchronization palette. These are the tools that enable messaging and event driven programming. Messaging and Events enable functionality that is not possible with dataflow, alone. It allows you to define timing and data-flow relationships that are not transmitted through LabVIEW wires. Once you have a grasp of the basic tools for messaging and events, you should invest some time learning the frameworks, architectures, and patterns, which utilize them. Good luck, -Jim Quote Link to comment
David Wisti Posted January 16, 2006 Report Share Posted January 16, 2006 I have to agree with Joe and Jim, OOP is the correct direction. However, there has been some advances from the queue-driven state machine. One of which I use quite often is the event-based queue-driven state machine. NI has called this "Producer Consumer with Event Structure and Queues." More information can be found here Link Quote Link to comment
WMassey Posted February 26, 2006 Report Share Posted February 26, 2006 If you are interested in looking into using OOP techniques in LabVIEW you might find the links, below, useful. Graphical Object Oriented Programming (GOOP) OpenGOOP - OpenG's GOOP framework -Jim Jim, The two links you referenced no longer work. Can they be fixed? TIA, Warren Quote Link to comment
Jim Kring Posted February 27, 2006 Report Share Posted February 27, 2006 Jim, The two links you referenced no longer work. Can they be fixed? TIA, Warren We are looking into it. A transfer of the site to a new server has given us some grief and we have not yet been able to resolve this issue. Thank you for your understanding. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.