Programming in Sedona is simple and fun and I look forward to sharing examples in the future. But before I post any code examples, you might want to know - just what is Sedona and why should I be excited about it? At its core, Sedona is a virtual machine and a computer language that runs the machine. But what is so exciting about it?

Keeping clocks synchronized to a standard reference is important in any control system that schedules tasks or records historical data. All Niagara systems have mechanisms built in to accomplish this and they should be implemented properly (I would estimate that it is normal for an RTC clock to lose or gain 5-50 seconds a day - see Clock Quality ). Before Niagara AX version 3.4, QNX based controllers could only keep their clock in sync using a method known as "Time Protocol". This older protocol has been superseded by a more sophisticated and more accurate one known as "Network Time Protocol" (NTP for short). Going forward this is the preferred mechanism for keeping your JACE controller's clock in sync. To implement it, you enable it and tell it which time servers to use (the official documentation is in docPlatform). This is done on the NtpPlatformService object under PlatformServices inside the station. This object allows you to configure the NTP daemon that is in the OS. Once it is configured properly it will continue to work even when your station is not running. Unfortunately (as of version 3.4), there is no feedback or monitoring of the NTP daemon. You can verify it is working by checking the clock to see if it closely follows your reference time. If your JACE controllers are set up to use NTP, then there is no reason to have the TimeSyncService in your station. You should take it out to avoid confusion.

When I think about PID loop tuning, one thing that comes to mind is the many variations of the PID formula:

I considered using a silly title, like "The Ups and Downs of AX Grades" to bait you into wondering just what I was writing about, but this is such an important topic I wanted to have a title that makes sense, so I'll spare you my odd sense of humor for this edition only.

Next to oBIX, BACnet is my favorite building automation protocol. But it took a while for me to understand how it all fits together. This blog will focus on the different types of BACnet networks and the routing of BACnet messages from one network to the next.

Your device is down or you cannot commission a device. Most of the time these problems are not a problem with the Niagara hardware and they are not due to a bug in our software, but typically it is the Niagara technical support person that gets the call. I know where you are coming from (I have been there). In the best case, you have a ladder and a drawing showing the location of all the equipment, their neuron numbers and a line showing the path the trunk follows from device to device. In the worst case, the job is a retrofit, the building is occupied and you don't have a clue where the devices are.

There are advantages to having your remote station collect the histories (which is why the system is designed for it). When I used to engineer jobs, I always wanted my data to be collected as close to the source as possible. I would try to have buffer sizes sufficient in the remote stations so that I could continue collecting data for a full day when the IP/Ethernet network is down. That way if there were a problem with the IP/Ethernet network for a few minutes or hours, my historical data would not be lost, invalid or marked stale. In this configuration data can still be collected even when your Web Supervisor is off. It takes more bandwidth to have points permanently subscribed across the network (they will update continuously) than to periodically transfer a history archive update since your history only records the value periodically (i.e. once every fifteen minutes if you have it configured that way).

No, I am not really going to put forth my own theory of time and space relationships - but its a cool title, eh? What I am going to discuss is time synchronization. In hind sight, I wish we had put more information about it in the Tech Tip on DST issues. But it is not really a "you need to know" item, so I am not going to author a new tech tip. I will post this blog and hope that I will receive fewer questions on the topic. One that I keep getting is, "won't the time-sync service automatically resolve all my 2007 DST rule issues?" It is really a silly question if you spend some time pondering how time-sync might work. Many of you are synchronizing with servers that are in another time-zone, right? So how does that work? Obviously, time sync servers don't send their local time - otherwise they wouldn't work across time zone lines.