| Автор |
Повідомлення |
|
Повідомлення створено: 14. 08. 2017 [17:09]
|
|
Yaroslav555
Ярослав Вишневский
Автор теми
Зареєстрован(а) с: 14.08.2017
Повідомлення: 4
|
Доброго времени суток.
Значит история такая: лично я занимаюсь написанием прошивки к некоему устройству Х, которое в итоге должно работать с проектом оскады.
В процессе разработки я у себя тестировал работу устройства с оскадой и проблем не возникало (usb->RS485).
В один прекрасный момент возникла необходимость поправить проект скады, для чего был проброшен кабель на соседний стол к коллеге. И тут у него примерно 50% данных начинают проходить с CRC ошибками. После исключения проблем c кабелями и преобразователями, коллега запустил проект на другом компьютере и продемонстрировал что там тоже есть ошибки. После чего я установил линукс на отдельный ноут и запустил там проект - 0 ошибок. 2-2.
Далее система была запущена с флешки на ПК который со стационарной системой давал ошибки - нет ошибок. После чего проверку прошел еще один ноутбук - ошибки есть. Итого имеем 3-3. Ядро одинаковое - 4.4.0, стороннего софта не запущено, так что конфликтов быть не должно. Проект тоже везде один.
Разница в том что у меня для тестов использовался Mint (работает), фирма использует Kubuntu (ошибки CRC). Кстати - простой RTU мастер на кубунте не дает ошибок и работает стабильно.
Версия оскады 0.8.18. Подскажите куда посмотреть/копнуть?
|
|
Повідомлення створено: 14. 08. 2017 [17:27]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
Читаем документацию на предмет времени символа!
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 14. 08. 2017 [21:35]
|
|
Yaroslav555
Ярослав Вишневский
Автор теми
Зареєстрован(а) с: 14.08.2017
Повідомлення: 4
|
"roman" wrote:
Читаем документацию на предмет времени символа!
так проект один и тот же, все настройки идентичны, даже на одном железе запускаем: Mint работает, Kubuntu - нет. Ну да ладно.
Смотрим вики: "symbol:frm[::rtsDelay1:rtsDelay2]"
symbol — время символа в миллисекундах. Используется для контроля факта окончания фрейма;
frm — максимальное время фрейма в миллисекундах. Используется для ограничение максимального размера пакета запроса (фрейма);
Смотрим всплывающую подсказку в самой скаде:
conn:symbol
conn - макс длина фрейма
symbol - длина символа используемая для определения окончания фрейма (это длина одиночного символа или с учетом умножения на 3.5??)
Мои коллеги прописали 586:5.73. Почти 600мС? Более чем, если учитывать что таймер который запускает ответ на моем устройстве тикает с периодом 20 мС.
Время одиночного символа при 19200:n:1 11/19200=5.729мС.
Не скажу что я читал какую-то документацию, но думал что изучения всплывающих подсказок более чем достаточно.
|
|
Повідомлення створено: 15. 08. 2017 [08:27]
|
|
fido_max
Maxim Kochetkov
Contributor
Зареєстрован(а) с: 28.10.2010
Повідомлення: 129
|
А теперь читаем документацию на протокол Modbus:
Modbus RTU — компактный двоичный вариант. Сообщения разделяются по паузе в линии. Сообщение должно начинаться и заканчиваться интервалом тишины, длительностью не менее 3,5 символов при данной скорости передачи. Во время передачи сообщения не должно быть пауз длительностью более 1,5 символов.
19200 8N1 - 10/19200 * 3,5 = 1,8229 мс
Это идеальный случай. Будет работать с аппаратным последовательным портом. В случае всяких преобразователей USB-RS485, Eternet-485 и т.д. в самом устройстве или в драйвере может быть буфферизация, в этом случае байты будут сыпаться пачками по 8, 16 ... хз сколько еще байт.
10/19200 * 3,5 * 8 = 14,583 (буферизация по 8 байт)
На разных осях разный результат, потому что могут отличаться драйвера, либо настройки драйвера.
Крути байтовый таймаут в большую сторону, пока не получишь стабильный ответ.
Также зависит от того, как монотонно ваше устройство выдает в линию ответ. И 20 мс - как-то многовато для таймера ответа. Я обычно делаю по одной милисикунде таймер. В таймере уменьшается счетчик, при достижении нуля считается что пакет принят. Интервал можно настраивать. Это и будет межбайтовый таймаут. При передаче ответа формирую буфер и отправляю его через DMA, если нет, то через прерывания по TXREADY (не TXCOMP!!!).
|
|
Повідомлення створено: 15. 08. 2017 [08:48]
|
|
Yaroslav555
Ярослав Вишневский
Автор теми
Зареєстрован(а) с: 14.08.2017
Повідомлення: 4
|
"fido_max" wrote:
19200 8N1 - 10/19200 * 3,5 = 1,8229 мс
(10/19200)*3.5=17.5 примерно, я в дороге, пишу с телефона. 20 мС очень даже нормально. Обычно тайм-аут ответа 50 мС встречал.
И потом - над тем и ломаем голову, что оси должны быть одинаковы - ядро одинаковое.
|
|
Повідомлення створено: 15. 08. 2017 [09:08]
|
|
fido_max
Maxim Kochetkov
Contributor
Зареєстрован(а) с: 28.10.2010
Повідомлення: 129
|
"Yaroslav555" wrote:
20 мС очень даже нормально. Обычно тайм-аут ответа 50 мС встречал.
И потом - над тем и ломаем голову, что оси должны быть одинаковы - ядро одинаковое.
"Нормально" - это пока одно устройство. Если несколько таких "нормальных" повесить на одну линию - то каждое из них будет молчать по 20 мс, плюс 10мс на таймаут ответа. минимум 30мс на устройство получается. 10 устройств будт молчать уже 300 мс. Т.е. за секунду опросить 10 и более таких устройств будет уже проблематично.
Ядра одинаковые... настройки разные.
|
|
Повідомлення створено: 17. 08. 2017 [11:17]
|
|
Yaroslav555
Ярослав Вишневский
Автор теми
Зареєстрован(а) с: 14.08.2017
Повідомлення: 4
|
При установке скорости скада автоматом рассчитывает время символа - 5.73, что как-бы верно. На Kubuntu CRC ошибки уходят при увеличении этого времени до 12 мС. Почему расчетные параметры не позволяют работать системе я не выясню, а наш специалист занят другими проектами. В любом случае - спасибо за помощь.
|
