Jump to content

abrink

Members
  • Content Count

    16
  • Joined

  • Last visited

  • Days Won

    1

abrink last won the day on October 25 2014

abrink had the most liked content!

Community Reputation

1

About abrink

  • Rank
    Active

LabVIEW Information

  • Version
    LabVIEW 2012
  • Since
    2007
  1. Time for another on-topic update! I've been playing around with the concept of 'simple' modular labview code, focusing on flexibility and ease of development. After many revisions, the basic module design has come down to a somewhat surprising layout! Module data is now stored into Global Variables, which are restricted to the Private scope of the module lvlib. A semaphore should be used to protect write operations, if you're worried about race conditions. This approach results in clean block diagrams and quick coding, and I'm really liking it so far. I'll share some code if there is any int
  2. Funny you should say that; I've now completed my LVOOP implementation and I hate it. I'm moving back to the solution I've described in this topic; it is more straightforward and looks way cleaner on the block diagram. The added value of inheritance turned out to be limited for our purposes.
  3. I've created a class which contains (mainly) a bunch of settings and a bunch of events. To keep things organized, I've put these into a Settings and Events cluster, respectively, in the class private data control. If I want to create neat property nodes for such clusters, I have to follow a rather cumbersome procedure: 1. Create a vi for data member access to the whole cluster via the appropriate dialog 2. Create a vi for data member access each individual element via the same dialog 3. Open the Class properties window and navigate to Item Settings 4. Locate the whole cluster accessor
  4. Unfortunately, a SEQ doesn't solve anything. Any references within the object (events, etc.) are released when the first caller leaves memory, so you'll end up with a useless object in the SEQ. QueueYueue, I fully agree with your first point, but this construction is impossible as I explained before. A root class cannot create a DVR to a child class. Hence my call for a Dynamic Dispatch DVR terminal type, which I'll file shortly.
  5. Thanks, I'd be happy to take a look if you can provide a LV2012 version. I think the issue could be elegantly solved by implementing Dynamic Dispatch DVR terminals. Any opinions on this?
  6. How does this affect persistence though? If I spawn the Holder thread in the root class and create the DVR in the child class, the ownership of the DVR (and other child-specific init code) lies with the calling vi. LabVIEW will clear those references when the first calling vi leaves memory, whereas other VIs might still need access to the object.
  7. I've created a by-reference framework similar to the Extensible Session Framework (https://decibel.ni.com/content/docs/DOC-12813), with the difference that my object references are self-persistent. This is achieved by creating the object instance in a separate thread, which remains running in the background. This is all working rather smoothly, but I would like to clean up my code a bit. Right now, I have a Persistent Object root class which contains only two properties (Instance Name and Destroy Event) and two methods (Create and Destroy). A child class overrides the Create and Destoy met
  8. I'd like to leave a small note for anyone reading this topic: this turned out to be a highly unmaintainable solution to the challenge. I've bit the bullet and moved to a LVOOP approach, which is converging towards the ESF solution. The required LV skill for using classes is definitely outweighed by the benefits, mainly inheritance and property nodes on DVR wires of the class.
  9. Nope, everything is running smoothly. I will post a barebone example once I find the time. It boils down to this: when calling Start on a module, a 'holder' vi is launched asynchronously. This initializes the module data and events and creates a DVR to that data, which it stores in a FGV. The holder then starts listening for a module stop event, which it also stores in a FGV. All functions which operate on the data get the DVR and modify it in an IPE structure, providing protection against race condition. Calling Stop on a module gets the stop event FGV and triggers it, causing the holder vi
  10. By now, I've created my implementation with little difficulty. The main challenge was data persistence, since data tends to leave memory when the original 'requiring' caller aborts. Hence, 'moving' a component from one owning module to the next releases all User Events and other allocated resources. The solution was to asynchronously launch an 'owning' vi on a component's first launch, which initializes the component and then just sits in memory. An added benefit of this approach is that you can implement an event handler for an 'emergency stop' event in this owning vi. As I mentioned, I h
  11. Thanks for the quick reply. The point is that the end users will have to create components as well as measurements. I'll be gone in two years, and if my successors buy a new piece of equipment I want them to be able to integrate it without hassle. My approach should allow them to copy a template lvlib, replace some code (aided by documentation) and get measuring. The necessity of simple interfacing is met by writing modular code; the question is, what should a module look like? Subsequently, how should modules interact? I've described a solution above, and I'm hoping for feedback from experi
  12. I've built (and re-built) a medium-sized application over the past months, learning more about LabVIEW in the process. The design is simplistic and reaching its limits by now, so I've been re-thinking the design lately. I'm looking for feedback on my design choices before I start implementing... all criticism and tips are welcome! The goal: flexible software for an ever-changing university laboratory environment, to be used and extended by students/staff with limited LabVIEW skills. Decisions: Avoid LVOOP unless clearly called for OOP has it's benefits but it makes code more complic
  13. On the Plugin HAL solution: I had looked at the Plugin HAL extensively before opening this topic. If I remember correctly, it uses SEQs to pass around the class instances. I wouldn't mind building a simpler application using the same idea, but the Plugin HAL itself seems daunting and bulky. On including a device identifier in each call to an AE: I had considered this as well. It would be the quickest fix, but feels hacky and doesn't provide OOP candy like inheritance. Two very similar devices, for example, would still require code duplication. On using DVRs only in private methods:
  14. I've recently built a medium-sized application that controls a bunch of devices in a university laboratory. From the start, I've been focussed on writing a modular, extensible program, as people tend to add or remove equipment and write new measurement routines accordingly. In my architecture, each device is represented by an Action Engine (i.e. Keithley Controller.vi). The UI is comprised of subpanels that contain a simple UI for a single device (i.e. Keithley Panel.vi). Due to the nature of AE's, any vi can send commands to any device; data changes are communicated to the panel through U
  15. Thank you! Keeping a 'shadow value' in the display state seems a bit clumsy, but it works well!
×
×
  • Create New...

Important Information

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