[cornflyer 0]

msp430 + ENC28J60

[_Pasha 0]

Возможно, лучше было бы пересылку пакетов осуществлять после проверки CRC.

Пакеты с BAD CRC.

Их надо как-то регистрировать. Как?

[Rst7 5]

msp430 + ENC28J60

 

Ну это ничем не отличается от любой_камень+ENC28J60. Это мы уже обсудили на первой странице ;)

 

Их надо как-то регистрировать. Как?

 

Регистрировать? Отбрасывать да и все.

[_Pasha 0]

Регистрировать? Отбрасывать да и все.

Сторона, отправившая плохой пакет, должна знать о том, что пакет не прошел. Получается сложняк, который не умещается в концепцию модбас-моста.

[Rst7 5]

Сторона, отправившая плохой пакет, должна знать о том, что пакет не прошел.

 

Чето я там такого не припомню. Можно дословную цитату, что делать с пакетом, у которого плохо с CRC?

[_Pasha 0]

Чето я там такого не припомню. Можно дословную цитату, что делать с пакетом, у которого плохо с CRC?

 

Да это понятно - через таймауты все откинется.

 

If the server receives the request, but detects a communication error (parity, LRC,

CRC, ...), no response is returned. The client program will eventually process a

timeout condition for the request.

 

Получается, нужна обязательная поддержка диагностических команд и счетчиков. А это - разбор пакетов и, в общем, никакой прозрачной реализации репитера не будет.

Т.е. application layer нужен?

[Rst7 5]

Т.е. application layer нужен?

 

Ну не целиком же. По-быстреньком посмотреть, нет ли ахинеи в принятом пакете и дропнуть его, если что не так.

А можно конечно и совсем тупо транслировать его в 485, пусть там разбираются. Хотя, а вот вопрос - в обратную сторону, из 485 в TCP надо смотреть CRC или нет?

 

Я бы сделал все-таки эти проверки.

[_Pasha 0]

Хотя, а вот вопрос - в обратную сторону, из 485 в TCP надо смотреть CRC или нет?

 

Я бы сделал все-таки эти проверки.

 

Поговорили. Я этот случай и имел ввиду.

 

Резюме: будет две ипостаси: тупой репитер и как полноценная аппликуха для диагностики и поддержки конфигурируемого адресного пространства в ведомом сегменте RS-485. Дабы трафик был гуманный.

[Rst7 5]

Поговорили. Я этот случай и имел ввиду.

 

Объясню. Я просто с MODBUS не сталкивался вплотную, по причине того, что мне эта система виртуальных веревочек (т.е. каждая веревочка говорит о состоянии какого-либо устройства) в приборы совсем не ложится - я работаю со своими протоколами, которые ориентированы на передачу событий. Поэтому глупые вопросы задаю. Сделайте на это скидку мне, окей? ;)

[defunct 0]

Максимальная длина фрейма - 255 байт.

Откуда взято ограничение длины?

 

Хотя, а вот вопрос - в обратную сторону, из 485 в TCP надо смотреть CRC или нет?

В обе стороны сделать CRC. В модбасовую сторону по modbus полиному "0xA001",

в Eth сторону - по любому оговоренному способу.

 

Нормальный конвертер должен распознавать правильность принятых пакетов входного протокола, отцеплять служебную информацию (в данном случае CRC), перепаковывать сообщение в соответвии с требованиями выходного протокола и отправлять перепакованный пакет.

 

IMHO совсем не обязательно делать over TCP.

На мой взгляд, over UDP будет ничуть не хуже и даже быстрее, при этом значительно проще, плюс можно броадкастом общаться сразу с несколькими конвертерами. Гарантировать доставку - фиксированным числом ретрансмитов.

[_Pasha 0]

Откуда взято ограничение длины?

 

В обе стороны сделать CRC.

 

На мой взгляд, over UDP будет ничуть не хуже и даже быстрее

 

1. Modbus_over_serial_line_V1_02.pdf

The maximum size of a MODBUS RTU frame is 256 bytes.

С учетом адреса.

 

2. Хочется простого репитера, не вникающего даже в CRC. Хотя, с другой стороны, если прикрутить именно UDP, то и аппликуха влезет достаточно умная

 

3. +1 :a14:

[Rst7 5]

Падаждытэ :)

 

Насколько я понимаю, есть спецификация Modbus over TCP, а вот over UDP как-то не встречал.

[sensor_ua 0]

есть спецификация Modbus over TCP

это не повод. Речь же вроде шла о туннелировании пакетов Modbus over serial line через сие устройство. А Modbus over TCP говорит, что CRC относится у него не к просто к инкапсулированному пакету Modbus over serial line, а к пакету в рамках TCP, где мухи отдельно и котлеты отдельно, потому это не есть туннелирование в чистом виде. ИМХО, туннелировать через UDP будет всё же попроще

[Rst7 5]

Речь же вроде шла о туннелировании пакетов Modbus over serial line через сие устройство.

 

Может я чего-то не вкурил? Я понял так, что хочется преобразователь Modbus over TCP <-> Modbus over serial line, чтобы и то и то согласно спецификации работало.

[sensor_ua 0]

Хм... думаю, что речь всё же шла об туннелировании Modbus over serial line <->TCP/UDP <->Modbus over serial line. При этом преобразование Modbus over serial line <->TCP/UDP может делаться как в устройстве, подключенном по RS к PC (чтобы не писать нового софта - вариации на тему Modbus over serial line гораздо более распространены), так и в самом PC.