CTRL++ Workshop

Europe/Zurich
864/2-B14 - SALLE J.B.ADAMS (CERN)

864/2-B14 - SALLE J.B.ADAMS

CERN

40
Show room on map
Description

A workshop to discuss the current experience with WinCC OA CTRL++, discuss the most important mechanisms that needs to be improved/added to make it an effective tool, and prioritize the request to feed them back to ETM.

 

Room booking: https://indico.cern.ch/rooms/booking/CERN/401345/

Compilation of questions/answers raised during the meeting:

Based on minutes taken by Jonas Arroyo

  • Remus:
    • Issue with enums not working in GEDI; since 3.15, they have to edit the panels manually (.pnl format);
      ACTION: should be reported by the REMUS team to icecontrols.support after having verified with most recent patches (many improvements to GEDI/CTRL++ integration were made).
    • Q: overloading member functions versus polymorphism
      A: CTRL++ is lenient concerning parameter lists, so a clean overloading like in C++ does not exist: there is only one member function implemented. Polymorphism is managed by using clean scope :: notification if ambiguities exist.
  • Atlas (Piotr Nikiel):
    • Presented concepts are per manager context? Yes, there is no special particular construct in CTRL++ that work across managers
  • Ivan from CMS tracker:
    • From which version all of this is present? WinCC OA 3.15 and 3.16 with latest patches are recommended; they might vary in a few features more being available in 3.16 (e.g. sysConnect or dpConnect with callback to an object)
  • Clara (LHCb):
    • Is there any relation between polymorphism and having optional parameters for the functions?
      Not really. Also discussed parameter overloading at this moment, and there is only on name of the function that is recognized - you can't have many functions with different numbers/types of arguments in the C++ style using CTRL/CTRL++. Still, "tricks" are possible using Control Extensions, whereby processing the list of parameters is fully customizable and this kind of tricks are possible.
  • Ivan from CMS tracker:
    • Would be possible to create a DP of a given class?
      CTRL language in using classes with no connection to DPs. Model a DPT into a class.
      Discussion was raised on having a functionality in the framework to have a CTRL++ class "wrap" a datapoint, and have all the interactions, updates/caching, callbacks, etc through a clean CTRL++ interface. Present users from CMS were very much interested in such development. Piotr acknowledged that the same idea (also presented in one of the examples in the slides) was developed in BE-ICS as a proof-of-concept for the consolidation and redesign. 
      It was suggested that CMS users raise the priority for such feature with their controls coordinator, and hence it could be accepted into the JCOP Program of Work for 2019. It was also stated that they would be keen to contribute to development.
  • Fernando:
    • What are the consequences of not deallocating a shared_ptr?
      It is kept in the scope of the function, and object is deallocated when the last reference to it is lost.
      Action: Piotr to speak to Martin to expose a function to show how many references are attached to a shared_ptr, or maybe to be able to monitor/count them somehow. This would be particularly useful for the "Factory" pattern with the list of object to finalize/"destruct" them after the last use.
  • Is there a way to design a class which has non-copy able object instances to avoid copying objects when in fact object references are needed as copy. This is CTRL++ syntax
    Maybe we could use a private constructor... ? Need to use assignPtr()
  • Piotr:
    • assignPtr vs the asignment operator (=) may be quite misleading. Still it was a compromise between having auto-dereferencing everywhere, or a large change to have like a "*" operator in C... It is therefore neither a bug nor a feature, but rather a "price to pay" for having shared_ptr
    • in addition the behaviour of the  "=" operator when used on shared_ptr objects differs depending on whether the LHS of it is already initialized or not (if it is null, then effectively assignPtr is done; otherwise it is dereferencing that takes place and object-assignment happens)
    • discussed that this is very unclear and very likely leading to errors. We should consider that the "=" operator on shared_ptr should issue a warning when used on already-initialized (non-nullptr) LHS; are there actual uses when one would like to have object-assigments in this case? (comment-PG: should we have a syntax with explicit brackets, like in C++, "(obj2=obj1);" or should we have execution-time warning? Action: to follow up for the CTRL++ workshop
    • Michael:
      • It there a way to do the class XXX not readable? No... Maybe a private constructor??? But then what is the class supposed to do?
  • P. Nikiel (Atlas)
    • Memory consumption in Bytes described in the slides: are these the pointer or pointer + allocated? Both; but treat these number very preliminarily.
    • Does CTRL++ support lambda expressions? Not unfortunately... (PG comment: no strong request was expressed to have them)
  • Clara:
    • in the example with zoo, how is it that objects are stored in a dyn_mixed list, and still recognize which method is called?
      There is no strict checking done there; whenever list[i].fun() is being acted on (it would be of type mixed), it is checked whether it is a class (or struct) and if so if there is a corresponding method to be called, hence no strict type checking at all. This allows for a lot of flexibility (storing apples, oranges and dogs on the same list) yet may be also very error prone. That is why we would very much like to have typed dyn_shared_ptr<T>, with type checking in all operations.
    • During discussion it was raised that one may not initialize a dyn_X structure "in place", because there is no literals for dyn- types. This is a serious limitation which we see elsewhere; Action: request as a feature
  • Remus
    • chaining of calls which returning objects does not seem to work (at least with 3.15P008 or P010) (e.g. a factory!). Action: To be checked/reported to ETM and must absolutely be fixed.
  • Michael: are there Regexp in CTRL++? There are pattern-matching functions in CTRL that work on strings
  • Fernando: typo in the name of one of CtrlOOUtils functions
  • Clara: why the functions of CtrlOOUtils have "ax" prefix? To be discussed offline - it is just a prototype anyway; available as a ctrl extensions for WinCC OA 3.16; we hope to convince ETM to implement some of these nativly. In general, a lot of functionality is available through the C++ API (and hence exploitable through control extensions).
  • Raul (CMS ECAL): comment on the factory pattern containing a static list of all instances and serving always the already-existing instance: 
    it is useful to store a shared_ptr to itself inside the object (ACK'ed by REMUS), and then one could construct objects while checking the existence in the constructor. Indeed, another possible solution.
  • Clara comments on the discussion of proposed work-around for namespaces and dynamic resolution of function at runtime: the pattern is indeed powerful but may be a nightmare to debug! Should not be used in general and advertised to users as a general-use recommendation!
  • JC: did ETM consider namespaces at all? Does not seem to be the case - other users apparently did not request this feature, from our point of view.

--- COFFEE BREAK ---

  • it would be useful to be able to declare operator-methods on objects (think of +, [] or () ). Compactize the notation
  • the notation with shared_ptr<MyClass> obj... is quite verbose. How about having an option to make it more compact (such as * operator in C...)
  • JC: a typed dyn_sharedptr<T> class would clarify the meaning of functions/methods interfaces, as it would be obvious what type of objects are returned/accepted, and the burden of checking for item types could be greately simplified!
  • MarcB: basic events and signal/slot functionality, such as those existing already in UI manager would be very useful; how about generalization of what is already in the UI manager? Action: report to ETM
  • Destructors seem to be one of the most favoured features, for symmetry and RAI pattern. The most typical case: dpConnect in constructor, dpDisconnect in destructor. Destructors would also be useful as a pattern for nice CTRL++ interfaces into complex Ctrl extensions that would use RAI.
  • It is very misleading to have a distinction between "share'able" objects created with the "new" operator, and non-shareable ones. Technical reasons behind them is not understood. It should be possible to get a shared_ptr to an object/variable that was not originally wrapped into a shared_ptr (ie. convert non-shareable to a shareable)
  • Another useful concept: weak pointers (shared_ptr that would not be auto-deallocated). Would be useful for the cases where circular references or caches are used.
  • Another missing and potentially useful feature: pure abstract classes (or "interfaces"). Not sure how much they would be useful in a single-inheritance model. Still, not being able to "forward-declare" a class, is one of the reasons.
  • Is it possible to explicitely call a constructor of a base class? Should be working now, yet still, a default constructor is called first: how about a "initializer list" style of C++ constructor?
  • GEDI: Add "save anyway" option in GEDI. At the moment CTRL++ integration to GEDI is not ideal, and certain valid scripts are rejected (and need to be manually edited in CTRL libs eg). There should be an option for "Save anyway" for this reason! Action: Report to ETM (REMUS)

 

Final discussion:

 

The participants expressed their priorities on top one or two CTRL++ features they would like to have implemented. The most favoured ones were:

 - dyn_sharedptr<T> collections with proper typing

 - destructors

 - overloading of functions' parameters (and hence usable constructors)

 - namespaces

 - signal/slot mechanism

In addition, it was assumed that the lack of "chaining" obj.f().g().h() is a bug rather than a new feature and should absolutely be addressed. Similarly, having the dpConnect() working from a constructor, and the RTTI functions of CtrlOOUtils being possibly taken over by ETM. A generic CTRL++ "proxy objects" for JCOP Devices' datapoints would be of common interest as well.

 

There are minutes attached to this event. Show them.
The agenda of this meeting is empty