Page 3 of 3 FirstFirst 123
Results 41 to 50 of 50

Thread: Free BACnet Widget/Tool- MSTP Speed Estimator

  1. #41
    Join Date
    Oct 2003
    Location
    Minnesota
    Posts
    1,411
    Post Likes
    Quote Originally Posted by crab master View Post
    Interesting read - Experimental Performance Evaluation of BACnet MS/TP Protocol

    Especially the latter on the importance of Grouping/Addressing data/controllers you deem important near one another.
    Yep.

    But in the grand scheme of things, in most cases the findings and recommendations made my those guys is gonna be of little importance/impact.

    The primary concern where their advice would be relevant is cases where it is critical to have the fastest possible updates times for data going from here to there .... over the network.

    Would be relevant, for instance, if one were using an intelligent, networked sensor feeding vital/critical information over the network to a controller or intelligent, networked actuator which needed to respond QUICKLY to any value changes.

    Usually not the case, for instance, in most HVAC/BAS control sequences. In fact, such fast updates and responses are usually counter productive.

    MIGHT be an important factor in cases of fire/life safety stuff. Where, for instance, one wants/needs an IMMEDIATE response to an event or measured variable change above or below certain limits. As when milliseconds might count. Or the difference between .5 and 1.5 seconds might be important.

    And there are situations/cases where such is wanted/needed/required.

    Off hand, in the kind of installations we do, I can't think of many such cases however.

    Typically, if there is something we want an IMMEDIATE response to, it gets hardwired direct. i.e. A typical case would be something like an AHU shutdown on fire/smoke detection. Yep, info about the event does get sent out over the network, and will arrive whenever it does at the controller controlling the air handler ... or VFD if that's the case. Program within AHU controller will get data and initiate it's own shutdown. But shutdown will have already occurred on any job we do. Trip of detector at AHU will break relay contacts right there, de-energizing start relay or whatever, regardless of what our BO is doing.

    Typically what one sees/experiences is immediate trip of AHU motors, dampers slamming to default positions, then if you can see front end screen at same time a moment later you see system registering fact that fan status is zero (off) and ... oh, yeah ... we have fire/smoke detected. Program reporting it turned start/stop BO off, it's assumed required operation mode (i.e. Shut down on fire/smoke report), etc, etc. AHU controller WILL do shutdown of fans and damper positioning (put BO's and AO's in required states) ... but such will have already occurred.

    <Shrug> I recall one installation where I came in after the fact, installation done and system operating. Problem was original controls design engineer and lead tech for project up and quit ... went to work for our competition. So I was called upon to do final acceptance stuff. Wasn't happy, the guys who'd left had set up system to respond to fire/smoke (AHU's, exh fans, etc) solely via network comms and program operation. I don't like that for critical fire/safety issues. But it was too late, fire inspector was on site and wanting to do testing.

    Everything worked okay, I held breath while waiting for one AHU to stop, and a particular exhaust fan to go into speed control bypass and full speed to control smoke. But everything worked okay. Was maybe 3 second delay between trip of alarm and everything responding. But .... fire marshal was more than happy. He told me that he allowed up to 15 seconds. Had been using stop watch, and our system beat it by wide margin.

    (I later made installers come back and rewire for hardwire operation ... but I'm a bit anal about such things.)

    Now, I am aware of cases where really fast detect and response is required, other than fire/smoke. i.e. Some lab and process control jobs we've done. But again we didn't rely on intelligent sensor sending critical data over network to actuator. Used old, dumb sensors producing milliamp signals, etc direct to onboard IO on local controllers, actuators also directly wired. Controller with custom program to accomplish SOO. Controller would send info over network to other places, and could receive info/parameter changes or whatever, BUT no network transported data was required for it to do what it needed to do. In these cases, if we'd relied on info from network, would have needed really, really fast network. And a dedicated one, couldn't have gone IP anything unless a dedicated control network separated from customer's ordinary data network. And they didn't even want that. Wanted stand-alone capability. Network went down, controller and stuff it controlled continued to work. Local network on sub-net connected controller to local LCD screen so people in room could adjust, override, etc if needed.

    My only real point here is that the authors of that article are quite correct in their suggestions. But applicability to what we here in these forums do is minimal. Their info is worth knowing however, there are cases where it might be handy.
    A site where I stash some stuff that might be interesting to some folks.
    http://cid-0554c074ec47c396.office.l...e.aspx/.Public

  2. #42
    Join Date
    Aug 2007
    Location
    Western Oregon
    Posts
    499
    Post Likes
    I read through some of the document that Crab posted.

    On page one I read the following:

    "BACnet provides five options for its data link layer
    protocol: Ethernet, ARCnet, MS/TP (Master-
    Slave/Token-Passing), PTP (Point-To-Point), and
    LonTalk. MS/TP is the most widely used protocol establish connections between field-level devices due
    to its cost-effectiveness and ease of implementation."

    And then on page two I saw this:

    "BACnet provides six options for the data link layer
    protocol including Ethernet, ARCNET, MS/TP,
    LonTalk, PTP and BACnet/IP. Among these six data
    link layer options, MS/TP is the most widely used
    protocol to establish connections between field level
    devices because of its cost-effectiveness and ease of
    implementation [5-8]."

    I hate reading something that has what seems to be glaring errors right off the bat:
    I want to know if Bacnet provides 5 or 6 - "options for the data-link layer"?
    And I want to know how Bacnet provides LonTalk in any fashion?
    RealEyes
    Realize
    RealLies!




  3. #43
    Join Date
    Aug 2009
    Posts
    2,456
    Post Likes
    Thread Starter
    Quote Originally Posted by rad1 View Post
    And I want to know how Bacnet provides LonTalk in any fashion?
    I have never played with any BACnet over LON devices, but the spec was designed to allow people to send BACnet messages that way.

    I believe that Siemens makes a device called "Desigo PX" which can be set up to operate in this manner. Perhaps someone with experience with a PX could fill in the details in a new thread.

  4. #44
    Join Date
    Aug 2009
    Posts
    2,456
    Post Likes
    Thread Starter
    Quote Originally Posted by rad1 View Post
    I hate reading something that has what seems to be glaring errors right off the bat:
    I want to know if Bacnet provides 5 or 6 - "options for the data-link layer"?
    The answer is 7, but when that paper was written (2007) the answer was 6. Since then Zigbee has been added.

    ISO 8802-3 "Ethernet"
    ARCNET
    MS/TP
    Point-To-Point
    LonTalk
    BACnet/IP
    Zigbee

  5. #45
    Join Date
    Aug 2007
    Location
    Western Oregon
    Posts
    499
    Post Likes
    Thank you BACnet. Have you done much with Zigbee? I don't know much about it.
    RealEyes
    Realize
    RealLies!




  6. #46
    Join Date
    Aug 2009
    Posts
    2,456
    Post Likes
    Thread Starter
    I have toyed around with zigbee dev kits, but I don't have any real world experience with deploying it out in the field.

  7. #47
    Join Date
    Sep 2011
    Posts
    67
    Post Likes
    Quote Originally Posted by BACnet View Post
    I believe that Siemens makes a device called "Desigo PX" which can be set up to operate in this manner. Perhaps someone with experience with a PX could fill in the details in a new thread.
    BACnet over LON uses he Foreign Frame message code for a LON application message to encapsulste the BACnet data into the APDU. The packet size is rather large compared to "normal" LON messages so you have to consider this when adding LON infrastructure devices. This is the information in short- did not want to start a new thread just for this.

  8. #48
    Join Date
    Aug 2009
    Posts
    2,456
    Post Likes
    Thread Starter
    Thanks for the info, 709. I had always wondered if anyone used that. Were your experiences using the Siemens devices, or is there another company that supports this medium?

  9. #49
    Join Date
    Sep 2011
    Posts
    67
    Post Likes
    AFAIK, Siemens at the moment is the only company who uses this. I personally never tested the devices, but what I have heared, the setup performs really good and they have no issues with the FT communication - much better than my experience with MSTP (no, I dont want to start the FT vs MSTP discussion also in this thread).
    I wonder why not more companies choose this solution.

  10. #50
    Join Date
    Jan 2003
    Location
    USA
    Posts
    6,447
    Post Likes
    Quote Originally Posted by 709 View Post
    I wonder why not more companies choose this solution.
    Overhead would be my guess. You need the protocol stack for Bacnet, then you would also need the lon protocol stack to wrap your bacnet traffic in...

    That's alot extra crap, why would you not just speak lon if that was the field bus at hand?
    Propagating the formula. http://www.noagendashow.com/

Page 3 of 3 FirstFirst 123

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •