launching a simple VISA-related VI takes far too long

[LuI]

Hi,

don't know, if I did it unintentionally, but after yesterdays launch, loading a simple VI (supposed to become a simple test socket device driver) takes several (~30!!!) seconds. A process called NIMAX (seems MAX is working) eats up about 80% of CPU and in the task manager LabVIEW is reported to not responding.
Finally everything recovers, but waiting ~30 seconds in a hanging-like LabVIEW is not very good style.
Any ideas?
BTW, the system is supposed to become a test station; there are lots of devices (~34 VISA devices). AND the questioned VI has a VISA reference control and indicator.

[Al_S]

Have you tried profiling the VIs to see what's causing the delay? From any VI window's menu bar, goto Tools >> Advanced >> Profile VIs. Review the Help on the Profile window.
Start the Profile then start the top level VI. After LabView "recovers", stop the profile and see which VI is eating up all the time. Take a look at that VI to see if it's doing some unnecessary initialization stuff.

[djadjok]

I'm not sure, but may be you get the same problem I've encountered a year ago (forum tread here), concerning VISA controls and a non fully-IEEE488.2 compatible device on PAD#1. So try to use NI-SPY to investigate whats going on with activity on the bus at this time...

[Rolf ?stvik]

LuI wrote in news:506500000008000000ED900000-
1042324653000@exchange.ni.com:

> Hi,
>
> don't know, if I did it unintentionally, but after yesterdays launch,
> loading a simple VI (supposed to become a simple test socket device
> driver) takes several (~30!!!) seconds. A process called NIMAX (seems
> MAX is working) eats up about 80% of CPU and in the task manager
> LabVIEW is reported to not responding.
> Finally everything recovers, but waiting ~30 seconds in a hanging-like
> LabVIEW is not very good style.
> Any ideas?
> BTW, the system is supposed to become a test station; there are lots
> of devices (~34 VISA devices). AND the questioned VI has a VISA
> reference control and indicator.

I have found that when i load (not necessere to execute) a
VI with a VISA
reference control or constant then MAX executes a *IDN? command (or some
other command) on the GPIB bus.

It may be that some instrument is not happy with this, or it may be that
you have a bad GPIB cable which messes up.

How i found out this? (Not important information)
1. Someone said that there happened something on the instruments when they
loaded the VI (Just loaded it, _not_ running it). I rpotested very much,
but they showed me that the instrument went into remote control state when
the VI was loaded.
2. I have an instrument which i have used old GPIB functions for. That
instrument would respond correct to *IDN? command and a lot of other
commands. But when i later executed one specific command then the
instrument hung. I then have to cycle the instrument power. When i started
using VISA in another VI then i got a problem with this instrument even if
i used old GPIB functions for the problematic instrument.

(By the way, about the instrument which di
d not tolerate the *IDN? command,
we have several instruments of that type and the error is dependent of
software version of the instrument and/or version of the GPIB interface of
the instrument)

[djadjok]

Yes, this is exactly the same problem I've referred in my previos post. The problem concernes, anyway, only devices at PAD#1 (to those devices LV send ?IDN command).
For 6i this can not only result in a serios communication delay with a non IEEE-488.2 compatible device, but also in a crash. I don't know if this was fixed in LV6.1 or 7 (as promissed). NI call this "a feature", but I'm really doubt that we can call so such a strange behavior of development enviropment...

[Rolf ?stvik]

defuflo wrote in news:506500000005000000CA010100-
1042324653000@exchange.ni.com:

> Yes, this is exactly the same problem I've referred in my previos
> post. The problem concernes, anyway, only devices at PAD#1 (to those
> devices LV send ?IDN command).

So if my particular instrument (one of 5 different instruments) had another
address than 1 then some of my problems would have disappeared. Gosh.

(By the way, have now read more closely about the problem you refered to
and i now have some explenations.)

--
Rolf