In the settings field - what I see when I change the device ID: ‘are you sure you want to change the mod-bus ID’? My questions are:
1- Is this field only used for Mod-bus?
2- When on a network with multiple T3s, do the ID #s need to be unique?
3- Does Bacnet care about this ID#? My guess is no.
4- Is there a ‘best practice’ for this ID field?
The reason I dug into it is because I have a site where the BVs stopped working and yet YABE shows that the Bacnet points are working. I was using the device address (ie. 13BV20, 14BV20, etc…) which used to work just fine for all 8 controllers on the network. So, I changed to using instance #s and I got all but 2 points to work (one BV per panel). The analog points still transfer using the device address: 13AV4, 14AV4, etc…
I have updated all software/firmware for said devices.
I browsed the help docs but didn’t see the Device ID explained, however, I may have missed a reference to it when reading through the help docs.
I look forward to Maurice’s answer. In previous emails to me he’s recommended the latest way to share points over Bacnet / Ethernet using this structure…
Controller ID and input, output or Var for example our Chiller T3 (ID#2) grabs input 4 from the CoolingTower T3 (ID#3) like this 3IN4. This has been the most reliable method. If so, then logically, each ID would need to be unique. No unique bacnet number is needed. Hope this helps. Meanwhile, I bet Maurice will add his expertise to this thread in the next 12 hours.
I will be traveling for the next few days and can reply in more detail when I get settled.
The ID is used for the modbus network ID and its also used for the bacnet equivalent which is referred to as the ‘MAC ID’'. They are the same thing in our environment.
The simplest way to refer to items in the t3 environment is to use this ID. Some examples would be 1OUT10, 2VAR3 and so on.
If you have subnets in your system then you’ll refer to points like 1.2OUT10 , 2.3VAR20 and so on.
You can also refer to these same things using bacnet instance numbers and the bacnet object ID: 1234AV1 , 445566BO2 and so on. This is slightly more complex because the io can be configured as binary or analog which will shuffle the numbering around depending on the rrange setting
There is an example for all the various types of ‘network programming’ and referencing in the forum with more details.
Thanks Maurice!
I understand you’re traveling so no hurry with answers.
In the forum I read a comment by Chelsea regarding Bacnet using an ID# for T3 to T3 transfers so it peaked my curiosity. I will look through the examples some more since it sounds like I missed answers that have already been given?. I am versed with the addressing schemes but am ignorant regarding how the ID comes into play. All of the IDs were set to 1 and they worked. Now they don’t work so I figured something changed in an update? I gave each controller a unique ID# but that didn’t seem to help.
I’m done hacking until I get a better idea of what happened and why. But I gave it the old college try…
That is how I was doing it too: 13BV20 and had great success. The analog AV points still come through but the BV points stopped. I used instance #s and got most of them to work but not all. Sounds like I have something else going on causing me a new challenge.
Thanks for touching base…
For clarification - I was using the controller panel # and not the Device ID. Do you use the Device ID or controller Panel #?
I suggest only using the bacnet instance number if you’re integrating with 3rd party equipment. Using the ‘intrinsic’ T3000 objects is slightly easier: 1OUT1 instead of 3212BO1. The 1OUT1 will replaced by the user name such as AHU1FAN after you send the program or trend log, etc. The bacnet 3212BO1 will stay as this rather cryptic reference which you will need to remember to make any sense of later.
I haven’t integrated with 3rd party gear at this point but will be in the future - I will use instance numbers for that.
I am transferring from T3000 to T3000 using the ‘intrinsic’ objects (1AV20, 1BV4) and the BV points stopped transferring. I switched from using the ‘intrinsic’ object and used the instance numbers to see what would happen…the BV points transferred fine except for one BV from one panel. The AV points transfer just fine using the ‘intrinsic’ AV objects ~ 1AV20 - I’m transferring analog and digital variables so am using AV and BV.
Anyway, the analog points transfer great and the binary points used to transfer great also, but the binary points stopped transferring.
I may have a network problem that has reared its ugly head and was just looking to see if I was doing things correctly…I now know I’m doing things correctly so that is a big help to me.
Actually Intrinsic would refer to 1IN1, 2OUT2, 3VAR3. These are ‘Temco’ specific, proprietary type objects. These use the ‘panel ID’ setting to refer to a particular controller. This method is easier because T3000 will replace the 1IN1 with the short 8 character label, say “AHU1SAT” for example which is more intuitive when reading programs, looking at trend logs and so on.
Then there’s the Bacnet objects which you describe, 1AV20, 1BV4 and so on. These are native bacnet objects and use the instance number to refer to a particular controller.
Have a look at the network points, its one of the icons up at the top right of the menu system. There you’ll see all the network points coming in to a particular controller. If any point from another controller is used in a program, placed on a display or trend logged the system will automatically make a list of all these external network points and poll them periodically. You can see the status of all the network points in this list.
I see, so I was using the Bacnet objects AV and BV. I should have just used VAR as in 1VAR20, 2VAR4, etc… I definitely misunderstood how to do the Intrinsic variables.
I will give that a try - Thanks again for your support.
Bret
