mje

Yeah, I think you got it. It's definitely more complex, but I despise polling variables. I've implemented a few things which are "wait until done or X amount of time" and usually end up using a synchronization based implementation rather than time polling. Sync objects also scale nicely, you can signal multiple tasks off the same occurrence, for example. Useful for the "wait until done or I say so" scenarios.

No, the tick counter in my example was just to simulate a "Long Task" running for some period of time, it doesn't even consider a rollover (you'd normally have some other code in the while loop). It's the event structure that does the timeout check. The idea is this: The bottom task, (or Watchdog task) creates some kind of synch object, in this case an event. It then launches a worker task (Long Task) which takes a long time for some reason. The Watchdog task then immediately blocks on the synch object with a timeout. In this case, it's an event structure, which has a maximum timeout of 2^31 milliseconds (the maximum value for an I32). The task will not return until either the original task is complete, or the specified timeout has happened. That's a really basic example which should not be used as-is, there is a possible race conditions in it. But it does gets the point across, I hope. By using a pair of synch objects (one for an "I'm finished!" signal, and another for a "Abort!" signal), you can achieve a logic that incorporates a timeout, and does absolutely no polling. I can try to elaborate later if no one else fills in...

Here's a really simple example of how I usually solve problems similar to this. Note this is quick and dirty, I don't clean up my refs, you might want two way synchronization for a cancel operation, etc, but it gets the point across... Basic idea is I let some kind of synchronization object handle the timeout for me. Of course if you need a timeout exceeding 2^31 milliseconds (~25 days), you'll need to consider something else... Timeout.vi

Name: MessagePump Submitter: mje Submitted: 19 Mar 2010 File Updated: 21 Jun 2010 Category: LabVIEW OOP Version: 1.1.4 LabVIEW Version: 2009 License Type: BSD (Most common) MessagePump v1.1.4 Copyright © 2010, Michael J Eggertson Author: Michael J Eggertson LAVA Name: mje Contact Info: Contact via PM on lavag.org LabVIEW Versions: 2009 SP1 Dependencies: None Description: Provides a object oriented implementation of a message pump in LabVIEW. Message pumps are also commonly referred to as a message loops, event loops, or message dispatchers in other programming languages. In terms of traditional LabVIEW design paradigms, a message pump would be considered the consumer portion of many kinds of producer-consumer based architectures. Installation and instructions: Extract the attached zip file to a convenient location. The included lvproj file contains four examples that should give a good indication of how to get started using the MessagePump and supporting classes. Using the MessagePump in your own projects will usually only require you to add the class to the project. Examples: Four examples are included. Basic Message Pump demonstrates a minimal implementation that defines a class which overrides only a single VI and provides a VI which uses the class. Parameters extends the previous example and demonstrates how parameters can be passed to and from a MessagePump. Progress Dialog demonstrates how a MessagePump might implement a user interface. Callbacks is an advanced example which demonstrates how one might implement a Callback. Known Issues: None Acknowledgements: This is a simple LabVIEW implementation of an architecture which has been around for quite some time... Version History: v1.0.0: Initial release of the code, posted but never submitted to the CR. v1.1.0: Inital lava.org CR submission. v1.1.2: Added a fourth example demonstrating the use of Callbacks. v1.1.4: Fixed a bug related to locking the MessagePump, StartLoop will now return an error 123 if the MessagePump is already in use. License: Copyright © 2010, Michael J Eggertson Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Support: If you have any problems with this code or want to suggest features: please go to lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and search for the "MessagePump" support page. Distribution: This code was downloaded from the LAVA Code Repository found at lavag.org Click here to download this file

Well, even though there's no error for the input, I still merge because if I recall there are some legacy VIs can issue a warning...error is false but a code exists. Hence I think it's always important to propagate a no error condition (or am I imagining things?). Jarrod's comments make sense though, I think I might have to agree now with the current design. However: If the left DVR node fails to get the value for whatever reason, I'd expect a default value to be returned, analogous to overstepping an array. I don't think it would be a big stretch to expect the same behavior with respect to an error condition. BUT...as Jarrod said, the real question is what happens on the right node. This node must always attempt to execute, otherwise all sorts of bad synchronization things can happen. The error in functionality makes no sense for this node...if you don't replace the value, most programs would enter an undefined state, probably a deadlock since NO task would ever be able to retrieve the value afterwords if the value is never re-referenced. So I guess after more careful consideration, I think the nodes are designed exactly the way they have to be designed.

I'm just finally getting enough time on my hands that I can explore DVRs. I think I'm missing something with respect to error handling and I'm hoping someone can enlighten me. See below: My first thought when I tried wiring this up was of the whiskey tango foxtrot variety, and well...it still is. The process of taking in a DVR, checking for an error, deserializing contained value, operating, then reversing the process is inherently...serial. Why is the error handling so discontinuous? Why doesn't anything have error in terminals which forces me to bundle 3 values together each time I need to operate on the DVR? This seems unnecessarily messy and inelegant. Am I missing something?

I've run into this as well, but my problem was actually memory allocation: large variable sized arrays of moderately sized objects leading to fragmentation/allocation. With a little code cleanup most copy operations vanished and everything went fine...I never really spent extra time about how it could be parallelized given the shift register limitation. I'll also caution that unless you can absolutely guarantee the index array will contain all unique values, you'll likely need to do some checking, or keep the VI private such that you can control what accesses it if you go ahead with parallel code. As for your queue example, that will execute, but there will be very little parallel operation, as all but one of the p-loops will be blocked by the one p-loop that has dequeued the array I've only ever "played" with DVRs, so unfortunately I can't really comment on them. On second thought, I'd expect the inherent mutual exclusions that are built into DVRs would put you up against the same loop blocking that happens with the single element queue...

Even easier would probably be a Get Text Rect.vi call to calculate the bounds of the string. Well perhaps not easier, but cleaner and possibly faster since it likely doesn't involve a UI update (though I'm not sure what happens under the hood of that VI).

I've been wanting this for ages. Well, at least as long as the structure has been around. I'd also like the option to allow the recompilation due to symbols to be done on the fly through a temporary file. If this is done at the application builder level, I don't see why the original VI needs to be modified due to a symbol definition. I dislike how some of my reuse libraries are always getting changed due to symbol redefinitions across projects...leave the original VIs alone! Since we're never going to get a separation of source from binaries in LV, this would be a nice way of handling compilation differences at the project level without modifying the source (kind of)...

Heh, now I feel a little guilty for not updating that thread in nearly a year. It's practically lost in the LAVA 1.0 archive. Attached is an up to date version of the framework. As of now, there are no external dependencies, and that weird bug (if you remember) has been resolved as of LabVIEW 2009. I've been wanting to overhaul it now that DVRs are around, but I haven't had the time to play with them enough to feel confident in making a *framework* out of them... MessagePump-LV2009SP1.zip

Summary: When dealing with the XML DOM functions if you close any reference to the DOMDocument and try to use another reference to the DOMDocument, LabVIEW crashes. The DOMDocument references do not appear to count properly. See attached VI: crashtacular.vi Steps to reproduce: Open attached VI, set a path to a file which will be written. Execute the VI. Notice how the execution succeeds, and the file is written. Open the block diagram of the VI. Look for the following code... Note the call to NI_XML.lvlib:Close.vi in the diagram disabled structure. Swap the cases such that the close call is made. Warning! This will crash LabVIEW, make sure you've saved any other data you have open: Execute the VI. Expected behavior: After obtaining a new reference to the Document, I expect I should have to close it as I would any other reference I obtain dynamically. I'd only expect the Document to fall from scope after the last reference to it has been closed, instead closing any reference appears to destroy the data. This bug has existed as long as I can remember, but after being bitten by it again I decided to try to document it. What are your opinions? My $0.02: It's a bug. If it's by design, it is at best inconsistent with how references are used in the rest of the library, let alone the rest of LabVIEW or programming in general. I see no mention of it in the list of known issues, however I've seen previous posts regarding the issue over at ni.com in the past. -Michael

So, I have an application which customers really want to be able to have multiple instances running. No problem, the quick cludge is to just do the AllowMultipleInstances=True ini setting. For now... But this is pretty much avoiding the larger issue. Things like config settings become competitive within the application when multiple versions of it are running, memory is also an issue since entire instances of the RTE and VIs get loaded into separate processes...basically the app wasn't designed for this. However even worse, controlling access to singleton type third party resources becomes at best undefined (mostly arising from queues/semaphores/etc not moving past process boundaries). I'm considering updating the underlying architecture in one of two ways: keep the instances as completely separate processes (which will involve some minor tweaking, but will not solve all my issues), or having a central app manager model that spawns re-entrant versions of the main UI VI (which could save on the overhead of having multiple RTEs and VIs, but also introduces risks since one large memory pool will be used which could take down ALL "instances" if something goes wrong, and memory consumption of the application can be significant). The question is: When you have an application that does *not* allow multiple instances, does the application receive any signal from LabVIEW or the OS when the user tries to launch the exe a second time? I'd really like to keep the behavior of each time you click the exe, a new window appears even if I go to the application manager model...

I've wondered this several times over the years as well and not come up with a solution. Recently I was hoping to find a way to do this in a .NET context, but came up dry. *waits...*

Upon closer examination of the documentation, I found this in the Flattened Data part: Though I wonder if the docs are up to date?

Ah, very nice! Thanks everyone. I had been browsing the Variant Data Type VIs for quite some time as Ton suggested, that's where the library I was referring to lives. I never thought to look at the data string, Aitor. Does anyone know if references indeed become U64s when running in the 64bit IDE/RTE?

Let's say I have a variant which is holding some type of refnum. The refnum class can not be known ahead of time, it must be determined at run-time. I'd like to be able to extract the numeric value of the reference, but I'm running into an absolute roadblock in how to deal with the fact that my refnum comes in as a variant. Usually I'd just cast a refnum to a U32 (or U64 I suppose if in LV64) and go from there. However, the variant is throwing a wrench in my plans...I can't directly go from a variant:refnum to a U32: And since I don't know the class of the refnum before hand, I can't use the same Variant to Data primitive to change to a refnum, can I? I've been playing with the VariantDataType.lvlib VIs for an hour now, and can't quite put my finger on it. One possibility is to use VariantDataType.lvlib:GetRefnumInfo.vi to get the general class, then assemble a large case structure for each possible enumeration...but surely there's an easier way?

Nevermind, chalk this one up to the wonderfully buggy Vista synchronization agent. MyDocs are stored on a network location, and...well...vista sucks. Both the network location, and the local filesystem cache of the location are accessible, but it appears the system can't resolve where MyDocs are at all. Since LV stores that data in MyDocs\LabVIEW Data, it fails... Yet another case of restarting the system magically fixing everything. Pathetic. Yay for simultaneous replies. Thanks Ben! The fact that mydocs weren't accessible (despite being accessible??) I guess also explains why my file system search turned up nothing.

Something started to go wring with my LabVIEW 2009f2 install. I'm working and all of the sudden a dialog box pops up saying "Failed to create directory for auto recovery VIs". Not much info on how to troubleshoot that, and searching (both the internet and my filesystem) isn't bringing up anything. Anyone know where the files are supposed to be created? The LabVIEW install has been working fine since the 2009 release until today...

Excellent, thanks!

So I'm working on making a generic algorithm for some sorting code of mine, using variants. Came across this little diddy: When examining the output, I get: 0x 001C 0054 ... The fourth byte (54) shows the type, but according to the documentation 0x54 is a waveform type. So I went ahead and wired up a waveform and I also get 0x54. Is this a bug? The two data types appear to not be equivalent (you can't wire up a waveform to a timestamp terminal, for example). Is there a way to differentiate between a waveform and a timestamp when using a variant? It now occurs to me I've run into this before but didn't dig deep enough...I recall running into unexpected waveform types when using EasyXML -michael

Yeah, I use the auto tool, but it's been annoying me lately. It's a love-hate relationship, and currently I'm in the hate part. A few weeks from now... Key mapping software isn't really a solution, even if you could find a program-aware one. As Yair implied you often need to type the 'wasd' characters for...typing 'wasd' and such. It would be nice that if LabVIEW was context-aware: there are plenty of times where you can't enter text input (such as selecting a VI in a block diagram)where the alphanumeric keys could easily double as other functions.

Is there a way to configure arbitrary keys in the IDE? I'm currently on LV2009. I'm looking to map the wasd keys to the arrow functions, so I have easy access to both the tab key and the ability to fine tune VI/wire placement without moving across the keyboard...

<br><br>I'm still looking...<br><br>Edit: ...and there we go. Should have spent more time before posting!

QUOTE (Ton @ Jun 5 2009, 09:16 AM) Hmm, maybe my wish is a little beyond the scope of what you're trying to do. For me the biggist issue with the existing editor is how you need to step out of the project explorer to do anything with poly VIs. I'd like to be able to right click on a class, or other node like a folder or vilib in the project explorer and select New > Polymorphic VI... Even better would be to show the polyVI as a tree directly within the project explorer, with all the instance VIs as children of the main polyVI. Of course I'm not suggesting creating a new explorer. I've never looked into how the existing one is implemented and if customizing it like this is possible, even with the new scripting capabilities. I guess for me the main issue with the existing polyVI editor isn't the editor itself, but rather there's no easy way to manage polyVIs at the project level.