Jump to content

Search the Community

Showing results for tags 'state'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Software & Hardware Discussions
    • LabVIEW Community Edition
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • GCentral
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
    • OpenG
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help


  • *Uncertified*
  • LabVIEW Tools Network Certified
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
    • Custom Probes
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Personal Website

Company Website

Twitter Name

LinkedIn Profile

Facebook Page



Found 2 results

  1. Hi all.. I've been playing around with various HAL implementations for a while now, and I have a question on implementing some simple "state" functionality in the HAL. I've attached one such example - It's just an abstraction layer for a range of I2C Adapter modules that I use (or intend to use in the future). So my parent class is an abstract I2cAdapter, with overridable (dynamic dispatch) methods and exposed private data, effectively forming my interface to upper layers. Then at run-time I will just instantiate one concrete 'product'. (By the way, when I say "Adapter", it's nothing to do with the GOF pattern). Now I also want to add some simple "state" functionality, and I'm hoping to get some pointers on the best way to approach this. The states I can identify in the HAL are: 1. Adapter physically disconnected (i.e. plugged out from the PC/laptop/whatever). I want upper layer(s) to know that this has happened. 2. Adapter connected, and enabled (normal operation). 3. Adapter connected, but disabled. Effectively I want the adapter to be in a high-Z state as far as the bus is concerned. (Of course this should happen automatically for a 'true' I2C adapter when its not accessing the bus, but unfortunately I can't guarantee that with the devices I'm using.) I've looked at the GOF State pattern, but I think it's too elaborate for this situation. Also, I'm not sure it really applies here anyway. As I look at it, the Enabled/Disabled states can be done simply - just add one (or two) abstract method(s) in my parent class and let each concrete adapter implement the necessary functionality. But what's the best way to handle the Disconnected state? Should the concrete adapter implement some functionality and inform the upper layer if a disconnect has occurred? Or should the upper layer have some sort of a periodic check of connectivity? Maybe I should also add that one of the learning 'glitches' I'm having with LVOOP is the topic of collaboration between objects, and this post ties in with that to a certain extent. So any help would be appreciated.
  2. Hi Ppl, I'm trying to reserve a VI for execution. I couldn't find any property/method that does it, in VIServer. LabVIEW ActiveX does expose a method to reserve the VI. But my problem is how to keep the VI in memory even after the VI that opened the reference stops running. I was wondering how TestStand does this. TS loads VI's into memory and reserves them. If TS used some code that open's these VI's ref, after that code stops these VI's should go out of memory. But that doesn't seem to happen.
  • Create New...

Important Information

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