Closed AdrianPotter closed 7 years ago
Could we “force” this using SNL?
I think a sequence record in the IOC might be sufficient for this.
We should also modify the emulator to do this, I don't think lewis has this functionality built we could probably just store the times commands are received and check that they are not too close to each other.
This was because the driver was sending the high and low words of the delay setpoint in the wrong order. This has now been hotfixed on Merlin and merged into master (https://github.com/ISISComputingGroup/EPICS-ioc/commit/97053994ce78dd635af14a3f7f1fec82ed60a2d4)
Adrian quickly reviewed the change as I was making/merging it, I've added details of this hotfix to the instrument page on the wiki and documented the fermi chopper's strange behaviour on the Merlin instrument page.
For reference, I believe the LabVIEW driver sends the low byte first, the high byte second. In addition, LabVIEW driver also sends the commands with a delay of 250ms between each command. These commands are also time delayed from all the other commands by 250ms (i.e. commands not related to the phase delay). Subsequently, this means a time delay between all set point values e.g. speed and gate width, which is the case with the LabVIEW driver.
As a Merlin instrument scientist, I would like the Fermi Chopper to move to the correct phase delay when I set it so that I can use the Fermi Chopper effectively from IBEX.
This was observed on MERLIN at the start of the September cycle. On inspection, the Fermi Chopper was not honouring the high word for the phase delay sent by the IOC. In the manual, it states that messages cannot be received within 20ms of each other. We have no way to enforce this within the IOC. However, we can reduce the risk. At the moment, the low word and high word for the phase delay are sent simultaneously when they are calculated after a setpoint is requested so will by design be sent very close together. We have hot fixed Merlin by arbitrarily delaying the high word by 100ms. A better solution would be to sequence those particular commands at the IOC level. Either way, a fix should be applied to our main repo