Mapp Services 6 - What is the new parameter 'cyclic task class' about?

Introduction

  • with mapp Services 6, new parameter Cyclic task class was introduced
  • it a part of general configuration of mapp AlarmX, mapp Database, mapp Recipe, mapp Audit,…etc.
  • The aim of this topic is to describe the functionality of this property in more detail.ls

Source of information:

Description:

  • We have to differentiate between “component” and “FUB”

    • Component: Exists as soon as a mappServices configuration is present/transferred
      • Can work independent of FUBs
    • FUB: Exists only when created as a PV
      • Cannot work without an enabled component
      • Acts as an “interface” to the component
  • Timing Diagram (Component vs FUB) example, it may clear up some things

    • Note: The order of execution with one Task Class can (up to my knowledge) not be defined/predicted
  • The “Cyclic task class” in the configuration just defines how fast the component itself is operating its internal cyclic task (monitoring alarms, PackML states, …)

    • For example MpAlarmX (TC1; 10ms): The component will check for and process new alarms every time TC1 is supposed to run
  • The FUBs can run in any task class, as they are now independent of the component

    • For example MpAlarmXCore (TC2; 20ms): The FUB will update its outputs whenever it is called
      • But when calling it, no “real” work is done (it’s really just updating outputs)
    • This does mean that the FUB may “miss” some information from the component
      • Eg. MpAlarmXCore may jump directly from 1 “ActiveAlarms” to 10 (as a very extreme example) if not called often enough
      • The FUBs themselves will however not lose any information (it will in the worst case just be delayed until the FUB is called next time) as the information is stored internally with the component

Q&A:

Q1: How is configuration in general of a mapp Services component (task calls) behaving and how is it influence by according FUBs and the task classes which are used for the according programs?

  • The component (and FUBs) are completely separate systems now and the timing of FUB calls does not influence the component (if at all the FUB tells the component that it has to perform some work)
  • Components which have this configuration option were commonly performing cyclic tasks before (requiring the FUB to be called)
    • Now the only purpose of the FUB is to provide In-/Outputs for specific (usually non-cyclic) work (like exporting to a file)

Q2: What happens when I select task class cyclic #1 (10ms) in the configuration of e.g. MpAlarmX, but then I am using the FUB MpAlarmXCore in the task class cyclic #2 (20ms)?

  • Nothing… The component will just update its internal information faster than the FUB will display it (so some state changes may be missed/hidden from the FUB)
    • Note: UI-FBs (or other mechanisms showing “lists” or “retainable” information) will never “miss” information. They would just be delayed…

Q3: Are there any recommendations from our side from our side regarding that?

  • No, as the FUB and component are separate things (which are just communicating with each other), any combination should work.
    • The only suggestion I (personally) would give is to run the FB either in the same TC or slower (running it faster does not really bring any benefits, but will also not cause harm)

Q4: Is there anything we need to take care about regarding configuration of task classes in the mapp Configuration?

  • Not more than with mappServices V5 and the FUBs. The only thing you need to take care about is to not overload the system…
    • Running everything in TC1 will quite likely still result in cycle time violations…

Hope this topic helps! Feel free to explore more of what’s new in the AS6 ecosystem. I’d be happy if you shared your new findings with us here. Community for community! :slight_smile:

Jaroslav

5 Likes