Hello Bruno:
In short, reading the string and parsing it yourself may be a very good solution.
You've found the C union behind the INP (or OUT) link, defined in link.h
It has elements like vmeio, camacio, instio, ...
Which one of these is used depends on the "device" line in your *.dbd file. If you specify
device(ai, INST_IO, devAiMyDevice, "MyDevice")
then the INP/OUT fields must be of the format "@…" and the text after the "@" ends up in the link.value.instio.string.
If you specify a type of VME_IO, your INP/OUT fields must be of the format "#C1 S3 @whatever"; the EPICS database code will parse that into the card, signal, parameter of the link.value.vmeio.card, ..
The advantage of using one of the existing link formats: There's already a parser for it, so things like VME card, signal numbers are already converted from the link text into numbers. You may even get a somewhat helpful error message if some actual INP/OUT link does not match the expected format.
In principle, if you now have a device that needs a format of "$(Addr).$(Param1).$(Param2).$(Param3)" you could add a new #define to link.h, add the corresponding struct to the union, add the parser code to the EPICS database loader, ...
But then you would also have to convince everybody else who uses EPICS world-wide that this new INP/OUT link format is really useful and should indeed be added to the EPICS base code, because otherwise you would have to re-apply your patch each time you fetch an update of the EPICS base sources.
So in reality nobody has added new link types for a long time, and most new device support modules use the INST_IO type, i.e. they get a string in link.value.instio.string and then parse that in the device support's init_record() routine.
Thanks,
Kay
From: Bruno Seiva Martins <[email protected]<mailto:[email protected]>>
Date: Wednesday, February 6, 2013 08:33
To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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:
http://www.aps.anl.gov/epics/EpicsDocumentation/AppDevManuals/RecordRef/Recordref-5.html#MARKER-9-11
"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
- Navigate by Date:
- Prev:
The INP field Bruno Seiva Martins
- Next:
RE: The INP field nick.rees
- 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:
The INP field Bruno Seiva Martins
- Next:
RE: The INP field nick.rees
- 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
|