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

Re: Antwort: Re: RE: [BACnetLighting] New file uploaded to BACnetLighting

Expand Messages
  • Paul Ericson
    All, For those that don t know me, I ve been involved with controls for some time and have monitored the BacNet working group with interest as I see more and
    Message 1 of 38 , Oct 30, 2009
    • 0 Attachment
      All,
      For those that don't know me, I've been involved with controls for some time and have monitored the BacNet working group with interest as I see more and more users asking me to have our lighting control system 'talk' to the Building Management System.  I think BacNet is the way to go.
      As such, Option 2, Delete the Blink Warn, should NOT be an option.  This is a critical feature of any ltg control system.
      Thanks,
      Paul

      Paul K. Ericson, PE
      VP-Lighting Design, Syska Hennessy Group
      San Diego, CA

      --- On Fri, 10/23/09, Christoph Zeller <christoph.zeller@...-bc.com> wrote:

      From: Christoph Zeller <christoph.zeller@...-bc.com>
      Subject: Antwort: Re: RE: [BACnetLighting] New file uploaded to BACnetLighting
      To: BACnetLighting@yahoogroups.com
      Date: Friday, October 23, 2009, 5:50 AM

       
      Hi Steve and all,
      as Steve mentioned here the plain text of my new file for those thtat are
      not able to read it.

      Critical Points in Lighting Output Objects

      1. Blink Behaviour
      1.1 Objective:
      Critical Points in Lighting Output Objects

      1.2 Background:
      In current objects of the BACnet standard 2008 we have 2 dependencies from
      the present-value in Output Object Types.
      Both, the level of physical output and the trigger for COV reporting are
      directly attached to the present-value. This means that every change in
      the present value is immediately transferred to the physical output.

      1.3 Problem Description:
      In the lighting Output Object, there is a strong wish to add blink-warning
      functionality which indicates the fact that the output is going to go off
      in near future.
      To accomplish this, the blink generator is hooked to priority 6 of the
      priority array.
      During a defined time, the lamps are going on and off repeatedly (how
      often depends on the implementation) . Doing this we get the connection to
      the hardware for free.
      Unfortunately this has an implication on COV-reporting.
      Because the COV-Reporting is directly coupled we see plenty of messages of
      the type I'm on, I'm off, I'm on … . This potentially generates a lot of
      network traffic. Additionaly it fills the Trend-Log Buffer if one is
      attached.


      1.4 Solutions:
      Option1 (Do nothing):
      - Live with the limitation that COV reporting and BLINK Warning
      cannot be used simultaneously
      Option 2 (Remove Blink warning feature)
      - Feature not available
      - (Unfortunately this was one of the major goals for the "Inventor")
      Option 3 (Remove COV capability from Lighting Output Object)
      - This option does not really work because there is an additional
      COVP service which causes the same problems (I guess it's not wanted to
      disallow devices supporting Blind-Outputs to use COVP services!)
      Option 4 (Move the blink warning behind the priority array):
      - Blinking is no more visible in the present-value property
      - Problem with COV-reporting is solved
      - How to detect weather blink warning is executed?
      - Output is no more directly coupled to present-value.


      2. Further Comments on Addendum
      2.1 Rename misleading properties
      I suggest to rename the properties Fade_Time and Ramp_Rate to
      Default_Fade_ Time and Default_Ramp_ Rate respectively to emphasize in the
      name, that those properties are used when no Ramp_Rate or Fade_Time is
      sent with the corresponding Lighting_Command_ Request.

      2.2 Clarify the behaviour of Lighting Command
      In the case of a lighting command is currently executed, it is not clear
      what to send if a read-property request is received for the priority
      array.
      If the intention is, that the entry in the priority array reads the target
      level immediately, then please say so. It might be the current level
      calculated by the dimm state-machine as well.
      What shall be the level read when reading pv?
      When to trigger the COV notifications?
      When the PV reaches a certain difference or should it be based on the
      Progress_Value?

      2.3 Controlling a Light_Dimmer using a Wall Switch
      If a wall-switch is used a source of ramp commands, the conditions for
      turning it on might not be as clear as expected.
      If the current level is OFF, then we have to define with which level we
      want to start.
      From the current addenda, I assume that this is a local matter (do all
      agree?)
      It might be better to add a property DEFAULT_ON_VALUE to the standard
      which would define the level at which ramping starts when coming from off.
      We then might add the special value 0.0 to indicate start with the level
      the lamp was previously turned off (This is the behaviour of old-fashioned
      analog dimmers).




      Christoph Zeller
      Abt. NT
      Fr. Sauter AG
      Im Surinam 55, CH-4016 Basel
      Telefon +41 (0)61 695 55 55
      Telefax +41 (0)61 695 56 19
      http://www.sauter- controls. com

      DISCLAIMER:
      This communication, and the information it contains is for the sole use of
      the intended recipient. It is confidential, may be legally privileged and
      protected by law. Unauthorized use, copying or disclosure of any part
      thereof may be unlawful. If you have received this communication in error,
      please destroy all copies and kindly notify the sender.

      Before printing out this e-mail or its attachments, please consider
      whether
      it is really necessary to do so.
      Using less paper helps the environment.



    • Isler, Bernhard
      Christoph, Can you elaborate a bit on the intent of this proposal, and what the simplification is against what is in addendum 135-2010i? Thanks, Bernhard
      Message 38 of 38 , Oct 19, 2011
      • 0 Attachment
        Christoph,

        Can you elaborate a bit on the intent of this proposal, and what the simplification is against what is in addendum 135-2010i?

        Thanks,
        Bernhard


        Bernhard Isler
        Siemens Switzerland Ltd
        Building Technologies Division


        -----Original Message-----
        From: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com]
        Sent: Wednesday, October 19, 2011 5:30 PM
        To: BACnetLighting@yahoogroups.com
        Subject: [BACnetLighting] New file uploaded to BACnetLighting


        Hello,

        This email message is a notification to let you know that
        a file has been uploaded to the Files area of the BACnetLighting
        group.

        File : /cz_011-001.doc
        Uploaded by : zeller_chr <christoph.zeller@...-bc.com>
        Description : Simplified Lighting Output

        You can access this file at the URL:
        http://groups.yahoo.com/group/BACnetLighting/files/cz_011-001.doc

        To learn more about file sharing for your group, please visit:
        http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.html
        Regards,

        zeller_chr <christoph.zeller@...-bc.com>






        ------------------------------------

        ======================================================
        To view the message archive, set user options, or view
        files in our archive, visit the following web page:

        http://www.yahoogroups.com/group/BACnetLighting/

        To subscribe to this group, send an email to:

        BACnetLighting-subscribe@yahoogroups.comYahoo! Groups Links
      Your message has been successfully submitted and would be delivered to recipients shortly.