disk2file readback on Mk5
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: <John.Reynolds_at_email.protected>
Date: Thu, 9 Dec 2010 15:00:15 +1100 (EST)
Cormac et al.
Some problems were experienced at Parkes during the recent Oct/Nov session
in fringe-checking with the Mk5, using disk2file. Since then I've looked
into it and have now run a couple of simple tests and have some
confidence it will work OK next time, with a little care.
Some details;
o In the original schedule a non-existent target directory
/home/oper/data was specified for the data;
disk2file=,/home/oper/data/vx999e_pa_no0005.m5a,10h27m49.00s,10h27m50.00s,
which I've now created. You could also write to /data on this machine.
It appears the default directory if not specified is the current
working directory of 'dimino', which is possibly why the above directory
was chosen.
NB: the above command specifies a *.m5a suffix instead of *.m5b.
o The original schedule contained commands;
disk2file=abort,,
?ERROR 5f -308 Parameter after abort must be 'autoftp' or blank.
which fs-9.10.0 rejected. The latest fs 9.10.4 (now installed at Parkes)
accepts it.
o Specifying start and stop times in a Mk5b disk2file command will
invariably fail except on the last recorded scan. For example
if there are 98 scans recorded on the active disk module;
03:57:26;disk2file=98,,03h33m46s,03h33m47s
03:57:42;disk2file=98,,03h33m50s,03h33m52s
03:58:49;disk2file=98
all works expected, but if I now record a 99th scan the first two
commands above now fail;
04:01:53;disk2file=98,,03h33m50s,03h33m52s
04:01:53?ERROR m5 -900 Probably flawed scan
as also does;
04:06:54;disk2file=98,,00h00m00s,23h59m59s
04:06:54?ERROR m5 -900 Probably flawed scan
This unadvertised restriction on disk2file (Mark5b) contributed
indirectly to the problems in the last run by creating a
considerable a distraction.
It's still possible to copy previous scans in their entirety;
04:03:22;disk2file=98
just not not selectively, either with absolute or relative start
and stop times.
The obvious consequence of this is that you can't grab a subset of a
scan for fringe-testing once the next scan has been recorded. This
shouldn't normally be a problem when running under a schedule.
I've raised this 'feature' with Dan Smythe and Ed Himwich.
Dan seemed unfazed, remarking pithily;
>> You have opened a can of worms.
>> 'mk5=disk2file' is known not to work as advertised.
Cheers,
John R
Received on 2010-12-09 15:00:46
Date: Thu, 9 Dec 2010 15:00:15 +1100 (EST)
Cormac et al.
Some problems were experienced at Parkes during the recent Oct/Nov session
in fringe-checking with the Mk5, using disk2file. Since then I've looked
into it and have now run a couple of simple tests and have some
confidence it will work OK next time, with a little care.
Some details;
o In the original schedule a non-existent target directory
/home/oper/data was specified for the data;
disk2file=,/home/oper/data/vx999e_pa_no0005.m5a,10h27m49.00s,10h27m50.00s,
which I've now created. You could also write to /data on this machine.
It appears the default directory if not specified is the current
working directory of 'dimino', which is possibly why the above directory
was chosen.
NB: the above command specifies a *.m5a suffix instead of *.m5b.
o The original schedule contained commands;
disk2file=abort,,
?ERROR 5f -308 Parameter after abort must be 'autoftp' or blank.
which fs-9.10.0 rejected. The latest fs 9.10.4 (now installed at Parkes)
accepts it.
o Specifying start and stop times in a Mk5b disk2file command will
invariably fail except on the last recorded scan. For example
if there are 98 scans recorded on the active disk module;
03:57:26;disk2file=98,,03h33m46s,03h33m47s
03:57:42;disk2file=98,,03h33m50s,03h33m52s
03:58:49;disk2file=98
all works expected, but if I now record a 99th scan the first two
commands above now fail;
04:01:53;disk2file=98,,03h33m50s,03h33m52s
04:01:53?ERROR m5 -900 Probably flawed scan
as also does;
04:06:54;disk2file=98,,00h00m00s,23h59m59s
04:06:54?ERROR m5 -900 Probably flawed scan
This unadvertised restriction on disk2file (Mark5b) contributed
indirectly to the problems in the last run by creating a
considerable a distraction.
It's still possible to copy previous scans in their entirety;
04:03:22;disk2file=98
just not not selectively, either with absolute or relative start
and stop times.
The obvious consequence of this is that you can't grab a subset of a
scan for fringe-testing once the next scan has been recorded. This
shouldn't normally be a problem when running under a schedule.
I've raised this 'feature' with Dan Smythe and Ed Himwich.
Dan seemed unfazed, remarking pithily;
>> You have opened a can of worms.
>> 'mk5=disk2file' is known not to work as advertised.
Cheers,
John R
Received on 2010-12-09 15:00:46