Adam Kemp

You can associate the gpib device resources with DNS names instead of IP addresses. I'm not sure if the gpibexplorer lets you do that, but you can just modify the configuration file and replace the IP with the domain name. Does that help? Surely if you have over 100 devices then they aren't constantly changing names, right?

I see. I've asked around a bit, and so far I haven't been able to figure out what the old behavior was that allowed you to directly use the DNS name in the VISA resource name. I have been told, though, that they didn't anticipate having a resource which changes IPs and DNS names frequently. We expect that a GPIB-ENET resource will keep the same IP and/or DNS name. Can you prevent it from changing names or IPs? That would be the best option.

I don't understand the question. You said you got it to work using gpibexplorer, so what's wrong with that?

It means what it says. The interface number isn't valid. If you used GPIB::1::INSTR then the error means that 1 doesn't refer to a valid interface. Check visaconf and see what's really available.

Even if there was such a solution I would still recommend the permissions fix over that. Ultimately I think the problem is that the VI isn't reentrant. You should at least make a request to whoever wrote the VI asking that it be made reentrant. With the new shared clone reentrancy feature in 8.5 there's not much of a downside to making commonly called VIs reentrant. EDIT: Also, I thought that the only difference between a .vi and a .vit was the file extension (I could be wrong). In that case you could just rename the VI and do whatever you would normally do for a template VI. That's not a code change, so there's no maintenance issue.

If the problem is permissions then the solution is to modify the permissions. The easiest fix is to just make that directory world-writable: $ chmod a+w dirName You may also need to do the same for the VI itself, but I think if you copy a file then the new file has the ownership and permissions of the user doing the copy. I may be wrong about that. The safer way of doing this would be to define which users can do this, put those users in a special group, change the group of that directory to your new group, and then make that directory writable by that group (but not by everyone else). You do the last steps like this: $ chgrp newGroup dirName $ chmod g+x dirName

QUOTE (Jon Sjöstedt @ Aug 15 2008, 05:48 AM) Just another thing to check: do you have 4GB or more of physical memory? I don't think the VISA or GPIB drivers will work with PAE enabled.

QUOTE (Jon Sjöstedt @ Aug 14 2008, 08:58 AM) Are you sure the administrator installed it correctly? There are special steps necessary for SuSE (detailed in the FAQ section of the README) in order for the kernel components to install properly. You also have to either restart or run updateNIDrivers before you can use the drivers. Try running visaconf to see if that will work.

QUOTE(Jim Kring @ Feb 14 2008, 10:59 AM) Did you try this with the latest version of LabVIEW? I thought we had fixed the installation issues with Ubuntu, including the mesa issue. Our installers are supposed to support installation without RPM, and I know we've tested it. It's still not officially supported, but it has been tested and should work. Which version were you using?QUOTE(neB @ Feb 13 2008, 12:27 PM) Hi all,My wife and were planning on setting up a Linux machine at home. She found the following " Debian Linux 4.0 CD Set - $19.99 "I plan on using it for LV development.Any comments or suggestions on this project would be greatly appreciated.Thank you,Ben If you're just using it at home, then you probably don't need to bother buying Linux. Just download it. No matter which distribution you choose you can download the .iso image of the CDs and burn them yourself.If you want support, then you should consider buying a commercial version like RedHat Enterprise Linux, SuSE Enterprise, or a payed version of Mandriva. Those are the versions we officially support. For more information, see http://www.ni.com/linux/ and http://www.ni.com/linux/labview.htm

It is not possible to host a shared variable in Linux natively. The necessary DLLs for managing that were not ported. I have no idea if you could do it with wine, but I doubt it would be trivial. If you do figure it out, though, let us know.

QUOTE(DAngstrom @ Sep 26 2007, 01:39 PM) If the VI you're opening uses an IOName control or VISA then you may need to run 'updateNIDrivers' (/usr/local/bin/updateNIDrivers). You also have to run that every time you update the kernel version.

QUOTE(LV Punk @ Sep 26 2007, 12:10 PM) The kernel is not rebuilt for either, but the kernel sources are needed to compile some things for the DAQmx drivers. It needs to know how your kernel was compiled. Unlike Windows and Mac, Linux has no standard kernel build. Every distribution (or even every individual computer) can have a different kernel, and drivers have to be built to work with that kernel. So in order to ensure that the drivers are compatible they need the kernel sources that go along with your particular kernel. This is probably covered in a README on the CD, so look for that.

QUOTE(DAngstrom @ Sep 25 2007, 10:42 PM) You need to install the source for your kernel. In SuSE 10 the package is named "kernel-source". If that's already installed, then make sure that it was installed where we're expecting it. Look in /usr/src. There should be a directory which has the same name as is returned by the command "uname -r". If there isn't, then figure out which one is correct and make a symlink to it with that name.

See this KB article: http://digital.ni.com/public.nsf/websearch...D2?OpenDocument This should be fixed in 7.1.1 and later.

QUOTE(rahimp @ Mar 21 2007, 11:18 AM) When you configure your call library node you tell it that the argument is a string, and then you tell it what kind of string. C String Pointer is one choice (it will say "CStr" in the function prototype), and that is a char*. If you're just sending a string to the DLL then that's all you need, but if you're also wanting the DLL to fill that string then you have to allocate the buffer first (in G). Usually people do this by initializing an array of U8s and then casting that to a string. In LabVIEW 8.2 you can actually configure the call to make sure that the string has a certain minimum size, so that extra code isn't necessary. Either way, you can then wire the output of that argument into LabVIEW as a normal string.

Just tell LabVIEW that your function returns an int32. That's your pointer. A pointer is just a number, after all. On a 32-bit system that number is 32 bits, so you just need an int32. Then for any function which takes a pointer you can just tell LabVIEW that it takes an int32. LabVIEW doesn't ever need to know what type it really is.

QUOTE(rahimp @ Mar 20 2007, 03:48 PM) If you're only using a pointer (i.e., you don't need to actually access the values in G) then tell LabVIEW it's an int32 (by pointer). Then you can just pass that value around into your various other DLL calls without LabVIEW ever having to care what type it is. If you need to actually interpret that data in LabVIEW then it's a little trickier. You have to create a cluster with the same layout as your C++ data structure. It looks like you have just a bunch of pointers and ints, so fortunately you're spared alignment issues on Windows (LabVIEW doesn't use native alignment on Windows). You can just create a cluster with an int32 for each of the elements in that class and pass it in as a void*. As long as you don't need to dereference any of the pointers inside the class you're fine. That includes the strings. You can't get to those unless you write a c function to dereference the pointer and write into your own string. By far the easiest thing to do is just pass the pointer around without trying to get LabVIEW to interpret the data.

QUOTE(Jeff Plotzke @ Mar 15 2007, 08:54 PM) There is a way of setting pan in the API, but converting from the two volumes to one master volume and a pan setting would be more complicated than it's worth, and it can't be easily extended to other channels.

Although the Sound Output Set Volume VI pretends to set volume on a per-channel basis, it doesn't really do that. It just takes the volume for the first channel and uses that as the volume for all channels. This is a known bug. I haven't fixed it because the DirectX API we use doesn't seem to actually have any method of setting volume on an individual channel, so the fix would be far more complicated than it should be (and few people have actually requested it). Even the Linux API we use only supports setting the volume for left/right channels. Even though it could theoretically use as many as 16 channels, it can only set volume for left/right. The LabVIEW code sets them both to the same value, though. Since you're generating your audio signal anyway, you should be able to simulate this by varying the amplitude of each channel separately.

The short answer is "no", because LabVIEW does not currently run on that processor. However, you may be able to use the LabVIEW Embedded Development Module. This allows you to convert VIs into C code which you can then compile using the toolchain of your choice. The process is more involved because you have to create a cross-compiling toolchain and then make some VIs to tell LabVIEW how to use the toolchain and also port some of the LabVIEW C Runtime Engine to your target platform. Still, it should be possible.

This was reported to R&D (#43Q7NJPT) for further investigation. Thanks for bringing it to our attention.

I could not reproduce that problem in either 8.0 or 8.2 in Linux using the steps you listed. This is what I tried: 1. New VI. 2. Drop numeric control. 3. Customize control. 4. Make the control a strict typedef 5. Apply changes. 6. Save both the control and the VI. 7. Close both. 8. Rename both 9. Open the VI. When I opened the VI, it searched for the control. If I chose the new name for the control, the VI was "good" (no broken arrow) and the VI had a doc mod (the asterisk). This is correct behavior. If I chose to ignore the control, then the VI was broken and had a doc mod (also correct). If you have another way to reproduce this problem every time then let me know.

I'm glad people are using the regular expression features. It makes me happy. Here's another regexp that may or may not perform better (I'll leave benchmarks as an exercise to the reader) : \/\*([^*]|(\*(?!\/)))*\*\/ It says "match /*, followed by a non-* or a * that is not followed by /, followed by /*". The ?! is a "negative lookahead" match. You can find more info the "definitive" reference for Perl-Compatible regular expressions here: http://www.perl.com/doc/manual/html/pod/perlre.html The regular expression feature was added in 8.0. If you want to do this in a pre-8.0 version of LabVIEW, then you'll have to write a simple parser to strip comments. Not that this would be a terrible thing. Regular expressions are great for simplicity of code and for writing validation code, etc., but they're usually very inefficient. For simple parsing problems (like this one), a well-written straight-through parse routine would perform far better. In fact, if this application is likely to deal with large amounts of text, then I would recommend rewriting the parser for performance reasons. Just be careful to get it right.

sub play_song { my $self=shift; for (([4,20],[5,20],[6,20],[7,20],[8,40],[ 8,40], [9,20],[9,20],[9,20],[9,20],[8,40],[-1,20], [9,20],[9,20],[9,20],[9,20],[8,40],[-1,20], [7,20],[7,20],[7,20],[7,20],[6,40],[ 6,40], [5,20],[5,20],[5,20],[5,20],[4,40])) { $self->tone(@$_) if ($_->[0] > 0); usleep($_->[1]*15000); } # Now how many square meters of LabView code # would you need to do this?} I see nothing in that code that would be complicated to implement in LabVIEW... It says "for each of these sets of 2 values, pass the set to the tone function if the first element in the set is greater than 0, then sleep for a bit". Or, put more simply, each bracketed pair of numbers is a tone and a duration. It plays each tone for the given duration, and -1 means silence. You would implement it in LabVIEW using an array of clusters, a for loop with auto-indexing, and a case structure. Pretty simple. That guy must know just enough LabVIEW to be dangerous.

Ok, this is definitely an issue with the DRI drivers/libOSMesa. I have a feeling that installing another version of Mesa would fix it, but in the process of trying to do so I was again reminded why I no longer use Mandrake. I couldn't find a binary update for Mesa, and the source version wouldn't compile because Mandrake doesn't come with all of the X headers. Then I was in RPM Hell trying to install them. You have two choices which both have about an equal chance of resolving this problem: 1. Go through the trouble of installing the X headers somehow, and then downloading and compiling/installing Mesa (mesa3d.org) from source. 2. Upgrade to Mandrake 2006. Both choices are annoying, but I'm not sure what else to suggest.