RE: PV for both input AND output

[Emmanuel Mayssat <emayssat@outlook.com>]

> You showed me an example about an asynchronous record, but what if I
> have a synchronous one?

async or sync is not relevant here.
What matters is that the output record is out of date (because the parameter was changed, but not through epics)
The update of that record is done with the input record which just fetched the correct parameter value from the hardware
The connection to that hardware can be sync or async since the processing/synchronization is done 100% in the EPICS database.

> Do I have the same 4 records used for 1 item?
Yes, a minimum of 4 records for (1 setpoint + 1 readback) which is one control parameter ( = 1 item?)
You can have more if the readback needs to be translated (i.e. not of the same type as the output record)

> When you say
> FileNumber is the output record that the user sees.
> what do you mean with "sees"?

The only one that appears in the GUI

> Why the "$(P)$(R)FileNumber_write", the "$(P)$(R)FileNumber_RBV" and the
> "$(P)$(R)FileNumber_Sync" are not seen by the user?

Exactly, the other ones are used for function-programming in the EPICS database
(That of course leads to proliferation of records which is not desirable, hence his suggestion of including this feature in asyn (i.e. c/c++ driver code))


> Will the fields specified in those records disable them from user view,
> and so if a user tries to query them with a client he will get an error?

No, but the user/operator is normally not playing with PVs.
He is only using the GUI to carry out his experiment.
Ultimately the user should care less about PV names, about PV naming convention, or even about what a PV is.

--
Emmanuel