At 1:17 PM -0400 4/6/04, Michael Aivaliotis wrote: >Ok, I guess a definition is required for the term "VISA" because I think we are on >different wavelengths. When I speak of VISA, I >mean any call (from LabVIEW) of the "VISA Read" and "VISA Write" functions. That is my definition as well. But to make them functional you need the libraries somewhere.
>Regardless, you are still obligated by NI licencing and >distribution requirements. I don't want to start another licencing thread... No, no, not that!!! Anything but a licensing discussion! :-) > > I fairly sure that for the correct platform you can embed the >> VISA libraries in an executable, > >This is the first time I hear of this. Embed? Meaning no external DLL's or support >files? Even if this is true, you still have to >have a valid VISA distribution licence. The DLLs (frameworks) can be placed in the resource directory of the built app. It will look monolithic as a single file. They are technically a support file, but the definition gets fuzzy if such a "bundle" of files looks like a single file to the user. That might be the only requirement, that the "final product" just be a single icon that can be dragged onto a machine. Of course another way to approach that is have the application look for the VISA libraries on launch and install them automatically. This will leave traces on the target machine, but to the user there is only one application icon and they just click on it. >There apparently are other none NI solutions that incorporate external DLL's, ActiveX >controls, .NET assemblies etc. (how about the Mac?). Are any of these Opensource? ;-) The Mac it is trivial. just open up a file to /dev/tty.USA28X1915P1.1 and you are connected to one of the keyspan serial port connectors. Linux would be the same trivial exercise with a different text string. You can set the port parameters with a system call to "stty" after you open it. However, VISA is still easier. -Scott
