rs485_MODBUS通讯探讨
有项目,单片机做的工控板是上位机(原来是进口PLC)工业采集用,rs485外接35个站号从机,MODBUS-RTU通讯.从机是温度/ 转速/湿度/产量等等机器设备的传感器采集系统,和上位机通讯一帧数据多达200个字节.19200波特率 , 上位机和最末端从机通讯导线长度在60米之内.现在,上位机采集一个循环(35个站号)通讯需要10-12s左右.造成故障不能及时反馈的情况,客户设备升级之后不认可这套系统 要求升级 通讯响应时间最好控制在5s-7s左右.
由于现场波特率不能再提高,通讯数据也不能少; 主管提出使用CAN通讯解决,以往项目没有接触过can通讯;软件硬件重新进行一般几天可以解决,
关键是: 通讯数据不能减少情况下 使用CAN能不能优化通讯延迟时间呢.有经验坛友指点指点.{:handshake:}
我不知道,不过你何不买一套CAN 收发模块 测试一下.
数据能不能压缩呢?比如温度只用了10位,剩下6位可以给别的数据用.收到后再解析出来.
两路485一路收，一路发，收发可以重叠 200多个字节19200波特率需要100多毫秒，算上请求帧和应答延时应该不超过150毫秒，35*150ms=5.25s,可见上位机还有很大优化空间 最简单的还是提高波特率 既然有上位机，还是用以太网吧，何必用CAN呢 35个从节点，每个节点都需要200字节吗
如果现场条件允许，最简单的方案是使用多个主站端口轮询，将从站挂到2~3条总线上即可快速提高轮询速度 网上不是有卖 modbus服务器的 或是 modbus 转modbus TCP？ 从机 接一个 模块。 然后网线汇总到上位机 。是不是通讯速度能加快？ 4楼说的得对，你主站或者从站程序没有处理好。按你的要求数据传输时间完全是够的。你这个典型的软件没处理好坑硬件啊。 我觉得也是提高波特率，19200太慢了，起步应该是115200，这就快了6倍了 回复各位亲，因现场干扰厉害，波特率19.2k是上限了，再高上去～误码率受不了。
上位机是和其他公司合作配套产品，硬件上串口rs485仅仅只能使用一个，再说，传感器现场也不可能重新引出通讯线再接一个串口。
35*150ms=5.25s是理想情况，其实，工控现场干扰信号复杂，一帧数据通讯失败二次不稀奇。
现在就是考虑，如果更换为can通讯（上位机软件已经同意），能不能优化通讯时间。 提高波特率，传输改用光纤。 lb0857 发表于 2020-10-3 19:22
回复各位亲，因现场干扰厉害，波特率19.2k是上限了，再高上去～误码率受不了。
上位机是和其他公司合作配套 ...
你觉得用485解决不了干扰而用CAN就能解决了？60米的距离115200和19200抗干扰没什么差别，除非你的硬件设计有问题，难道又是用的那种准485电路 lb0857 发表于 2020-10-3 19:22
回复各位亲，因现场干扰厉害，波特率19.2k是上限了，再高上去～误码率受不了。
上位机是和其他公司合作配套 ...
你原来19.2k，用can的话250k总是要的吧，肯定快多了 你这个其实可以改下任务优先级，比如每秒轮训一遍每个站的报警，这些优先级高。优先级低的可以拉长时间 转发器，多个485对从机（从机分组），数据汇总后直接面向上位机。 楼主需要一个对等协议，来优先处理报警信息。 can数据处理麻烦，一帧只有8字节，485改善后效率还是不错的，这点距离可以泡57600bps看看 建议你总线上挂个485抓包的设备看看时间消耗在什么地方了，八成是你的 从机响应速度慢导致的。就算是有干扰某些数据需要重传，也不可能一直有干扰吧，如果这样你要考虑提高硬件的性能了。 有干扰要解决干扰的问题，比如用双绞屏蔽线啥的，否则换成can一样没用。 谢谢各位亲，通讯线是双绞带屏蔽线，不过手拉手的接线方式，中间增加不少接插件，带来损耗不少，综合大家建议，提高波特率看法居多，你们做工控产品，60米通讯传输线，波特率实际用到产品上面的有多高，工控现场，或者石油行业。 erxun 发表于 2020-10-3 21:02
转发器，多个485对从机（从机分组），数据汇总后直接面向上位机。
现在产品，基本上都是价格上面大家进行肉搏战，现有基础上多增加几块钱都很难。
改can通讯，项目上报时候，话题多一些。说服老总概率大一些吧。 kitten 发表于 2020-10-3 22:34
建议你总线上挂个485抓包的设备看看时间消耗在什么地方了，八成是你的 从机响应速度慢导致的。就算是有干扰 ...
从机采集处理等等，是花销不少时间呢。以前老一代留下来的东东，大家都不像接手，不如趁此机会全盘推翻，重新来过。 lb0857 发表于 2020-10-3 23:53
从机采集处理等等，是花销不少时间呢。以前老一代留下来的东东，大家都不像接手，不如趁此机会全盘推翻， ...
楼主只是想评估一下换Can后能不能达到5--7秒的要求，不想升级现在的485，哈哈 tianbianren 发表于 2020-10-5 00:47
楼主只是想评估一下换Can后能不能达到5--7秒的要求，不想升级现在的485，哈哈 ...
{:tongue:}老大下指令是要更换滴 咋们电工只是服从而已 CAN的传输效率并不高，抗干扰能力并不比485总线高，只是多主机抢占式优先级而已，要想解决楼主的问题，并不见得有效。
现场远距离波特率不是那样容易提高的，我们都是采用串口服务器，多个串口并列运行，每个串口少接几个装置达到提高响应速度的目的。 提高485硬件性能
正常485电路做快瞬都不应该有误码或丢包 用CAN了,为什么还非要轮询,直接定时发不就行了. yuguoliang 发表于 2020-10-5 11:00
CAN的传输效率并不高，抗干扰能力并不比485总线高，只是多主机抢占式优先级而已，要想解决楼主的问题，并不 ...
大实话,工业现场的干扰不经历过的朋友 不晓得现场排查故障的难度系数;大多数情况下还是忽隐忽现的故障;对方机器接地不好 布线不合格等等 而且某些人为因素 对方不配合找到干扰源也不能去解决只能自己这里采取措施 如果19200的RS485都能经常受干扰而误码，那么至少250K的CAN，能不受干扰？
支持4楼说的，不超过5秒就能轮询完毕，还是每机200字节返回的情况。485通信不会经常出现误码的，一般到1%你就要重新审视你的产品或施工问题了。近25年来我一直用MODBUS，有经验。 多串口，每个串口分几个负载，这样行不行？ 自己定义协议吧，看一下canopen的pdo数据收发，从机主动发送数据，不要再采取一问一答的方式，如果每个从机的数据都是一样的，可以把帧定义成一帧数据包含所有采集的数据，不要分几个帧，最多再加一个简单的同步帧，这样估计能至少省下一半的时间，不要用can了，波特率又不能提高，然后can通讯是多了帧头，估计时间还不如我说的做法，然后还要换硬件 lb0857 发表于 2020-10-3 23:53
从机采集处理等等，是花销不少时间呢。以前老一代留下来的东东，大家都不像接手，不如趁此机会全盘推翻， ...
明显从机机制有问题，从机应该一直处于采集处理状态，当主机发命令读取数据的时候，从机应该立即将上一次的数据给到主机，而不是主机读取之后，从机才开始采集处理。你这个问题跟485和can没半点关系的。 19200的速度没有跑满, 就别谈什么别人要求高了, 3.5秒一个循环是极限速度, 你慢了三倍, 用个逻辑分析看看问题出在哪个地方吧 can的差分电平比485低的多,怎么会觉得抗干扰更好?实际情况是上can的地方很多都为了伺候通信额外准备了更好的电磁环境,从而使can的速率能跑的更高.
至于说485跑不快的,Profibus了解一下,甚至最便宜的PPI在实际现场上很多都是跑187.5K的最高速率的.我这里说的起码是现场跨柜通信,can总线我自己接触的少,见过的几个都是用在PLC挂伺服的场合,都是同一个电气柜的场景.
不过这两年几乎都是以太网了,插上就用不太需要考虑干扰,多的出的硬件成本和现场实施的时间成本相比根本不算啥~
所以定论是这样的:同等电磁环境下,CAN不具备更高的抗干扰性能,希望用CAN的容错性能得到更高的通信效率也是不现实的(你算一下一个can帧的负载效率).
还是从改善现场的通信质量入手吧. 谢谢各位 不吝点评 讲解,大都是经验之谈收下啦{:handshake:} 4楼的估算完全合情合理，你们的上位机和从机在通信上根本没有好好利用协议规约，很多时间浪费了，却要额外投入更复杂的硬件。
这次如果改了CAN，那以后RS485-MODBUS-RTU在你们公司的名气就是被彻底被你们的码农搞臭了{:titter:}，太冤枉了 嘻嘻楼上项目和国营性质石油行业研究所合作的话他们的上位机无论如何都是完全正确{:tongue:} 现在我们也有类似的需求，也是工业的。直接上光纤，波特率高，也不怕干扰。最好工程布线的时候多预留一组，怕施工或者后面有损坏 lb0857 发表于 2020-10-3 23:48
谢谢各位亲，通讯线是双绞带屏蔽线，不过手拉手的接线方式，中间增加不少接插件，带来损耗不少，综合大家建 ...
工业自控的话，很多都是9600，因为现场有很多不确定的因数，比如线和380V一块走这种。 cingljlw 发表于 2020-10-9 00:27
现在我们也有类似的需求，也是工业的。直接上光纤，波特率高，也不怕干扰。最好工程布线的时候多预留一组， ...
思路很好哦光纤收发器是哪家公司的 ilikemcu 发表于 2020-10-6 12:35
4楼的估算完全合情合理，你们的上位机和从机在通信上根本没有好好利用协议规约，很多时间浪费了，却要额外 ...
也不一定是楼主的问题。
你可能没见过有些很烂的仪表响应速度非常慢的。那种情况下没别的办法，除了拆成多条485，各管一部分从机。
换can更不可能，那些从机仪表，你能买到用can通迅的吗？
除非自己做全套，主从机都自己做了，那你爱用啥都行。
正确设计的从机，可以在收到命令后几毫秒就应答，直接按理论速率算就行。但是也有很多笨人做的从机，响应非常慢的。 楼上 同道中人{:handshake:} redroof 发表于 2020-10-9 13:14
也不一定是楼主的问题。
你可能没见过有些很烂的仪表响应速度非常慢的。那种情况下没别的办法，除了拆成 ...
我做的从机RS485模块，早期刚弄的时候，因为应答太积极，最终因为主机发完数据，还没有把总线切换到接收状态，我这边从机就已经开始回传数据了......................大量客户投诉：（
最后在指令系统里专门加了一条延时参数设置，让用户自己折腾去，没办法有客户需要越快越好，有需要慢点的，众口难调，实际现在的从机响应可以快到波士的RS232转RS485都来不及切换，导致时不时回传的数据帧头被切掉一部分，特别增加了固定的延时，要不然硬件这关都过不去....................
有时候，高效也是一种罪：（ 本帖最后由 dukelec 于 2020-10-9 17:55 编辑
ilikemcu 发表于 2020-10-9 17:43
我做的从机RS485模块，早期刚弄的时候，因为应答太积极，最终因为主机发完数据，还没有把总线切换到接收 ...
回的太快的確可能是不規範的做法。。。
譬如 Modbus RTU 規定的是 3.5 字節長度的間隔，不能小於此時間長度。
你當時是多快？ dukelec 发表于 2020-10-9 17:51
會的太快的確可能是不規範的做法。。。
譬如 Modbus RTU 規定的是 3.5 字節長度的間隔，不能小於此時間長 ...
如果是MODBUS-RTU，我当然会遵守规约操作，3.5T的时间，我时间会略微增加点，在3.6-3.8Z之间，就是被这个太快响应搞怕了。但是我的系统还有一套自定义的ASCII协议，有固定的帧尾识别字节，和自己的上位机通信没事，但是客户的上位机千奇百怪啥都有，后面加了延时参数，就不怕了，反正配了PC端的配置小软件，用户随意调，10mS延时也没啥，只要自己不嫌慢。 ilikemcu 发表于 2020-10-9 17:55
如果是MODBUS-RTU，我当然会遵守规约操作，3.5T的时间，我时间会略微增加点，在3.6-3.8Z之间，就是被这个 ...
完整的Modbus主机和从机都应该有通讯延时的。不只是从机，主机也需要。
我们遇到过如果主机飞快的不停的读，从机就只顾通讯没空干别的了{:titter:} 。所以后来在主机里面也加了通讯延时 9600是不是也太低了，RS485在灯具协议里250K 码率都玩了几十年了，视频图像都按样播放；还有监控视频用的RS485； ilikemcu 发表于 2020-10-9 17:43
我做的从机RS485模块，早期刚弄的时候，因为应答太积极，最终因为主机发完数据，还没有把总线切换到接收 ...
所以说ModbusRTU还是挺适合RS485的，只要双方都严格遵守协议，就不用担心总线切换时间问题，以前经常买的RS232转485模块在ModbusRTU协议上跑的好好的，换到其他协议上就不稳定了 本帖最后由 dukelec 于 2020-10-10 00:33 编辑
modbus 发表于 2020-10-9 23:18
所以说ModbusRTU还是挺适合RS485的，只要双方都严格遵守协议，就不用担心总线切换时间问题，以前经常买的 ...
剛又看了一下 modbus rtu，感覺能做到遵守協議的幾乎沒有。。。
一個包內部的兩個字節之間時間超過 T1_5 必須丟棄，總線上的兩個包之間的間距要大於 T3_5.
很少理會 T1_5，一直用 8N1 的 10 bit 格式，而不是協議要求的 11 bit，且計算方式竟然是：
if (baud > 19200 bps) {
T1_5 = 750 us;
T3_5 = 1750 us;
} else {
T1_5 = 1 / baud * 11 * 1.5 s;
T3_5 = 1 / baud * 11 * 3.5 s;
}
Modbus RTU use 11-bit char, regardless using parity or not. The formula should be : 11 * 1000000 / ( baud_rate ) for one char time, this applies for baud rate <= 19200 bps.
For baud rate > 19200 bps, fixed time is used, which are 1750 micro seconds for 3.5 char time, and 750 micro seconds for 1.5 char time
來自：
https://stackoverflow.com/questions/20740012/calculating-modbus-rtu-3-5-character-time
https://modbus.org/docs/Modbus_over_serial_line_V1_02.pdf
要遵守協議的話，效率就太低了：
115200 每個 T3_5 要浪費 8N1 格式的 20.16 個字節長度。 0.00175÷(1÷115200×10)
921600 每個 T3_5 要浪費 8N1 格式的 161.28 個字節長度。
10 Mbps 每個 T3_5 要浪費 8N1 格式的 1750 個字節長度。
50 Mbps 每個 T3_5 要浪費 8N1 格式的 8750 個字節長度。 本帖最后由 makesoft 于 2020-10-10 06:13 编辑
redroof 发表于 2020-10-9 13:14
也不一定是楼主的问题。
你可能没见过有些很烂的仪表响应速度非常慢的。那种情况下没别的办法，除了拆成 ...
是啊，很多仪表设计做的很差，看过有几百个MS没有响应的{:lol:} 。我们的设备要求像这种是有包头包尾的二个字节延时内一定要回复，不过确实也不符合3.5T的要求。 若是普通的收发器，35个从机很吃力的 lb0857 发表于 2020-10-3 19:22
回复各位亲，因现场干扰厉害，波特率19.2k是上限了，再高上去～误码率受不了。
上位机是和其他公司合作配套 ...
can的话软件要重写了，can都是短帧改造比较麻烦，还不如用modbus-tcp lb0857 发表于 2020-10-3 23:53
从机采集处理等等，是花销不少时间呢。以前老一代留下来的东东，大家都不像接手，不如趁此机会全盘推翻， ...
原来如此，那是要好好规划一下了 dukelec 发表于 2020-10-10 00:15
剛又看了一下 modbus rtu，感覺能做到遵守協議的幾乎沒有。。。
一個包內部的兩個字節之間時間超過 T1_5 ...
当年定协议的人肯定没考虑到你用那么高的波特率啊。
规定高波特率的间隔1.75ms对于通常的软件实现的串口通信已经非常短了。更短的间隔基本上没法用纯软件做到
你用硬件做超高波特率就加个选项不按标准做呗，反正这种超高波特率基本上就是跟你自己的硬件对接了，随便你怎么定都行。
redroof 发表于 2020-10-10 09:44
当年定协议的人肯定没考虑到你用那么高的波特率啊。
规定高波特率的间隔1.75ms对于通常的软件实现的串口 ...
其实纯硬件的情况下还可以更夸张，可以规定整个数据帧都不准误差超过一个bit。比如西门子MPI/Profibus在高波特率下面的规定。
这样可以简化一点硬件，同时保证难住很多第三方的纯软件实现，以提高自己的价值{:titter:} 本帖最后由 dukelec 于 2020-10-10 10:28 编辑
redroof 发表于 2020-10-10 09:47
其实纯硬件的情况下还可以更夸张，可以规定整个数据帧都不准误差超过一个bit。比如西门子MPI/Profibus在 ...
話說 115200 不高吧，一般一個包也才 10 個字節不到，每傳一個包就要等 20 多字節。。。
比 115200 再高點的用的也很多，所以 460800 和 921600 也是非常常用的。（有時用整數版本，分別是 500kbps 和 1Mbps。）
我的 linux 板子默認調試用的串口速率是 3Mbps，純軟件的，為了啟動速度更快（開機打印多）。
純軟件用過最快的是 FT232H 的 12Mbps。 dukelec 发表于 2020-10-10 10:24
話說 115200 不高吧，一般一個包也才 10 個字節不到，每傳一個包就要等 20 多字節。。。
比 115200 再高 ...
在Modbus出生那年代115200都算很高了，若按3.5T的话很多CPU都实现不了，现在的CPU，921600照样能实现3.5T标准 dukelec 发表于 2020-10-10 00:15
剛又看了一下 modbus rtu，感覺能做到遵守協議的幾乎沒有。。。
一個包內部的兩個字節之間時間超過 T1_5 ...
只要能严格做到字节间隔发送不超过1.5T，接收只考虑3.5T就很稳定了 本帖最后由 dukelec 于 2020-10-10 12:44 编辑
modbus 发表于 2020-10-10 10:48
只要能严格做到字节间隔发送不超过1.5T，接收只考虑3.5T就很稳定了
反了吧，1.5T 其實是接收超時，接收時用來分包，超過 1.5T 就認為當前包接收完畢，後續數據當下一個包，哪怕小於 3.5T 也要能正確接收所有包。
3.5T 是針對發送者，因為 3.5T 比 1.5T 大，所以才能確保接收方能拆開兩個包，哪怕雙方時鐘有誤差。
如果接收和發送都是 xT，只要時間有一點點偏差，就會導致粘包，譬如都是 3.5T，實際發送者的時間是 3.499T，接收者的實際時間是 3.501T，就会導致接收者不能正確分包，把 2 個包當成一個包。
（所以二個包相隔在 1.5T 和 3.5T 之間也應該都被正確接收。）
而且 modbus 協議正在接收的時候不方便知道應收包長，要等 1.5T 超時來結束當前包的接收，這點也會導致響應效率低，速率越高，效率越低的可怕。
（除非一邊接收一邊解析包的 function 種類，再根據不同種類和可能存在的 size 字段一起計算包的大小。Function 種類很多，還要區分 Request 和 Response，size 位置也不固定，很麻煩。）
如果不一邊接收一邊解析，那麼每收一個包，哪怕 10 個字節不到，都要等待很長時間才能開始 解析命令 和 執行命令：
115200 每個 T1_5 要等 8.64 個字節長度。 0.00075÷(1÷115200×10)
921600 每個 T1_5 要等 69.12 個字節長度。
10 Mbps 每個 T1_5 要等 750 個字節長度。
50 Mbps 每個 T1_5 要等 3750 個字節長度。 本帖最后由 dukelec 于 2020-10-10 12:59 编辑
modbus 发表于 2020-10-10 10:41
在Modbus出生那年代115200都算很高了，若按3.5T的话很多CPU都实现不了，现在的CPU，921600照样能实现3.5T ...
之前用的 x64 PC 工控機，上到 921600 不能用 USB 轉串口，要用 pcie 接口的串口卡（xr17v25x），且要用打了 preempt-rt 實時補丁的 linux 內核，且 pcie 串口卡的驅動要重寫，不能走傳統的串口框架，要直接暴露給應用程序，應用程序也只能用 C 按照 preempt-rt實時任務來寫，缺一不可，否則就會偶發的出現一個包被拆開很長時間，導致接收端丟包的問題。（windows 就不要想了，完全保證不了實時性。） 不要采集实时数据，采集历史数据，采集实时上位机存历史就是靠高频采集来保障数据时标尽可能准确，和数据同期性的 dukelec 发表于 2020-10-10 11:11
反了吧，1.5T 其實是接收超時，接收時用來分包，超過 1.5T 就認為當前包接收完畢，後續數據當下一個包， ...
同帧数据之间发送不超1.5T间隔是保证自己发送的正常数据不会被接收者当作不正常数据，接收只考虑3.5T是为了尽可能的兼容发送者 可不可以换成2个通道采集,1个串口17个,另一个串口18个,这样速度是不是就可以快1倍左右了
页:
[1]