Jay,
I don't know of anyone else using saveData to write to windows NFS.
Is there any other NFS server around that you could try writing to?
Tim
On 11/3/2010 10:07 AM, Jay Steele wrote:
Hi
Mark and Tim,
I'm not entirely
clear yet on how saveData works, but I'm working with cygwin
as a host environment to cross-compile the vxWorks target
image using the gcc-vxWorks cross-compiler. I believe that
saveData is executing on vxWorks, creating a NFS mount to my
Windows computer, successfully creating a scan file on the
Windows computer, successfully writing out the header info to
this file, then getting an error while executing the
xdr_setpos function. Since the file write was unsuccessful,
the code starts over to write out to the file 9 more times and
then gives up.
Tim - let me know if
you come up with any other tests I can do to illuminate the
source of this problem with xdr_setpos. In the meantime, I'll
continue inspecting the saveData.c source code and trying to
debug the code on my own. One thought - since xdr_setpos is a
UNIX-type function, could this be a problem with the Windows
filesystem? Has anybody ever tested scanning with a Windows
NFS mount file?
I appreciate your
rapid tech-talk feedback late at night and early in the
morning.
Thanks,
Jay Steele
From: Mark Rivers
[[email protected]]
Sent: Wednesday, November 03, 2010 4:21 AM
To: Tim Mooney; Jay Steele; EPICS tech-talk
Subject: RE: FW: write failure occuring in
writeScanRecInProgress function(after writing header) in
saveData.c (sscan-2-6-6 module)
Tim and Jay,
I'm confused. Jay's original message said:
"... start the scan and the vxWorks terminal
reports the following (with debug_saveData =10,
debug_saveDataMsg=10)"
"... I'm using epics-3-14-11 with VxWorks and
compiling with cygwin on windows-x86."
Which implies that Jay has saveData running on
vxWorks. But I think Tim is talking about a possible problem
arising from the Cygwin switch to the new xdr code (tirpc),
which should not affect cross-compiling Cygwin to vxWorks,
only code running locally on Cygwin?
Mark
From:
[email protected] on behalf of Tim Mooney
Sent: Wed 11/3/2010 1:51 AM
To: Jay Steele; EPICS tech-talk
Subject: Re: FW: write failure occuring in
writeScanRecInProgress function(after writing header) in
saveData.c (sscan-2-6-6 module)
Jay, This is trouble, though I don't know why xdr_setpos()
is returning an error. I've found
on the web indications that others have had trouble with
xdr_setpos() not working on
some streams (ref
http://linux.die.net/man/3/xdr_setpos) but I haven't
found out why.
It may simply be that folks neglected to implement the
function in the xdr library, when
they switched cygwin over to new code.
If worse comes to worst, I could recode saveData so it does
the xdr writes "by hand",
instead of relying on an xdr library. But I'd like to find out
more before doing that.
Tim
On 11/2/2010 6:21 PM, Jay Steele wrote:
Yes
- xdr_setpos is returning 0. What does this mean?
Thanks,
Jay Steele
From: Jay Steele
Sent: Tuesday, November 02, 2010 3:51 PM
To: Tim Mooney
Cc:
[email protected]
Subject: RE: write failure occuring in
writeScanRecInProgress function (after writing header)
in saveData.c (sscan-2-6-6 module)
Hi Tim,
The
function is exiting out of this block of code (I added
the printf("write failed\n") line).
****************************************************************
if
(pscan->old_npts < pscan->npts) {
writeFailed |= !xdr_setpos(&xdrs,
pscan->dims_offset);
Debug3(2, "saveData:writeScanRecInProgress:(%s)
scan_dim=%d, dims_offset=%ld\n",
pscan->name, pscan->scan_dim,
pscan->dims_offset);
if (writeFailed) {
printf("write failed\n");
goto cleanup;
}
lval = pscan->npts;
writeFailed |= !xdr_long(&xdrs, &lval);
}
*****************************************************************
Cheers,
Jay Steele
From: Tim Mooney [[email protected]]
Sent: Tuesday, November 02, 2010 3:47 PM
To: Jay Steele
Cc:
[email protected]
Subject: Re: write failure occuring in
writeScanRecInProgress function (after writing header)
in saveData.c (sscan-2-6-6 module)
Jay,
The next thing saveData wants to do, after the last
message you've shown,
is to call xdr_setpos(), and I'm pretty sure this will
be its first call to xdr_setpos()
for the file. I'll guess xdr_pos() is returning an
error (zero). Can you check to see
if this is true?
Tim Mooney
Jay Steele wrote:
Hi EPICS tech-talk,
I'm having a problem executing my
first simple 1D scan here at XRadia. I set up the
scan as simply as I could - with one positioner
and one data source (SIS 3820 board with input to
channel #9 from a signal generator). I am using
TPMAC records (e.g., bkgfix1pcs_scanrec_v3.db and
AssyGeneric_scanrec_v3.db to set up records) for
the positioner. I verified that the SIS 3820
record works to count the pulses from the signal
generator, and also that I can move the motor
simply by setting 21:D3:BNP:XY:PX:RqsPos. I start
the scan and the vxWorks terminal reports the
following (with debug_saveData =10,
debug_saveDataMsg=10) and keeps trying to write to
the scan file without success. Attached is a
screen shot of the MEDM interface for the scan.
I'm using epics-3-14-11 with VxWorks and compiling
with cygwin on windows-x86.
saveDataTask:
MSG_SCAN_PXNV, ix=0, val=2.000000
21:D3:BNP:scan1 MSG_SCAN_PXNV(2)= 0.000000
saveDataTask: MSG_SCAN_PXNV, ix=0,
val=0.000000
21:D3:BNP:scan1 MSG_SCAN_PXNV(0)= 0.000000
saveDataTask: MSG_DESC, val=
MSG_DESC()= 0.000000
nb_scan_running=1
saveDataTask: MSG_SCAN_DATA, val=0
proc_scan_data(21:D3:BNP:scan1):entry:pmsg->val=0
scan started: 21:D3:BNP:scan1
Checking number of valid positioner
Checking number of valid detector
Checking number of valid trigger
Outermost scan
proc_scan_data(21:D3:BNP:scan1):New file
saveData: stat returned -1 for filename
'/data/Nov-1-2010/test_0008.mda'; errno=
3145730
saveData:writeScanRecInProgress: Opening file
'/data/Nov-1-2010/test_0008.mda'
saveData:writeScanRecInProgress: Writing file
header
saveData:writeScanRecInProgress: scan_dim=1
saveData:writeScanRecInProgress:(21:D3:BNP:scan1)
scan_dim=1, dims_offset=0
saveData:writeScanRecInProgress: File Header
written
saveData:writeScanRecInProgress: Writing
per-scan header
saveData:writeScanRecInProgress: Save scan
info
saveData:writeScanRecInProgress: Pos[0] info
saveData:writeScanRecInProgress: Det[0] info
saveData:writeScanRecInProgress: Trg[0] info
saveData:writeScanRecInProgress: Allocate
space for Pos[0]
saveData:writeScanRecInProgress: Allocate
space for Det[0]
saveData:writeScanRecInProgress:(21:D3:BNP:scan1)
scan_dim=1, dims_offset=0
From this output, I tracked the problem
down to a write failure in the
writeScanRecInProgress function in saveData.c.
This occurs after the function writes out the
file header and allocates space for Pos[0] and
Det[0].
I'm confused why there would be a write
failure at this point. Can anybody determine
from this problem what might be wrong with
my setup to cause this problem?
Thanks,
Jay Steele
XRadia
Corporation
The
information in this email, including any
attachments, is confidential and intended only for
the recipient(s) listed. Any use of this email for
any other purpose is prohibited. If you have
received this email in error, please notify me
immediately by reply email, delete this email, and
do not disclose its contents to anyone.
--
Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab
The information in
this email, including any attachments, is confidential and
intended only for the recipient(s) listed. Any use of this
email for any other purpose is prohibited. If you have
received this email in error, please notify me immediately
by reply email, delete this email, and do not disclose its
contents to anyone.
--
Tim Mooney ([email protected]) (630)252-5417
Software Services Group, Advanced Photon Source, Argonne National Lab.
The information in this
email, including any attachments, is confidential and intended
only for the recipient(s) listed. Any use of this email for any
other purpose is prohibited. If you have received this email in
error, please notify me immediately by reply email, delete this
email, and do not disclose its contents to anyone.
--
Tim Mooney ([email protected]) (630)252-5417
Software Services Group, Advanced Photon Source, Argonne National Lab.
|