> cRIO-9066 板载 232 口下挂一台 485 转 232 转换器和四台 PLC，两线 Modbus 跑了几周都正常，某天回来所有 Read Holding Registers 都报 -1073807254（VISA Hex 0xBFFF006A，传输中发生奇偶校验错）。最后查明是其中一台 PLC 故障、往总线上乱发数据，把它摘掉就恢复。

![](https://developer.qcloudimg.com/http-save/yehe-12787172/568124e0fa49b4b115ce5308af4d7707.jpg)

*TestMain.vi 程序框图：左侧超时与待发数据输入，中间 Modbus 主站读写循环，右侧汇聚到 error out*

## 01 现象

系统架构是这样：四台 PLC 分布在不同位置，用两线 Modbus 485 菊花链接到一台 DTech 485 转 232 转换器，转换器插在 cRIO-9066 机箱自带的 232 口上。机箱上还挂着几块 cDAQ 模拟输出、数字输出模块。整机运行在扫描模式（scan engine）下，程序是 LabVIEW 2015 写的，用数据通信 VI：Create Modbus Master 和 Read Holding Registers。

这个系统稳定跑了几周，各台 PLC 都能访问、读数也正确。周一还好，隔了两天回到现场，每次 Read Holding Registers 都报错：

Error -1073807254 occurred at Property Node (arg 1) in SubVIs.lvlib:RTU Data Unit.lvclass:Read ADU Packet.vi:5030001->Modbus Master.lvclass:Read Holding Registers.vi:2420001->TestMain.vi  
VISA: (Hex 0xBFFF006A) A parity error occurred during transfer.

有时候这个错误出现在建主站实例时，路径不同、错误码一样：  
...Configure Serial Port.vi->...Initialize Master.vi->...Initialize.vi->...Create Master Instance (Serial).vi->TestMain.vi，同样是 0xBFFF006A。

现场已经排掉的部分：串口参数在 PLC 侧和 cRIO 侧都确认过是 RTU、38400、1、Odd、None；改动这些参数、或者从转换器上拔掉一根线，LabVIEW 会给出预期的错误提示，说明参数是被真正用上的。PC 通过 USB 还能连上 cRIO，模拟模块受 LabVIEW 命令控制也正常；从 PLC 到转换器这一段确认是通的，转换器也换了新的；程序从周一之后没改过，cRIO 复位、重装软件都没有效果。

## 02 根因

最后确认的原因在总线上，不在 cRIO 这一侧：其中一台 PLC 出了故障，往网络上乱发随机数据，把通信搅乱了。把这台 PLC 从系统里摘掉之后，问题消失。

作者也保留了一点不确定：他并不清楚为什么这个干扰只影响了 cRIO，而用 PC 做的其他 Modbus 通信尝试没有受影响。这一点原样保留，不要去把它解释圆。

回到错误码本身，-1073807254 对应的是 VISA 的 Hex 0xBFFF006A —— 传输过程中发生奇偶校验错。校验错是物理层/报文层的信号，所以当串口参数没变、接线没动、程序也没改却突然全网报这个码时，要把"总线上多了一台乱发数据的从站"作为候选原因列进来，而不是先怀疑代码。

## 03 怎么做

1.  先走常规项：核对串口参数（本例是 RTU、38400、1、Odd、None），确认接线与转换器。本例这些都没问题、转换器还换过新的，说明常规项可以排除，注意力应转到总线上。
2.  用报错位置做区分：错误落在 Read Holding Registers（读数据的阶段），还是落在 Create Master Instance / Configure Serial Port（初始化的阶段）。初始化阶段就报校验错，说明总线上已经有干扰数据，而不是读请求本身有问题；这两种路径在 TestMain.vi 里最后都汇到同一个 error out，看路径最后一跳是谁就能分辨。
3.  逐台断开 PLC。这类"参数没改、程序没改，却突然全报错"的情况，一台一台摘下来看错误是否消失，是最快的定位办法；本例就是这样做找到那台故障 PLC 的。
4.  摘掉之后做回归验证：Read Holding Registers 恢复正常、模拟模块照常、错误簇里不再出现 0xBFFF006A。
5.  把结论记下来：这条总线上任何一台设备的异常都会影响整条链路，排查时不要把范围锁在 cRIO 和程序上。

## 04 记住这几条

-   0xBFFF006A 是传输中的奇偶校验错，先看物理层和总线，不要一上来改程序。
-   参数没变、程序没改却突然全错，优先怀疑总线上多了一台乱发数据的设备。
-   单独确认某一段通信正常，不代表整条总线挂满设备后没问题。
-   本例已确认摘掉故障 PLC 后恢复正常；至于为什么只影响 cRIO，作者没有定论，这一点保持原样。

我们专注 LabVIEW 软件开发与测试测量系统集成，从硬件选型、方案设计到现场交付调试，提供一站式服务。手上有一台设备想接进 LabVIEW，或者几台设备要串成一套系统，欢迎在评论区留言；身边朋友有类似项目，也欢迎帮忙引荐。

cRIO-9066 板载 232 口下挂一台 485 转 232 转换器和四台 PLC，两线 Modbus 跑了几周都正常，某天回来所有 Read Holding Registers 都报 -1073807254（VISA Hex 0xBFFF006A，传输中发生奇偶校验错）。最后查明是其中一台 PLC 故障、往总线上乱发数据，把它摘掉就恢复。

cRIO-9066 串口报 -1073807254

硬件

编程语言

开发工具

cRIO-9066板载232口连接四台PLC，Modbus通信几周后突发-1073807254奇偶校验错，经排查为其中一台PLC故障乱发数据干扰总线，摘除后恢复。该错误需关注总线设备异常，而非代码问题。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

cRIO-9066 串口报 -1073807254-腾讯云开发者社区-腾讯云

cRIO-9066 串口报 -1073807254

cRIO-9066 串口报 -1073807254

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐