Сергей Борщ 134 18 февраля, 2015 Опубликовано 18 февраля, 2015 · Жалоба Читал по-английски - не понял. Прочитал по русски - та же фигня слово-в-слово. Поэтому цитирую русский вариант: Фрейм сообщения передается непрерывно. Если интервал тишины продолжительностью 1.5 возник во время передачи фрейма, принимающее устройство заканчивает прием сообщения и следующий байт будет воспринят как начало следующего сообщения. Таким образом, если новое сообщение начнется раньше 3.5 интервала, принимающее устройство воспримет его как продолжение предыдущего сообщения. В этом случае устанавливается ошибка, так как будет несовпадение контрольных сумм. Типичный фрейм сообщения показан ниже. Только мне кажется, что второе предложение противоречит первому? Как принимающее может воспринять сообщение через 2 интервала как продолжение, если оно уже через полтора должно было воспринять его как начало следующего? На всякий случай оригинал: The entire message frame must be transmitted as a continuous stream. If a silent interval of more than 1.5 character times occurs before completion of the frame, the receiving device flushes the incomplete message and assumes that the next byte will be the address field of a new message. Similarly, if a new message begins earlier than 3.5 character times following a previous message, the receiving device will consider it a continuation of the previous message Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Vladivolt 0 18 февраля, 2015 Опубликовано 18 февраля, 2015 (изменено) · Жалоба Действительно, можно мозг сломать. Приведённая цитата кочует из книжки в книжку. Источник 1996 года -- Modicon Modbus Protocol Reference Guide PI–MBUS–300 Rev. на старанице спецификаций этот документ значится как справочный. MODBUS Over Serial Line FOR LEGACY APPLICATIONS ONLY В рекомендованном актуальном Modbus Serial Line Protocol and Implementation Guide V1.02 рисунок 14 задаёт такую процедуру -- при паузе 1.5 .. 3.5 выставлять флаг ошибки и дождаться паузы 3.5 и забраковать весь фрейм. Изменено 18 февраля, 2015 пользователем Владивольт Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
A. Fig Lee 0 18 февраля, 2015 Опубликовано 18 февраля, 2015 · Жалоба Ну в первом случае речь идет о "внутри фрейма" если пауза 1.5 или больше, выбрасываем весь фрейм. Если же ВЕСЬ фрейм уже пришел, то ждать надо 3.5 карактера, иначе это будет присоединятся к предыдущему. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 18 февраля, 2015 Опубликовано 18 февраля, 2015 · Жалоба Ну в первом случае речь идет о "внутри фрейма" если пауза 1.5 или больше, выбрасываем весь фрейм.То есть пакет нужно разбирать на лету, нельзя считать паузу в 3.5 символа признаком конца пакета? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
A. Fig Lee 0 18 февраля, 2015 Опубликовано 18 февраля, 2015 · Жалоба То есть пакет нужно разбирать на лету, нельзя считать паузу в 3.5 символа признаком конца пакета? Похоже, что так. Я сам с ним работал очень чуть чуть, практического опыта почти нет. Но судя по описанию, так и есть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SSerge 4 18 февраля, 2015 Опубликовано 18 февраля, 2015 · Жалоба То есть пакет нужно разбирать на лету, нельзя считать паузу в 3.5 символа признаком конца пакета? Вот как раз пауза в 3.5 символа и только она является концом пакета (кадра, фрейма). Собственно разбор пакета в процессе приёма не обязателен, логичнее просто собирать приходящие байтики в буфер, а проверять CRC и учинять разбор уже после приёма всего пакета. Если в процессе приёма была зафиксирована пауза больше 1.5 (но меньше 3.5) символа то нужно продолжать приём до паузы в 3.5 символа, но сами символы при этом сохранять уже не обязательно, всё равно весь фрейм должен быть проигнорирован. Новый фрейм начинается только после обнаружения паузы t3.5 На практике вполне можно не заморачиваться с отслеживанием паузы t1.5, а определять только только конец фрейма по t3.5. Благодаря CRC вероятность выловить в потоке помех правильный фрейм очень низкая и отслеживание t1.5 ничего к надёжности не добавляет. Но особо пристрастная проверка на соответствие стандарту такое, конечно же, выявит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MrYuran 21 19 февраля, 2015 Опубликовано 19 февраля, 2015 · Жалоба То есть пакет нужно разбирать на лету, нельзя считать паузу в 3.5 символа признаком конца пакета? Посмотрите FreeModbus, там именно так и сделано. По приему символа перевзводится таймер 3,5т, а по истечению интервала вызывается коллбэк завершения фрейма. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 19 февраля, 2015 Опубликовано 19 февраля, 2015 · Жалоба На практике вполне можно не заморачиваться с отслеживанием паузы t1.5, а определять только только конец фрейма по t3.5. Благодаря CRC вероятность выловить в потоке помех правильный фрейм очень низкая и отслеживание t1.5 ничего к надёжности не добавляет. Но особо пристрастная проверка на соответствие стандарту такое, конечно же, выявит. Спасибо за развернутый ответ. Теперь стало ясно. При особо пристрастной проверке такое выявить можно если CRC первого пакета будет равно 0xFFFF. Случай редкий, обрабатывать не буду. По приему символа перевзводится таймер 3,5т, а по истечению интервала вызывается коллбэк завершения фрейма.Сделал таймаут на приход символа в 3.5т - то же яйцо, только в профиль. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 20 февраля, 2015 Опубликовано 20 февраля, 2015 · Жалоба При особо пристрастной проверке такое выявить можно если CRC первого пакета будет равно 0xFFFF. При чём тут CRC? Отправят корректный по содержимому фрейм с паузой в середине больше t1.5 и менее t3.5. Ваш прибор примет этот фрейм, и это будет ошибкой. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 20 февраля, 2015 Опубликовано 20 февраля, 2015 · Жалоба При чём тут CRC? Отправят корректный по содержимому фрейм с паузой в середине больше t1.5 и менее t3.5. Ваш прибор примет этот фрейм, и это будет ошибкой. Почему он должен быть принят, если я считаю концом пакета паузу 3.5т? Эти два пакета будут приняты как один и CRC этого большого пакета сойдется только в том случае, если CRC первого была 0xFFFF. По-моему так.Недопонял ответ. Да, действительно, пакет с такой паузой будет принят. Ну так если он был корректный по содержимому - думаю, ничего плохого в его приеме не будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
A. Fig Lee 0 20 февраля, 2015 Опубликовано 20 февраля, 2015 · Жалоба Ну немножко будет не соответствовать стандарту. И там немножко и там.. А потом - и че у нас ракеты не взлетают? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 7 20 февраля, 2015 Опубликовано 20 февраля, 2015 · Жалоба Ну немножко будет не соответствовать стандарту. И там немножко и там.. А потом - и че у нас ракеты не взлетают? Забейте болт. Стандарт RTU неадекватен реалиям современности. Мастером в 90% случаев будет выступать писюк с виндой или линем. Писюк тайминги RTU гарантировать неспособен. Поэтому продаваемые девайсы к таймингам должны относиться философски потому что если наставить жестких проверок то девайс будет точно соответствовать спецификации но у пользователя будет жестко глючить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 21 февраля, 2015 Опубликовано 21 февраля, 2015 · Жалоба Да, действительно, пакет с такой паузой будет принят. Ну так если он был корректный по содержимому - думаю, ничего плохого в его приеме не будет. Ну, я говорил в контексте "особо пристрастной проверки" :) Когда я реализовывал Modbus RTU, то сделал для такого случая настроечный параметр - контролировать или нет t1.5. Это позволяло моему устройству уверенно проходить любую проверку, и при этом нормально работать с мастерами под Windows. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
smalcom 0 21 февраля, 2015 Опубликовано 21 февраля, 2015 · Жалоба Мастером в 90% случаев Ано-то можно и "прибором" лампочки бить... Для этого придуман MODBUS ASCII. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lead_seller 0 6 мая, 2015 Опубликовано 6 мая, 2015 · Жалоба После конца фрейма - 1.5 байта, перед началом следующего 2 байта промежутка. Отсюда и набегают те самые 3.5 байта. Намного проще не завязываться на эти самые байты, а сделать регулируемый разрыв пакетов в сервере, и соответственно его же настроить на клиенте. Как собсно в большинстве модбас устройств и делается. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться