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

RE: [bacnet-mstpwg] Re: Large Frames for MS/TP

Expand Messages
  • Clifford.H.Copass@jci.com
    Actually I don t think this issue has anything at all to do with the physical location/connector on the board necessarily. If a client device is trying to
    Message 1 of 10 , Feb 11, 2011
      Actually I don't think this issue has anything at all to do with the physical location/connector on the board necessarily.  If a client device is trying to determine if a potential server device can handle a big message, it doesn't care where the connector is located.  It may only want to know which Network Port Object contains the information for the port it is communicating through (assuming there is more than one).

      An installer may need information on the physical port, but even then I am not convinced they would always care when adding/removing devices to/from an existing bus.  Especially if that bus disappeared off into the unknown reaches of some building where a physically inaccessible device was located that needed something on the appropriate Network Port Object verified or changed.

      Cliff Copass
      Johnson Controls, Inc.



      From:"Coleman Brumley" <bacnet_cb@...>
      To:<bacnet-mstpwg@yahoogroups.com>
      Date:02/11/2011 09:04 AM
      Subject:RE: [bacnet-mstpwg] Re: Large Frames for MS/TP






      Cliff,

       

      I've been mulling this over since we talked about it in Vegas.

       

      How would you be able to make a logical connection/relationship from the NPO on the wire to the physical port?  I don't think you can other than with labels, documentation, or whatever.  

       

      Consider I/O objects, where this already an issue.   If I have X binary outputs on a device, and I have X BO objects -- how do I (being a BACnet client) know where BO-1 is physically on the board???   I, Coleman, have to look at the board or documentation (as-builds, manufacturers documentation, whatever) and check for a label that says "Binary Output 1" or something that matches the description or whatever.  The point being that there is some entity outside of BACnet for representing this relationship.  

       

      The same applies for the NPO.   If I have X MS/TP ports on an device, and I have X NP objects -- how do I (being a BACnet client) know where NPO-1 is physically on the board?

       

      - Coleman

       

      From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Clifford.H.Copass@...
      Sent:
      Friday, February 11, 2011 9:15 AM
      To:
      bacnet-mstpwg@yahoogroups.com
      Subject:
      RE: [bacnet-mstpwg] Re: Large Frames for MS/TP

       

       


      I think this is yet another reason why the Network Port Object proposal needs a way to find the Network Port Object for the port you are communicating through when there is more than one.


      Cliff Copass

      Johnson Controls, Inc.


      From: "carlneilson" <carlneilson@...>
      To: <bacnet-mstpwg@yahoogroups.com>
      Date: 02/09/2011 07:29 PM
      Subject: RE: [bacnet-mstpwg] Re: Large Frames for MS/TP

       




      1 – I think that the only appropriate methods for determining large versus small would be via the Max_APDU_Length_Accepted property in the device or the similar value in the application request header. Note that routers will take the message they are given and will send to the destination device. The source device of the packet have generated a packet based on what it believes that the destination device can consume.

       

      Carl

       

      From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of kerlyn2001
      Sent:
      Wednesday, February 09, 2011 5:14 PM
      To:
      bacnet-mstpwg@yahoogroups.com
      Subject:
      [bacnet-mstpwg] Re: Large Frames for MS/TP

       

       

      I'll take a pass at this:

      > Three things that probably need to be considered along with this:
      > 1 - How does a device that can send a large frame determine that
      > another device can accept it?

      I'd say configuration or discovery. It seems that the loopback test
      method could be used for this purpose. Section 9.1.3.1 ends with
      "If the receiving node cannot detect the valid reception of frames
      with overlength information fields, then no response shall be
      returned."

      > 2 - These should probably only be used with higher baud rates.

      That is one possibility. It might eliminate many legacy devices
      from the set of nodes that might receive large frames. The concern
      I have (and will elaborate in a separate message) is that the
      probability of a CRC failure (passing bad data up the stack as good)
      is dependent on bit error rate and message size. The former goes up
      with bit rate and the latter goes up with large frames.

      > 3 - Will old devices that don't understand the frame type or allow
      > larger messages have problems even if the message is not addressed
      > to them?

      The new frame(s) will have a different frame type (not 5 or 6). In
      the normal case, a frame will not be unicast to a device that doesn't
      understand it (see #1 above). A device *may* receive a large frame
      that was broadcast. In this case, the device should either reject it
      because of FrameTooLong (set in Receive Frame HEADER CRC state) or
      ReceivedInvalidFrame (set in Master Node IDLE state).

      Comments?

      -K-







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