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

81Re: [BACnetLighting] Meeting in Germantown, Maryland

Expand Messages
  • Steve Karg
    May 16, 2005
    • 0 Attachment
      Hi Lighting Applications Working Group!

      Here are the draft minutes of our meeting in Germantown, Maryland.
      Please post any corrections to this list:



      Meeting Minutes (DRAFT)
      28 April 2005
      Germantown, Maryland

      Participants - Affiliation
      Steve Karg - Lithonia Lighting
      Craig Spangler - Square D
      Robert Hick - Leviton Lighting
      Jack Neyer - Polarsoft
      David Fisher - Polarsoft
      Bill Jennings - NAVFAC MIDLANT
      Ernie Bryant - NAVFAC MIDLANT
      Don Gottschalk - Johnson Controls
      Pete Baselici - The WattStopper
      Bob Johnson - Siemens Bldg. Tech.
      Steve Treado - NIST

      The meeting was called to order at 1pm.

      A timekeeper (Pete Baselici) and a scribe (Robert Hicks) were assigned.
      Don Gottschalk was volunteered to track the non-agenda items.

      Review of minutes - approved

      Meeting agenda approved

      Liason Reports
      Robert Hick reported no NEMA DALI activity since last meeting:

      LA-WG proposal discussion:

      DMF028-02 Famous Times
      David Fisher reported that problems have been discovered with DMF028-02
      and requested that we withdraw and table this proposal until we enlist
      help from other working groups, such as the OS group. All agreed.

      DMF030-3 WriteGroup Service
      David Fisher presented this revision to his original proposal as a
      partial solution to the requirement in lighting systems to change a
      large number of values quickly.

      Primary change was the addition of an acknowledgement mechanism and
      supporting services. Whereas, if the sender required an acknowledgement
      from the group members, the sender would include a REPLY REQUESTED ID.
      The group members would be required to reply through a WriteGroupAck

      It was noted that control mode is similar to activating "presets" in a
      lighting control system and that a device may have membership in
      multiple groups. The broadcast may be sent locally, to a remote BACnet
      network number, or using the global BACnet network address.

      There was a question about returning error codes. It was decided that
      error codes may be difficult to define and may be unnecessary.

      There was discussion about why the current Command Object could not be
      modified to accomplish the same. The conclusion was that the Command
      Object was unsuitable.

      There was also a question concerning how long to wait for replies. The
      decision was to leave it unspecified and a local matter.

      Motion to move DMF030-3 to SSPC committee, as is, was seconded and
      passed with no opposed and one abstaining.

      Speed of Lighting Control on the Wire.

      Furthering the discussion from last meeting.

      There is still a need in the lighting community for a service that would
      allow many individual values to be set to individual levels in one
      packet, similar to DMX512.
      David Fisher presented his notes on a concept for a GroupWriteMultiple
      service. David’s concept involved "slots" that may be configured in
      each dimmer or switching device.

      Three possible methods were described:
      Method 1 - Typical BACnet tagged approach.
      Method 2 - Use only one datatype, map is local matter.
      Method 3 - Octet string, canonically encoded.

      The third method was most efficient, but was furthest from BACnet norms.
      It was noted that MSTP networks would limit the packet size to 480
      bytes, so efficiency was very important. It was suggested that the
      service needs to address at least 100 values in a packet.

      It was also suggested that a separate priority need not be sent with
      each value, and that 8 bit data may be sufficient for lighting control
      but may not be sufficient for other uses.

      Steve Karg and Robert Hick presented an example of a typical case for
      the use of this service where a ballroom may be serviced by partial
      number of outputs from several dimmer cabinets. The "slot" concept was
      questioned and a more global "channel" assignment similar to DMX was
      discussed. Whereas, each output of dimmer or switching devices would be
      configured locally with an identifier, commonly referred to as a
      "channel number" in the lighting community. The identifier may be
      unique, or several outputs may have the same identifier if the outputs
      were designed to always operate in tandem. The GroupWriteMultiple
      service would utilize Method 3 and encode the Values as "GroupChannel,
      Value, GroupChannel, Value, etc".

      Further discussion resolved that both the GroupChannel and GroupValue
      should be an unsigned 16bit. It was also decided that a single priority
      should be included as an overall priority for the packet. Relinquish
      would be handled as a specially encoded value such as 0xFFFF indicating null

      David agreed to cast the new WriteGroupMultiple service and present a
      proposal to be discussed at the next meeting. David requested email
      discussion prior to the meeting.

      Other needs of lighting community.

      Steve asked what were the other needs for the lighting community. A
      method for "Room Combining" was suggested. It was noted that the
      mechanics of this may be kept a local matter, although there may be a
      way of supervising using current BACnet objects and services. This may
      be discussed in future meetings.

      Future Meeting.

      It was decided that the next meeting would be held in Denver, possible
      on Sunday, June 26th , 2005. Steve will confirm the date and time
      through email.
    • Show all 12 messages in this topic