I’m trying to periodically read and write remote points over Bacnet MS/TP using the INTERVAL function and it’s not working as I anticipated. My program saves the remote points into global variables but the results are always zero with the periodic read. The one local point saves correctly. The program also tries writing a point on the T3-OEM but that doesn’t work either. It’s a simple network with T3-TB as device 3 with thermistor on IN1, Temco CO2 as device 4, and T3-OEM as device 5 with thermistor on IN1. I was also trying to read a 3rd party device on the network as #6 but I removed it and commented out the read as it was creating device tree issues in T3000. A Dtech RS485/USB converter is device 1, but I’ve also tried removing the Dtech and accessing the T3-TB through ethernet, as well as re-ordering the MS/TP device addresses with the same result. It’s all on a bench with short cables. I have no trouble reading and writing points with your built-in YABE or a current YABE so I don’t think there’s a communication issue. I started with 5 min interval and reduced to 20 sec for troubleshooting. If I remove the INTERVAL command and let the MS/TP reads/writes run continuously, then reasonable values appear in the global variables, but writes to the T3-OEM still don’t work. The other thing I note is that I can only read the Temco CO2 device with the instance expression - note that the CO2 reading using the proprietary 4IN3 does not work. I also examined the MS/TP data with Wireshark. The instance mode reads look OK and the IN reads are proprietary so I don’t know. The 5OUT7 and the 200032AO7 program statements seem to generate a MS/TP read so maybe my syntax is wrong I’ve pasted the two versions of the program and the global variables below. I put them in two different “programs” of the T3-TB and enabled one at a time. I note that I can enable the continuous program and it will populate the global variables (except for the CO2), the values remain if I disable both programs, but they go to zero once I enable the periodic program using the INTERVAL function. The network points display generally show values when running the continuous read program, but don’t show values when running the periodic read. Sometimes it doesn’t show all the points when running either program. The firmware for all devices is the latest as of a few day ago. Do you have any recommendations for periodic or one-time MS/TP reads and writes? This really needs to work, and also work with the 3rd party devices, if I’m to use the T3-TB.
Periodic
Continuous
Thanks for your lengthy report here. One thing to keep in mind is that the T3 controller will handle network updates automatically as a background task. The polling interval is not controlled by the program flow but rather by the network update task running behind the scenes.
I can see it would help to be able to control the network update rates, we’ll mark this down as a task for a future update.
Just for reference, line 110 could be written like this:
110 OUT1 = NOT OUT1
And line 130 could be:
130 5OUT7 = OUT1
I assume this program is running on panel5 because if this is running on controller number 1 for example, it cannot turn outputs of panel5 on and off. Only panel5 can turn its own outputs on and off.
Question 1: Using Interval to read remote points
First, I would like to explain our mechanism for reading/writing remote points. When the program code is running, all remote points are listed in a network point table. These points are polled sequentially in the background, so the reading and writing of all remote points are not real-time. Whether you use Interval or not does not affect the background read/write frequency.
Each point has a lifecycle, if the remote point is removed from your program it will eventually be removed from the network point task list. The housekeeping is done approximately every five minutes.
We can see that having program control over the network polling would be useful, we will add it to the task list for the not too distant future. Thank you for your feedback.
Question 2: 4IN3 cannot be used to read CO₂
Our company’s product architecture consists of controllers and devices. TB and OEM belong to the ‘controller class’, while CO₂ is a ‘sensor class’ type of device.
Only controllers can use INx as a keyword, so CO₂ cannot be read using IN3, but T3 and OEM can. When you set the protocol to Bacnet you will be able to use the bacnet objects on sensor class devices. You can use a program like:
10 VAR1 = 3333AI1 < where var1 is a local variable on the T3 controller.
<And 3333 is the bacnet device number.
Thank you both for your prompt answers.
Regarding Maurice’s reply, I was trying to write to an “analog output” of Panel 5 from Panel 3. I could do it from the Bacnet tool so I assumed I could do it from Control Basic. I will need to find another way to do that if I need to do so.
Thank you Chelsae for explaining how external Bacnet points are handled. I was able to read points more reliably after removing the Interval command. The MSTP/USB converter may also have been impacting MSTP communication between devices, as communication became more reliable once I removed the device and switched to the ethernet port on the T3-TB - but accessing the MS/TP devices through the T3-TB was less reliable.
I still cannot write to an AV point on either the 3rd party device or the T3-OEM from the T3-TB. Here is the syntax I used to write a constant 60 to the 3rd party device - instance#AVpoint# = 60. The Network Points display showed the actual value in the 3rd party device (not the 60 I intended to write) and Wireshark showed reads from that device, so I think the T3-TB was only reading the device. For writing to the T3-OEM I used the syntax panel#VARpoint# = 60 to write the AV, with similar results. I also tried writing a T3-TB global variable to the devices using similar syntax but that didn’t work either. Please advise on proper syntax to write to AVs in both 3rd party and Temco devices.
Lastly, the INT function does not seem to work. The original intent was for the T3-TB to read a temperature from the T3-OEM, save it, and write the integer portion to the 3rd party device, but I could not remove the fractional part of the temperature. Here is the statement I used: 50 D5TRND = INT ( D5TEM ) This also seems to be a problem on the T3-OEM as I tried the INT function on it also. I would have preferred a “round” function but there does not appear to be one in Control Basic.
Thanks.
It seems that the current MSTP function of TB is limited. We do have the default setting as limited, but the latest firmware rev67.5 has fixed this issue and will automatically change the MSTP function to full. Please update it.
INT function is fixed in rev67.5 too.
Thank you. I confirm the INT function is fixed.
MS/TP writes are enabled, but the write operation is unusual as described below and I don’t think it will meet my needs. Here is a simple test program similar to yours that writes an incrementing value to 3 points. Line 40 and 60 write points on the 3rd party device. Line 50 writes VAR1 of the T3-OEM which can be observed on the T3-OEM LCD.
- On Wireshark, I only see the last point in the program written, in this case 12345AV229. If you comment out that line, then 200032AV1 will be written and can be observed changing the T3-OEM LCD. Otherwise the LCD will not change. Unfortunately, if you comment out both Line 50 and Line 60, point 12345AV1200 will not be written. I suspect this has something to do with the point number > 255 but not sure. I did verify that I can read point numbers > 255 from the 3rd party device.
- A point is only written when the value changes, so I don’t see a way to periodically refresh a point with the same value. This may be necessary on devices that have a failsafe timeout and have to be periodically refreshed. Do you have any thoughts on how to do this as my point 1200 seems to require refresh every 2 min and I have another device that requires refresh every 15 min.
- This program does not read any points, but all 3 points are read rather often even if the value has not changed. On Wireshark, I see several reads between writes with the 5 second timer interval. This seems to be generating a lot of unnecessary MS/TP traffic.
- Values displayed on the Network Point display are inconsistent. Usually it displays the value read back from the devices, but occasionally seems to show the just-written value. Below item 3 is being written and the value increments. Item 2 is not actually being written and usually displays the value read back, 14 in this case, but occasionally it will momentarily display the same value as item 3. I’ve never seen item 1 display anything but the value read back.
Lastly, I note two items in the firmware release notes that may be of interest. Item 3 in the Rev67.5 release notes mentions changing the default READ_POINT_TIMER. Is this a parameter I could change to reduce the read rate and therefore network traffic.
Item 2 in the rev67.4 release notes mentions adding bacnet COV. Is this feature explained somewhere?
Thanks.
-
Investigate point number handling.
Indeed there is an upper limit to the point numbers, this is due to rom & ram limitations on our devices. Its currently fixed at runtime at 128 points i believe. We’re working on making it dynamically allocated so if you’re not using a lot of inputs you can use more vars for example.
-
Suggest periodic writes for refresh.
We could add some features but we’re quite backed up. If you are able to help out you can check out the source code here:
GitHub - temcocontrols/T3-programmable-controller-on-ESP32
-
Provide instructions for adjusting READ_POINT_TIMER.
Its not an adjustable feature at the monent, we could work on it but again things are quite backed up here. If anyoune out there is able to help out please PM me and we can work something out.
- Share resources on BACnet COV.
We will write it up ASAP. We tested it using the T3000 → tools → bacnet tool which assumes very standard bacnet functions. You can test it out using the tool and the details will be clear.
If I missed something in your post you can let me know. Replying from my phone just now so its not so easy to see teh big picture.
For the write operation of the REMOTE MSTP point, we are trying our best to achieve real-time processing. If several write commands are executed consecutively, there is a high possibility of write failures. If you add a delay before each write operation, it should basically be possible to avoid such failures.
You don’t need to worry about failing the first time you write. If the values read from the “remote point” are inconsistent, we will rewrite them.
Thank you both for your responses.
I posted an inquiry about the maximum Bacnet point values some time ago and it was my impression that my use case would not be a problem. Based on my testing, it appears the higher point numbers are OK for reads but not for writes.
I will play around with delays as suggested above, but it was my impression that Control Basic didn’t do any I/O processing until execution reached the end of the program and then all the I/O was updated, so delays in the middle of the program didn’t actually create delays between the actions implemented in those program statements. I was thinking I would have to implement a state machine to create delays between writes like you have above. I actually have another use case that requires delays between steps, so have been thinking about how to do it.
The concerns I mentioned limit my ability to use the T3-TB in my intended application. Not sure how usable they will be for this project - may still be usable for data logging.
FYI, I noticed the T3-OEM had the same INT and Bacnet issues. I also found I could define and use arrays, but the array definitions did not survive power cycles.
Thanks.
For T3-OEM, you also need to update the latest firmware to solve the problem with the INT function.
Regarding the ARRAY you mentioned, could you provide me with some screenshots so that I can understand the issue you are describing?
