LabVIEW 7.1, RDA Bug?!

[LA 75]

Hello Neal,

I tried reproducing the error you are having, but in my case everything worked out well, but maybe it is because we have a different setup or we are doing different things. This is what I did:

1.) My server and client computers have both WXP and NI-DAQ 7.3 installed.
2.) In my client computer, I created an executable from one of the shipping examples that are in Help=> Find Examples (Cont Acq&Chart.vi) and run it. (Is this what you are doing, running an executable?) I inferred this from what you wrote about "The executable file "c:\..(path to my VI)" cannot be found."
3.) I have another question please, what did you mean when you wrote �then tried running a LabVIEW 7.1 built
application with the new DAQ driver�?

If you could also tell me what exact hardware (cards, chassis, etc) you are using will be very helpful for me to recreate your issue. My intuition tells me though that the fact you have installed so many DAQ driver versions, there might be a corrupt file that it not letting you do the RDA successfully. Did you uninstall the old driver versions before installing the new ones?

I couldn't find anything regarding the INI files Ben mentioned. I am going to continue looking into that and will let you know if I find anything regarding this.

Thank you,

LA

[Ben]

Hi LA,

I ead to much to be able to recall details.

Chase down Dan Mondrik (aka VISA-Dan).

I think he did an extended e-mail to Info-LabVIEW talking about some of the things that got moved around in the LV start-up when there was a discussion of either slow starting or someone suspecting that LV was now "phoning home" beacuse looking for some resource somewhere.

It was either Dan or Greg ( I think).

Ben

[Ben]

These are two memos pulled from Info-LabVIEW.

The first is from Scott Hannah (Thank you Scott!) and list all of the LV options.

The second is from Dan Mondrik and I believe this is the memo I was thinking of (see below).

-----Original Message-----
From: Scott Hannahs [mailto:sth@magnet.fsu.edu]
Sent: Tuesday, August 26, 2003 2:12 PM
To: Info LabVIEW
Subject: Option settings in LV 7.0



I know everyone has been waiting for this... 🙂

But here is the complete list of normal options for LabVIEW 7.0. <>
There is also a list of which options have been added or removed since LV 6.1. All of these can be set in the .ini file and *some* are can be set from the preferences panes. Just for the curious, the number of options has grown

LV 5.1.1 231 Options
LV 6.0.2 259 Options
LV 6.1.1 288 Options
LV 7.0.0 406 Options

So you can see that there are quite a few new things!! Only one preference was dropped (and from a quick inspection, it was probably merely renamed).

One that might help in making reliable connection is the rviServerTCPTimeout setting. This is set initially to a very high number (like 60 seconds) and results in long delays when a server is not responding.

Enjoy! But watch for those rusty nails!

-Scott

End of memo #1

Memo #21 from Dan mondrik responding to a question from George Gatling.

Start of memo #2.



George, et al:

I first saw this last week and wanted to wait and see what various problems
people were having. I'd like to comment on which things will help and
which won't. Obviously I have some insight into where the performance hits
are.

One person suggested keeping MAX (Measurement & Automation Explorer) in
memory. This is actually a workaround that, while not something I'd
recommend, would actually make LabVIEW 7.0 more responsive when you drop
that first VISA control. Let me explain. That VISA control really does 2
things - it first calls VISA's viFindRsrc, which is usually quite fast, and
then on Windows it calls through a DLL named NiViMxs.dll to get information
about MAX so you can edit the settings (things like the alias or the serial
port settings, etc.). The good news is that LabVIEW 7.1 (announced today)
has fixed this issue. We now get the information about MAX only when you
select the "Edit VISA Resource" menu item.

Note that in LabVIEW 7.0, the long wait happens both when you drop the
first VISA refnum on a new VI, or also when you load the first VI that has
a VISA refnum on its front panel. If you really can't stand the wait in
LabVIEW 7.0, there is only 1 workaround that I am aware of. You can remove
NiViMxs.dll (located in the \Shared\NI-VISA
directory). Doing so will make it impossible to use the "Edit VISA
Resource" menu item in LabVIEW 7.0 or the item properties button in the
Instrument I/O Assistant. It may also cause you to have to re-locate that
file (from your original distribution media) when upgrading to a higher
version of NI-VISA or LabVIEW. I really don't recommend snooping around
and deleting NI files, but I do understand that it affects and annoys a lot
of you. So remove it at your own risk. (Actually, if you're going to try
this, please don't really delete it, just put it in a temp directory or
something where you can get it back if/when you need it.)

Using a string or combo box control on your front panel, instead of a VISA
refnum, isn't a bad idea if you always know what instrument you're going to
communicate with. Obviously this loses all advantages of the VISA refnum,
such as the list of instruments that are auto-detected and the ones you've
configured in MAX. But this is all about trade-offs. So if a string
control works for you, consider it.

There were a lot of other comments about how to make changes to
visaconf.ini so that viFindRsrc will perform faster. Let me tell you which
are worthwhile.

Turning off the GPIB-VXI auto-detection used to be something that would
speed it up. That is no longer true. We made auto-detection performance
optimizations for GPIB-VXI in both NI-VISA 3.0 and again in 3.1. Turning
it off won't make a difference any more. We used to send *IDN? to
instruments at address 1 with no secondary address; we now send them only
to instrument that have a secondary address, which is the only way we
support the GPIB-VXI. So it shouldn't confuse any older instruments any
more.

Turning off Passports you don't use is not a bad idea. It saves memory
footprint as well as having fewer components to query during viFindRsrc.
But this should save a few hundred KB in memory and a few (up to a few
hundred) milliseconds during viFindRsrc. This is extremely useful in
LabVIEW RT, for example, where footprint and timeliness are critical. But
on your normal PC, this is not a panacea. If this makes a significant
difference, please let us know, because it shouldn't.

Disabling GPIB boards in the GPIB-specific section of visaconf.ini is not
something that should ever make a difference. In fact, we'll probably be
removing those entries in the next version or two of NI-VISA. On all
platforms other than Solaris, NI-488 has a way of letting NI-VISA know
which boards are configured in the system. So this is just an extra check
that doesn't really save much time. If it does, please let us know,
because it shouldn't.

There was some discussion about GPIB-ENET systems that are mal-configured
or off-line. Yes, these can cause viFindRsrc (and thus the responsiveness
of the VISA refnum in LabVIEW) to be slow. We know that we need to improve
that eventually.

Finally, a word of warning about manually editing the visaconf.ini file.
We make changes to its format from time to time. While we generally try to
keep compatibility, occasionally we break it. That's why we provide
graphical configuration utilities - MAX on Windows and LabVIEW RT, visaconf
on Linux and Solaris, and VisaConfig on Mac OS X. The only place we didn't
have such a utility was Mac OS 8/9, which is why we had that extra readme
on that platform. Mac OS 8/9 is no longer supported (at least not with any
newer versions of NI-VISA software). So basically, just remember that
there's a reason we don't document what's in those files.

I hope you find this information helpful. I know that controls taking an
extra few seconds (or apparently in some of your cases, a few minutes)
impacts your performance and impacts how you feel about our products. We
really do want to save you time.

Dan Mondrik
National Instruments



|---------+-------------------------------->
| | "George Gatling |
| | (Contractor)" |
| | | | y.mil> |
| | Sent by: |
| | | | .nhmfl.gov> |
| | |
| | |
| | 04-29-2004 11:36 AM |
|---------+-------------------------------->
>--------------------------------------------------------------------------------------------------------------|
| |
| To: info-labview@labview.nhmfl.gov |
| cc: |
| Subject: VISA Refnum Constants & Controls |
>--------------------------------------------------------------------------------------------------------------|




When using VISA controls and refnums in my LabVIEW 7.0 (WinXP) panels and
diagrams I am finding extraordinarily long delays where labview seems lost
down some thread path and if very unresponsive (ie no windows redraws and
windows might report labview as "not responding".) If I sit quietly and
patiently control will eventually return and everything will function as
normal. This behavior only happens on the first instance of a visa object
and appears to happen while something (max?) populates the ring with a list

of active instruments (GPIB). The problem is this process can easily take
minutes and most people have long since written the application or VI off
as dead and start ctrl-alt-deleting things.

Has anyone else noticed similar problems? Is there a way to improve the
performance of whatever is trying to populate the ring? Or is there a way
to disable ring population? Sure it is convenient, but I would rather have

the faster (and i believe more friendly) performance.



George Gatling
Applied Technology Division, SFA Inc.
Space Physics Simulation Chamber
US Naval Research Laboratory
202-404-5405 (phone)
202-767-3553 (fax)

If trees could scream, would we be so cavalier about cutting them down?
We might, if they screamed all the time, for no good reason. --Jack Handy

End of memo #2.

I hope this helps,

Ben

[Ben]

Another memo from Scott

At 11:46 AM -0400 8/25/03, Scott Hannahs wrote:
>LV 7 does a whole bunch of network activity in the background at startup. This can cause apparent hangs if you are not on a network. This article outlines how to reduce or eliminate this network activity.

And to answer my own comment and provide the actual reference I forgot! There is a way to shut off the help connection and the "Service Locator" function or make it local only.

http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/fb8f357ceade7df186256cca00191c6d?OpenDocument

This prevents the whole OS from getting locked up for 20 minutes while it is finding nothing
(really bad programming?). A new options list will be coming out soon, but for those who may need to create a preference file directly the relevant settings are:

helpServerEnabled: False
serviceLocatorEnabled: False
serviceLocatorLocalOnly: True

-Scott


Ben

[nealpederson]

3.) What I meant was that I used LabVIEW 7.1 to build and application that
used Traditional DAQ and RDA. I also get the problem when LabVIEW 7.1 is
shutdown and I double click on a VI that uses Traditional DAQ and RDA
forcing the VI and LabVIEW to load at the same time (the problem doesn't
occur if you first load LabVIEW and then the VI). My primary goal is to run
from the built application.

I have tried this with several hardware scenarios on several computers. My
office setup is an HP laptop and a Dell desktop with a PCI-MIO-16X card.
The systems that don't belong to me have NI-DAQ 7.2, new Dell computers, and
new PXI sytems with PXI-6115 cards in them. These other systems are new and
have only had NI-DAQ 7.2 installed on them so unless the problem was fixed
with NI-DAQ 7.3 then the issue does not have to do with DAQ versions. The
problem is definitely related to LabVIEW 7.1 because it does not occur with
LabVIEW 7.0 or earlier regardless of the NI-DAQ version. I plan to look
into the stuff that Ben sent.

"LA" wrote in message
news:50650000000500000037CB0100-1079395200000@exchange.ni.com...
Hello Neal,

I tried reproducing the error you are having, but in my case
everything worked out well, but maybe it is because we have a
different setup or we are doing different things. This is what I did:

1.) My server and client computers have both WXP and NI-DAQ 7.3
installed.
2.) In my client computer, I created an executable from one of the
shipping examples that are in Help=> Find Examples (Cont Acq&Chart.vi)
and run it. (Is this what you are doing, running an executable?) I
inferred this from what you wrote about "The executable file
"c:\..(path to my VI)" cannot be found."
3.) I have another question please, what did you mean when you
wrote "then tried running a LabVIEW 7.1 built application with the new
DAQ driver"?

If you could also tell me what exact hardware (cards, chassis, etc)
you are using will be very helpful for me to recreate your issue. My
intuition tells me though that the fact you have installed so many DAQ
driver versions, there might be a corrupt file that it not letting you
do the RDA successfully. Did you uninstall the old driver versions
before installing the new ones?

I couldn't find anything regarding the INI files Ben mentioned. I am
going to continue looking into that and will let you know if I find
anything regarding this.

Thank you,

LA

[LA 75]

Hello Neal,

In my attempt to reproduce your issue, I realized that I might not be getting the same error as you because in my computer here I have LV 6.1,7.0 and 7.1 installed. Since pretty much all the computers here have those 3 versions installed, I am going to bring my laptop that only has LV 7.1 and will try to reproduce your issue again. Please allow me some time to do so, and I will be letting you know the results I get.
I am already investigating what Ben said about the ini files, but will be definitely helpful to have the issue reproduced to work on it better.

Thanks for your patience!

LA

[Ben]

This memo just came across the wire;



>To: "Info LabVIEW Mailing List"
>Subject: RE: LV71 App Tries to Access I-Net
>X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003
>From: Jeff.Boettcher@ni.com
>Date: Mon, 12 Jul 2004 10:23:23 -0500
>X-MIMETrack: Serialize by Router on PostOffice4/AUS/M/NIC(Release
> 6.5.1|January 21, 2004) at 07/12/2004 10:23:24 AM, Serialize complete at
> 07/12/2004 10:23:24 AM, Itemize by SMTP Server on
> MailServer01-US/AUS/H/NIC(Release 6.5.1|January 21, 2004) at 07/12/2004
> 10:23:25 AM, Serialize by Router on MailServer01-US/AUS/H/NIC(Release
> 6.5.1|January 21, 2004) at 07/12/2004 10:23:26 AM, Serialize complete at
> 07/12/2004 10:23:26 AM
>Sender:
>List-Software: LetterRip Pro 4.05b5 by LetterRip Software, LLC.
>List-Subscribe:
>List-Digest:
>List-Unsubscribe:
>X-LR-SENT-TO: cat@catscreek.com
>X-NAS-Bayes: #0: 3.11495E-231; #1: 1
>X-NAS-Classification: 0
>X-NAS-MessageID: 17990
>X-NAS-Validation: {8597EF76-EA5F-4B49-8954-90C3B154E9B8}
>
>Hello,
>
>I have spoken with some of the networking guys here at NI about this
>issue.
>
>As Greg mentioned, you guys are already on the right track, aside from the
>calling home stuff. 🙂 In addition to these things, some other places
>where a DNS lookup might occur is:
>
>- when a VI with I/O Name Controls is loaded (they can be networked in
>some cases)
>- (RT) when LabVIEW is launched, if RT is installed, it tries to contact
>the service locator and RT Proxy
>- (RT) when connecting to an RT target
>
>If you have RT installed on your development machine where the executable
>is being built, you might try disabling the "Show LabVIEW Real-Time target
>selection dialog when launched" on the application settings tab before
>building. Aside from that, there's not much you will be able to do to
>disable the DNS lookup at this time. We will consider this functionality
>for a future release.
>
>Regards,
>
>Jeff Boettcher
>National Instruments
>
>
>
> >Subject: RE: LV71 App Tries to Access I-Net
> >From: "Sergey Liberman"
> >Date: Wed, 7 Jul 2004 11:01:29 -0400
> >
> >Paul,
> >
> >> I got problems launching LV7.0 in the MacClassic environment as well.
> >> This INI-entries worked for me:
> >> serviceLocatorEnabled: False
> >> serviceLocatorLocalOnly: True
> >
> >Thanks for your suggestion. It still did not work for me. Here's what I
> >currently have:
> >
> >The executable Add.exe (written and built in LV7.1). The INI file is
> >Add.ini, it is in the same folder as the executable. Its contents:
> >
> > [Add]
> > DNSLookupEnabled=FALSE
> > serviceLocatorEnabled=False
> > serviceLocatorLocalOnly=True
> > helpServerEnabled=False
> >
> >Additionally, the following Windows services are stopped:
> >- NI Service Locator
> >- nidevldu
> >- NILM license manager
> >- nipxirmu
> >- niRTProxy
> >- all Lookout services
> >
> >Upon launch of Add.exe, the firewall reports it trying to access IP
>address
> >204.127.198.19:DNS. After I deny access, the application starts and works
> >normally.
>
> >(A few days ago, it was a different IP address, but both of them seem to
>be
> >Comcast name servers:
> >204.127.198.19 - ns7.attbi.com; 63.240.76.19 - ns10.attbi.com)
> >
> >If you can think of anything else, please let me know. Thanks!
> >
> > Sergey Liberman sliberman@solidusintegration.com
> > Solidus Integration http://solidusintegration.com


End of memo:

Ben

[LA 75]

Hello Neal,

I tried reproducing your issue with Andrew, and we didn't have any problems. We used a shipping example using Traditional DAQ, and run it on a client computer using RDA. We even created an executable from that shipping example and didn't have any problems.

I am investigating about the ini files that Ben mentioned. I already got in contact with R&D and we are investigating about this. I will let you know about any updates of this next week.

Thanks,

LA

[JD2]

Has NI fixed this problem yet? We are experiencing the same problem with an application
we developed. We start the executable and after about 1 and a half minutes the front panel
is finally displayed. If MAX is loaded before running the executable this is reduced to about
15 seconds.

John

[sergesl]

Hello Neal,

There have been a couple of suggestion in the replies above, namely disabling the network activity check at startup (see http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/fb8f357ceade7df186256cca00191c6d?OpenDocument) and disabling the Show LabVIEW Real-Time target option: ">If you have RT installed on your development machine where the executable
>is being built, you might try disabling the "Show LabVIEW Real-Time target
>selection dialog when launched" on the application settings tab before
>building." Have you tried any of these options?

Also, does it make a difference whether you have MAX running or not?

Serges L.