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

108Re: Feedback DMF-011

Expand Messages
  • jbroeker2712
    Sep 13, 2006
      Hi Steve,

      please find my comments below ...

      --- In BACnetLighting@yahoogroups.com, Steve Karg <steve@...> wrote:
      > Thank you for your insightful comments and discussion.
      >
      > I would like to summarize where we are regarding potential changes to
      > DMF-011-9, and see if you agree.
      >
      > 1. change Fade_Time from Unsigned to REAL.

      OK with me.

      > 2. add Power_On_Value
      >
      > From DALI:
      >
      > The interface signals shall be received properly 0.5 sec after
      > 'Power-On'. Earliest after another 0.1 sec the ballast shall go to the
      > 'POWER-ON LEVEL' via preheat- (if applicable) and ignition phase. The
      > ballast shall not go in the reset status. During the 0.1 sec interval
      > the ballast shall react on a possible command if this 'POWER-ON LEVEL'
      > is not desired.
      >
      > proposed BACnet:
      >
      > [add to Table 12-X Properties of the Lighting Output Object]
      > Power_On_Value REAL O
      >
      > [add to 12.X, Lighting Output Object Type]
      > 12.X.30 Power_On_Value
      >
      > This optional property, of type REAL, shall specify the level that
      > output shall go to after power is applied and before going to the
      > Present_Value.

      Shouldn't it be: "... and before a new Present_Value is set"?

      I would add:

      "If the lighting output is a DALI ballast this value corresponds to
      the DALI register 'POWER-ON LEVEL' of the ballast."

      >
      > 3. add System_Failure_Value
      >
      > The levels are converted from REAL to 0-254 using the DALI logarithmic
      > dimming curve. MASK is 255. How is MASK set or reported? (perhaps -1.0
      > or 0.0 or NAN or INF?)

      I use -1.0, but I think NAN is just as good.

      > From DALI:
      >
      > In case of the interface idle voltage is permanently below the specified
      > receiver high level range (see Appendix: Voltage ratings) during more
      > than 500 ms the ballast shall check the content of the 'SYSTEM
      > FAILURE LEVEL'. If 'MASK' is stored the ballast shall stay in the state
      > it is (no change of the arc power level, no switching on or off). In
      > case of any other value stored, the ballast shall go to this arc power
      > level immediately without fading. After the return of idle voltage the
      > ballast shall not change its state.
      >
      > proposed BACnet:
      >
      > [add to Table 12-X Properties of the Lighting Output Object]
      > System_Failure_Value REAL O
      >
      > [add to 12.X, Lighting Output Object Type]
      > 12.X.31 System_Failure_Value
      >
      > This optional property, of type REAL, shall specify the value that
      > physical output shall go to if the interface to the output is deemed
      > inoperable. A value of NAN (not a number) shall specify that the
      > physical output remain in the state that it is in.

      I would add:

      "If the lighting output is a DALI ballast this value corresponds to
      the DALI register 'SYSTEM FAILURE LEVEL' of the ballast."

      > 4. add On_Delay
      >
      > [add to Table 12-X Properties of the Lighting Output Object]
      > On_Delay REAL O
      >
      > [add to 12.X, Lighting Output Object Type]
      >
      > 12.X.32 On_Delay
      >
      > This optional property, of type REAL, indicates the time in seconds that
      > the lights wait before turning on. When the Present_Value is changed
      > from zero to some value greater than zero, the action is delayed for the
      > time given in this property.
      >
      > [change 12.X.4 Present_Value]
      >
      > If the object supports fading (indicated by the presence of Fade_Time),
      > ramping (indicated by the presence of Ramp_Rate), or delaying (indicated
      > by the presence of On_Delay), then it is possible that Present_Value may
      > not indicate the actual state of the lighting output due to a fade,
      > ramp, or delay in progress.

      Shouldn't Off_Delay be mentioned as well ("...or delaying (indicated
      by the presence of Off_Delay) ...")?

      > 5. Change Blink Warning Behavior to support an Off Delay:
      >
      > [add to 12.X.11.1 Blink Warning Behavior]
      > When Blink_Time is zero and Present_Value becomes 0%, the lights shall
      > remain on and not blink for up to Blink_Delay seconds.
      >
      > == Discussion ==
      >
      > > But "blink warn" is in effect BEFORE a transition TO 0 is eminent,
      > > while "auto-off" is in effect AFTER a transition FROM 0. So, confusing
      > > semantics asside, I don't understand how you want to use this feature
      > > for both.
      >
      > To support Off Delay, set the Blink_Delay equal to the amount of time
      > that you want Off_Delay to be. Set Blink_Time to zero. When the
      > Present_Value transitions from non-zero to zero, then the lights remain
      > on for Blink_Delay seconds, and automatically relinquish at the end of
      > Blink_Delay.
      >
      > Perhaps changing the words Blink_Delay in DMF-011-9 to use the words
      > Off_Delay would make things clearer. They are the same thing.

      That is ok with me.

      > > How would this work with multiple switches, when the timer should be
      > > reset every time one of the switches is pressed (like in a typical
      > > staircase)? The different clients do not know about the timers in the
      > > other clients and have no means to reset those timers.
      >
      > I agree that the timer should reside in the Lighting Output objects.
      >
      > I would say that the switches would have to send to the Lighting Output
      > a non-zero value followed by a zero value, similar to what a maintained
      > switch input would send. Or, when the switch is pressed, a non-zero
      > value is sent to the Lighting Output object; when the switch is
      > released, a zero value is sent to the Lighting Output object.
      >
      > Or the wall switch could simply send a Lighting_Command with the
      > Duration field populated.

      Well I guess the Lighting_Command duration field is what suites the
      application best. Seems I overlooked that feature.

      Do you attend the Plug-Fest in Vancouver in two weeks? Me and a
      college of mine will be there. If so, maybe we can continue the
      discussion over a nice beer ... :-)

      BTW, maybe you can direct me to a manufacturer of DALI equipment in
      the US. I need a 110V bus-power supply and ballast for the plug-fest.
      The stuff I have is 230V only.

      Best regards,

      Jörg
    • Show all 18 messages in this topic