> Now the question is: How do I do
> it? It seems to me that there can only be one asyn record
> per IOC application. I am assuming that because there seems
> to be only "implicit" (or built in) device support for the
> asyn record. Is that so?
No, there is no limitation of one asyn record per IOC application.
There can be many asyn records. Each is connected to an asyn port
driver. The asyn record can be dynamically changed from one asyn port
server to another at run time, which is typically only done when
debugging. This is controlled via the PORT and ADDR fields.
> What if I wanded to read the data from the device with the asyn
> record? How could that be done? In other words, Can the
> asyn record be somehow setup to first write the data and then
> read the data from the same device?
Yes, that is done by simply setting TMOD="Write/Read" (which is the
default). In that mode the asyn record will first write the data, and
then read the response.
> 4. I can see how to achieve what is listed in point 1. if I
> can access the asyn data structure from the process
> subroutine of the genSub record. How can I access the asyn
> record data structure from that subroutine?
The genSub record provides you with an output link (e.g. OUTA) to which
it writes the output values (e.g. VALA). The VALA field can be an
array. So you just need to set OUTA to be asyn.BOUT, set the number of
elements (NOVA) and field type (FTVA), and have your subroutine load
VALA with the correct values.
Mark
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Szalata, Zenon M.
> Sent: Monday, October 15, 2007 3:52 PM
> To: Tim Mooney
> Cc: EPICS tech-talk
> Subject: RE: genSub
>
> Hi,
> I like the idea of using the asyn record to output the data
> to the camac crate controller (KS3988). My test soft IOC is
> using asyn support anyway. Now the question is: How do I do
> it? It seems to me that there can only be one asyn record
> per IOC application. I am assuming that because there seems
> to be only "implicit" (or built in) device support for the
> asyn record. Is that so?
> 1. the data, which consists of 10 to 15 bytes of numbers
> (some zero) is constructed in the process subroutine of a
> genSub record. Somehow, the data and the number bytes need
> to be transferred to the BOUT and NOWT fields of the asyn
> record. Also, TMOD needs to be given value "Write" and OFMT
> "Binary". These two I could do in the asynRecord.db file.
> 2. I suppose I could force processing of the asyn record via
> FLNK in the genSub record.
> 3. When the asyn record is done writing the data to the
> device, Then the IOC needs to start reading an array of
> integers from the same device. I see that the asyn record
> has a FLNK field, so I could use that to trigger processing,
> for instance, of a waveform record. This might work. What
> if I wanded to read the data from the device with the asyn
> record? How could that be done? In other words, Can the
> asyn record be somehow setup to first write the data and then
> read the data from the same device?
> 4. I can see how to achieve what is listed in point 1. if I
> can access the asyn data structure from the process
> subroutine of the genSub record. How can I access the asyn
> record data structure from that subroutine? Is there a
> better (safer) way to accomplish what is in point 1?
> 5. One more, a bit more general question. In an output
> record, e.g. ao, it is necessary to specify what device to
> output the data to. This is done using the
> field( out,"#L<link> A<addr> @<number>") statement. I can
> easily imagine a case where no gpibCmd is needed to do the
> IO. In such a case how is the @<number> specified? Can it be
> just omitted in the field statement?
> Thanks,
> Zen
> -----Original Message-----
> From: Tim Mooney [mailto:[email protected]]
> Sent: Monday, October 15, 2007 6:59 AM
> To: Szalata, Zenon M.
> Cc: EPICS tech-talk
> Subject: Re: genSub
>
>
>
> Zen,
> The aao (array analog out) record and the asyn records can
> write an array of bytes from an EPICS PV to a device. The
> aao record is in base, though it's not built by default in at
> least some versions. (See <base>/src/rec/Makefile.) The asyn
> record is not in base, but in the asyn module. This record
> has the field, BOUT, which I think will suit your purpose.
>
> Tim
>
> Szalata, Zenon M. wrote:
> > Thanks Tim,
> > In this case, one more difficulty remains. I think ao is not
> > appropriate because the data to be output typically
> consists of 10 to
> > 15 bytes of numeric data, 0 value being valid and could be
> anywhere in
> > the array. This I think, makes stringout not useful. Can
> waveform be
> > used to output array of bytes? Quick look at the definition of the
> > waveform record tells me that it can only be used for input, I see
> > only INP link there. What else is there that can handle writing an
> > array of bytes to a device? Thanks again, Zen
> >
> > -----Original Message-----
> > From: Tim Mooney [mailto:[email protected]]
> > Sent: Sunday, October 14, 2007 5:50 PM
> > To: Szalata, Zenon M.
> > Cc: EPICS tech-talk
> > Subject: Re: genSub
> >
> >
> >
> > Szalata, Zenon M. wrote:
> >
> >
> >>I have successfully put together a soft IOC which consists
> of a number "Soft Channel" type of records. These are mostly
> longin, one ot two bo and mbbo, and one genSub. In the edm
> companion for this IOC, I have a number of text controls to
> put new values into all the records with the exception of the
> genSub record. There is a Message Button in the edm program
> which is used to trigger processing of the genSub record,
> When genSub is processed it takes the values from all the
> other records, performs some calculations, creates a string
> of numeric values and prints the results. All works fine.
> >>Next step in the evolution of this learning exercise is to
> output the calculated result to a GPIB CAMAC crate controller
> (in this case KS3988). I do not know how to do that.
> >>I am using asyn.
> >>1. genSub is not part of EPICS nor asyn. There is no
> DSET_xx type of definition
> >> for it that I can find.
> >>2. In my case I do not need a gpibCmd for it, but it seems
> to me that I need to
> >> have the device( genSub, GPIB_IO, devyyxxxx, "XXXXX")
> statement, so that I can
> >> specify that the output is GPIB_IO...
> >>What do I need to do to accomplish that?
> >>I have tried a few combinations and either the IOC
> generates a linking error or crashes with segmentation fault
> when the IOC is initialized. I guess, I need an example
> showing how to do that. I see in "myExample" (chapter 2 in
> EPICS IOC Application Developer's Guide) how to add a use
> defined "Soft Channel" type record.
> >
> >
> > You can't use device support with the genSub record. The
> record simply lacks the code required to use device support.
> You'll have to get the genSub record to write to a record
> that can have device support, such as an ao record.
> >
> >
> >>Once I overcome the previous difficulty, I think I will
> have another problem to solve. This is what I am worried about.
> >>1. When I send a certain combination of numberic values to
> KS3988, it should be
> >> ready to return some data. That is, sending it some
> sequence of numbers
> >> prepares the crate controller to return some numeric results.
> >>2. I am thinking to have a forward link in the genSub
> record to a waveform record
> >> which would be setup to read from the GPIB controller.
> Is it guaranteed that
> >> the waveform record is processed after the genSub record
> has sent the command
> >> bytes to the controller? If not, what should I do to
> assure properly timed
> >> execution of the two records?
> >
> >
> > Yes, If you have an output record that writes to a device
> and forward links to an input record, the input record will
> not process until the output record has sent its data.
> >
> > In view of previous comment, of course, you would in actual
> practice have the genSub record write (using a PP link) to an
> ao record (for example), and have the ao record forward link
> to the waveform record.
> >
> >
> >>Many thanks in advance,
> >>Zen
> >
> >
> >
> > --
> > Tim Mooney ([email protected]) (630)252-5417 Beamline
> Controls & Data Acquisition Group Advanced Photon Source,
> Argonne National Lab.
>
> --
> Tim Mooney ([email protected]) (630)252-5417 Beamline
> Controls & Data Acquisition Group Advanced Photon Source,
> Argonne National Lab.
>
>
- References:
- RE: genSub Szalata, Zenon M.
- Navigate by Date:
- Prev:
Re: fedora core 7 medm (was >> Re: MEDM compile - update :) Bertrand H.J. Biritz
- Next:
Re: which ca_get failed? Jeffrey O. Hill
- 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: genSub Szalata, Zenon M.
- Next:
which ca_get failed? 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
|