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

RE: Multiplexer Object

Expand Messages
  • Karg, Steve
    RE: Multiplexer Object Hi Carl, The Lighting Applications working group reviewed your comments at our Kansas City meeting, and I have modified STK-004
    Message 1 of 1 , Sep 18, 2003
    • 0 Attachment
      RE: Multiplexer Object

      Hi Carl,

      The Lighting Applications working group reviewed your comments at our Kansas City meeting, and I have modified STK-004 accordingly.  Hopefully the changes address your concerns, and make this object a better object.

      > 1) I think that it would make sense to have Status-Flags,
      > Out-Of-Service & Reliability properties added to the object:
      > - If the object fails to write any of the other objects,
      > the multiplexor should go into Fault. It should use the same
      > reliability value defined for the new GlobalGroup object. An
      > alternative would be to add the All_Writes_Successful property
      > (as found int he Command object).
      > - When the object is placed Out-Of-Service it would not
      > write to the other objects when written to.

      One of our earlier drafts had the All_Writes_Successful, so we decided to bring that back into the object along with Out_Of_Service.  We also added In_Process to go along with All_Writes_Successful.

      > 2) The BACnetMultiplexerPV should be changed to be
      > more generic. I understand that this was added in
      > to allow a choice of any basic datatype without
      > allowing the choice of constructed datatypes. As
      > such, this would be useful in other places in the
      > future and should be named accordingly. In addition,
      > it should contain most, if not all, all of the basic
      > datatypes.

      Although this is the third name change for this property type, I like the idea of reuse.  I added more base types to it, but tried to stick to numerical-in-nature primitives.

      BACnetPrimitivePV ::= CHOICE {
              null-value              NULL
              binary-value    BOOLEAN
              unsigned-value  Unsigned
              signed-value    INTEGER
              real-value              REAL
              double-value    Double
              enumerated-value        Enumerated

      > 3) I disagree with the addition of text to WP & WPM
      > that describes the use of the priority when writing
      > to the multiplexer object. This use of the priority
      > should only be described in the multiplexor object
      > itself either in the introduction paragraph (which is
      > effectively the object's service procedure), or as is
      > arelady done in the Present_Value property description.
      > I believe this to be the case because the WP/WPM service
      > procedure is not responsible for redirecting the written
      > value, the multiplexor object is.

      This was Bill's suggestion, so we will leave it as is for committee debate.

      > 4) Is there a standard alarm algorithm that might
      > be useful with this object? Or would it be reasonable
      > to allow this object to just generate Fault alarms
      > when it is unable to perform its command?

      We did not feel that this was necessary for this object.

      > 5) Would it be beneficial to include a property that
      > contains the last written priority?

      This idea was in the early drafts of the object, so we decided to add it back in.

      > 6) How should the object behave when a failure occurs?
      > Will the object continue to try to write to the other
      > items in its list?

      We added text to define the behavior in the description of the List_Of_Object_Property_Reference.

      > 7) The introduction to this object alludes to the
      > object writing to properties of differing types
      > (BO.PV, and AO.PV) at the same time, yet the body
      > of the proposal makes no comment on this. Is this
      > behaviour expected to work or should it be specifically
      > denied?

      We agreed that this behaviour is expected to work, and text was added to the description of Present_Value.

      Best Regards,

      Steve + LA-WG
      Steve Karg
      Senior Engineer
      Lithonia Lighting, ESG
      1 Lithonia Way
      Decatur, Georgia 30035 USA
      skarg@... (alternate)


    Your message has been successfully submitted and would be delivered to recipients shortly.