в этот момент играющий на втором WinDVD запросил очередную порцию фильма с винта, винда этим занялась и тут

А Modbus - да фик с ним, с Modbusom

Под вываливаюсь по таймауту подразумевается обработка принятого пакета.

Нет, перед приемом пакета устанавливаю время, в течение которого я жду данные, если это время истекает, а данных нет, генерируется исключение, т.е. данных никаких не пришло. Далее расцениваю это как "модуль не ответил" и реагирую в зависимости от ситуации.
Ну и повторюсь, что пользую ModBus RTU-подобный протокол, заточенный под мои задачи.
А то, что "винда не real time" - это точно

Ну так в любом случае этот ложный таймаут может появиться именно из-за действий винды ! Можно конечно real time приоритет выставить, но это моветон

Так, уже интересно.
Вариантов может быть 2 более-менее разных.
1. При приеме очередного символа, таймаут довзводится.
При истечении таймаута анализируется пакет, указатель приемного буфера на начало.
2. При приеме очередного символа, подсчитывается CRC16.
Если СКС16==0 обрабатывается пакет, указатель приемного буфера на начало.
Таймер таймаута используется для еще одной установки указателя приемного буфера на начало.
Что за вариант используется у Вас ?

Мужики, то, что ложных пакетов таким образом не нахватешь - точно. А вот потерять - запросто

2-3 % убитых и раненых на учениях - это нормально. Главное шпионов в плен не брать.

Так и есть. Потом повтор команды и т.д..

Но на помощь может прийти "умный" конвертер 232<->485.
Который в отличие от тупого, будет знать modbus, и уметь обрамлять/раздевать стаффинги. Пакеты "к компу" обрамлять тагами байт стаффинга, а "в сеть" - снимать таги компа - и слать чистый modbus RTU с требуемыми задержками. Работать не по CRC а по таймаутам, с проверкой CRC после обнаружения таймаута в 4 символа.

Ну не знаю.. меня системы на жесткой времянке нервируют и раздражают. И по F9 занудно их пошагово трассировать


Угу, а CAN еще лучше придет на помощь. По-моему проектировать умный конвертер автору пока не хочется, но можно спросить его

Этот вариант считается предпочтительным.

Дык, это ж только транспорт на жесткой времянке.. Один раз отладить и все..

А зачем ? Если есть Wake ? Стаффинг и ноль проблем.

Пригодится. Нынче много готовых слейвов имеется которые понимают Modbus RTU, но не понимают Wake.
Да и работает чистый RTU неплохо на самом деле (когда мастер не PC )

Добавлю, что ModBus RTU является самым распространенным стандартом выполнения RS485.

RS485 вообще программный уровень не стандартизирует. А с чем доводилось работать - было либо ASCII либо и то и то вместе. А еще чаще просто текстовые строки - любят юзера, чтобы в обычной терминалке можно было бы с прибором поговорить.