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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: waveform changes using subArray |
From: | Hinko Kocevar <[email protected]> |
To: | Rod Nussbaumer <[email protected]> |
Cc: | [email protected] |
Date: | Mon, 17 Sep 2012 19:56:48 +0200 |
Hi Rod, On 09/17/2012 06:28 PM, Rod Nussbaumer wrote:
I have used waveform records with device support to acquire data from hardware, and then post-process the waveform data using a subroutine record. The waveform .VAL is linked to an INPut link on the subroutine record, and the waveform FLNK processes the subroutine record. The subroutine record uses it's init function (specified in field 'INAM') to locate the waveform record using dbGetPdbAddrFromLink(). I also connect other waveform records that get written to as part of the subroutine processing code ('SNAM'). This seems to work well for things like stripping SCPI headers and converting odd numeric formats to EPICS-friendly data types.
Yet another great solution.. it seems possibilities are endless, thats good.At the start of development we've focused on the C part of the EPICS under the impression that this way we would have more control over how the data is processed and delivered. I must admit that DB part far neglected to some extent thus losing the ability to design powerful solutions using DB (and C). What we are trying to do is expose as EPICS PVs a very large set of parameters and data sources. The software that EPICS IOC will talk to (locally on a Linux host) and obtain data provides all parameter meta data. Things like name, type, size, ..
It is quite easy to get an EPICS record template and substitution files automatically generated from this meta data. Things get funky when trying to generate DB logic (not just 1:1 records). Also there is a natural expectation that IOC would be able to be used on several instruments in the family. That why automatism with certain extent of user intervention like custom configuration is an integral part of development.
Map data types like handling 64-bit (unsigned) integer or array of enumerated values to base EPICS record types becomes a challenge.
Another major development drive was performance. Every data copying saved is highly valued.
That being said and what we learned during the course of development I would say that more emphasis needs to put on DB part.
Thanks, Hinko