Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Tue, 31 Mar 2009 21:19:22 -0500

John,

I don't know what's wrong.  I talk to the Newport XPS motor controller from vxWorks also over TCP/IP and it normally works fine.  I do have a problem with every couple of weeks the sockets being disconnected, but otherwise it works reliably.  Perhaps try increasing the timeouts?  Have you played with that in the asynRecord?

Mark

________________________________

From: John Hammonds [mailto:[email protected]]
Sent: Tue 3/31/2009 7:41 PM
To: Mark Rivers
Cc: Tech Tech Talk
Subject: Re: connections with pasynOctetSyncIO->connect

I should also mention the specs of the non functioning system:

vxWorks 5.5.2
synApps 5.4 which gives motor 6.4.2 and asyn 4-10
mvme2100

John

John Hammonds wrote:
> The information in previous messages was for a vxWorks IOC.  I have
> now tried this on a Linux softIOC and this seems to work fine.  This
> is for the Aerotech Ensemble which is now in the motor package
> included with synApps.  Anyone have any ideas why this might work with
> Linux and not vxWorks?
>
> John
>
> John Hammonds wrote:
>> Mark,
>>
>> This connection is set up with the following commands:
>> drvAsynIPPortConfigure("usaxsEns","164.54.102.16:8000",0,0,0)
>> asynOctetSetInputEos("usaxsEns",0,"\n")
>> asynOctetSetOutputEos("usaxsEns",0,"\n")
>> asynSetTraceMask("usaxsEns",0,0x9)
>> asynSetTraceIOMask("usaxsEns",0,0x2)
>>
>> I only see evidence of the first try for this send that tests
>> communications.  There should be 3 retries.  After the first try we
>> get the message:
>>
>> 164.54.102.16:8000 write error: S_errno_EPIPE
>>
>> We then get the message that seems to come from
>> pasynUser->errorMessage on subsequent retries.
>>
>> I can go to an asynOctet MEDM screen and send some messages.  The
>> trace on these reflects the send/recieve of messages.  I have to send
>> a couple of messages to get the connect but communications can be a
>> bit spotty (sometimes need retries).
>>
>> I can also add the following to the st.cmd and see reasonable
>> communications coming through:
>> asynOctetConnect("myID", "usaxsEns", 0, "\n", "\n", 80, 20)
>> asynOctetWriteRead("myID", "NONE")
>> asynOctetWriteRead("myID", "GETPARM(CONTROL, 265)")
>> asynOctetWriteRead("myID", "GETPARM(@0, 257")
>> asynOctetWriteRead("myID", "AXISSTATUS(@0)")
>>
>> This seems much more reliable than the using the asynRecord
>> Interface.  I took this from an example on
>> http://www.aps.anl.gov/epics/modules/soft/asyn/R4-10/asynDriver.html. 
>> Note however that the documentation for asynOctetConnect does not
>> appear to match the example.
>>
>> John
>> Mark Rivers wrote:
>>> John,
>>> 
>>> I think that if it returns asynSuccess you should ignore the error
>>> message, because it may be stale.
>>> 
>>> What do you see if you turn on asynTrace and do some writes?  Does
>>> the driver claim to be writing?  What type of communication port is
>>> this?
>>> 
>>> Mark
>>> 
>>>
>>> ________________________________
>>>
>>> From: [email protected] on behalf of John Hammonds
>>> Sent: Mon 3/30/2009 11:21 PM
>>> To: Tech Tech Talk
>>> Subject: connections with pasynOctetSyncIO->connect
>>>
>>>
>>>
>>> What checks should be done to verify a connection with
>>> pasynOctetSyncIO->connect?  I have a driver that calls this.  The
>>> return
>>> value is asynSuccess but the pasynUser->errorMessage is "port usaxsEns
>>> or addr -1 not connected" and we see no communication.
>>>
>>> Thanks,
>>> John
>>>
>>> --
>>> John Hammonds
>>> Beamline Controls and Data Acquisition Group
>>> APS Engineering Support Division
>>>
>>> Argonne National Laboratory
>>> [email protected] <mailto:[email protected]>
>>> (630)252-5317
>>>
>>>
>>>
>>>
>>>
>>>  
>>
>

--
John Hammonds
Beamline Controls and Data Acquisition Group
APS Engineering Support Division

Argonne National Laboratory
[email protected] <mailto:[email protected]>
(630)252-5317

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System