RIKEN Front End: Test the changeover logic

[KathrynBaker]

As an IBEX developer or a member of the PLC team I want to make sure that the changeover logic and handshaking all work as expected.

Acceptance Criteria

1. All signals and behaviours are as expected when changing over the simulated/test system Port changeover
2. All signals and behaviours are as expected when changing over the simulated/test system RB2 changeover

Notes

1. This logic was written in RIKEN Front End: Changeover logic #2813
2. This may require alterations to the Schneider PLC IOC (see GEM: Vacuum Valve Status #2798) if appropriate commands are not available

requires #3266
requires #3267

[KathrynBaker]

There should be access, exact time TBC, early to access from the 16th of May 2018.

[KathrynBaker]

The test system has been set up and the list of registers is now available at http://www.facilities.rl.ac.uk/isis/computing/ICPdiscussions/RIKEN%20FE/RIKEN%20PLC%20Ibex%20Modbus%20Interface.docx

There is time in the coming weeks.

[KathrynBaker]

As the test system is now available, we should schedule this and get this testing done. This is likely to involve @KathrynBaker, @FreddieAkeroyd and @Tom-Willemsen. Ticket moved from awaiting to proposal to ensure that we prioritise and include it.

[kjwoodsISIS]

We need to:

1. estimate how much effort is required to perform the tests and any (small amount of) remedial work
2. agree a day (or days) on which we can perform the tests. This should not be difficult as the test system is available for use now.
3. block out the time in @KathrynBaker, @FreddieAkeroyd & @Tom-Willemsen calendars
4. Do the tests & make any small fixes. If a substantial amount of re-work is required, we may need to book another test session (via another ticket).

[KathrynBaker]

There is some concern related to some of the functionality that is in the PLC related to safety (this was only realised at a planning meeting recently). Whether these risks are acceptable or not are still being discussed.

If the risks are acceptable, then we can continue as planned above, the PLC interactions can be set up as per the memory map and the changeover logic uses those interactions.

If the risks are not acceptable, then the solution may depend on the number of free IO ports on the PLC. At which point, rather than the PLC needing to be set up it will be some DAQ (choice here - MOXA as is planned for the ZOOM motion safety which will need to be ordered, or NI hardware such as we have sat in the office and can then order replacements for them) and the changeover logic will talk to that.

If there are not enough ports on the PLC this may be a little harder to implement, and we can discuss that solution once we have a clearer idea of what the issues might be.

I am very aware that the instrument scientists are VERY keen to get the control via computing over the summer, as it will start to limit some of the user errors that occur.

[kjwoodsISIS]

@KathrynBaker : what are the risks? We should enumerate them all, along with the plans & decisions for managing each risk (i.e. mitigate, avoid or accept). When will the discussions end and decisions be made? Depending on what is decided we might need additional tickets to implement.

[KathrynBaker]

@kjwoodsISIS: The main risk is that we are opening up something which relates to safety to having values within it changed remotely (and with the way we usually run our systems, the other side of the world remotely). That is the risk that is of concern, and enumerating them is part of the meeting that the PM for the RIKEN upgrade is going to organise as soon as she can.
I expect the decisions to be made at that meeting unless there is a decision as to whether we use the MOXA or NI DAQ - which is a decision for us to make, once we know that the decision has been made to use DAQ rather than other solutions.

[ChrisM-S]

Yes, if the PLC has any implication for personnel safety it will (or should have) a risk assessment giving SIL or Pl rating. Unless there is a clear demonstration of separation so that our system cannot (even in error) affect a safety function, the need for the risk assessment or rating to be extended into our software is high. (e.g. can it write to the wrong register, what if it writes continuously and floods the register etc.).

Using fixed controls signals to the external IO ports does seem like a good way to do it. Note, we can potentially send a sequence of values to the port to save I/O lines or (even clearly discriminated analogue values if there are Analogue I/O lines available).

[KathrynBaker]

There was a meeting relating to this held, the outcome of which is that the computer will NOT talk directly to the PLC, instead there will be a hardware interface between the two. What solutions are available and which to choose can be discussed in the planned meeting to agree on what we would do when, and extra tickets will be raised as appropriate.

[KathrynBaker]

There is now a plan of action:

On the 3rd of July, we will test the computing side of things with the PLC in R6a.

Between now and then, the PLC will be rewritten to cope with the change to external DAQ and relays will be added so that the external DAQ can run in the 10V range, and the PLC in the 24V range.

The logic will fail into a safe mode so that 0V on a "please turn things off signal" will be the trigger to turn them off, such that a cut wire would lead to PSUs being off rather than on.

Between now and the 3rd of July two tickets will need to be undertaken

• RIKEN FE: NI DAQ setup for PLC interactions #3266 Set up NI DAQ with DIO for use with the logic - this will involve ensuring that the DAQmxBase IOC functions, is able to read 5 digital inputs and set 5 digital output
• RIKEN FE: Arduino setup for PLC interactions #3267 Write code/IOC etc. for an Arduino to act as an interface for this

When either of these tickets is completed we should be able to simulate the PLC interaction well enough with signals either from the other device or the other items available in the office to test the PLC logic with it, and will then be able to simply move the hardware to R6a and test with the PLC on the 3rd of July.

[Tom-Willemsen]

The latest version of the logic is documented here:

RIKEN PSU Controls - Issue C.zip

Anything in red/purple are things that have changed since the original changeover logic was written, so may need to be re-checked before 3rd July.

[Tom-Willemsen]

Has been tested with Tim Carter. All appears to be working (using DacMX). Nothing to review for this ticket so putting straight into review complete.