Jump to content

ElijahKerry

Members
 View Profile  See their activity

  • Posts

    33

  • Joined

  • Last visited

  • Days Won

    3

 Content Type 

Posts posted by ElijahKerry

  3. First post, and first LVOOP program, feedback really appreciated.

    in Object-Oriented Programming

    Posted

    Matt raised several excellent points. In particular, he brings up a valid point about the UI loop and the use of references - sometimes the simplest approach is the best one, and it's probably more than adequate in your scenario to simply wire the data to the appropriate terminals as it arrives. I go back and forth on the use of references - it's certainly nice to be able to send commands from anywhere in the system to a single process than then knows how to display them, but allowing data to simply flow to the terminal is often more readable, easier to debug and definitely more performant. I tend to use references when I know I'm going to be using a lot of VI server commands to act upon the UI anyway, especially since it's best to decouple this from other processes.

    That being said, not using references will not mitigate the potential nightmare of a very large front panel.  Depending upon how large you intend this panel to become, you should consider relegating logical groups of UI components to subVIs and displaying them in sub panels.  Put generally, when you start thinking about having tabs, start thinking about a sub-panel too.

    Matt also brings up a good point about the use of classes to represent the different busses in your system.  The command pattern is a simple way to bridge knowledge of traditional LabVIEW patterns like PC-QMH to classes, but the real power of OOP for LabVIEW users is when you have to represent multiple similar-but-different components of a system, such as hardware, measurements or in your case: busses.  The real trick is determining where in the architecture of your system to abstract functionality such that these devices can be used through a common interface that can automatically take advantage of device-specific functionality under-the-hood.  In your case, the generic command set would be defined by a base class and children would extend this by implementing the unique functionality for the bus they represent.

    I recently put together an example of using the Actor Framework to build a measurement and hardware abstraction layer system.  It's a deep dive into Actor Framework, but this blog I wrote on the design decisions I made may still benefit you as you explore HALs.  You might check it out if you have time and see if it yields any insights on how/where you would abstract components of your system.

    • Like 1
    • Popular Post
    • Popular Post

    First post, and first LVOOP program, feedback really appreciated.

    in Object-Oriented Programming

    Posted

    Hey dmurray,

     

    Glad to hear you found the command pattern example useful.  It was my first successful application using OO, so I created the manual in the hopes of leading others down a similar path.

     

    I took a minute to glance through your code, and one big question jumps out at me: are you actually passing data between these loops?  One of the major reasons to use the command pattern is the encapsulate the data associated with a command inside of a class instead of passing it as a variant.  Given that none of your classes appear to have private data, I can only assume that you aren't actually sending information between the loops.  

     

    If my assessment is correct, the use of this pattern may be overkill - though there's nothing necessarily wrong with using it. 

     

    However, your second question leads me to believe that you may actually want to pass information between your loops.  Your UI loop already contains references to front panel items you might want to update upon receive data - ideally, it only updates the necessary component upon receiving new data.  Rather than be free-running, it could respond to commands sent from other loops that contain the new value to be displayed.  As an example, you would have a class to update a graph and the private data could be wafeform data and cursor information - any other loop who had access to the UI queue could then send a command to update the value of this graph.  PS: Rather than increasing the scope of this loop as you add more UI elements, consider having sub-diagrams that load separate UIs with their own dedicated processes)

     

    Q3: One loop two sources is fine - in fact, it's what queues are best at.  Even if you weren't using the command pattern, it's common to have multiple producers of commands/data pumping that information into a queue, which should only ever be dequeued in one location (ie: the consumer).  The approach you've described for logging sounds appropriate

     

    Q4: A dialog should be treated like a free running process that has it's own P/C loops on the block diagram.  For a good example of this, see the sample projects and how they invoke an options dialog.

     

    Finally, is this the right pattern?  It's fundamentally a producer/consumer queued message handler (P/C-QMH), but we use OO instead of enums with case structures.  As such, it's just as  appropriate a as a regular QMH would be, but you're able to encapsulate the data you pass between the loops using classes (should you choose to do this).

    • Like 3

  8. Star Trek

    in LAVA Lounge

  9. Memory grab after several hours of running

    in Development Environment (IDE)

    Posted

    QUOTE (neBulus @ Mar 24 2009, 11:34 AM)

    Yup, I'm the guy. I've brought your complaints to the attention of the development team, but any additional information you can provide to help us reproduce your problems would be extremely helpful. We've addressed a number of known issues for the LabVIEW 2009 release, which is available for evaluation at http://ni.com/beta' rel='nofollow' target="_blank">ni.com/beta. There were several known issues in the 1.0 related to filtering and parsing extremely large datasets, which have been improved.

    Tracing a large application will quickly result in tremendous amounts of data and information, so we imposed the 1 million item limit to prevent users from using all the memory on their computer. However, this can be changed in the ini file, which should be located here: 'C:\Program Files\National Instruments\MAX\Assistants\Trace Toolkit\TraceTool.ini.' the parameter is MaxEvents.

    As with any software issue, if we can reproduce it here, we can fix it, so don't hesitate to let us know if you've encountered a specific problem.

  10. Code Checking

    in LabVIEW General

    Posted

    VI Analyzer is being removed from Developer Suite Core, but the price of the standalone toolkit has not changed. We are investing in new functionality for the next version of LabVIEW that warranted moving it into a new Developer Suite Bundle for Software Validation Tools. This bundle also includes the new Unit Test Framework and the Desktop Execution Trace Toolkits and offers roughly a 40% discount over the cost of these tools individually.

    In the meantime, those of you who have VI Analyzer through a previous purchase of DevSuite Core and are still subscribed to SSP will still be able to activate the version that came out in Q1 using your previous serial number.

    Hope this helps

  12. What is your LabVIEW application development process?

    in LAVA Lounge

    Posted

    I'm personally very interested to see where this discussion goes. I know that requirements management is a difficult, and all-too-often overlooked aspect of software development. It seems that in the real-world it's very much an iterative process between working with customers, developing a prototype or proof of concept, and documenting findings towards developing specifications.

    Check out the new group on ni.com dedicated to large LabVIEW application development. We're just getting it off the ground, but we're hoping to leverage the expertise of those of you working on large applications and struggling with topics like requirements management and code validation, to share your expertise and your knowledge.

    Here's a question for everyone on this thread: imagine that you were in charge of coordinating 5+ developers on a single LabVIEW application. How would you do it and what are some of the biggest challenges you think you would face in this task? How, if at all, different would these be from the challenges you would encounter with any other development environment? Have any of you coordinated or been a part of group development on a single project?

    I'm glad to see the launch of the Software Engineering wiki on LAVA. You may find some value in reviewing the content c. relf pointed out at ni.com/labview/power

    QUOTE (jgcode @ Dec 8 2008, 05:16 PM)

    It's true - we're preparing to release a new tool aimed at helping developers perform automated unit testing and even requirements based validation. We plan to make these products available in Q1 of 2009, but I would encourage you all to join the http://ni.com/beta' rel='nofollow' target="_blank">beta program for these tools - be sure to select 'LabVIEW Software Engineering Tools.'

    The idea is simple, but the use cases allow for advanced testing. You define test vectors consisting of pairs of inputs and expected outputs and effectively run the VI and compare the results with what you had anticipated. This goes beyond troubleshooting because it's not just about demonstrating to ourselves that it works, but it's about proving to someone else that it works exactly as defined, which again ties in very closely with how you define your requirements and how granular they are in so far as describing expected behavior. This tool is also likely to prove valuable for those of you interested in regression testing.

    Sign up for the Beta and download the video tutorials along with the installers. You'll see another tool for dynamic code analysis is also available as a part of this program. This tool will help identify the existence and source of issues such as memory leaks or where un-handled errors are coming from.

    Hope this sounds like something that will prove useful for those of you who mentioned test driven development.

  13. Article - Fighting Corruption: Using Source Code Control Systems

    in Source Code Control

    Posted

    I just wanted to make sure that everyone on this thread is aware of some articles that might be useful concerning Source Code Control and LabVIEW. Here are a list of a few. Note that one is actually a wiki article on ni.com that is open for editing and community contribution.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.

  I accept