Re: spec Channel Access calls timeout

[Gerry Swislow <gerry@certif.com>]

Hi folks,

This thread interests me, of course.  I will be at APS on Monday, Dec 
2.  It might be worthwhile to set up a meeting with some EPICS experts 
to go over the EPICS code in spec to see what (if anything) can be done 
to make spec more robust at the beamlines where there are timeout 
problems.

> Mark wrote:
>> Do you know what PVs those timeouts are occuring for, and are they 
>> Puts or
>> Gets?
>
> Great question.  Don't know how to find the answer.
> Doesn't spec have a debug mode wherein we can examine
> the communications sent/received by spec?
> Anyone remember how to do that?  I believe the output
> can be logged to an external file so that the diagnostics
> don't have to appear on the user's console.

The commands are:

fon dlog
debug 128
....
fclose dlog
debug 0

'fon' opens and turns on a file for output.  'fclose' closes a file.

An output file named 'log' or anything.log logs all output, and will 
not be turned off on ^C or errors, as are ordinary output files.

An output file named 'dlog' or anything.dlog is similar to a 'log' 
file, but debugging output won't appear on the screen.

The 'debug' macro sets the value of DEBUG, where each bit corresponds 
to a different debugging category.

The debugging log files can get quite big.  One might want to start 
over if nothing interesting happens.  The following macros can help 
with the starting over:

global dlog_cnt
# saves the current dlog file temporarily
def newdebug '
          close('dlog')
          unix(sprintf('mv -f dlog dlog.sav\n'))
          on('dlog')
'
# archives the current dlog file
def savdebug '
          close('dlog')
          unix(sprintf('mv dlog dlog.%03d\n', dlog_cnt++))
          on('dlog')
'
def debug_on'
          debug 192
          on('dlog')
'
def debug_off'
          debug 0
          close('dlog')
'

Every so often, type 'newdebug' to recycle.  If an event is captured, 
type 'savedebug' to save the file.


> Mark Rivers wrote:
>> Tom Trainor talked to Gerry today, and found that there is a way to 
>> trap
>> errors in user macros, so that when an error occurs spec won't stop, 
>> but
>> will instead go to the next command in the user command file.
>
> What's the method?  Probably we all could benefit here.

 From the 'changes' help file:

RELEASE 4.05.01
      These notes summarize the cumulative changes made for spec release
      4.05.01 as of June 13, 1999.
.....
New Option To Keep Going After An Error In a Command File
      You can now tell spec to keep reading and executing commands from a
      command file no matter what errors occur.  The new 'keep_going'
      option to spec_par(), if set, will tell spec not to return to
      command level and the main interactive prompt on any type of error.
      Instead, the next line from the current command file will be read.
      Note, depending on where the error is in a file, reading subsequent
      lines will generate more errors, particularly if the error occurs
      inside a statement block.

In other words type  spec_par('keep_going', 1)  at the spec prompt, or 
put that line in the
site.mac file, if you want to always have that mode set.

Gerry