81Re: [BACnetLighting] Meeting in Germantown, Maryland
- May 16, 2005Hi 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
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
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.
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
- << Previous post in topic Next post in topic >>