TcHmi中PLC变量绑定：JS实现与直接绑定哪种方案更优？

TcHmi PLC变量数据绑定方案选型建议 #

以下是两种方案的实际使用对比和选型参考：

方案1：单User Control + JS动态修改绑定 #

• 优势：
  • 控件复用率极高，仅需维护1份控件逻辑，后续调整控件样式、参数校验规则、交互逻辑时仅需修改1次，不会出现多份控件配置不一致的问题
  • HMI运行时内存占用更低，无需同时实例化多份控件对象，下拉框选项越多时优势越明显
  • 扩展性更强，后续下拉框新增选项时，仅需补充PLC变量的映射逻辑，不需要重新创建控件、配置绑定
• 劣势：
  • 存在少量JS代码维护成本，需要熟悉TcHmi的绑定API，修改绑定时要注意旧绑定的资源释放，避免出现变量订阅残留、内存泄漏的问题
  • 绑定逻辑无可视化展示，后续不熟悉代码逻辑的维护人员排查绑定问题的成本更高
  • 不支持TcHmi原生的设计期绑定校验，若写错PLC变量名，仅能在运行时报错，设计阶段不会有提示

方案2：多User Control + 原生静态绑定 #

• 优势：
  • 所有绑定均为可视化配置，无额外代码开发，后续维护人员不需要掌握JS也能修改配置、排查问题
  • 支持TcHmi原生的设计期绑定校验，变量名写错、数据类型不匹配的问题在设计阶段就能发现，不会带到运行环境
  • 稳定性更高，不需要处理动态绑定的资源释放、订阅失效等边缘场景，运行时出问题的概率极低
• 劣势：
  • 维护成本高，后续调整控件样式、逻辑时需要同步修改所有对应版本的控件，很容易出现漏改导致的功能不一致问题
  • 运行时资源占用更高，多份控件实例会占用更多内存，下拉框选项越多资源占用问题越突出
  • 扩展性差，后续新增下拉选项就要重新创建控件、配置绑定，工作量远高于方案1

最终选型参考 #

优先选方案1的场景：

• 项目后续有扩展下拉选项的规划
• 控件的样式、交互逻辑大概率会迭代调整
• 项目维护团队熟悉TcHmi JS API，有配套的代码规范和注释要求

优先选方案2的场景：

• 控件和绑定逻辑基本不会再变更，后续长期不需要迭代
• 维护团队以自动化工程师为主，不熟悉前端/JS开发
• 对运行稳定性要求极高，不能接受动态绑定可能带来的异常风险

补充优化思路：如果想结合两者优势，可以在单控件基础上把10个参数做成控件的对外暴露属性，用原生绑定把5组PLC变量全部绑定到控件属性上，下拉切换时仅做参数显示切换，不需要动态修改绑定，既不用开发复杂的动态绑定逻辑，也不需要维护多份控件。

内容的提问来源于stack exchange，提问作者Kumaraswamy Gaviyappa