大家有比较严谨的自定义485协议来参考吗

jufr12315 · 发表于 2020-8-9 23:00:00

公司以前的同事在项目上用自定义的485协议，发现好多问题。了解下你们都是怎么定义协议的。

qtechzdh · 发表于 2020-8-9 23:36:32

modbus可以么

dukelec · 发表于 2020-8-10 00:46:26

本帖最后由 dukelec 于 2020-8-10 01:02 编辑

自認為自定義的 cdnet 還算通用，各種需求基本可以滿足。
因為足夠通用，最近公司有一個 nrf52832 藍牙 ble 項目，都用了它做 ble 通訊，準備過段時間把自寫的 OTA 功能的 bootloader 和 PC 端 Python 升級程序開源，比官方的簡潔很多。

https://github.com/dukelec/cdnet
（這個代碼最近接下來會有大的整理，協議本身基本穩定。）

建議樓主列舉一下目前遇到的問題。

wajlh · 发表于 2020-8-10 01:41:16

不妨说说问题

redworlf007 · 发表于 2020-8-10 03:15:19

发帖子能不能表述清楚，你发现自定义协议有好多问题，啥问题?要让大家猜么？

hzpyl · 发表于 2020-8-10 06:42:20

modbus，已经很好了。

D.lovers · 发表于 2020-8-10 06:51:18

dukelec 发表于 2020-8-10 00:46
自認為自定義的 cdnet 還算通用，各種需求基本可以滿足。
因為足夠通用，最近公司有一個 nrf52832 藍牙 ble ...

是否可以用于uab的64字节通信协议？想研究usb转各种接口的软件编写，上下位机都准备好，可以通信了，就是想找个协议参考一下

dukelec · 发表于 2020-8-10 09:57:59

D.lovers 发表于 2020-8-10 06:51
是否可以用于uab的64字节通信协议？想研究usb转各种接口的软件编写，上下位机都准备好，可以通信了，就是 ...

uab 是什麼？

如果只是兩台機器通訊，且硬件已經是一個包一個包傳輸，且長度信息已經由底層告知，可以只用 cdnet payload 部份（開頭的 3 字節和結尾 2 字節 CRC 省略，我的 ble 就是這樣的）。

如果是 USB 串口，涉及到包中包的時候，內包的 3 字節頭也可以壓縮成 2 字節，因為長度信息可以由外包得知。譬如這個 usb 轉換器：
https://github.com/dukelec/cdbus_bridge

Flyback · 发表于 2020-8-10 10:05:45

串口自定义协议的主要问题就两个：可靠的分帧和协议可扩展性

由于串口没有像USB / CAN / ETH这些接口的硬件分帧功能，如何判断一帧起始和结束就是主要问题了

modbus的asc和rtu模式就是最佳范例了，分别使用了唯一分帧符和空闲时间两种方式可靠的方式，自定义协议基本也就这两个思路

推荐唯一分帧符方式，可直接套用modbus-asc，带宽利用率50%左右；想提高带宽利用率的话，可以通过8b转7b或者base64等转码来保证数据段和分帧字符区别开。这样可以保证协议通用性，同时减少对实时性的依赖

Excellence · 发表于 2020-8-10 10:08:13

modbus

工业常用，
还有HART，也是常用的。

Excellence · 发表于 2020-8-10 10:11:43

1、HART通信采用的是半双工的通信方式，属于模拟系统向数字系统转变过程中过渡性产品。

2、PROFIBUS依据EIA-485规范的电气传输方式会使用阻抗150欧姆的双绞线，比特率范围可以从9.6 kbit/s到12 Mbit/s。

3、Modbus已经成为工业领域通信协议的业界标准（De facto），并且现在是工业电子设备之间常用的连接方式

xyz543 · 发表于 2020-8-10 10:20:56

将 Modbus 小改一下，取重要的用估计可以。

D.lovers · 发表于 2020-8-10 14:49:20

dukelec 发表于 2020-8-10 09:57
uab 是什麼？

如果只是兩台機器通訊，且硬件已經是一個包一個包傳輸，且長度信息已經由底層告知，可以只 ...

抱歉，不好意思。应该是USB。使用STM32F103C8T6 实现HID，现在是python 上位机，采取的是64字节一包。
上位机发送一包数据给下位机，下位机送到数据包解析后做事，或者返回数据包。
现在就是想要一个比较可靠的协议，后续可以现在各种功能。如USB 转Lin UART I2C。

huike · 发表于 2020-8-10 15:18:31

MODBUS在实时性要求高的地方不是那么爽。
对于强实时性的时候，一定要自己已折腾。

newuseruser · 发表于 2020-8-10 15:43:37

先说说发现了什么问题？

gsq19920418 · 发表于 2020-8-10 16:12:26

好奇都有什麽問題，485的協議主要是分幀和擴展性吧

yy20062516 · 发表于 2020-8-10 18:02:41

包头（1F 0F）,地址（0-ff）数据长度（lenth_L lenth_H）数据（data1……datan）校验和（crcL crcH）

jufr12315 · 发表于 2020-8-11 09:15:12

目前的问题就是分帧，帧头帧尾定义

himan · 发表于 2020-8-11 09:18:35

jufr12315 发表于 2020-8-11 09:15
目前的问题就是分帧，帧头帧尾定义

不是好多问题么

knight_sh · 发表于 2020-8-11 09:41:13

jufr12315 发表于 2020-8-11 09:15
目前的问题就是分帧，帧头帧尾定义

见过很多0xAA 0x55之类来作帧头，其实这种定义非常不严谨。

ljq77402 · 发表于 2020-8-11 13:24:46

knight_sh 发表于 2020-8-11 09:41
见过很多0xAA 0x55之类来作帧头，其实这种定义非常不严谨。

怎么不严谨法？

dukelec · 发表于 2020-8-11 14:00:24

本帖最后由 dukelec 于 2020-8-11 14:03 编辑

ljq77402 发表于 2020-8-11 13:24
怎么不严谨法？

後面跟的數據可能出現同樣的兩個字節。
除非每次遇到相同的字節序都轉譯成更長的其它數據，類似 ppp 協議那樣，不過長度變化會帶來很多麻煩，轉譯效率非常低。。。

redroof · 发表于 2020-8-11 14:23:13

knight_sh 发表于 2020-8-11 09:41
见过很多0xAA 0x55之类来作帧头，其实这种定义非常不严谨。

只要带长度和校验，严谨程度就是够的。
帧头只是方便找起点而已。
问题是严格的识别方法是平方级复杂度，很多人不会。
正确方法:先找一个帧头，然后看下一个长度是不是合理，然后读够长度，再看后面的校验对不对，都对了就算ok
如果不对，要回到找帧头的状态，在已收到的数据中找下一个帧头，找到了再继续上面的步骤。注意，不是从上一个错误的帧尾来找，而是从上一个帧头开始找。之前按帧头长度跳过的数据要重新分析一次。这就是问题的关键。

redroof · 发表于 2020-8-11 14:27:38

如果数据内容含有很多帧头，而你又搞乱了帧边界要重新扫描，那么这个正确做法会比较慢，但慢归慢，只要帧校验是个正确的算法，不要碰上一堆随机数恰好凑岀正确的校验，那么就没关系。modbus标准规定的crc16通常都够了。别用简单的累加和就行

dellric · 发表于 2020-8-11 14:29:03

MODBUS有一些毛病，比如数据更新的问题，严谨的话参考DLT 645协议

momo_li · 发表于 2020-8-11 14:39:52

dukelec 发表于 2020-8-11 14:00
後面跟的數據可能出現同樣的兩個字節。
除非每次遇到相同的字節序都轉譯成更長的其它數據，類似 ppp 協議 ...

一般的低速通信，超时的方法就挺好的，简单，发送的时候注意连续发就行，不要中间停顿太长时间

对于想压榨串口效率的用法，我倒是觉得PPP非常合适，我自己稍微改进了一下ppp，不但带了帧头，还带了帧尾，这样程序就很容易检测到完整的一帧。收到帧尾后立刻就可以解码处理数据。
ppp编码虽然会降低有效数据的占用率，不过一般发生编码事件的概率还是可以接受的，对于高速串口，省下来的时间还是划算的。
至于ppp编码的内存消耗和解码时间占用，目前的cpu还是可以接受，其实也算不上什么。真正资源受限的项目，毕竟还是少数，大部分都是感觉不够而已。如果使用了几百字节内存的mcu，超时判断就算了，各种花样都玩不起来。
可变长度对于ppp根本就不算个事。

使用AA55做帧头帧尾的，实在是太放心了。

dukelec · 发表于 2020-8-11 14:50:56

momo_li 发表于 2020-8-11 14:39
一般的低速通信，超时的方法就挺好的，简单，发送的时候注意连续发就行，不要中间停顿太长时间

对于想压 ...

我覺得高速通訊用超時也夠的，譬如用 STM32 的接收超時事件，只要超過一個 byte 空閑，就當作傳輸完畢，沒有比這開銷更小的了。。。

momo_li · 发表于 2020-8-11 15:53:13

dukelec 发表于 2020-8-11 14:50
我覺得高速通訊用超時也夠的，譬如用 STM32 的接收超時事件，只要超過一個 byte 空閑，就當作傳輸完畢， ...

是的,可惜这个长度不能设定,能设定的话就更加实用了

michael.yang · 发表于 2020-8-11 18:00:48

帧头 + 数据长度 + 数据 + 校验
其中：数据里面可以包含各种命令和参数。

dzcn · 发表于 2020-8-11 19:12:01

帧头是什么不重要，关键字转义一下，加上校验，万无一失。

knight_sh · 发表于 2020-8-11 23:07:06

redroof 发表于 2020-8-11 14:27
如果数据内容含有很多帧头，而你又搞乱了帧边界要重新扫描，那么这个正确做法会比较慢，但慢归慢，只要帧校 ...

讲得非常详细，厉害。
我一般定义协议都是拓展Miro Samek博士在PSiCC2书中关于QS数据协议，简单好用;

redroof · 发表于 2020-8-12 08:30:39

dzcn 发表于 2020-8-11 19:12
帧头是什么不重要，关键字转义一下，加上校验，万无一失。

转义会改变缓冲区长度，如果数据随机，这种开销不可控。
常规的modbus做法足够了，如果没有搞乱帧边界就没任何开销。

lb0857 · 发表于 2020-8-12 08:33:13

帧头 + 数据长度 + 数据 + 校验足够也

modbus · 发表于 2020-8-12 09:30:08

最好的分帧还是空闲时间分帧，CAN分帧也是空闲时间分帧，所以即使高速通讯效率也没问题

ljq77402 · 发表于 2020-8-12 11:03:47

momo_li 发表于 2020-8-11 15:53
是的,可惜这个长度不能设定,能设定的话就更加实用了

STM32F0 系列的接收超时中断可以设置

dukelec · 发表于 2020-8-12 11:05:45

本帖最后由 dukelec 于 2020-8-12 11:07 编辑

redroof 发表于 2020-8-12 08:30
转义会改变缓冲区长度，如果数据随机，这种开销不可控。
常规的modbus做法足够了，如果没有搞乱帧边界就 ...

开销也是可控的，單字節頭的 ppp 協議，數據長度最大接近原始數據的 2 倍，如果是 2 字節的頭，最大數據長度是原本的 1.5 倍而已。
對於 cpu 的開銷，也不比 23 樓的方法多耗費多少資源。

我也覺得 modbus 足夠了，55 aa 這種幀頭一般只是起到安慰劑的做用（不轉義的情況下），串口發命令都是一來一回，沒有粘包的可能性，就算有：清空緩存，等超時重傳即可（所有錯誤都是同樣操作）。
而且，就算粘包並要從中恢復數據，通過一個字節地址、長度、16 位 crc 三方聯合判斷，也足以恢復數據包。。。

redroof · 发表于 2020-8-12 17:16:27

dukelec 发表于 2020-8-12 11:05
开销也是可控的，單字節頭的 ppp 協議，數據長度最大接近原始數據的 2 倍，如果是 2 字節的頭，最大數據 ...

问题不只是粘包。
问题是485在双方都没发数据的时候，空闲状态只靠很弱的上下拉电阻维持电平，这个时候完全可能受干扰。
接收方看起来就在正常数据前面多收到了一个垃圾数据。以前遇到过有人用简单算法，经常会错。因为那一个垃圾数据搞得后面正常数据也被一起丢弃了。
后来让那个人改了严格算法，这种情况再也不怕了。

modbus · 发表于 2020-8-12 17:44:13

redroof 发表于 2020-8-12 17:16
问题不只是粘包。
问题是485在双方都没发数据的时候，空闲状态只靠很弱的上下拉电阻维持电平，这个时候完 ...

只要是485通讯，肯定都有空闲状态的，所以设计好空闲状态下的抗干扰能力也是很重要的，像西门子的PROFIBUS，空闲状态是由390欧的上下拉电阻维持电平

dukelec · 发表于 2020-8-12 17:51:49

本帖最后由 dukelec 于 2020-8-12 17:59 编辑

redroof 发表于 2020-8-12 17:16
问题不只是粘包。
问题是485在双方都没发数据的时候，空闲状态只靠很弱的上下拉电阻维持电平，这个时候完 ...

靠很弱的上下拉电阻

問題出在哪就解決哪裏啊，我喜歡用 330 Ohm 的上下拉電阻，很穩定，還能順便吸收反射（120 Ohm 不接）。

不然，硬件有問題，連 modbus 都兼容不好。或者浪費不必要的 CPU 資源、降低實時性。

一般，萬一是阻值比較大的 AB 上下拉電阻（或者沒接上下拉），也只是容易導致上電後的首個包接收不暢順，因爲 AB 壓差的滞回特性，譬如 VA 接近 VB 的時候，從機端輸入邏輯有可能判 0，導致第一個包開頭的空閒時間不夠，導致接收出錯。
只要主機發送過一次數據，因爲數據結尾是發送的邏輯 1，那麼，當 AB 壓差再次回到相等，從機端輸入邏輯會判 1，不影響後續接收。

還有些人，每次接收到的數據前容易有多出來的雜亂數據，是因爲他的 RO （接 MCU 的 RX）這條線沒開上拉，導致自己在發送數據的時候，RO 懸空高阻收到干擾，接收到雜亂數據，等會切換到接收方向，繼續接收有效數據，結果就是干擾數據+有效數據。
干擾並非是來自總線，而是因爲本地 RO 沒上拉。。。（還有 TTL 也是一樣，很多人沒有給 RX 開上拉的習慣，譬如很多 Linux 板子的調試口。。。）

redroof · 发表于 2020-8-12 18:09:09

modbus 发表于 2020-8-12 17:44
只要是485通讯，肯定都有空闲状态的，所以设计好空闲状态下的抗干扰能力也是很重要的，像西门子的PROFIBU ...

为了多带从机，只能把上下拉变弱。没办法的事情。
只要有可能，当然还是让上下拉变强一点更好。
我也认为390欧太强了，你算算这样的并5个就只剩多少欧了？就不说连10个20个了

dukelec · 发表于 2020-8-12 18:11:16

redroof 发表于 2020-8-12 18:09
为了多带从机，只能把上下拉变弱。没办法的事情。
只要有可能，当然还是让上下拉变强一点更好。
我也认为 ...

上下拉，整條總線只接一處。

redroof · 发表于 2020-8-12 18:12:22

dukelec 发表于 2020-8-12 17:51
問題出在哪就解決哪裏啊，我喜歡用 330 Ohm 的上下拉電阻，很穩定，還能順便吸收反射（120 Ohm 不接） ...

你跟别人通讯，问题在别人，但客户要你改，这种情况你认为是多还是少？

所以我们的modbus里面一直保留着这种做法，确保在有效数据前面有若干个垃圾数据都不影响。
也推荐大家都这么做～～

dukelec · 发表于 2020-8-12 18:15:44

本帖最后由 dukelec 于 2020-8-12 18:18 编辑

redroof 发表于 2020-8-12 18:12
你跟别人通讯，问题在别人，但客户要你改，这种情况你认为是多还是少？
所以我们的modbus里面 ...

跟别人通讯，问题在别人

你上面 37 樓貌似說的是讓「别人」改的。。。

我跟别人通讯，我主動加 330 的上下拉電阻即可。別人的接收有問題，只能讓對方改啊，除非有源碼。

redroof · 发表于 2020-8-12 18:20:22

dukelec 发表于 2020-8-12 18:11
上下拉，整條總線只接一處。

那算你有本事。可以教育客户这么正规的接

如果现场接线的电工都那么听话就好了。。。。
实际的现场，大概率你这种单独的上拉电阻别人不会接的。所以只能自己内置一个，内置就回到我上面的问题了

dukelec · 发表于 2020-8-12 18:29:22

本帖最后由 dukelec 于 2020-8-12 18:33 编辑

redroof 发表于 2020-8-12 18:20
那算你有本事。可以教育客户这么正规的接
如果现场接线的电工都那么听话就好了。。。。
实际的现 ...

我的設備，主機單獨有一個口插上下拉附件，默認插上出貨。

想內置的話，就主機內置就好了。

或者，主機是別人的，你可以通過軟件（或硬件），只使能 ID 爲 1 的從機的內部上下拉。

無論如何，都要留接口可以在外部關閉上下拉。

而且，我 39 樓最後有提到，我覺得干擾很可能不是上下拉的問題。

redroof · 发表于 2020-8-12 18:48:01

dukelec 发表于 2020-8-12 18:29
我的設備，主機單獨有一個口插上下拉附件，默認插上出貨。

想內置的話，就主機內置就好了。

你是很高端的设备才能这么要求客户啊。
485上专门弄个上下拉配件不费事吗？不花钱吗？常用的PLC我没见哪一家给485配外置上下拉的。。。。
能自己用软件对付一下多好啊。

knight_sh · 发表于 2020-8-12 19:17:06

这个帖子算是把modbus通讯的要点都给点出来了，收获蛮大，谢谢各位大佬

modbus · 发表于 2020-8-12 23:35:50

redroof 发表于 2020-8-12 18:20
那算你有本事。可以教育客户这么正规的接
如果现场接线的电工都那么听话就好了。。。。
实际的现 ...

现场接线的电工都是按接线图来接线的，怎么画图怎么接线，绝对听话

redworlf007 · 发表于 2020-8-13 00:34:48

redroof 发表于 2020-8-12 18:09
为了多带从机，只能把上下拉变弱。没办法的事情。
只要有可能，当然还是让上下拉变强一点更好。
我也认为 ...

弱弱的问下，485不是主机带上下拉就好了么？从机的AB也要上下拉么？

redroof · 发表于 2020-8-13 10:02:13

redworlf007 发表于 2020-8-13 00:34
弱弱的问下，485不是主机带上下拉就好了么？从机的AB也要上下拉么？

你去市场上随便买几个Modbus的从机设备，看看他们里面带不带上下拉就知道了。
理论和实际是不一样的。
理论上的最佳做法，实际使用中经常让位于接线方便性。你无法改变这些。

modbus · 发表于 2020-8-13 12:08:37

其实485只有一个主站还好处理，我们都是在主站上直接内置强上下拉电阻，CAN那种多主结构才麻烦，虽然一再向客户强调在CAN总线的两个末端要加终端电阻，并且把电阻也提供了，但实际上还是有很多客户不加

MAD_FISH · 发表于 2020-8-13 12:11:26

严谨的参考 645 698

redroof · 发表于 2020-8-13 12:21:24

modbus 发表于 2020-8-13 12:08
其实485只有一个主站还好处理，我们都是在主站上直接内置强上下拉电阻，CAN那种多主结构才麻烦，虽然一再向 ...

很多485设备岀厂的时候并不知道主从。难道plc就一定当从机？触摸屏一定当主机？都不一定的。很多灵活一点的设备都是主从可配的。所以太强的上下拉并不好

redworlf007 · 发表于 2020-8-13 12:33:45

redroof 发表于 2020-8-13 10:02
你去市场上随便买几个Modbus的从机设备，看看他们里面带不带上下拉就知道了。
理论和实际是不一样的。
理 ...

我现在做的设备是主机，我是10K上下拉，120的匹配直接焊上面的，这么干行不行？

redroof · 发表于 2020-8-13 12:56:36

redworlf007 发表于 2020-8-13 12:33
我现在做的设备是主机，我是10K上下拉，120的匹配直接焊上面的，这么干行不行？ ...

10K太弱了，如果用正规的120匹配，那么上下拉按规定应当是390。反正你知道是主机。
我们不知道主从，传统做法是3个1K串起来。也就是上下拉和终端都是1K，比较弱。

modbus · 发表于 2020-8-13 14:02:58

redroof 发表于 2020-8-13 12:21
很多485设备岀厂的时候并不知道主从。难道plc就一定当从机？触摸屏一定当主机？都不一定的。很多灵活一点 ...

那就设计的做主机时自动切换到强上下拉，做从机时自动切换到弱上下拉，成本上也只是增加几毛钱，我们有一个产品就是这样设计的，如果只有一个主站就可以有很多种方法

redroof · 发表于 2020-8-13 15:01:22

modbus 发表于 2020-8-13 14:02
那就设计的做主机时自动切换到强上下拉，做从机时自动切换到弱上下拉，成本上也只是增加几毛钱，我们有一 ...

其实全用1K这么多年了都没问题，哈哈，不必那么费事。

redworlf007 · 发表于 2020-8-14 00:07:13

redroof 发表于 2020-8-13 12:56
10K太弱了，如果用正规的120匹配，那么上下拉按规定应当是390。反正你知道是主机。
我们不知道主从，传统 ...

那我把上下拉换成390Ω，5V 390Ω上拉，GND 390Ω下拉。

cddx · 发表于 2020-8-14 06:43:57

momo_li 发表于 2020-8-11 14:39
一般的低速通信，超时的方法就挺好的，简单，发送的时候注意连续发就行，不要中间停顿太长时间

对于想压 ...

帧头+长度+加CRC校验+timeout的自定义协议一直在用，实际使用好像没有什么问题，不过心里不踏实。

wintelboy · 发表于 2020-8-14 11:43:41

好多高手，学习了

AlertTao · 发表于 2020-8-14 12:05:22

redroof 发表于 2020-8-11 14:23
只要带长度和校验，严谨程度就是够的。
帧头只是方便找起点而已。
问题是严格的识别方法是平方级复杂度， ...

精髓表达.

zprs · 发表于 2020-8-17 11:15:11

正在做485通讯调试，学习。。。。。

gsq19920418 · 发表于 2020-8-17 16:41:15

knight_sh 发表于 2020-8-11 23:07
讲得非常详细，厉害。
我一般定义协议都是拓展Miro Samek博士在PSiCC2书中关于QS数据协议，简单好用;

有全的，可以上传吗？看截图没看懂

simplorer · 发表于 2020-8-17 16:53:14

modbus协议查找帧头的开销有点大。
我自己做的协议都没用超时控制来判断帧起始，都是按照字节，一个一个校验是不是完整的帧，
这样开销大一些，现在看稳定性可以、

knight_sh · 发表于 2020-8-18 18:06:09

gsq19920418 发表于 2020-8-17 16:41
有全的，可以上传吗？看截图没看懂

这本书坛友已经发了好多回了。

redroof · 发表于 2020-8-18 18:51:09

simplorer 发表于 2020-8-17 16:53
modbus协议查找帧头的开销有点大。
我自己做的协议都没用超时控制来判断帧起始，都是按照字节，一个一个校 ...

就得这样。
比如你外面接有中继器之类的情况下，是有可能不保证精确的字节超时的。所以最安全的做法就是不管超时，只算内容的校验来确定帧结尾。

shhludb · 发表于 2020-8-19 07:44:38

某些字节如果能确定范围，就增加过滤，个数确定的也可以过滤，否则都返回帧头，再加crc校验，

jiangyimfs1 · 发表于 2020-8-20 08:52:15

modbus在工业中的确用的比较多了

redworlf007 · 发表于 2020-10-14 22:27:24

本帖最后由 redworlf007 于 2020-10-14 22:42 编辑

redroof 发表于 2020-8-13 10:02
你去市场上随便买几个Modbus的从机设备，看看他们里面带不带上下拉就知道了。
理论和实际是不一样的。
理 ...

大神请教个问题，别人的设备，上位机是PC，有上位机程序，下位机是加气机，485通讯，一个上位机485口对应一个加油机485口（接线不到20米，用的是那种两芯电源线，地埋拉倒室内收银台），我的设备接在下位机的485口上监听，接线30cm，我的485监听设备是1201+max13487做的，电源隔离的，上下拉10K电阻，拉到5V和地，我的监听设备上485匹配电阻不接，这么搞行不行？

1、为啥有时候，我的485设备，只要接上去，还没上电，别人的设备的485通讯就异常了，要把我的设备拔掉，然后断电重启别人的下位机设备才能恢复，只拔掉我的设备，也不能恢复。
2、我把我的设备上电后，监听到的情况是，上位机给下位机发送命令，并且命令正确，下位机毫无反应。
3、十一前装的设备，跑了一周了，今天上午出现这个问题，一直各种测试，下午的时候，又测不出来了。。。郁闷。。。明天再去测下看。

dukelec · 发表于 2020-10-14 23:07:17

本帖最后由 dukelec 于 2020-10-14 23:10 编辑

redworlf007 发表于 2020-10-14 22:27
大神请教个问题，别人的设备，上位机是PC，有上位机程序，下位机是加气机，485通讯，一个上位机485口对应 ...

你 Q3 做什麼的？
沒上電時相當於接了一個二極管從 B 到 A，會導致總線其它設備發送邏輯 0 的時候，數據被二極管短路。

redworlf007 · 发表于 2020-10-14 23:09:29

dukelec 发表于 2020-10-14 23:07
你 Q3 做什麼的？
沒上電時相當於接了一個二極管從 B 到 A，會導致總線發送邏輯 0 的時候，數據被二極管 ...

Sm712 防静电那个

dukelec · 发表于 2020-10-14 23:45:37

本帖最后由 dukelec 于 2020-10-15 00:07 编辑

redworlf007 发表于 2020-10-14 23:09
Sm712 防静电那个

第一眼不看型號。

我猜一下，設備要掉電才能恢復，可能是連續收到錯誤，軟件主動罷工？

你的板子接入的時候給總線帶來了干擾。

主要原因我猜在你板子上：未通電時，總線的電壓經過你的上下拉電阻給你的 485 側的電源充電，充到一定程度，你的 485 芯片会上電，然後檢測到 DI 是低電平，以為是你主動發送的低電平，於是向總線上發數據。然而一發數據消耗電比較多，又會掉電，不停重複。

具體情況還是要示波器看一下，設備和 pc 不共地不是很好（如果有共地球大地倒也湊合），不行要拆開 pc 和設備的板子，看下它們的 485 電路分別怎麼設計的。

redworlf007 · 发表于 2020-10-15 08:46:28

dukelec 发表于 2020-10-14 23:45
第一眼不看型號。

我猜一下，設備要掉電才能恢復，可能是連續收到錯誤，軟件主動罷工？

我今天把监听485的上下拉去掉再试试，对方的设备安装在现场，在工作，我不好拆开看，我打算在实验室再安装一套相同的设备来测试。

plc_avr · 发表于 2020-10-15 09:10:34

redworlf007 发表于 2020-10-15 08:46
我今天把监听485的上下拉去掉再试试，对方的设备安装在现场，在工作，我不好拆开看，我打算在实验室再安 ...

1、为啥有时候，我的485设备，只要接上去，还没上电，别人的设备的485通讯就异常了，要把我的设备拔掉，然后断电重启别人的下位机设备才能恢复，只拔掉我的设备，也不能恢复。
---485总线上，有部分的485没有上电，这个时候，这条总线大部分都是瘫痪的，所以现象正常，但是拔了下位机不会恢复，应该是下位机的软件没有处理好，自动重连没做好或是处理的太好了，防止监听？但是这样也会干掉自已。如果可能你更改一下上电顺序，你的先上电，他的后上电。
2、我把我的设备上电后，监听到的情况是，上位机给下位机发送命令，并且命令正确，下位机毫无反应。
　 ---用示波器测量波形，是不是有多余的东西。这个可以看出99%的问题
3、十一前装的设备，跑了一周了，今天上午出现这个问题，一直各种测试，下午的时候，又测不出来了。。。郁闷。。。明天再去测下看。
　 ---非周期性出现故障，是要仔细分析的，没有找到点子上，后续还会再出现

楼主可以把最后的解决方法，与大家分享，这样大家也可以从中学到很多东西。

redroof · 发表于 2020-10-15 10:08:19

redworlf007 发表于 2020-10-14 23:09
Sm712 防静电那个

SM712你画个三极管明显是不对的啊。它是双TVS管。
建议你把上下拉以及SM712全拆了，包括放电管。
这样应该能完全不影响别人的设备
要确保你这里断电的时候，对外表现为一个很大的电阻，不能有别的东西

redworlf007 · 发表于 2020-10-15 10:40:30

plc_avr 发表于 2020-10-15 09:10
1、为啥有时候，我的485设备，只要接上去，还没上电，别人的设备的485通讯就异常了，要把我的设备拔掉， ...

好的，谢谢犀利哥。

redworlf007 · 发表于 2020-10-15 10:42:55

redroof 发表于 2020-10-15 10:08
SM712你画个三极管明显是不对的啊。它是双TVS管。
建议你把上下拉以及SM712全拆了，包括放电管。
这样应 ...

sm712我借用了三极管的原理图封装，我把sm712也拆掉看看，我怕静电打坏，所以加的，放电管，万用表测200M的电阻。

redworlf007 · 发表于 2020-10-15 10:59:27

redroof 发表于 2020-10-15 10:08
SM712你画个三极管明显是不对的啊。它是双TVS管。
建议你把上下拉以及SM712全拆了，包括放电管。
这样应 ...

上下拉不拆、sm712不拆、放电管不拆，不上电，万用表测485AB之间电阻17K。

都拆掉，测电阻0.15M。

dukelec · 发表于 2020-10-15 11:43:48

redworlf007 发表于 2020-10-15 10:59
上下拉不拆、sm712不拆、放电管不拆，不上电，万用表测485AB之间电阻17K。

都拆掉，测电阻0.15M。 ...

建議你先試試只用 AB 信號給你的板子供電（外部用 1k 的上下拉電阻接到 5V 電源即可），你的板子有上下拉的時候，看看你的板子是否在向外發送數據。

如果有，表示電路設計有邏輯 bug，簡單的去掉上下拉電阻也不安全。
譬如你板子正常工作，掉電的時候 DI 變成低電平，因爲 485 芯片掉電慢，它也會誤以爲你在發送數據，從而干擾總線。

所以，對於自動切換方向的 485 PHY 芯片，雖然 DE 可以省掉，但是 /SHDN 還是要默認下拉，MCU 上電後通過 IO 去控制 /SHDN 爲高電平。
貌似這樣，自動切換方向的意義就不大了。。。

redroof · 发表于 2020-10-15 12:18:15

redworlf007 发表于 2020-10-15 10:59
上下拉不拆、sm712不拆、放电管不拆，不上电，万用表测485AB之间电阻17K。

都拆掉，测电阻0.15M。 ...

正牌大厂的485收发器没那么脆弱。
啥也不接，确认电阻够高不会影响对方了，就拿去实测一下吧

redworlf007 · 发表于 2020-10-15 15:00:22

redroof 发表于 2020-10-15 12:18
正牌大厂的485收发器没那么脆弱。
啥也不接，确认电阻够高不会影响对方了，就拿去实测一下吧 ...

我现在把上下拉去掉，只留sm712，测了一上午，暂时正常。

redroof · 发表于 2020-10-15 16:48:40

redworlf007 发表于 2020-10-15 15:00
我现在把上下拉去掉，只留sm712，测了一上午，暂时正常。

那就是了呗。你的上下拉影响了别人。
tvs管反正没接电源，也就不影响。

redworlf007 · 发表于 2020-10-15 17:00:27

redroof 发表于 2020-10-15 16:48
那就是了呗。你的上下拉影响了别人。
tvs管反正没接电源，也就不影响。

嗯，那个双向tvs，对地接到AB上的，接不接TVS，我测了电阻没啥变化。

大家有比较严谨的自定义485协议来参考吗

阿莫论坛20周年了！感谢大家的支持与爱护！！

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源