Repeated calls to a serial comm's sub-vi

[Alistair Gillespie]

Dear all,

I've written a LabView vi that uses a sub vi to communicate with a serial
instrument. The sub vi is called once every second, and each time it's called
it accesses the pc's hard drive. The disk access appears to write a temporary
file each time the sub-vi runs. When the vi has been running for extended
periods and is then stopped, it can take ages for the hard drive to free-up
before allowing other programs to run. Using the standard set of LabView
serial comm's sub vi's, is there any way of stopping such continuous disk
access?

Thanks in advance,

Alistair Gillespie

[Johannes Niess]

"Alistair Gillespie" writes:

> Dear all,
>
> I've written a LabView vi that uses a sub vi to communicate with a
> serial instrument. The sub vi is called once every second, and each
> time it's called it accesses the pc's hard drive. The disk access
> appears to write a temporary file each time the sub-vi runs. When the
> vi has been running for extended periods and is then stopped, it can
> take ages for the hard drive to free-up before allowing other programs
> to run. Using the standard set of LabView serial comm's sub vi's, is
> there any way of stopping such continuous disk access?

Alistair,

AFAIK there are some reasons why the hard drive might get used. But
none of them is directly related to the serial port:

Another VI is
saving the data from the serial port. (Sometimes too
obvious to see 🙂 )

Your operating system is swapping out some memory to disk in order to
load the serial vi.

You are accumulating the serial data in a huge array and writing it to
disk at the end. This needs RAM for temporary storage.

A memory leak: Memory doesn't get deallocated and this leads to
swapping.


Without any details diagnosis stops at the level of my wild
speculations. Did you think about using VISA? It does a lot of the low
level programming for you. But beware of Linux and _binary_ I/O via
VISA and serial ports. Your data gets messed up (until a fix is
ready).

Johannes Niess

[AndersB]

A commenten on the operatingssystems on win 95
is that the diskcache can increase below the amount of ram memory. If the
max value for diskcache is not set in autoexe.bat or if was system.bat
dont remember which.

Anders Björk

Johannes Niess wrote in message
news:m290163alr.fsf@server.landtechnik.uni-bonn.de...
> "Alistair Gillespie" writes:
>
> > Dear all,
> >
> > I've written a LabView vi that uses a sub vi to communicate with a
> > serial instrument. The sub vi is called once every second, and each
> > time it's called it accesses the pc's hard drive. The disk access
> > appears to write a temporary file each time the sub-vi runs. When the
> > vi has been running for extended periods and is then stop
ped, it can
> > take ages for the hard drive to free-up before allowing other programs
> > to run. Using the standard set of LabView serial comm's sub vi's, is
> > there any way of stopping such continuous disk access?
>
> Alistair,
>
> AFAIK there are some reasons why the hard drive might get used. But
> none of them is directly related to the serial port:
>
> Another VI is saving the data from the serial port. (Sometimes too
> obvious to see 🙂 )
>
> Your operating system is swapping out some memory to disk in order to
> load the serial vi.
>
> You are accumulating the serial data in a huge array and writing it to
> disk at the end. This needs RAM for temporary storage.
>
> A memory leak: Memory doesn't get deallocated and this leads to
> swapping.
>
>
> Without any details diagnosis stops at the level of my wild
> speculations. Did you think about using VISA? It does a lot of the low
> level programming for you. But beware of Linux and _binary_ I/O via
> VISA and serial ports. Your
data gets messed up (until a fix is
> ready).
>
> Johannes Niess

[David Thomson]

Johannes Niess wrote:
>
> "Alistair Gillespie" writes:
>
> > Dear all,
> >
> > I've written a LabView vi that uses a sub vi to communicate with a
> > serial instrument. The sub vi is called once every second, and each
> > time it's called it accesses the pc's hard drive. The disk access
> > appears to write a temporary file each time the sub-vi runs. When the
> > vi has been running for extended periods and is then stopped, it can
> > take ages for the hard drive to free-up before allowing other programs
> > to run. Using the standard set of LabView serial comm's sub vi's, is
> > there any way of stopping such continuous disk access?
>
Alistair,

I have run across one similar situation.
I have a LV program that reads from a serial port. It opens the
port, then has a loop that polls for Bytes at Serial Port. If another
program has grabbed that serial port before the LV program initializes
it, then what I observe is that the hard disk is accessed every time
Bytes at Serial Port.vi is called. (It also returns error 37, of
course.) More specifically, if you look in Bytes at Serial Port, it
calls Open Serial Driver.vi, which in turn calls a primitive called Open
Device. It is this primitive that is responsible for accessing the hard
disk.
Does anyone have any ideas why? Also, could a permutation of this
problem be responsible for what Alistair saw?

Regards,
Dave Thomson

-------------------------------------------------------------
David Thomson 303-499-1973 (voice and fax)
Original Code Consulting original.code@technologist.com
www.utinet.net/~dthomson
National Instruments Alliance Program Member
-------------------------------------------------------------
Research Scientist 303-497-3470 (voice)
NOAA Aeronomy Laboratory 303-497-5373 (fax)
Boulder, Colorado dthomson@al.noaa.gov
-------------------------------------------------------------

[Brian H. Powell]

Regarding the serial functions accessing the hard disk...
In "normal" usage, the functions should not access the hard disk. But
what's "normal"?
First, let me explain how our existing VIs work. When you call a
serial function, we call "Open Serial Driver". If the port has already been
opened, this function just returns a device reference immediately. If the
port has not been opened, though, we load a file called "serpdrv", which is
kind of like a DLL, and call it to open the serial port. If the load of
"serpdrv" succeeds, but the open of the port fails, we unload "serpdrv".
So, this explains the behavior of accessing the disk a lot when LabVIEW
didn't have permission to open the serial port (because another program had
it). La
bVIEW's not smart enough to avoid the unload/reload in this case.
The same thing would happen if you used the Close Serial Port function to
close the serial port--we'll reload "serpdrv" the next time you open the
port.
There are other reasons why we'll reload "serpdrv" with each call. For
example, "Open Serial Driver" only caches a certain number of open sessions.
We had a user with a hundred or so serial ports, and the symptom was that
the first 20 or so worked quickly, and the others were slow. That's because
we reloaded "serpdrv" and went through the motions of reopening the serial
port when we didn't recognize that the port was already opened. It worked
correctly; it just did extra work. The cache size is easy to increase;
there's a For Loop in Open Serial Driver that controls it.
There might be something else going on, but I'd rule these out first.
In the future, we plan on dumping the "serpdrv" idea.


Brian