Jump to content

Murugan

Members
  • Posts

    4
  • Joined

  • Last visited

LabVIEW Information

  • Version
    LabVIEW 8.6
  • Since
    2005

Murugan's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. I see. Well, the DOM Document object is instantiated inside the functional global and the reference is also held there on a shift register. Before, I was only calling that functional global from the XControls, which I suppose would be the "top level" VI in that case. Anyhow, once I initialize/shutdown that functional global from a different top level persistent VI (an event-driven state machine), it remains a valid resource as long as that VI is running. XControl VIs may not be reliable as "top level" VIs in this case because the state of those VIs and the XControls seems a little hazy. I may have misspoke rather than misunderstood. If we're talking about "resources" rather than "refnums", my earlier description might have been more valid. That refnum remained in the functional global, and the number was always the same, which is something I checked earlier in my debugging. Obviously, it was the actual resource that the refnum was referring to that was disposed. Is that more correct? I don't always have my semantics in order.
  2. Yes. During edit time, as I add and remove controls, I am keeping track of all the controls as XML. This XML is being exchanged with external code (written in C) to make things happen in software outside of LabVIEW. Because I am keeping a persistent link between LabVIEW (in either edit or run time) and the outside software, and they both make use of common data related to the XControls, I have to keep it alive somehow. Since that common data is in XML, I could also just keep writing to/reading from a common file, but would rather just keep it alive in memory the entire time. Running a background daemon in LabVIEW that keeps that functional global active does the trick. Eventually, I'd like to migrate many of these functions to external software running as a service, so that the XControls just make the appropriate function calls and LabVIEW handles very little of the functionality/data persistence itself. Even in this case, though, I might still have to keep a reference alive! I don't know how LabVIEW interacts with services.
  3. You hit it on the head, that was the problem, and I fixed it. XControls are little reentrant VIs that run as soon as the control is dropped on to a VI in edit time. Because there is a strange interplay going on between some things being in edit time and others in run time, I can see how LabVIEW might think that all callers to a functional global VI have been closed and clean up the references. So here's the rule: When building XControls that call functional globals, be sure to initialize/shutdown the FG independently of the XControls. This happened because XControls are supposed to be self-contained, so that I shouldn't have to manually run other VIs before dropping XControls down on my front panel. This "self-containment" principal can still be followed by dynamically running a loader/unloader VI that initializes and shuts down resources such as functional globals, and remains running as long as an XControl that needs those resources is loaded. Thanks, rolfk!
  4. I am using an Action Engine (Functional Global) to maintain a reference to a DOM Document, with several states for manipulating the document. I call the action engine VI from XControls on Init and Uninit, so that there are XML elements that are added/removed from the action engine when the XControl is added to or removed from a VI. I am able to add many copies of the XControl without problems. Often I can go on adding and removing XControls several times. Randomly, however, I get a warning 15 related to the XML Parser, stating that the DOM Document resource is invalid. From this point on, I am no longer able to make modifications to the document--I can view the XML associated with the DOM Document using Get XML, but am not able to manipulate it in any way. It is as if the object or reference has become corrupted. Is there a known bug related to this? If I run the action engine independent of the XControl I do not get this problem. Do XControls have a tendency to corrupt references contained in VIs external to the XControl? I am using LabVIEW 8.6. Thanks for any help.
×
×
  • Create New...

Important Information

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