Experimental Physics and
Industrial Control System

"Liyu, Andrei" <[email protected]> · Tue, 13 Apr 2004 12:35:23 -0400

Ralph,

	Please, see from another point. Control system has set and get.
It can be implemented DAC<->ADC, OutputRegister<->InputRegister,
StepMotor<->Detector ... . From another side operator's dialog have
input and output areas. In output area operator sets new value and reads
feedback from detector in output area. Also I add button SET in input
area. When operator sets new value into dialog control he clicks SET
button and client program sends value one time. (Also operator has time
to estimate his actions.)

Then Scenario 1
Device specialist 
- switch REMOTE to Middle
- comes to rack
- sets Middle to LOCAL
- does his work
	*** during this time operators will see detector parameters in
dialog output area

- sets LOCAL to Middle
- comes to control room
- switch Middle to REMOTE
- go to drink 

Operator can continue to do its works. And they have old (wrong)
parameters in input area and new (right) parameters in output area ...

Then Scenario 2
Operator set new value in input area. Then client program (for example,
EDM) connects to server (IOC). Good server works with this parameter,
checks limit value, sets possible value and sends new value to client.
Client draws new value in output area. So operator sees what he likes
and what he has really.

Then Scenario 3
There are not small "intelligent" sub-systems. There is right software
structure server - detectors (subsystems) - subdetector parts - modules.
If server was rebooted there are possible variants
- at first, each detector, subdetector, module must have default value
- at second,
	- server can has file (DB) with current initial settings
	- server can save last settings before rebooting and then use
them

Thanks, Andrei.
P.s. All questions come from wrong structure. Cesar said "divide and
drive".

-----Original Message-----
From: Ralph Lange [mailto:[email protected]] 
Sent: Tuesday, April 13, 2004 6:08 AM
To: Liyu, Andrei
Cc: EPICS Tech-Talk
Subject: RE: Bidirectional device support

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System