Experimental Physics and Industrial Control System
|
On Nov 3, 2008, at 7:39 PM, Szalata, Zenon M. wrote:
Hi Dirk,
Thank you for replying.
First, a little explanation.
The instrument only sends the waveform data as ASCII coded string,
no raw data option is available.
I chose to use genSub to reformat the data only because I needed to
rescale it by adding offset and multiplying the result by a scale
factor. These come from longin epics records.
I implemented your suggestion for the protocol and also added
ReadTimeout=2000 to the protocol. This unfortunately did not cure
the interference I see between the two GPIB instruments as described
in my original note. So, now I have:
--------------------------------------------
record( waveform, "$(P)wfTrCh$(N)Data"){
field( DESC, "hist$(N) data")
field( DTYP, "stream")
# field( DISV, "0")
# field( SDIS, "$(P)wCh$(N)Enable.VAL NPP NMS")
field( INP, "@rfpmChan.proto rTDCh12($(N)) L$(L) $(A)")
field( EGU, "points")
field( NELM, "1000")
field( FTVL, "FLOAT")
field( FLNK, "$(P)gsCh$(N)WForm PP")
}
rTDCh12{ ReadTimeout=2000; Separator=",";
out "TRAC:SOUR CH\$1;:TRAC\$1:INDEX 1;:TRAC\$1:AVER:DATA?";
in "%f";}
--------------------------------------------
I suppose it is possible that I do not really know how to use the
ICS 8065 controller, or that this device has some implementation flaw.
Eric Norum suggested that perhaps merging these two IOC's into one
could lead to a working solution. What do you think? I have used
epicsMutex in a device driver I wrote, but I do not see how to use
something like a Mutex on the epics record level. Of course, a very
simple solution would be to use one ICS 8065 Ethernet - GPIB
controller for each IOC.
In the one IOC solution it might be possible to carefully arrange
record scanning such that no two data reading records can scan
simultaneously. It seems tricky.
I don't think that any trickiness is needed in this case. As Dirk
mentioned, the command/response will be an atomic operation when only
one IOC is communicating with the GPIB/LAN adapter.
The problem is that when you have multiple IOCs communicating with the
GPIB/LAN adapter you have no guarantee that IOC B will not issue a
request in between the command/response of IOC A.
I am quite sure that switching your applications around so that only
one IOC is connected to the GPIB/LAN adapter will fix the problem.
Yes, the VXI-11 protocol does provide lock/unlock operations, but:
a) a given GPIB I/O operation already takes an awful lot of TCP/IP
packets back and forth
and
b) the possibilities of deadlock seem all too likely, especially if
one IOC decides to quit in the middle of a transaction.
If you really want to have two IOCs I think that it would be best to
use two GPIB/LAN adapters as well.
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793
- References:
- GPIB - asyn - streamdevice Szalata, Zenon M.
- Re: GPIB - asyn - streamdevice Dirk Zimoch
- Re: GPIB - asyn - streamdevice Dirk Zimoch
- RE: GPIB - asyn - streamdevice Szalata, Zenon M.
- Navigate by Date:
- Prev:
RE: GPIB - asyn - streamdevice Szalata, Zenon M.
- Next:
Re: GPIB - asyn - streamdevice Dirk Zimoch
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: GPIB - asyn - streamdevice Szalata, Zenon M.
- Next:
Re: GPIB - asyn - streamdevice Dirk Zimoch
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|