EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Comms issue with New Focus 8752 motor driver
From: Mark Rivers <[email protected]>
To: "'[email protected]'" <[email protected]>, "[email protected]" <[email protected]>
Date: Tue, 20 Aug 2013 19:25:19 +0000
It seems that sometimes when the VER command is issued the response does not arrive before the timeout expires.  But then it does eventually arrive, and screws up the expected response to the DRT command.  The timeout is defined on this line in the driver:

#define PMNC_TIMEOUT    3.0     /* Command timeout in sec. */

There is something I really don't understand in the output:

2013/08/20 17:37:57.709 192.168.42.31:23 write 4
VER\r
2013/08/20 17:37:57.716 192.168.42.31:23 read 1
>
send_recv_mess(): recv message = ""
send_recv_mess(): message = VER
2013/08/20 17:37:57.717 192.168.42.31:23 write 4
VER\r
send_recv_mess(): ERROR - staus =1, nread = 0
send_recv_mess(): message = VER
2013/08/20 17:37:57.736 192.168.42.31:23 write 4
VER\r
2013/08/20 17:37:57.742 192.168.42.31:23 read 16
Version 1.6.0\r\n>
send_recv_mess(): recv message = "Version 1.6.0
"

The line

send_recv_mess(): ERROR - staus =1, nread = 0

Is coming from this code (note the typo on status, spelled staus):

    /* Perform atomic write/read operation  */
    status = pasynOctetSyncIO->writeRead(cntrl->pasynUser, send_com, size,
                                         recv_com, BUFF_SIZE-1,
                                         PMNC_TIMEOUT, &nwrite, &nread, &eomReason);
    if (eos)
      // Reset EOS to default
      pasynOctetSyncIO->setInputEos(cntrl->pasynUser,PROMPT_EOS,strlen(PROMPT_EOS));

    if (status != asynSuccess)
    {
      int int_status = (int) status;
      Debug(3, "send_recv_mess(): ERROR - staus =%d, nread = %d\n", int_status, nread);
      recv_com[0] = '\0';
      return(MESS_ERR);
    }

status=1 is asynTimeout.  So this is saying that the writeRead operation failed with a timeout on the read, and nread=0.

But look at the timestamps above. Only 19 ms has elapsed between the second 2 "write 4" messages, but in that time the read has timed out!  This does not make sense, there should be a 3 second delay in there before the read times out.

Mark




-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Tuesday, August 20, 2013 1:14 PM
To: [email protected]
Subject: Comms issue with New Focus 8752 motor driver

Hi all,

I'm having an intermittent communications problem when using the NewFocus 8752 motor controller driver.

My setup is EPICS 3.14.12.3, Motor R6.8, and asyn 4.21, on an Ubuntu 12.04 Linux IOC, connected via Ethernet to the 8752 (firmware version 1.6.0).  In my st.cmd file I configure the driver along with some asyn debug to see the problem (unrelated bits of st.cmd omitted):

drvAsynIPPortConfigure("serial1", "192.168.42.31:23", 0, 0, 0)
asynOctetSetInputEos("serial1",0,">")
asynOctetSetOutputEos("serial1",0,"\r")

asynSetTraceIOMask("serial1",0,2)
asynSetTraceMask("serial1",0,9)

var drvPMNC87xxdebug 4
PMNC87xxSetup(1, 2, 10)
PMNC87xxConfig(0, "serial1")

dbLoadTemplate("motor.substitutions")

All is well about 80% of the time I run st.cmd, with the driver starting OK and I can control the motor nicely.  But about 20% of the times I start the IOC, the initial driver configuration goes wrong in one of 2 ways.  Sometimes I get an "invalid driver" error from drvPMNC87xx:motor_init():

Starting iocInit
############################################################################
## EPICS R3.14.12.3 $Date: Mon 2012-12-17 14:11:47 -0600$
## EPICS Base built Aug  8 2013
############################################################################
send_recv_mess(): message = VER
2013/08/20 17:37:57.709 192.168.42.31:23 write 4
VER\r
2013/08/20 17:37:57.716 192.168.42.31:23 read 1
>
send_recv_mess(): recv message = ""
send_recv_mess(): message = VER
2013/08/20 17:37:57.717 192.168.42.31:23 write 4
VER\r
send_recv_mess(): ERROR - staus =1, nread = 0
send_recv_mess(): message = VER
2013/08/20 17:37:57.736 192.168.42.31:23 write 4
VER\r
2013/08/20 17:37:57.742 192.168.42.31:23 read 16
Version 1.6.0\r\n>
send_recv_mess(): recv message = "Version 1.6.0
"
send_mess(): message = DRT
2013/08/20 17:37:57.743 192.168.42.31:23 write 4
DRT\r
2013/08/20 17:37:57.767 192.168.42.31:23 read 16
Version 1.6.0\r\n>
"ecv_mess(): message = "Version 1.6.0
drvPMNC87xx:motor_init() - invalid driver = -1
No init PV: ZZ-SM-FF:mX dev_NoInit (init_record_com: callback2 timeout

No init PV: ZZ-SM-NF:mX dev_NoInit (init_record_com: callback2 timeout

The problem here seems to be the driver is sending the VER command more than once, and the second response to it is being interpreted as a response to the later DRT command causing the problem.

The other thing that can happen is I get a "card does not exist" error from motor_init_record_com().  This seems to be caused by recv_mess() getting an error status back from pasynOctetSynIO->read():

Starting iocInit
############################################################################
## EPICS R3.14.12.3 $Date: Mon 2012-12-17 14:11:47 -0600$
## EPICS Base built Aug  8 2013
############################################################################
send_recv_mess(): message = VER
2013/08/20 17:31:31.733 192.168.42.31:23 write 4
VER\r
2013/08/20 17:31:31.741 192.168.42.31:23 read 1
>
send_recv_mess(): recv message = ""
send_recv_mess(): message = VER
2013/08/20 17:31:31.741 192.168.42.31:23 write 4
VER\r
2013/08/20 17:31:31.765 192.168.42.31:23 read 16
Version 1.6.0\r\n>
send_recv_mess(): recv message = "Version 1.6.0
"
send_mess(): message = DRT
2013/08/20 17:31:31.765 192.168.42.31:23 write 4
DRT\r
recv_mess(): ERROR - staus =1, nread = 0
motor_init(): Total Drivers 0
Total Axis=0
Illegal field value PV: ZZ-SM-FF:mX motor_init_record_com(): card does not exist!

For comparison, a 'normal' set of debug messages starts like this, with the DRT response being received OK (interestingly the VER command is still being sent more than once as the first reply is just the > prompt):

Starting iocInit
############################################################################
## EPICS R3.14.12.3 $Date: Mon 2012-12-17 14:11:47 -0600$
## EPICS Base built Aug  8 2013
############################################################################
send_recv_mess(): message = VER
2013/08/20 17:27:43.586 192.168.42.31:23 write 4
VER\r
2013/08/20 17:27:43.594 192.168.42.31:23 read 1
>
send_recv_mess(): recv message = ""
send_recv_mess(): message = VER
2013/08/20 17:27:43.594 192.168.42.31:23 write 4
VER\r
2013/08/20 17:27:43.617 192.168.42.31:23 read 16
Version 1.6.0\r\n>
send_recv_mess(): recv message = "Version 1.6.0
"
send_mess(): message = DRT
2013/08/20 17:27:43.617 192.168.42.31:23 write 4
DRT\r
2013/08/20 17:27:43.640 192.168.42.31:23 read 13
A1=1\r\nA2=1\r\n>
"ecv_mess(): message = "A1=1
motor_init(): Next Driver A1=1
"ecv_mess(): message = "A2=1
motor_init(): Next Driver A2=1
recv_mess(): ERROR - staus =1, nread = 1
motor_init(): Total Drivers 2
Total Axis=6

If anyone else has noticed similar behaviour, or has any ideas how to determine why this is happening I'd be most interested to learn.  I can't see any pattern to the failures, it seems to just randomly happen about 1 in 5 times I start the IOC.

Thanks in advance for any help.

Tim Hayton
Central Laser Facility
Rutherford Appleton Laboratory
Science & Technology Facilities Council
UK

PS The Central Laser Facility at RAL has just started using EPICS for a new 100J 10Hz laser project called HiLASE (http://www.stfc.ac.uk/2631.aspx). We're looking forward to becoming part of the EPICS community.

-- 
Scanned by iCritical.



References:
Comms issue with New Focus 8752 motor driver tim.hayton

Navigate by Date:
Prev: RE: Comms issue with New Focus 8752 motor driver Mark Rivers
Next: EPICS Qt Framework Ricardo Fernandes
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Comms issue with New Focus 8752 motor driver Mark Rivers
Next: RE: Comms issue with New Focus 8752 motor driver tim.hayton
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·