Loading ...
Sorry, an error occurred while loading the content.

135-2004 Addendum i comments

Expand Messages
  • Steve Karg
    Hi BACnet Lighting Applications Group! I received some comments on 135-2004 Addendum i (Lighting Output object) from Christoph Zeller via email on September
    Message 1 of 4 , Dec 5, 2007
    • 0 Attachment
      Hi BACnet Lighting Applications Group!

      I received some comments on 135-2004 Addendum i (Lighting Output
      object) from Christoph Zeller via email on September 26, 2007. I am
      posting the comments here for your review and consideration as we edit
      PPR2.

      My opinion:
      1. Changing units of Blink_Time to hundredths for consistency is a
      good thing.
      2. Adding an informative diagram can be done (I will post a proposed
      diagram that I did).
      3. Adding a second example to "F.3.9 Encoding for Example E.3.9 -
      WriteProperty Service" for BACnetLightingCommand Datatype could be
      done (volunteers?).
      4. Using a dedicated priority (6) for Blink Warning was discussed at
      the meeting in Atlanta. I agree with Christoph that using a dedicated
      priority for this action (and using a similar mechanism as the Binary
      Output described in Clause 19) would simplify implementations greatly.
      (opinions?)

      Best Regards,

      Steve
      -----------------------
      Comments on the Lighting Output Object - Christoph Zeller

      Harmonizing Units:
      The unit of Blink_Time should be hundreth instead of tenths of seconds
      to be consistent with other time units (not introducing new units if
      not required to).

      Describing the behavior of lighting command:
      - When reading the addendum i to the Standard 135-2004 it is hard for
      me to understand the behavior. I tried to draw it in a diagram, which
      could probably be included to the addendum.

      [diagram omitted]

      I read it in a way that the lighting_command solemnly controls the
      progress value, which is reflected in the priority_array using the
      priority given by Lighting_Command_Priority.

      Additions wanted:
      It would be nice to have an encoding example of the newly introduced
      BACnetLightingCommand Datatype.

      Describing the blink behaviour:
      When trying to understand it, I have some troubles with the
      description of “is automatically relinquished” from priority.
      Assuming:
      The priority array reads {0.5,NULL,NULL,NULL,NULL,NULL,…} 0.5 in
      priority 16 (lowest).
      Blink_Priority_Threshhold is 5
      An OWS is writing 0 to priority 8
      Result:
      The Blink Warning is activated due to write of 0.0 to priority 8 which
      is below the threshold, During Blink_Time the output is physically
      deactivated (same priority (8)?). Afterwards the value is restored
      with the original value for Off_Delay and finally set to NULL
      (relinquished).
      The maximum priority falls back to 16 and thus the output will be
      activated with a value of 0.5.
      Is this the correct behaviour
      a)according to the wording of the addendum?
      b)what the intention was?

      New Ideas:
      In Binary Outputs, we use a dedicated priority (6) to control the
      behaviour. In this object we use internal priorities if we want to
      call it this way. Why can’t we use a dedicated priority for this
      behaviour too, probably controlled the Blink_Threshhold, this would
      probably simplify the implementation greatly, as only one blink
      warning can be active simultaneously. The behaviour of relinquish
      priorities lower than the Blink_Warning_Threshhold when (and only
      when) writing 0.0 could be very dangerous.
    • Steve Karg
      Hi BACnet Lighting Applications Group! One of the discussion items at our meeting in Atlanta revolved around the need for Minimum_On_Time or Minimum_Off_Time -
      Message 2 of 4 , Dec 7, 2007
      • 0 Attachment
        Hi BACnet Lighting Applications Group!

        One of the discussion items at our meeting in Atlanta revolved around
        the need for Minimum_On_Time or Minimum_Off_Time - it received a
        comment from the public review. The consensus was that the needs of
        HID were local to the fixture, and this minimum mechanism was really
        not needed in the Lighting Output object. We looked for a valid use
        case, but could not find one.

        I received a customer request that is probably a valid use case which
        substantiates the need for a minimum time:

        "[We have some] lights that are metal-halide. They have the re-strike
        issue once they are hot. Is there a way to prevent a re-strike on
        those [lights] for 10 minutes?" "[If you try] to turn them back on
        without allowing for sufficient cooling time ... the resulting power
        draw through the still hot metal halides trips the breakers. Then we
        need the custodian to unlock the closet and reset the breaker."

        If we add Minimum_On_Time or Minimum_Off_Time to the Lighting Output
        object in Addendum i PPR2, should the mechanism be as described in
        Clause 19, or should it be a local matter?

        Best Regards,

        Steve
        --
        http://steve.kargs.net/
      • Randy Shaull
        Steve, I have a question. Could not the On_Delay property handle the re-strike issue? ... From: BACnetLighting@yahoogroups.com
        Message 3 of 4 , Dec 7, 2007
        • 0 Attachment
          Message
          Steve, I have a  question. Could not the On_Delay property handle the re-strike issue?
           
          -----Original Message-----
          From: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com] On Behalf Of Steve Karg
          Sent: Friday, December 07, 2007 12:41 PM
          To: BACnetLighting@yahoogroups.com
          Subject: Re: [BACnetLighting] 135-2004 Addendum i comments

          Hi BACnet Lighting Applications Group!

          One of the discussion items at our meeting in Atlanta revolved around
          the need for Minimum_On_Time or Minimum_Off_ Time - it received a
          comment from the public review. The consensus was that the needs of
          HID were local to the fixture, and this minimum mechanism was really
          not needed in the Lighting Output object. We looked for a valid use
          case, but could not find one.

          I received a customer request that is probably a valid use case which
          substantiates the need for a minimum time:

          "[We have some] lights that are metal-halide. They have the re-strike
          issue once they are hot. Is there a way to prevent a re-strike on
          those [lights] for 10 minutes?" "[If you try] to turn them back on
          without allowing for sufficient cooling time ... the resulting power
          draw through the still hot metal halides trips the breakers. Then we
          need the custodian to unlock the closet and reset the breaker."

          If we add Minimum_On_Time or Minimum_Off_ Time to the Lighting Output
          object in Addendum i PPR2, should the mechanism be as described in
          Clause 19, or should it be a local matter?

          Best Regards,

          Steve
          --
          http://steve. kargs.net/

        • Steve Karg
          Hi Randy, ... I believe that the On_Delay would provide a delay *every* time that the lights are requested On, even if the lights were already cool. Best
          Message 4 of 4 , Dec 8, 2007
          • 0 Attachment
            Hi Randy,

            > Steve, I have a question. Could not the On_Delay property handle the
            > re-strike issue?

            I believe that the On_Delay would provide a delay *every* time that
            the lights are requested On, even if the lights were already cool.

            Best Regards,

            Steve
            --
            http://steve.kargs.net/
          Your message has been successfully submitted and would be delivered to recipients shortly.