mje

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...

The XControl doesn't work correctly when building an executable. The reason is that the column width is decided by placing text in a decoration in a subVI and checking the size of the decoration. The problem is that the FP of the subVI is removed when building, so this doesn't work. The easiest way of working around this is creating a property node for one of the controls in the subVI. The node doesn't have to do anything, but just having it causes the subVI to keep the FP when building the EXE.

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)...

Don't forget the 'message pump' as well.

Never did get to fully appreciate the capabilities of that but always felt that it was a strong contender to LVx although different in a couple key ways.

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:

LabVIEW stores the majority of flattened refnums as flattened 32-bit integers, which represent an internal LabVIEW data structure.

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...

You need to look at the next I16 value after the base type. 0x03 is a waveform; 0x06 is a timestamp...

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

No. The WASD keys, surprisingly enough, are reserved for typing W, A, S and D.

I can think of four options:

1. Use an external keyboard mapper. The problem - it will be global, which is probably not what you want.
2. Stopusing tab. Switch to the auto-tool. Some people (like me) like it.Others hate it. The recommendation is to force yourself to try to useit for at least a week before giving up. There have been severalthreads about the various advantages and disadvantages both here and inthe NI forums.
3. Get an external keypad. I doubt this would helpyou, since you would probably place it on the left side of thekeyboard, when you want the keys on the right side of the tab key.
4. Usea key mapper and map one of the keys near the keypad (e.g. num lock) tothe tab key. That way, you can keep your hand on the right side, butyou won't have easy access to Ctrl, Shift, etc.

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>The "View New Content" link is a bit hard to find.

QUOTE (Ton @ Jun 5 2009, 09:16 AM)

You mean like a project integration tool?

Or could we build a better project explorer?

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.

Perhaps I can seed an idea? Somehow getting this tool incorporated into the class browser would be great. Adding polymorphic VIs to a class isn't really that intuitive at the moment.

The MessagePump is saved in LV 8.6, I doubt it can be opened in previous versions.

Oh yes, I realize the two implementations are quite different, I like how you attached your callbacks. I saw your code for VI and event callbacks, and saw an abstraction there that was similar to what I had done via the Callback and related classes I had used so I thought I'd chime in.

The real power of your way of doing it is you can use the callbacks to register for events generated outside of LabVIEW that are exposed in .NET or ActiveX objects. Basically, using the callback mechanism you used, LV code can synchronize with virtually any modern Windows code.

And for the record, I too am somewhat disappointed at how events haven't evolved with LabVIEW. They are very powerful and I use them all the time, but I also find the exposed interface to often be lacking.

I also like the idea of callbacks. I've previously used an object based implementation to abstract the callback mechanism such that the choice of implementation (notifiers, events, VIs, or anything else) is transparent to a given framework. I've since moved to using such an abstraction almost exclusively now, I rarely use raw notifiers and what not for simple synchronization or cross task communication as the flexibility of a generic callback is much more elegant.

Always been one of my favorite comics, and that one in particular has always made me laugh. You should at least reference the source though.

As candius pointed out, you're looking for nodes, not elements. Sticking with DOM methods, if you iterate over each node and compare its nodeType, you're looking for ones of the NODE_COMMENT (8) variety.

If you want more than hints, show us what you have so we have a starting point.