JCOP FWWG Meeting, 20 March 2018
Present: Jonas (BE-ICS), Valeri F (NA62), Ivan A (TOTEM), Clara G (LHCb), Mateusz L (ALICE), Christoph (COMPASS), Luis G (LHCb), Gerladine T (BE-ICS), Fernando V (BE-ICS), Piotr G (BE-ICS), Joanis (CMS), George (CMS), Frank G (CMS)
News for WinCC OA and JCOP Fw:
- patch P010 for WinCC OA 3.15 released, no major features/bugfixes of particular interest
- bug in CtrlRDBAccess (likely since 3.14/3.15); data integrity problem when inserting "bulk" data; one problem resolved (ISO encoding, accented chars); another under investigation
- agreement that we do not release the P010 immediately but way for possible fix in CtrlRDBAccess
- A proposal for "amnesty" on Jira issues discussed at JCOP CB; no agreement to close old cases without reviewing it first; the issues will be reviewed and acted upon, with the aim of closing them if possible; initial set of issues under review already
CAEN component and OPC UA Server:
- discrepancies between OPC UA and DA namespaces; partially reviewed with the help of experiments; 80% cross-checked.
- Migration panel (from OPC-DA to OPC-UA) practically ready; pending on stabilization of OPC-UA Server namespace. The reason for the delay in delivery of the panel is because of the OPC-UA namespace instabilities.
- OPC-UA server for Linux is considered as stable and being used in production in ATLAS
- No urgency to prepare a Windows build. Timescales for CMS and ALICE are the beginning of LS2
- modification of DPType - would we loose archive? Not if we ADD an element to DPT, without removing the old one (ie. without leaving the gap); if one removes something from the middle of definition, this may be lost at the project export-import (ie. ATLAS way of upgrades)
- Is the ASCII backup a mandatory step? Should be optional as some people do regular ASCII exports anyway, and this will save time
- Mapping of multiple subscriptions to multiple OPC groups. Text in the radiobox is misleading; improve/clarify
- What is the procedure for rollback? A simple ASCII import
- Should we have access control in the operational panels? Convention was not to put it on the fw panels... to be reconsidered
- Important limitation: in CAEN Easy, if you add a board in the middle of a crate, you need to re-create all the DPs... Should be reviewed as a part of consolidation.
- Mapping of OPC groups to subscriptions was done for large systems in the past; for the event-driven readout, this is not relevant anymore. In ATLAS experience, this mapping is not needed for newer crates or newer firmwares. And it is much simpler to configure. Performance tests done by ATLAS
Which driver number should we use for CAEN OPC-UA? The panel should propose by default the same driver number as CURRENTLY USED by OPC-DA address. For this we give up on the use case to import only one crate to UA, and keep the other in DA as not really needed. The OPCUA client configuration panel should also be pre-filled with some standard information, such as localhost and port numbers
Having multiple clients connected to a single server seems to be faster that connecting to a single one (this seems to be for OPC-DA). In CMS they keep a few crates on the default driver num 6, and then move other crates to higher driver numbers for others. This seems to give better performance in CMS. Is it the same for OPC-U? In ATLAS' OPC-UA experience, this seems not to be the case, yet no systematic testing was done. To be tested.
Do we have a "keepalive" for monitoring the crates/boards with new OPC-UA? Yes, the CAEN internal keepalive and its timeout are exposed now to OPC-UA. How about a safe read-write "dummy register" for a complete roundtrip? Ideas to have monitoring of the crate but also individual boards (sometimes mainframe is OK, but a board is dead). Fan speeds are commonly used as of now by many people to check the aliveness.
Clarification: in the scope of the VENUS project a new tool was prepared to extract the information about the CAEN crate (layout of boards, firmwares) and dump it to a file; it would also dump the OPC items to give us information. This needs to be run per mainframe and could be run in parallel to OPC. ALICE is already using it. It is a C program -> candidate for a 5 min talk next FWWG.
- Next meeting to be scheduled in 4 weeks: XPra (Marc B. BE-ICS), SupervisorD logging (Giovanna Lehman, EP-DT); no meeting in 2 weeks as many people may be away.
There are minutes attached to this event.