search

epics-modules / optics

APS BCDA synApps module: optics
http://epics-modules.github.io/optics/
Other
1 stars 3 forks source link

Problem with filterDrive.st #15

Open MarkRivers opened 2 months ago

MarkRivers commented 2 months ago

There is a problem in filterDrive.st. In the lower right of the filter_4_4_more.adl screen there are buttons to manually move filters 1-4 In and Out. These buttons control the FiN:Set records. However, changing these records has no effect if the SNL program is running, because this line change the :Set record back to OutSet, which is the current value of the actual hardware output. https://github.com/epics-modules/optics/blob/2cc9ff87bc5204811618aa9c96f049110ae2ce49/opticsApp/src/filterDrive.st#L474

It does work to directly change the hardware output in other screens: Set then changes, and it recalculates the actual transmission. It seems to me that either the SNL logic or the medm screen are wrong, because it gives the appearance of being able to directly control the filters, but it does not work.

The :Set buttons do work OK if the SNL program is not running.

prjemian commented 2 months ago

@AnaSousa314 Can you describe your fix here in words? Your post and URL look more like phish than fix.

MarkRivers commented 2 months ago

I believe I understand this problem. The :Set record forward links to OutSet, which writes to the hardware output record. Meanwhile, when ":Set is written the SetBusy record is processed, which causes the SNL program to enter the update_filters state. That state sets the :Set record to the OutGet value.

There is a race condition. If the hardware bo record driver is synchronous, then when OutSet writes to the hardware bo record it will change immediately. That was the case with the VME Unidig support. However, if the bo record driver is asynchronous, then OutSet will have just triggered a queueRequest to process the hardware bo record. The actual hardware I/O happens in the asynDriver callback thread. This is the case with the Measurement Computing USB driver we are now using. Thus, when the SNL program reads the current hardware value it may not yet have been set to the value that the :Set record wrote to it.

I believe the solution may be to set an event flag on the :Set record, and first test to see if that has been written to directly. If it has then just process it.