For this program I was asked for a solution to two units which share the same space fighting against each other. These units feed a critical space which needs to be controlled at all costs. Currently, however the two space temperatures vary by 1.5 degrees which the building manager / owner do not find acceptable. I created this macro as an option for these space temperatures.
The space temperature(s) are reported as degrees F.
Right click on the image(s) and select “open in a new tab” to view full size.
The niHeartBeat input, the noALARM_COMM and the noHeartBeat network variables are setup as unitless -> ubyte and type BV in the Advanced (Network Input) dialog box.
The ptToLogic pass thru will output a Fahrenheit temperature to the controller’s logic. The macro logic analyzes the heart beat coming from the other controller to ensure that communication is happening. As long as communication is occurring the netSpaceTemp value is accepted. However if no heart beat is received the physical space temperature attached to the controller will be used. The override block between the network temperature and the select block is to ensure that a value is being received for the network space temperature. The macro also contains a heart beat which is connected to the other controller.
The heart beat variables are connected between the two controllers via the BacnetNetwork wiresheet. The connections are made from the noHeartBeat of each controller to the niHeartBeat of the other controller. Doing the heart beat links this way will prompt a Bacnet Link Bind anytime a download is performed on the controllers.
The space temperatures are linked via the points list. On one controller place three numericWritables and an average block. These will be used to find the average of the space temperatures. In the image below the two fromController points link to the output of the space temp. They then go to the average block, from the average block to a numeric writable called toControllers and then out to the spaceTempIn variables. The reason I use the numeric writable points is so that in the future if I need to make changes to the average block (not likely but if the logic was more complex) i would be able to do it without having to re-find and link between points on other wire sheets.
Yesterday I received a call from a customer of mine who was having problems with a BACnet network attached to a JACE. As a result of this conversation I was sent a document which contains BACnet installation and tuning tips. Because I do not know who wrote the article I will only put some of the tips here.
One of the tips is whenever you are troubleshooting BACnet, turn on the link debug trace. To do this right click on the station and select Spy.
Then select logSetup and look on the list for the link debug trace. Once this is enabled go to the Application Director and stream to a file for several minutes. This file will be helpful for tech support to determine what is happening on the wire.
The first recommended step to troubleshooting the network is to increase the APDU timeout value. This will increase the time that the station is giving the MS/TP device to reply. Two other settings which correlate to this are the number of APDU retries and the retry timeout. The retry timeout tells the station how long to wait for an acknowledgment from the controller before re transmitting to the device. The number of APDU retries specifies the number of times unsuccessful transmissions (transmissions which do not receive a reply) will be repeated. If no reply is received after the APDU retry count no further attempts to transmit will be made. If no reply is received the device will be marked as off-line. Changing these settings may help correct devices intermittently dropping offline.
A few additional recommendations are to ensure that the default tuning policy max write time is set to zero. However, if using Spyders with fail detect enabled duplicate the default tuning policy set the max write time to 1 minute (or longer if you have changed the settings for the fail detect on your network variables). All other points should be set to the default tuning policy. The max info frames property of the MS/TP port should be increased from the default of 20 to a value between 60 and 100.
I was asked yesterday if there was a way to capture the “Alarm” state of a kitControl LeadLagCycle logic block. As a result of this question I put together an example of how I have used the LeadLagCycle block in the past. For this question I was also asked if there was any way to take the “Alarm” status of the output and cause an Alarm Light to come on in the panel door. Below is an example of how I would use the LeadLagCycle logic block.
Tip: Right Click on the above image and select “Open image in new tab” to view it larger.
In the above example the call, a booleanWritable point, enables or disables the LeadLagCycle block. The status inputs of the pump’s are shown as booleanWritable points, because there is only one feedback input on the LeadLagCycle block these status inputs go into an or block which is then tied into the feedback. The outputs of the LeadLagCycle block are then tied to both the pump call’s as well as StatusDemux blocks. The StatusDemux blocks interpret the current status of the LeadLagCycle block. For this situation the alarm slot of the StatusDemux block is then tied to an or block which will turn on the alarm light on the panel door.
Frequently we receive a phone call from someone asking for a temperature sensor. Occasionally the person knows what they are looking for and will say “I need a 20k, 6 inch, duct sensor” this makes our life easy and we are able to quickly inform them whether we have one or not. And most likely we have them in stock from multiple vendors. Most often however the requester will say “I need a duct sensor” to which we will respond “What resistance do you need?” For some people this catches them off guard not knowing what to say. While others will respond with a resistance, sometimes however even this is still not a complete answer to the question. For example a customer may respond “I need a 10k resistance.” To which we will respond with an additional question “Which do you need a 10k Type II or a 10k Type III?” This post will attempt to help you understand the differences between resistances first, then explain the different types of sensors available.
For a duct sensor there are multiple sensor resistances. For example MAMAC SYSTEMS, Inc. ordering information guide for their TE-701-BX VAV discharge air temperature sensor lists 15 different resistances which the one series (TE-701-BX) can be configured with. For us the most common requests are for the 20k, 10k Type II and the 10k Type III NTC sensors. The difference between the 20K and the 10 K sensors is easy to explain and understand. For the 20k sensors when the sensed temperature is 77 degrees F the sensor resistance is measured at 20,000 ohms. Regarding the 10k sensors when sensed the temperature is 77 degrees F the sensor resistance is measured at 10,000 ohms.
MAMAC SYSTEMS, Inc resistance to temperature chart for the 10k Type II and 10K Type III sensors found at http://www.mamacsys.com/pdf/Sensors/AllSensor_FINAL.pdf (Sensor Type 7 is Type III, Sensor Type 12 is Type II) the resistance at the extremes is where the differences are found. When the sensed temperature is -40 degrees F and a 10K type III sensor is used the measured resistance is 239,831 ohms, whereas the 10K type II sensor’s measured resistance is 336,095 ohms. Comparing the chart, if a 10K Type III sensor is expected and a 10K Type II sensor is used the temperature will show off by 10 degrees F on the low side. On the high side when the sensed temperature is 250 degrees the Type II sensor’s measured resistance is 377 ohms and the Type III sensor’s measured resistance is 469 ohms. This causes the sensed temperature to be off 13 degrees on the high side.
The other set of information we need is where the sensor will be used. A good tool for what sensor options are available is Honeywell’s sensor selection guide which can be found at https://customer.honeywell.com/resources/techlit/TechLitDocuments/63-0000s/63-9285.pdf