Integrating Johnson Controls FEC with T3-TB

Hello,

I’m trying to read/write Bacnet MSTP objects from a Johnson Controls FEC2611 controller. Example as follows:
Device ID = 200104
Object ID = AI 10137

Trying to read this value into a variable like this:
VAR1 = 200104AI10137

When I compile and refresh the code window, it gets changed to this (which doesn’t work):
VAR1 = 200104AI1945

This may be caused by the large object ID address. Is there a limit to the size of a Bacnet object ID in the T3000 environment?
Unfortunately the object ID addresses are generated automatically in the Johnson Controls programming tool. They are usually going to be large numbers and they can’t be changed.

1 Like

Thanks for sharing this, at the moment the maximum size of the ID is one byte, 256. It’s a fairly large change for it to handle larger IDs since it will change the fundamental structure of objects in our system but I can see it’s a change we’re going to have to make.

update: There is a new ESP32 based version of our controllers coming out in Oct2021 which has a lot more resources, we’ll add it to the todo list to make this larger

Maurice

image001.jpg

1 Like

Thank you Maurice. I would also like to ask if there is a way to specify a Bacnet property to read/write? By default, the T3 is using (85) Present Value, however the JCI devices have many parameters that only support writing to (104) Relinquish Default.

Here’s what we do have, I know we can do more so do let us know what features you’d like to see.

The T3 controllers as well as the T3E expansion modules support priority array and relinquish defaults for the outputs. This is explained more in the forum here:

And here’s a view of the priority array using T3000 → Tools → Bacnet Tool (Yabe). Currently the output is in auto mode and the program running on the thermostat is in charge of the output at priority 10. You will see the array change if you put the output into manual mode or move the switches on the controller if it has the override switches.
The relinquish default value is also there, the controller will set the output to this value if the dead master feature is in use. Currently the only way to get at the dead master feature is to write a modbus register,

ToBeDone: Expose the dead master setting to Bacnet
ToBeDone: Document the modbus register for the deadmaster feature

[08/2020 Update] You can see the priority array from the T3000 interface now by right clicking on a particular output, this is a ‘view only’ dialog.

You can write to the outputs from an external master and the devices will assume priority level 11 for network commands. This means the local program in the controller will have precedence over programs running on external masters. (Easier to debug systems this way). If you need an external program to be in total control then you can turn off the local programs or use the external master to write to a VAR and incorporate that into the local program.

We dont (yet) have priority array implemented on the other bacnet objects like AV/BV and AI/BI.

Let me know if you need more functions and we’ll get them into the TODO list.

I am mostly interested in third party integrations. I would like to use your T3 controllers and Nano router to for Modbus and Bacnet integrations with other devices. Consider the Bacnet protocol is much more complex than Modbus. With Bacnet you have multiple properties for each object type. Object Name, Description, Type, Units Relinquish Default and Present Value are all different Bacnet Properties that may read or written on fully complaint Bacnet controllers. Most of these are not important for general integration.

As it stands, the T3 devices read/write only the Bacnet Present Value property. There is no way to reference other properties, like Relinquish Default property. In the case of Johnson Controls, many of their data values, setpoints etc… do not use the Present Value property. They use Relinquish Default property. One reason for that is the controller will use the Relinquish Default value after a power loss, which is generally a good idea. It would be nice if we could specify the Bacnet Property in your Control Basic programming.

As for the Write Priority, that is a whole different subject. The Write Priority is only used when writing to the Present Value of certain types of Bacnet objects. It would be nice to specify that as well and it is also important.

My feeling is to use some keywords in your Control Basic code to specify these different attributes. Something like this. DEV = Device ID, OBJ = Object ID, PRP = Property ID, PRI = Write Priority. The string could look something like this:
“DEV 35 OBJ AV1 PRP 104 = VAR1” This would write the value of variable 1 into the Relinquish Default of Object AV1 on Device 35
Or something like this “DEV 35 OBJ AV1 PRP 85 PRI 8 = VAR1” This would write the value of variable 1 into Present Value of Object AV1 on Device 35 at Priority 8.

I realize this would probably be a big effort to work this into your code. You guys have a nice product, but it does fall short right now with Bacnet compliance. Adding this functionality along with supporting larger address values would make your product much more valuable in the industry.

I am definitely game to help out. please consider joining the GitHub developer crew. we can do some good things there.

Maurice Duteau

Hi Maurice, Any update on this. I am in the same situation. T3000 program is having trouble with the long Bacnet object ID. Eg AV165708. In the JCI FEC controllers you can set the Device ID but the Object ID’s are generated by the program and cannot be edited.

We’re on it. thanks.

Maurice Duteau

Our AV number is up to 65535 now.

Hi Chelsea,

I was not able to compile the larger address. I have T3000 version 1.2.0 and controller firmware 60.1. Also, should this change affect all Bacnet addressing? AI, AO, BI, BO, AV, BV, MV?

Thanks, Dan S

1 Like

Your example above has AV165708, its larger than our max of 65535.
All bacnet objects are supported up to this maximum value: AI, AO, BI, BO and so on.

The example you refer to is old, from last May. When I try right now with address AO 2114, it changes to AO 66 after compile.

T3000 version Mar 26 2021 . 15

Seems to be working here. I am using the latest T3000 and device firmware, the bacnet instance is 65535 and the program is compiling.

Yes, I see we may talking about something different. It looks like you have updated the instance ID where I am talking about the point address.
When I compile 7AV2047 and refresh the screen it works fine.
When I compile 7AV2048 and refresh the screen it changes to 7AV0
Anything larger then 2047 does not work.
I am using the latest T3000 with update 1.2 (Mar 26 2021 . 15 at top of screen)
Controller firmware update 60.1

I see what you mean, you have more than 2047 AVs on this device. Normally I’d get our team right on it but we are overwhelmed with a big porting project to get our products running on a new CPU. This chip shortage makes this chore top priority for the next while. Hopefully you have some workaround on your end to get the AVs down below 2047.

No worries. This is for integration to Johnson Controls. They generate Bacnet addresses automatically in their programming tool and cannot be changed. They are typically very large numbers where any custom program address starts at 10,000.

It sounds like your main issue is the limit to 65,000 or so for bacnet instances. We could have a look at bumping that up.

And your other issue is the limit of 2000 or so for bacnet AV’s, we can mark that down for a future upgrade as well.

Hope I got your meaning right.

I think this fits in here…?

I’m trying to integrate with two RTUs - JCI, FC-Bus / MSTP.
The instance numbers are too large to use I’m guessing. AV29764 (BACoid) is the type of numbers from JCI.

If anyone can help me with a work around for this, I would be grateful.
Thanks,

We’re using two bytes for the storage of AV’s so you should be good to go up to 64k AVs

Update: Also can add that the maximum instance number is 3FFFFF [Hex] which converts to a maximum Bacnet instance of over 4 million devices.

I must be doing something wrong. I’ll be working with JCI tech support today hopefully. I may need some assistance with the T3000 side of things. I’ll let you know what I find out.
Thanks!

Bret Burnett
Inside Passage Integrated Control Systems
Cell. (907) 957-1146
Email. Bret. Icsak@gmail.com