Thank you Jean-Pierre.
The only reference I found in LabVIEW docs was about LabVIEW.ini file.
Can you point me to reference info on myapp.ini?
I understand your point, and yes that seems like it would solve it for
distibuted apps, which was my example gripe :~)
However, what if I write an instrument driver? When I distribute the
VIs to other LabVIEW users, I must tell them to change their LabVIEW.ini
file?
I think you may know that VERY different programming is required for
sync versus async calls. The async functions return immediately, so you
can do other processing while the I/O completes. However, you MUST
determine that the I/O did complete before you attempt more I/O with the
same device. And GPIB devices typically tens of milliseconds to
complete I/O. In my opinion, the vast majority of GPIB applications
don't have any other processing to do while waiting for the last I/O to
complete. So sync I/O ought to be the default because it is much
simpler and straight forward. You call the function, the I/O completes,
and the function returns. Good, clean, data flow programming :~)
Even still, I just do not understand why LabVIEW does not provide both
VISA write functions (sync/async) and both VISA read functions. Is it
not conceivable that a single application would want to use sync I/O in
some cases and async I/O in others?
Thanks again for your thoughts.
Mike
Jean-Pierre Drolet wrote:
>
> Usually, when you distribute an application, you also distribute with it its
> app.ini that is configured properly to the application needs. Thus in your
> distributed application myapp.exe you add this line yourself in the
> myapp.ini file and add the file as a support file installed in the
> application directory.
> I think asynch VISA is OK for GPIB on Windows (default) but not recommended
> for serial I/O. This is why you have to add syncVisa=True when you use VISA
> serial I/O.
>
> Jean-Pierre Drolet
>
> "Mike T" a �crit dans le message news:
> 3A32F01C.BE5B01E5@postoffice.pacbell.net...
> > Quoting LabVIEW Online Reference:
> >
> > "VISA Write
> >
> > Writes data to the device. Whether the data is transferred synchronously
> > or asynchronously is platform-dependent. For Windows, add syncVisa=True
> > to the LabVIEW.ini file, which is located in the LabVIEW directory. For
> > Macintosh, add syncVisa:True to the LabVIEW Preferences file, which is
> > located in the System/Preferences folder. For UNIX, add
> > labview.syncVisa:True to the .labviewrc file, which is located in your
> > home directory."
> >
> > IMNSHO, this is a very bad thing. The "default" is not a part of VISA.
> > It is LabVIEW behind the scenes choosing which of the two separate VISA
> > functions to call! Why?!?
> >
> > If you develop a project using VISA Write, and then distribute it, it
> > will NOT run correctly on another machine that "defaults" to
> > Asynchronous Writes. And vica-versa.
> >
> > The VISA library has two separate functions: viWrite and viWriteAsync.
> > Why doesn't LabView just give us two functions?
> >
> > Duh! VISA Write and VISA WriteAsync.
> >
> > And by the way, the same applies to VISA Read and VISA ReadAsysnc.
> >
> > So let's say you want to build an application for distribution. Your
> > user has to run your app's installation program, then run the VISA
> > runtime library and then dick around with the LabVIEW.ini file. Doesn't
> > seem like a "professional development system" to me.
> >
> > --
> >
> > Mike T
--
Mike T
