BACnet TEC Thermostats and busy time

[Igotworms]

I'm looking for some recommendations on how to map points from a Johnson TEC thermostat to an FX20/60. Im doing a job now with an FX60 that has 3 MS/TP trunks and about 60 heat pumps (roughly 20 Heat pumps on each trunk) using TECs and a few PCGs for the tower, boilers and pumps. I'm not mapping in all of the points from the TECs and I'm only trending 3 points on each (Zone Temp Interval trend, Compressor command COV trend, and effective occupancy COV trend). No matter what I do I can't seem to get the busy time down. It bounces around between 70% to 80%. I have a separate policy for outdoor air which only writes once every hour. Also I have a policy for the occupancy command which is once every 20 minutes. My normal poll rate is 10 seconds. Any ideas on how to reduce this busy time? Also im pretty confident that I have a strong trunk.

[davem]

Keep in mind that a JACE (okay, an FX20/60...) actually uses 2 polling threads for BACnet polling, but sums their total busy times. So, you're really running somewhere in the neighborhood of 35-40% per thread - which isn't bad. The best I've ever achieved with MS/TP trunks is about 60-65%, so you're in the ballpark.
You'll know if your polling rates and write times are good is if the "dibs polling" cycle clears to zero percent - then you know everything is getting written in a timely manner, and the points are getting shifted to their appropriate timing cycles.

(Probably more than you were looking for...sorry)

[Igotworms]

Thanks davem, that's good to know. Why do I get the error "Transaction Timeout : Invoke ID xx" on the points that I'm trending? I figured it was some sort of collision from the busy time being too high?

[davem]

I believe that the "transaction timeout" errors have more to do with token passing problems than with anything else. I'd try to ensure that your addressing doesn't have any conflicts (which would be fairly obvious to see in your Bacnet Device Manager by now...), and the MAC addressing of the devices is fairly close to sequential (without big holes in the sequence to slow down the token passing).

[Questionz]

I don't mean to hijack this thread, I'm hoping someone can help me with BusyTime.

I have 4 trunks on an FX70 each handling roughly 30 PCVs, a few PCGs. They are all on BACnet MS/TP. Now, unfortunately, no matter how I configure the PCG/PCV programs, random variable names show up when I discover the points. I don't add them, and just add the points that are necessary (~20 or so points per device).

After everything is setup, trends, alarms, etc, I check the BusyTime of each trunk, and notice that it's an access of 300%!

Based on what I read, davem, that means it's not being written in a timely manner. On top of that, I didn't check the dibs polling, so I don't know whether it's good or not.

Any pointers on how I can reduce the busytime - if my busytime exceeds 300%?

[Igotworms]

http://pub.controls.johnsoncontrols....er_Videos.html

There is a good video describing busy time and bacnet polling. Questionz, this should help you he has pcvs on the trunk he's tuning. He's says at the end that an ideal busy time is around 10%, mine is only that low with 1 controller mapped in. After more are mapped it starts to get a little high. I still think the way I map TECs is wrong.

[Questionz]

Wow, Igotworms, that link is very helpful, thanks for the suggestion! I will take a look hopefully it will help, as i feel that i did the best i can for the trunks. I feel that the only other option is to increase the polling time, which i did on one trunk reducing the busytime from 300% to 120% or so.

[Questionz]

Wow, Igotworms, that link is very helpful, thanks for the suggestion! I will take a look hopefully it will help, as i feel that i did the best i can for the trunks. I feel that the only other option is to increase the polling time, which i did on one trunk reducing the busytime from 300% to 120% or so.

Ok, so I watched the video, and there are some things I didn't do that he recommended. I will be trying this, and hopefully (Fingers crossed) it will substantially reduce the busy time. One of the things he talked about which I'm not too sure, is the min write time and max write time. When he set the min write time to 10 minutes, and left max write time to 0, I thought it meant the max write time was "disabled". Then he went on to change another policy - max write time = 20 minutes, but min write time was left to 0. Wouldn't this mean that the write time will be a random time between 0 and 10 minutes?

Anyway, I'm going to try creating a few policies, seting fast and slow poll times for dynamic and static values.

[CB_Matt]

That was a great video explaining the tuning policys. Thanks for sharing that!

[davem]

Questionz - I haven't watched the video, but perhaps he left out explaining one more step: once the various tuning policies are created, you then have to go assign the appropriate proxy points to those various policies. The various timers are mutually exclusive to that particular policy, and do not affect points not assigned to that policy.

For instance, when I need to ensure that a schedule point gets regularly written, I'll go through my database (with the Program Service), and assign all proxy extensions of my "OccCmd" points to a tuning policy that has a max write time of 1 minute - but nothing else gets thrown in there.

The min write time means that writing the points assigned to that policy will not happen until at least the min write time has expired - prevents writing too often.
The max write time means that no more than the max write time will expire before the points assigned to that policy are written - keeps points fresh.

Guess I should go watch that video...

[Questionz]

Questionz - I haven't watched the video, but perhaps he left out explaining one more step: once the various tuning policies are created, you then have to go assign the appropriate proxy points to those various policies. The various timers are mutually exclusive to that particular policy, and do not affect points not assigned to that policy.

For instance, when I need to ensure that a schedule point gets regularly written, I'll go through my database (with the Program Service), and assign all proxy extensions of my "OccCmd" points to a tuning policy that has a max write time of 1 minute - but nothing else gets thrown in there.

Thanks for the reply davem. If I am understanding you correctly, after I create the tuning policy, I have to go the specific point and assign them. I have done so, and have periodically gone back to the Bacnet comm in order to check if my busytime has been substantially improved.

Unfortunately, I don't see a significant change. The system is still exceeding 100%. I guess I should also include the amount of points that are showing up:

Trunk 1:
Point Count = 250
Busy Time = 148%
Fast Poll = 71%
Normal poll =28%
Fast Count = 18
Normal Count = 26
Fast Cycle Time = 3552ms
Normal Cycle Time = 12956
Slow Cycle Time = 1156

Trunk 2:
Point Count = 243
Busy Time = 144%
Fast Poll = 46%
Normal poll =50%
Fast Count = 21
Normal Count = 25
Fast Cycle Time = 1873ms
Normal Cycle Time = 8407
Slow Cycle Time = 1173

Trunk 3:
Point Count = 337
Busy Time = 137%
Fast Poll = 46%
Normal poll =50%
Fast Count = 11
Normal Count = 33
Fast Cycle Time = 3875ms
Normal Cycle Time = 18174
Slow Cycle Time = 1239

Trunk 4: Roughly same as Trunk 1

All of these have a Fast Rate = 5 sec, Normal Rate = 15 sec, Slow Rate = 30 sec.
Dynamic values (temperature, output%, PID loop outputs) are set to fast rate, everything else (setpoints, commands, etc) are set to normal rate.

[BACnet]

Using your data for trunk 1 (and adding in some guesses to fill in the blanks) I end up with the following data. Please correct me if any assumptions, marked with *’s, are incorrect:

Trunk 1:
Point Count = 250
Fast Count = 18
Normal Count = 26
*Slow Count = 250-18-26 = 206
Fast Rate = 5 seconds
Normal Rate = 15 seconds
Slow Rate = 30 seconds

Using those numbers, It would seem that every minute there would be 2 polls of each of the “slow” points, 4 polls of each of the “normal” points and 12 polls of each of the “fast” points.

So Polls per minute would need to be at least:
(206*2)+(26*4)+(18*12) = 732 points polled every minute.

To put this another way, you need to have a network that will operate faster than an average of 12.2 polls asked & answered every second.

If your network is configured correctly, that should be no problem at all.

As an example, let’s say your MS/TP network is set up at one of the slower but still common baud rates, 38.4 kbps. If you have 128 masters on the network and no slaves you would have a fairly typical, well loaded network.

In this setup, you will find that the network throughput is directly proportional to the efficiency of your front end. There are two things that I would look into- the “Max Info Frames” setting on your router/front_end and the actual points you are polling for.

Specifically, I would always suggest that you use a higher number setting for your “Max Info Frames” variable on your front end and/or router. By boosting this number up you are able to ask more questions before passing on the token. I know some devices come defaulted at 10 frames and that’s fine for a controller when it wants to talk to other controllers but a front end should be set much higher, perhaps 30 or 40.

The other issue isn’t quite as big a deal as the max info frames but it is worth mentioning. Every time you poll for a point on a controller that doesn’t exist, the network pauses for approximately 255ms before moving on. So if you have set up your front end to poll for points that are to be in a controller you haven’t installed yet, that will also drop your network throughput.

I made this graph using the generic assumptions of a baud rate of 38.4kbps, 128 master devices and no slaves. This should be an accurate real world worst-case example of an MS/TP network:



Remember that you need a minimum of 12.2 points polled every second in Trunk 1. That means that you cannot have your Max Info Frames variable set as low or below a value of 10. In addition, if you are polling for points that don’t exist, you will start to run into trouble somewhere near 70 points per minute, even if you have a Max Info Frames set to 20.

I’d immediately bump up your max info frames to a reasonable number like 30 or 40. Then I would sniff the network to see if there is anything wasting time (like polls to units that don’t exist). I assume that somewhere along the way you will find that you have solved your throughput issues.

[davem]

I knew BACnet would chime in here - great information!

It would take a perfectly installed network to see the ideal throughput of 12 polls per second (83ms per poll), but now that I type this, I remember that I have seen serial polling happen as fast as 60ms...so ideally an 83ms poll is possible.

Nice explanation about the info frames, too - definitely something I'll look into on my projects.