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  2013  2014  <20152016  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  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Question about device support
From: Florian Feldbauer <[email protected]>
To: Mark Rivers <[email protected]>, EPICS Tech Talk <[email protected]>
Date: Tue, 26 May 2015 12:52:26 +0200
Hey,

On 05/25/2015 05:20 PM, Mark Rivers wrote:
> Hi Florian,
> 
> I can think of one way to do it:
> 
> Use the normal asyn device support syntax:   @asyn(portName, addr, timeout)drvParams")
> 
> Implement all addressing with the addr field:  addr = crate*48*20 + module *48 +channel
> 
> Your driver then converts this compound address into the 3 individual fields.
> 
> Cons: 
> Non-intuitive address in database file.  If databases are edited manually this is not nice.  If they are generated from a script then it is probably OK.
> 
> Makes many parameter tables in asynPortDriver, i.e. maxCrates * 48 * 20.  If maxCrates is 10, then this is about 10,000 tables.  Might be too much memory on a very small embedded system.  They are directly indexed however, there is no searching to find the correct table, only searching to find the drvParams parameter within the table.
Unfortunately, there is another "Con": Some parameters are related to
the modules itself. E.g. "0.4.BoardTemperature" would be the temperature
of the fifth module in crate 0.
Having a setup with 4 modules, this parameter would exist ~200 times
(since I have ~200 tables) although it is only 4 times available from
the underlaying daemon
Also crate related parameters (like switch backplane on/off) exist.

iseg is planning to install the device support/IOC on their new crate
controllers which are bases on ARM-Cortex A8 (IIRC). So memory usage
could become a problem...

It is not possible to use a value for drvParam in the DB which was not
registered using
createParam(...);
inside the portDriver, right?

Florian

> 
> Mark
> +
>   
> ________________________________________
> From: Florian Feldbauer [[email protected]]
> Sent: Monday, May 25, 2015 8:51 AM
> To: Mark Rivers; EPICS Tech Talk
> Subject: Re: Question about device support
> 
> Hey Mark,
> 
> I'm using the asynPortDriver for all my device support implementations
> so far and I really like it!
> But I'm not sure if (and how) I could effectively use the asynPortDriver
> for the device support for iseg.
> 
> To access a certain value I need the address of the crate (multiple
> crates can be connected to the CAN bus), the address of the module (up
> to 20 modules per crate) and the address of the channel (up to 48
> channels per module).
> The parameters for the server look like this:
> "<crate-address>.<module-address>.<channel-address>.<paramtername>"
> E.g. if I want to read a the current voltage of channel 47 in module 4
> of crate 0, the parameter is called:
> "0.4.47.VoltageMeasure"
> 
> If I want to access a module or crate related parameter the unused
> address values are omitted in the command.
> 
> Do you have an idea how to implement this addressing scheme using only
> _one_ asynPortDriver?
> The hole device support should to be easy to configure...
> 
> Cheers,
> Florian
> 
> 
> On 05/15/2015 12:50 PM, Mark Rivers wrote:
>> Hi Florian,
>>
>> Both of the things you asked about are implemented in the standard asyn device support.  Updating output records on a callback from the driver was added in asyn R4-26:
>>
>> http://www.aps.anl.gov/epics/modules/soft/asyn/R4-26/RELEASE_NOTES.html
>>
>> Support for setting timestamps was added in asyn R4-22:
>>
>> http://www.aps.anl.gov/epics/modules/soft/asyn/R4-22/RELEASE_NOTES.html
>>
>> So you might consider writing an asyn port driver to talk to your OPC, rather than device support.  It may be simpler.
>>
>> Mark
>>
>> ________________________________________
>> From: [email protected] [[email protected]] on behalf of Florian Feldbauer [[email protected]]
>> Sent: Friday, May 15, 2015 1:51 AM
>> To: EPICS Tech Talk
>> Subject: Question about device support
>>
>> Hey all,
>>
>> I'm currently working together with the company iseg Spezialelektronik GmbH
>> to develop EPICS device support for their high voltage power supplies.
>>
>> Two questions came up so far:
>> 1) It is possible that some Control values change their values,
>>     e.g. if a trip occures the "channel is on" control word is set to off.
>>     Can the device support in such a case change the value of a bo record?
>>     Will the record be processed when changing its value from device
>> support?
>>     (I was thinking of some kind of callback here)
>>
>> 2) The device support will not directly communicate with the hardware,
>>     but with a daemon in between (iseg also wants to support OPC server
>> and others,
>>     so one common interface for all).
>>     This daemon gives me the value and timestamp of its last change.
>>     Is it possible to give this timestamp through the device support to
>> the record?
>>     From the record reference manual I guess not...
>>     What would be your suggestion to make the timestamp
>> available/visible to the operator/experts?
>>
>> Best regards,
>> Florian
>>
>>
>> --
>> ----------------------------------------
>> | Dr. Florian Feldbauer                |
>> |                                      |
>> | Helmholtz-Institut Mainz /           |
>> | Johannes Gutenberg-Universität Mainz |
>> | Johann-Joachim-Becher-Weg 36         |
>> | D-55128 Mainz                        |
>> |                                      |
>> | Office: SB1 / 00-213                 |
>> | Phone:  (+49)6131 / 39-29605         |
>> ----------------------------------------
>>
>>
> 
> 
> --
> ----------------------------------------
> | Dr. Florian Feldbauer                |
> |                                      |
> | Helmholtz-Institut Mainz /           |
> | Johannes Gutenberg-Universität Mainz |
> | Johann-Joachim-Becher-Weg 36         |
> | D-55128 Mainz                        |
> |                                      |
> | Office: SB1 / 00-321                 |
> | Phone:  (+49)6131 / 39-29605         |
> ----------------------------------------
> 


-- 
----------------------------------------
| Dr. Florian Feldbauer                |
|                                      |
| Helmholtz-Institut Mainz /           |
| Johannes Gutenberg-Universität Mainz |
| Johann-Joachim-Becher-Weg 36         |
| D-55128 Mainz                        |
|                                      |
| Office: SB1 / 00-321                 |
| Phone:  (+49)6131 / 39-29605         |
----------------------------------------

Replies:
RE: Question about device support Mark Rivers
Re: Question about device support Ralph Lange
References:
Question about device support Florian Feldbauer
RE: Question about device support Mark Rivers
Re: Question about device support Florian Feldbauer
RE: Question about device support Mark Rivers

Navigate by Date:
Prev: Re: about Galil controller in linux-64bit system LiuP
Next: RE: Question about device support Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Question about device support Mark Rivers
Next: RE: Question about device support Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·