Jim Kring

I guess I'll chime in again, since I started this thread. I am very happy to see that NI has really taken this issue to heart, understands its impact, and is going to work to help the community continue to use LabVIEW as a software development environment. I am sure that a lot of time, energy, and resources have been spent by NI on this issue I commend them for making this investment in the foundation of their relationship with their customers. I haven't seen the new license, as it has not yet been posted to the NATIONAL INSTRUMENTS SOFTWARE LICENSE AGREEMENT page on ni.com -- I am cautiously optimistic. :thumbup:

I assume that you mean a version control system that allows concurrent access to files. "Concurrent Versions System" (commonly called "CVS") is the name of one such system, but there are others. There are a lot of people who use Concurrent Versions System (CVS) and Subversion (SVN) with LabVIEW. Subversion is a little more modern, has better support for binary files and fixed-width keyword replacement, and various other features. Here is a good comparison chart.

Hello, Have you seen LabSQL? The code you have written is probably very similar, or complementary to it. In the near future, we will be packaging up LabSQL and releasing it on OpenG Commander. Regards, -Jim

LabVIEW applications must have a user interface and be targeted at a display, even if it is only a virtual display. There is more info on how to do this here.

That's wonderful, Heiko. He looks just like you

Take a look at the lv_new_vi.vi callback VI which is documented on the LabVIEW Documentation: Development Environment Event Callback VIs page at OpenG.org

You can add, duplicate, and delete case frames but there does not appear to be a way to sort/change/reassign them.

If you are on linux, you can use a pipe to communicate with plink (PuTTY Link - a derivative of putty). On windows, some folks are working on supporting pipes from LabVIEW. Nothing working, of production quality, yet.

That's how I reset the grab-handles. A quick Undo then a Redo will do the trick. With a little practice you can hit CTRL+Z then CTRL+SHIFT+Z very fast.

That is strange. I have activated your account and you should be recieving an email that will allow you to change your password and log in. Regards, -Jim

Kirk, Could you please post this in the OpenG Support Forums? This is our support channel, and ensures that the issue gets visibility by our developers and users. Regards, -Jim

Mike, I'm glad that you asked this question. Recently I have been getting DAQmx errors in WindowsXP when users perform window-related operations (switching between windows, launching apps, dragging windows around). I found that if I configure windows for "Performance" (no special window effects, classic window appearance, etc.) that the problem goes away. Could you do us all a favor? Please compile the list of suggestions and tips that you receive and post it to the forums. This would make a wonderful LabVIEW FAQ entry.

I like to listen to several of the channels on soma fm. "SomaFM is listener-supported, commercial-free, underground/alternative radio broadcasting from San Francisco."

Wow. That is great feedback! We, at OpenG, try very had to make useful, well-documented tools. But, unless users demonstrate that they are using a specific tool and have a need for more features and better documentation, it is very easy for the developers to simply move on to the next exciting project. We really do listen and want to make your experience with OpenG tools better. Please get involved in the process by sending us your feedback and feature requests. OpenG has recently made its discussion and support forums a whole lot more user friendly. OpenGOOP related discussions currently belong in the Packages Forums. Regards, -Jim

Yes you are right. I guess what I meant to say was that the LabVIEW Run-Time Engine has not been ported to Linux for the ARM processor. LabVIEW for Linux only runs on x86 and there is no compiler or cross-compiler for ARM. Also, LabVIEW PDA isn't really "LabVIEW" running on the PDA, but rather the LabVIEW code is translated into C and then compiled by a third-party compiler (automagically). The only platforms where LabVIEW is supporting this scheme is PocketPC and PalmOS.

No, because because the delimiter is an EOL character (each line in the string becomes and array element). However, that code has a couple small issues: 1) the LabVIEW "End of Line Constant" changes depending on platform (Windows EOL = CRLF, Mac EOL = CR, Linux EOL = LF), which may not give consistent results for the same input string. 2) the code does not handle strings with mixed EOL characters While the OpenG version of "Multiline String to Array" does not exactly keep it simple (if you feel the need to look at the code), it does handle any combination of mixed EOL characters. It does this by first replacing all instances of CRLF with LF and then replacing all instances of CR with LF and then using a LF delimiter to convert the string to an array. You're welcome

I suggest that you build a Queued Message Handler (similar to a state machine) that has a "macro recorder" which enables you to save and replay sequences of messages. This is a topic that comes up time and again. A search of LAVA or Info-LabVIEW should produce some interesting threads.

The "oglib_string" library which you can obtain using OpenG Commander has a VI called "Multiline string to Array".

Hey, Eric. I hope all is well I've seen stuff at NI Week (a couple years ago) showing LabVIEW running on ARM. There is no productized solution at the moment for Linux running on ARM (only Linux on x86). LabVIEW PDA will only run on PocketPC. So, the answer is, "call NI and ask." Send me a private message and I'll send you some names of people who you might want to talk to. Regards, -Jim

I have created a homepage for this package here: Notifier Bugfix Patch (notifier_bugfix)

This is a bug inherited from 6.1 and 7.0. You can find the original posting here.

There is a nasty little bug in the Notifier compatibility VIs that causes a sever performance hit, and memory leak. This is caused by the caching of the notifier names and not ever flushing stale notifier references when they are destroyed. This bug exists in LV 6.1, 7.0, and 7.1. BUG FIX DOWNLOAD If you are interested in obtaining this fix, I have created a patch which is packaged as an OpenG Package File. This can be downloaded using the OpenG Commander. Download the "ogpatch_notifier_bugfix" package. When installed this package will apply the patch, and when it is uninstalled it will restore the original (buggy) VI. DISCUSSION If you would like to discuss this package or the OpenG Commander, please use the OpenG Discussion and Support Forums. Regards,

This is a known limitation of LabVIEW. It has to do with the fact that they use the strict data type as the definition of the data, rather than using the XML as the definition of the data. The OpenG version of "Flatten(Unflatten) to(from) XML" does not have this limitation. You can obtain it from here: OpenG Flatten to XML You will also need to install OpenG Commander and the lvdata package (and its dependencies). If you have any questions about the installation of the OpenG tools, please feel free to ask them in the OpenG Discussion Forums.

There is information about how to do this at OpenG. Visit this link for more info: http://openg.org/tiki/tiki-index.php?page=LvDocMenuLaunchVIs

There's no reason that a GOOP class developer cannot create a custom probe for a GOOP class. The hard part is integrating these into the custom probe's framework. Right now the mechanism for integrating custom probes is a little awkward. Ideally, custom probes would be declared in a GOOP class's manifest (if such a thing existed) and LabVIEW would automatically know how to make it available to users. Finally, for those of you who love the Universal Probe, here is another little gem called "Config File Probe". Drop it into your <My Documents\LabVIEW Data\Probes> folder and then probe a Config File wire. Download File:post-17-1105376809.vi -Jim