New control tasks conversion tips and new features

ctrl_spec_converter script

A script has been created for CyFlex release 6.3.24 to simplify the process of going from the old control programs to the new control programs. The script uses entries in your ctrl_specs.xx file to populate an eng_ctrl_specs.xx file. See the example below:

[tc1@mynode1 specs]$ ctrl_spec_converter /specs/ctrl_specs.1
Your new eng_ctrl_specs file can be found in

After review and update, move the newly formatted file to the /specs directory, which is the default search path for eng_ctrl_specs application, or a /cell/sub_systems subdirectory if preferred.

Enter the following for full details on usage and compatibility of the script:

$ use ctrl_spec_converter

Usage of ctrl_spec_converter

Converting the Old Control Program to the New Control Program

Execute the following steps:

  1. Verify there are no errors with the existing control spec file. With CyFlex running, execute the following:
  2. Determine whether there are any errors generated related to the ctrl_task and remedy them.
  3. Run the ctrl_spec_converter application with the old ctrl_specs.xx file. For example:

    ctrl_spec_converter /specs/ctrl_specs.1

  4. Move the new file to its final directory. For example:

    $ mv /tmp/new_eng_ctrl_specs.1 /specs/eng_ctrl_specs.1

  5. Back up the old user control spec file:

    $ cp /specs/ctrl_specs.1_user /specs/ctrl_specs.1_user.old_ctrl_task

  6. Edit the user control spec file in one of the two ways mentioned below. The advantage of method (b) is that user loops can be grouped in more meaningful ways.
    1. Quickest way:

      Add the critical column to all the @USER_LOOP_CTRLER keywords.
      The old format follows:
      # label command interval open-loop
      # root output units ramp rate
      AirVolFlow % MED 2.0

      The new format has the critical entry:
      # label command interval open-loop
      # root output units ramp rate critical
      AirVolFlow % MED 2.0 N

    2. Best way:

      To maximize the benefit of the new control programs, break each of the control loops into a separate file for each loop or group the control loops by category (user_ctrl_specs.cell_ventilation for example).

      For each control loop, copy and paste the section from the @USER_LOOP_CTRLER keyword to the following $END into a new file. A good naming convention for individual loops is to name the file user_ctrl_specs.loop_name so it is easy to identify.

      NOTE: Automatic reading of plug and play (PNP) files is no longer supported. Each former PNP specification must be launched directly.

      When complete, add the critical column mentioned above in step 6.a and review the comments for each keyword to see if new capabilities can be used to advantage.

  7. Edit the go script
    1. Remove all instances of ctrl_task.
    2. Remove comp_ctrl.
    3. Remove ctrl_specs. Ensure this command is not running in multiple places in the go script.
    4. Substitute the following in place of running ctrl_specs:
      eng_ctrl_specs /specs/eng_ctrl_specs.xx
      # full path is not needed if file is located in specs directory

      user_ctrl_specs /specs/user_ctrl_specs.clnt_ot_t

      user_ctrl_specs /specs/user_ctrl_specs.FMS

      user_ctrl_specs /specs/user_ctrl_specs.exp_tnk_p

      NOTEIf all of the user control loops are in one file, you could replace all the user_ctrl_specs instances above with the individual line below

      user_ctrl_specs /specs/ctrl_specs.xx_user

New Features

  1. Bumpless Transfer:
    # —————————————————————————
    # Bumpless Transfer
    # The engine control task can operate in one of two ways when feed forward
    # control is made either active or inactive and when a controller is
    # switched from open to closed loop.
    # The first way (Y or YES) is called bumpless transfer. In that mode, the
    # output will NOT suddenly change when feed forward is turned on/off
    # or the control mode is changed. Instead, the integral term will be
    # adjusted by the feed forward term and the output will remain
    # constant (bumpless).
    # In the second way (N or NO), the output is instantly changed by the feed
    # forward term when a switch is made. This is how the old control
    # task (ctrl_task) has worked since some time in 2005 and has been found to
    # be necessary for transient emissions testing.
    # If this keyword is not used, then transfer will NOT be bumpless so that
    # behaviour of the new eng_ctrl_task is the same as the older ctrl_task
    # NOTE: Always use all 3 entries even if a second dyno is not being used
    # First Dyno Second Dyno Throttle
    # (if dual dyno)

  2. Change display precision of dyno and throttle control loop variables:

If a higher or lower precision is required for the dyno or throttle controller variables, they can be changed using the keywords below

# ---------------------------------------------------------------------------
# Specify some attributes of the created controller variables.
# <display_precision> <history_active> <history_tolerance>
# where:
# display - The number of decimal places to be displayed by
# precision the display task when the variable
# is displayed. Default is 1
# history - A flag indicating if the variable should be included
# active in the history log. Valid entries for this field
# are Y, YES, T or TRUE. All other entries are
# set to FALSE.
# NOTE: The history save flag is now obsolete since ALL variables are
# saved in history files. Entries should still be made
# until the eng_ctrl_specs program can be modified.
# history - The amount the variable must change for it to be
# tolerance written to the history log. Default is 5.0.
# A value of 0 will NOT be accepted.
# NOTE: There is a similar specification for each of the created variables.
# The only thing that is different is the suffix of the keyword. The
# additional keywords for created variable options are:
# ---------------------------------------------------------------------------

  1. Functional changes:
  • Using the old control program
    • Long keywords (TORQUE, SPEED) have delays of 50ms in them which can cause issues on very fast transients
    • The delays can be avoided by using the short keywords (TRQ, SPD).
      • There is an additional difference with the short keywords and that is the control mode (open/closed) is not changed the way that you think it might.
      • The long keywords set a target and put the appropriate controller in closed loop
      • The short keywords only set a target
    • Using the new control program
      • The delays have been removed with the long keywords so it is OK to use them for fast transients
      • The long keywords set both the target and open/closed mode
      • The short keywords only set the targets

For more details, visit the following links