Eiger2 500K exposure and acquisition time are reset to 1s on IOC restart

[tguruswamy]

I am testing with the Detector Pool Eiger2 Si 500k and it seems on every IOC restart, the autosaved values are displayed in the GUI, but the detector itself is reset to 1.0s for exposure/acquire time. They must be re-set before taking effect.

This is similar to #31 but is happening every IOC restart, no change to detector needed.

Eiger firmware release-2020.2.2
SDK 1.8.0
Driver 3.2.0
ADCore 3.12.1
StreamAPI selected; FileWriterAPI disabled

This detector setup seems to have other issues (#57) which may or may not be related

[antoninomiceli]

Also, if you change PhotonEnergy (which automatically adjusts the ThresholdEnergy to 0.5 PhotonEnergy) and the reboot the IOC, PhotonEnergy stays ok, but the ThresholdEnergy goes back to the old value. See photo.

but PV like # Images behavely normally.

[MarkRivers]

I understand why you are seeing this with both AcquireTime and ThresholdEnergy.

Note that AcquireTime and AcquirePeriod affect each other.

• The actual AcquirePeriod must always be at least slightly greater than the actual AcquireTime.
• If AcquireTime is set greater than AcquirePeriod then the actual value of AcquirePeriod (the RBV value) is increased to slightly larger than AcquireTime.
• If AcquirePeriod is set less than AcquireTime then the actual AcquireTime (the RBV value) is decreased to slightly less than AcquirePeriod.

So if AcquirePeriod is currently 1 and AcquireTime is set to 300 then the actual value of AcquirePeriod (and the RBV value) will be set to 300. But the output record will still be 1.0, and that is what is in autosave. AcquirePeriod_RBV is 300, but that is not what is saved with autosave. So when the system reboots AcquireTime is set to 300, but then AcquirePeriod is set to 1 (the value before reboot). That causes the actual value of AcquireTime (and the RBV value) to be set to 1.0. AcquireTime and AcquirePeriod both have PINI=YES. It is clear than during iocInit AcquirePeriod is processing after AcquireTime, but this is not something the user can control. There are 3 ways to overcome this problem:

1. The user always sets the AcquirePeriod manually to the correct value, and not relying on the value that is set automatically.
2. Add the following line to the end of st.cmd. This will force the AcquireTime record to process. That will give AcquireTime priority over AcquirePeriod.
   dbpf $(PREFIX)cam1:AcquireTime.PROC 1
3. Set the info tag of AcquireTime and AcquirePeriod to ASYN_READBACK. That will cause the callbacks that update the RBV record to also update the output record itself. Then the VAL will always match the RBV and autosave will work fine. That would need to be tested to make sure it does not have any bad side-effects. It could be done in the database that is specific to the Eiger so it does not affect other detectors.

The problem with the Threshold is similar. The problem is that whenever the PhotonEnergy is changed the actual Threshold (and the RBV value) is set to 50% of PhotonEnergy. But the output record is not updated to this value. In the screen shot above the PhotonEnergy was set to 7000 so the actual value of the Threshold (and the RBV value) were set to 3500. However, the output record for the Threshold was still 3000, and that is what is in autosave. It is clear during iocInit PhotonEnergy is processing before Threshold, so the value of 3000 for Threshold is being restored after PhotonEnergy is set. All 3 of the methods described above can be used to overcome this problem as well.

[MarkRivers]

The problem with AcquireTime being changed because the autosave value of AcquirePeriod is "wrong" is fixed via dbpf commands in the st.cmd files on the alignment_mode branch. This assumes the user wants to give priority to the AcquireTime. If priority should go to AcquirePeriod then comment out that line.

The issue with Threshold and PhotonEnergy is more difficult. @antoninomiceli in your screen shot above what is the "correct" value to restore for Threshold. the value 3000 that the user last explicitly set, or the value 3500 that was last set by selecting the PhotonEnergy? autosave cannot save the Threshold_RBV value so it does not know what was actually in use.

[MarkRivers]

I implemented option 3 above (asyn:READBACK info tag) for the ThresholdEnergy, AcquireTime, and AcquirePeriod records. This keeps the output records synced to the RBV records, so there is no longer any issue with autosave values.

[antoninomiceli]

I think you figured it out already, but to answer you question above.... the =correct value in the above screenshot should been 3500 for Threshold.

[MarkRivers]

This is fixed in 84dcd74 by adding the asyn:READBACK info tag to AcquireTime, AcquirePeriod, and ThresholdEnergy in the database. This keeps the output record synced with the readback when the driver changes these. This avoids problems with autosave.