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: The INP field
From: Mark Rivers <[email protected]>
To: "'[email protected]'" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>
Date: Wed, 6 Feb 2013 15:57:12 +0000

I second what Nick has said.  If you use asyn then you should be able to use the standard asyn device support.  You only need to write an asyn port driver.  If you base that on the asynPortDriver C++ base class then most of the overhead of configuring the asyn port driver is taken care of for you, and the amount of code you need to write is minimized.

 

Mark

 

 

From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Wednesday, February 06, 2013 8:15 AM
To: [email protected]; [email protected]
Subject: RE: The INP field

 

Hi Bruno,

 

While I don’t know anything about your particular device, in general I would recommend using the asynDriver framework for new devices. This already does most of the legwork for you and you only have to write one layer of support. Also, despite its name, it works with synchronous as well as asynchronous devices.

 

Cheers,

 

Nick Rees

Principal Software Engineer           Phone: +44 (0)1235-778430

Diamond Light Source                  Fax:   +44 (0)1235-446713

 

From: [email protected] [mailto:[email protected]] On Behalf Of Bruno Seiva Martins
Sent: 06 February 2013 13:34
To: [email protected]
Subject: The INP field

 

Hi everyone,

 

I'm writing both device and driver support layers for my custom device. I'm trying to make them as generic as possible, but for that purpose I need to pass them some configuration parameters.

 

They interface with common records: AI, AO, BI and BO. I'm trying to pass those configurations parameters, via INP/OUT field of those records. There are four parameters I would like to pass. For instance, I would like to be able to do something like:

 

record(ai, "LOCON$(Addr):ai")

{

    field(DTYP, "LocoAi")

    field(DESC, "Local Converter Analog Input")

    field(SCAN, "1 second")

    field(INP,  "$(Addr).$(Param1).$(Param2).$(Param3)")

    field(PREC, "3")

    field(EGU,  "Volts")

    field(LINR, "LINEAR")

}

 

Notes: The separator must not necessarily be the dot character, could be anything. All four parameters are numerical.

 

Then I would like to parse the resulting string in my init_record code:

 

//...

char configString[40] = {0};

recGblInitConstantLink(&record->inp, DBF_STRING, configString);

// parse config string

 

 

This won't work. And the documentation is very clear about that:

 

 

"Input link fields and desired output location fields can specify a constant instead of a hardware or database address. A constant, which is not really an address, can be an integer value in whatever format (hex, decimal, etc.) or a floating-point value. "

 

BUT I can access that resulting string using:

 

record->inp.value.constantStr

 

 

Now, I have several questions I couldn't find the answers by myself:

 

1. Is there another way of passing several (in my case, four) numerical parameters from the record to the device support? Right now I'm accessing the string using record->inp.value.constantStr, but this feels dirty and hacky. 

 

2. I could pack those four values into one unsigned long value, as each one of them is one byte long, but this wouldn't be recommended, would it?

 

3. If the INP field (when CONSTANT) is a number only (and I have tested the outputs of recGblInitConstantLink with several inputs to confirm that), what is the purpose of that constantStr field in the value union? Is it just to hold the value before it is parsed?

 

4. Will I have to write new records or record supports?

 

 

Thanks in advance!

 

Best regards!

 


Bruno

 


References:
The INP field Bruno Seiva Martins
RE: The INP field nick.rees

Navigate by Date:
Prev: RE: The INP field nick.rees
Next: Problem with mca R7.2 and Rontec XFlash Phillip Sorensen
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: The INP field nick.rees
Next: Problem with mca R7.2 and Rontec XFlash Phillip Sorensen
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 ·