Experimental Physics and
Industrial Control System

Florian Feldbauer <[email protected]> · Fri, 26 Jun 2015 15:46:13 +0200

Hey all,

so far I have my device support working, and
changing output-records, when the value on the
hardware was changed, works also.

Only one last problem:
Switching the device on/off is done via a bo record.
If the state of this switch was changed outside of EPICS,
the device support changes the RVAL field of the bo record to 0 (or 1
respectively),
but VAL ( "Off" | "On" ) does not change.

Device support routine returns with 0 after changing RVAL.
How can I get the device support/record to update also the VAL field?

Cheers,
Florian

On 05/26/2015 03:52 PM, Florian Feldbauer wrote:
> Hey Ralph,
>
> yes, I experienced such a problem for my current device support
> for our iseg HV modules.
> There I'm also using the asynPortDriver (one driver per module).
> For "small scale" systems (about one crate) it works,
> but with larger setups we also have problems with the port-locking...
>
> For the new device support I'm currently working on, this is no issue,
> since now I don't have any hardware i/o at all.
> iseg is providing their so called Hardware Abstraction Layer which works
> as a daemon collecting and caching all the parameters of the
> connected HV modules.
> The device support just communicates with the daemon to get the cached
> values or queue new values to be send by the daemon, respectively.
>
> But looking at your first reply to this topic, programming a thread
> checking if any set-values have changed and updating the corresponding
> output-records seems not too hard. So maybe I will try to write
> the device support myself and keep the asynPortDriver as backup solution.
>
>
> Cheers
> Florian
>
> On 05/26/2015 02:46 PM, Ralph Lange wrote:
>> Hi Florian,
>>
>> Yet another thing to keep in mind is the level at which you want locking
>> of things to happen.
>> Usually (in the blocking case), a port driver locks its port, does the
>> IO, then unlocks its port.
>>
>> Some years ago at BESSY we were thinking how our CAN-Bus driver would
>> fit the ASYN model. CANopen compliant, i.e. many nodes per bus (~30),
>> many variables per node (~15), and some types of indexed variables with
>> many values per variable (~120).
>> The only thing that we wanted to be locked (between request and reply)
>> was the variable, to avoid sending commands on two different indexes of
>> the same variable without waiting for an answer.
>> Something like that does not fit the ASYN model well. For each fully
>> populated bus segment you would basically end up with ~450 instances of
>> a blocking "variable" port driver, all talking to the same non-blocking
>> lower level "bus" port driver. Starting 450 threads per bus made this
>> look very unattractive.
>> In the end we kept our patchwork non-ASYN driver, as (for this and other
>> reasons) the rewriting effort was not justified well enough.
>>
>> ~Ralph
>

-- 
----------------------------------------
| 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         |
----------------------------------------

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System