Open davidkeymer opened 6 years ago
Related to this task, although probably deserves its own ticket, is the replacement of the obsolete NI FieldPoint unit which monitors the detector's voltage and temperature. A cDAQ has been suggested and this will need to be ordered (well) before the migration of LOQ to IBEX.
@davidkeymer - are we likely to encounter noisy signals with this cDAQ? (like we did on MuonFE).
For the FieldPoint Unit, Steve has mentioned this to Jamie who will be in touch to talk about alternatives for it.
Am I correct in thinking that the Omega device in #3689 will be used to measure the detector temperature and voltage? If so, we needn't worry about ordering a replacement for the FieldPoint unit.
I have some limited physical documentation for the detector system should whoever picks up this ticket requires it.
You are indeed, and we don’t need to worry about a replacement
Assuming it can be made to work…
Suggestion from @FreddieAkeroyd on 03/09/2018:
"If it is 32bit windows XP then sysinternals portmon may may do the job"
The OS on the detector control machine needs to be upgraded (or machine replaced) by 30/09/2019 to comply with "end-of-site-support" for Windows 7. This would be a good opportunity.
It has been suggested that as an interim solution, the detector control machine be virtualised to prolong its life before the hardware expires. (We have experience of this with the two Astrium chopper control machines on LET). This may make it easier to analyse the protocol as a copy of the VM could be run offline. However, this doesn't preclude the requirement to upgrade/replace the machine by the end of September 2019.
It has been agreed that an image of the disk will be taken on the upcoming maintenance day (19/06/2019). A separate ticket will cover this aspect of the task: #4429.
Some initial investigation work was done on the detector control program after the VM was generated in #4429. With @Tom-Willemsen's help. the executable was searched for interesting strings and together with a decompiled version, these were used to try to determine the operation of the program. Unfortunately, not enough information was present to discover the communications protocol required to complete this ticket (although some other code believed to generate timestamps and log values was found). Therefore, the original idea of listening to/watching the commands go back and forth to the detector electronics should be tried next.
An update on the control of the Ordela detector side of things: LOQ is going to be withdrawn from the User Programme as a scheduled instrument later this Autumn. Until further notice it will continue in warm standby for commissioning, Xpress, training, or helping out the TS2 SANS instruments where applicable. This means it no longer makes sense to devote significant resources to porting the Ordela control to IBEX. In the last couple of weeks I have managed - it wasn't straightforward though - to get all the proprietary Ordela software, and the NI PCI-DAQ, running under 32-bit W10 on a clean build loan machine from FIT. I am now waiting for FIT to put a clean install of 32-bit W10 on the LOQ PC that we use for controlling the detector. Once everything is working on that machine we can close this issue.
This ticket may be more appropriate in the [https://github.com/ISISComputingGroup/ControlsWork](Controls list)
Currently the detector is controlled by proprietary piece of software running on an aging and obsolete PC. Although if this PC were to expire, the software could be installed on another (VM even), it is still a critical piece of equipment as it is the only way to turn the detector on and off.
This is not part of the IBEX/SECI control system, but an IOC could be written to communicate directly with the detector from the control machine, thereby removing the need for a separate PC.
No manuals are present describing the protocol, so it is envisaged that either a software (Wireshark equivalent, etc.) or hardware (available) analyser is required to deconstruct the commands and replies.