RE: Bidirectional device support

[Ralph Lange <Ralph.Lange@bessy.de>]

>>>>> "Andrei" == Andrei Liyu <Liyu> writes:

  > [...]

  > At second, bi-direction data is not need usually. Operator in LOCAL
  > (rack place) and REMOTE (from computer) sets new value and than sees it.
  > This is two operations, two values ...

  > Andrei.

I do not agree.


Scenario 1 (quite usual during commissioning):
  Some part of the machine is not working correctly. The device
  specialist goes there, switches everything local, optimizes until
  things are running.
  -> Without some bidirectional functionality you are left to write down
  all setpoints locally and hack them back into the system manually
  (quite error-prone) else you will lose beam as soon as you touch
  something.

Scenario 2 (usually with large "intelligent" sub-systems such as PLCs):
  No strict hierarchy, i.e. the EPICS system is just one client of the
  system and not the only master.
  -> Without some bidirectional functionality your EPICS screens will
  most likely not show the current status of the system. Touching setpoint
  sliders will most likely produce unwanted output jumps.

Scenario 3 (usually with small "intelligent" sub-systems such as
embedded device controllers):
  To create a "bumpless" reboot behaviour, the EPICS IOC should be able
  to read back the setpoints from the device. The collected values
  should end up in the same records that are used to control the
  device. (Else you still get bumps when you touch a slider.)


I think these are three good reasons why bi-directional behaviour is a
desireable feature. (I'm sure there are more...)

Ralph