Hi,
We have been testing a T3E-32i / T3-32I as a BACnet/IP I/O module for integration with our control system, and overall the unit is working very well for our application. We have successfully tested the universal inputs with 0–5 V signals and are quite impressed by the number of supported input types.
During commissioning, however, we found a reproducible issue with the BACnet server after configuration changes.
Our unit:
- Product ID: 53
- Model: T3-32I
- Hardware version: 4
- Firmware: 7.0 (
T3_32AI_REV70.hex) - BACnet device instance: 247350
After a power cycle, the BACnet objects can be browsed normally. For example, analogValue.18, which represents RANGE1, reports normal string properties such as:
objectName = RANGE1RANGE1
description = RANGE1
If we then make a configuration change, for example changing IN1 from 4–20 mA to 0–5 V in T3000, the actual configuration is written correctly and works as expected. However, some BACnet CharacterString properties then become corrupted. For example, reads from AV18 have returned values such as:
objectName = <invalid character>
description = <control characters>T3-AI29
At this point our BACnet browser can also no longer reliably browse the Analog Value objects.
We initially suspected that this was related specifically to T3000. However, we can reproduce the same behaviour by changing an input objectName directly over BACnet. The name itself is written correctly and is persistent, but afterwards the Analog Value string metadata becomes corrupted in the running device.
A power cycle completely restores normal BACnet operation. Importantly, the configuration changes themselves are retained. For example, the selected 0–5 V range and a changed input objectName both remain after restart.
We have reproduced this behaviour with both firmware 6.9 and the current firmware 7.0.
Our current workaround is therefore:
After making configuration changes to the T3-32I, we power-cycle the unit before putting it into normal BACnet operation.
This works reliably for us, but it appears that some internal BACnet string/object data may not be correctly rebuilt after configuration writes until the unit is restarted.
Could you please check whether this is a known issue, or let us know if there is another recommended procedure after changing the configuration?
Apart from this issue, the T3-32I looks very useful for our application. We originally selected it primarily for voltage and current inputs, and were pleasantly surprised by the range of additional sensor/input types supported by the universal inputs.
Best regards,
David Fredriksson
DAVITOR AB