RE: [Bacnet4linux-developer] BACNet4Linux TimeSync

[Coleman B. <col...@co...>]

Welcome!

RE:  BACnet/IP

There were some bugs in the original code I checked in.  Actually, a
pretty silly one was causing the original B/IP code to not work 100% of
the time, the IPLEN variable was calculated incorrectly.  It worked for
addresses like 192.168.1.14, but not 172.62.1.14.  This had a direct
effect on broadcasts.  This is before I knew about the other definition
in the BSD headers.  The current B/IP code has been working (send and
receive!) like a clock for months now...

It's actually a strncpy(npdu->dest_ip, Local_Broadcast_Address, IPLEN)
type of problem.  If the IPLEN variable is wrong, dest_ip didn't contain
the full bcast address.  

RE:  Time-Sync

A BACnet device isn't allowed to simply broadcast time-syncs.
Unfortunately, this is how the current implementation of B4L works.
BACnet device *have* to contain a time-sync-recipient property and it
must be writable.  Even more than that, there are some bizarre rules
with what can be written.  However, Steve is right, it's implemented and
works beautifully.  

What I had considered doing was letting my BACnet device receive it's
time via NTP (ntpd???) and then have my BACnet stack broadcast TimeSync
requests occasionally, say every 15-30 minutes.  So, from my point of
view (in the case of my current implementation), yes this is quite
helpful.  However, can't this be accomplished by the current NTP
mechanisms?  However, my device isn't a workstation.   

Coleman




> -----Original Message-----
> From: bac...@li...
> [mailto:bac...@li...] On Behalf
Of
> Steve Karg
> Sent: Thursday, March 10, 2005 10:51 AM
> To: bac...@li...
> Subject: [Bacnet4linux-developer] BACNet4Linux TimeSync
> 
> Hello Heiko,
> 
> You have been added to our developer list.  Welcome!
> 
> >>> For this we are using NTP (the Network Time Protocol) and when
some
> >>> customer told me about BACNet today, I wanted to find out how a
> >>> BACNet network dealing with time synchronization.
> >>
> >> You are at the right place!
> >>
> > That's good :-) I am not quite sure about the market chances we have
> > with such a device. What do you think, could a native BACnet UTC
time
> > source be of interest to end users of this system? And, what do you
> > think about the market shares of BACnet in the Building Automation
> > market? I heard of something called LONWorks which looks like a
> > competiting system and cannot really determine at the moment which
> > system is the most wanted in the BA world..
> 
> Yes, LON is the competition.  BACnet is the better system :-)
> 
> >>> Can you shed some light on this for me? I would like to find out
if
> >>> it would make sense to add BACNet support to our time servers
which
> >>> then could be used in a BACNet installation. Because they are
> >>> stand-alone appliances, the time synchronization could be taken
off
> >>> the shoulders of the workstation and this could add stability and
> >>> (maybe accuracy, too) to the time base of such a network. For this
it
> >>> would probably make sense to use your BACNet4Linux and add support
> >>> the four BIBBs I mentioned earlier.
> >>
> >> It should be trivial to add BACnet support for TimeSync and
> >> UTCTimeSync under Linux using the BACnet4Linux code as a baseline.
In
> >> fact, we already have support for TimeSync in the core code.  You
> >> would probably want to strip out some things, like the HTML and the
> >> query new device code.
> >>
> > That would make sense. I did not look into your code but I guess it
is
> > possible.
> >
> >> Also, to be a good BACnet citizen, you need to have a BACnet Device
> >> Object with a unique BACnet ID.  The current code has this using
> >> command line parameters when starting the daemon.
> >>
> > That's something we have to ask for someone I guess.
> 
> It's really just a matter of configuration.  The unique BACnet ID is
> just like an IP address in that it is unique on the LAN and needs to
be
> configured in the device.  There is also a special BACnet address that
> acts like a DHCP kind of thing.
> 
> If you are going forward to making a BACnet device, you would also get
a
> unique Vendor ID, which is free.  A link to the request form is at:
> http://www.bacnet.org/VendorID/
> 
> >> The BACnet Ethernet layer is working well, but the BACnet/IP layers
> >> needs a little attention.
> >>
> > Can you specify "needs a little attention" ? :)
> 
> With the current code base, BACnet/IP seems to send out messages, but
I
> couldn't get it to receive any messages (when I disable the BACnet
> Ethernet layer).  Coleman swears that it used to work, and also has
> given me his latest code which he says works, but I haven't taken the
> time to compare the two to find out why the current BACnet4Linux
> BACnet/IP is not receiving (or possibly not sending with the right
> network layer data).
> 
> >> The UTCTimeSync would need to be added, but it should be trivial as
it
> >> would mostly be a copy/paste from the TimeSync function.
> >>
> >> Most of the time the TimeSync is sent out as a global or local
> >> broadcast, but occasionally it is sent out as unicast to a specific
> >> device.  Our current code only has the broadcast.  There is a time
> >> sync reception list in the Device Object, which can contain a
> >> broadcast address or the address of a specific device, and can be
> >> writeable.  I don't think we have that list in our current code.
> >>
> > How does this work? A "-B" device tells the "-A" device that it
wants to
> > receive unicast time synchronization messages at a specific
interval? Or
> > on request? Or is the -A device responsible for querying the network
and
> > finding devices which need TS messages in unicast form?
> 
> Usually the specific interval is a configuration issue and doesn't
come
> from an A or B side device.  But it is possible to have a writeable
> recipient list where the B side device requests to be added to the
list.
>   In the Lithonia Lighting BACnet device, I have the list configured
to
> send out local or global broadcast of time sync at a specific interval
> if it is enabled.  But since that list is not writeable, I don't even
> support the recipient list property of the device object.
> 
> Coleman has been doing some work with the
> time-synchronization-recipients property lately.  Perhaps he can chime
in.
> 
> Best Regards,
> 
> Steve
> --
> http://www.kargs.net/
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Bacnet4linux-developer mailing list
> Bac...@li...
> https://lists.sourceforge.net/lists/listinfo/bacnet4linux-developer