| 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 <2020> 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Opinions please, what should this database do |
| From: | "Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov> |
| To: | EPICS core-talk <core-talk at aps.anl.gov> |
| Date: | Wed, 26 Aug 2020 23:16:47 +0000 |
|
record(stringin, "si") {
field(VAL, "This is a string")
}
record(lsi, "lsi") {
field(SIZV, 80)
field(INP, "si")
field(PINI, YES)
}
record(aai, "aai") {
field(NELM, 100)
field(FTVL, CHAR)
field(INP, "si")
field(PINI, YES)
}
record(waveform, "wf") {
field(NELM, 100)
field(FTVL, CHAR)
field(INP, "si")
field(PINI, YES)
}
The lsi record's Soft Channel device support copies the string from the si record into the lsi.VAL field through its INP link. You can point an lsi link to either a DBF_STRING or an array of DBF_CHARs and it will handle either type.
Should the aai and waveform records also get copies of that string when they process?
Currently the aai.INP and wf.INP links read the si.VAL field and attempt to parse the string into an 8-bit integer, which they would then use to set the first element of their char arrays. The word “This” isn’t a valid integer, so the parsing
fails and both arrays remain empty.
I am considering making changes to the type conversion routines that would make the aai and waveform device supports Do What I Mean in the above cases, at the risk of breaking some very obscure conversions between strings and arrays of char (but
not arrays of UCHAR). There would probably be some similar changes in the other direction too.
Any objections? Comments?
- Andrew
--
Complexity comes for free, simplicity you have to work for.
|