Modbus RTU. Как (чем) задать/подсчитать интервал между фреймами в windows?

[avp94]

Интервал между фреймами в modbus RTU должен быть "длинной" не менее 3.5 единичной посылки. При скорости 115000 и 11 битах в единичной посылки интервал составит: 3.5 * 11 / 115000 = 0.335 мс. Вопрос: как его сфoрмировать при передаче  (подсчитать при приеме) при программировании под windows (обычные таймеры имеют разрешение 1 мс)?

[RXL]

Не менее - значит, что может быть больше. Одна мс будет в самый раз.

Кстати, зачем реализовывать протокол самому? Есть готовые библиотеки и SDK.

[avp94]

Не менее - значит, что может быть больше. Одна мс будет в самый раз.

Весьма условно можно согласиться, но в данном протоколе надо "отсеивать" фреймы с паузой между "кадрами" или единичными посылками (не знаю как правильно назвать) более 1.5 их величины, а если меньше, то все Ok. Таким образом надо что-то с большей разрешающей способностью, чем 1мс.

Кстати, зачем реализовывать протокол самому? Есть готовые библиотеки и SDK.

Я не силен в программировании, настолько, что бы разобраться в исходниках чужих библиотек. Сам протокол не сложен и достаточно хорошо описан и его логическая (программная) реализация не вызывает (пока) вопросов, кроме момента подсчета/формирования указанных интервалов времени. Те реализации протоколов исходники которых видел, основываются на априорном знании "длины" ответа, а хочется типа "прослушки" (сниффера) .

[RXL]

Я искал недавно информацию по реализации Modbus: 1.5 символьный пропуск (ошибку передачи согласно спецификации) рекомендуется не отлавливать, т.к. это проблематично. Только межкадровую паузу.

Все ведомые участники сети являются "сниферами", т.к. даже если пакет предназначен не им, то все равно надо отслеживать его начало и конец.

Самому писать не легче. Библиотеки, обычно, снабжаются документацией.



Кстати, народ, кто пользовался виндовым ожиданием событий от последовательного порта? В событии есть время возникновения этого события? Тогда никакие специфичные таймеры не потребуются.

[Sla]

RXL, нет никакого времени возникновения события.

1,5 символьные промежутки проверяются только на специфических контроллерах (может даже и сами Шрейдеры уже не проверяют).

[avp94]

Все ведомые участники сети являются "сниферами", т.к. даже если пакет предназначен не им, то все равно надо отслеживать его начало и конец.

Ведомые, как правило, выполнены на микроконтроллерах, а там эта проблема не возникает.

Самому писать не легче. Библиотеки, обычно, снабжаются документацией.

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

Кстати, народ, кто пользовался виндовым ожиданием событий от последовательного порта? В событии есть время возникновения этого события? Тогда никакие специфичные таймеры не потребуются.

На сколько я разобрался в winapi, там квант времени - миллисекунда.

[RXL]

Странно. А я полагал, что типовой PC имеет на порядки больше ресурсов, чем типовой 8-битный м/к.
Алгоритм прост: запрашиваешь системные микросекунды (QueryPerformanceCounter, QueryPerformanceFrequency), ставишь ожидание событий последовательного порта с таймаутом 1 мс (WaitForSingleObject, WaitForMultipleObjects); по возврату запрашиваешь микросекунды и сравниваешь, сколько времени прошло - >= 1 мс или много меньше.

[avp94]

Странно. А я полагал, что типовой PC имеет на порядки больше ресурсов, чем типовой 8-битный м/к.

M/k бывают не только 8-битные , но независимых аппаратных таймеров даже в них бывает больше, чем в PC.

Алгоритм прост: запрашиваешь системные микросекунды (QueryPerformanceCounter, QueryPerformanceFrequency)

А это, очень похоже, то что надо, СПАСИБО, буду разбираться.

[DneprSMV]

Посмотри ф-ю WinAPI  ReadFileEx() - ее надо настроить на генерацию событий и там же есть возможность настроек сериал-драйвера. Он должен работать в "блочном" режиме, когда блок воспринимается как целостный поток символов без интервалов, а окончание блока как раз и детектируется, если есть разрыв-таймаут в приеме символов. Там 3-4 таймаута задается - ожидание, мин. разрыв, ожидание, кол-во символов в пакете.
Самостоятельно таймауты ты не отловишь, тк. надо ловить миллисекунды, а это может сделать только драйвер. (если это не в рейалтайм-ОС делается).
В QNХ есть подобная настройка для сериал-устройства, я раз задал таймауты и до сих пор код не трогаю
- уже года как 4

[RXL]

DneprSMV, можно подробнее?

[DneprSMV]

 SetCommTimeouts function sets the time-out parameters for all read and write operations on a specified communications device.

по таймаутам см.
(я пока не гонял, сидел на QNX, если получится пиши)

BOOL SetCommTimeouts(
    HANDLE hFile,   // handle of communications device
    LPCOMMTIMEOUTS lpCommTimeouts   // address of communications time-out structure
   );

посмотри ф-ии группы:  (winbase.h кажисть)
BuildCommDCB
BuildCommDCBAndTimeouts
ClearCommBreak
ClearCommError
CommConfigDialog
DeviceIoControl
EscapeCommFunction
GetCommConfig
GetCommMask
GetCommModemStatus
GetCommProperties
GetCommState
GetCommTimeouts
GetDefaultCommConfig
PurgeComm
SetCommBreak
SetCommConfig
SetCommMask
SetCommState
SetCommTimeouts
SetDefaultCommConfig
SetupComm
TransmitCommChar
WaitCommEvent

[RXL]

Посмотрим...
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363190%28v=vs.85%29.aspx

COMMTIMEOUTS structure

Код: (C++)

typedef struct _COMMTIMEOUTS {
  DWORD ReadIntervalTimeout;
  DWORD ReadTotalTimeoutMultiplier;
  DWORD ReadTotalTimeoutConstant;
  DWORD WriteTotalTimeoutMultiplier;
  DWORD WriteTotalTimeoutConstant;
} COMMTIMEOUTS, *LPCOMMTIMEOUTS;

ReadIntervalTimeout
    The maximum time allowed to elapse between the arrival of two bytes on the communications line, in milliseconds. During a ReadFile operation, the time period begins when the first byte is received. If the interval between the arrival of any two bytes exceeds this amount, the ReadFile operation is completed and any buffered data is returned. A value of zero indicates that interval time-outs are not used.
    A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received.

Значит, интервал в миллисекундах. А на типовой скорости 19200 длина символа ~0.52 мс. Полтора символа - 0.78 мс. 3.5 символа - 1.82 мс. Т.е., теоретически, можно отловить межкадровый интервал. А практически? Винда - не риалтайм система... Если же скорость выше, то таймаут точно не отловить.

[DneprSMV]

я в винде еще не плавал по этой тематике - только док набрал.
сейчас завал, времени нет, в пятницу командировка.
Судя по твоей доке выше (может не так прочитал чевой по аглицки)
Скорее всего речь идет о таймауте между двумя последовательно идущими байтами.
Если интервал НЕ БОЛЕЕ - все ок, драйвер продолжает прием (блока), события не генерируется.
А вот если таймаут превышается - это считается разрывам, что аналогично окончанию пакета, что собственно, и требуется отловит, насколько я понял 
А что слушать собираешься ? PLC какойнить  ?
У драйверов (по крайней мере в QNX) сериальных есть 2 режима работы - символьный и блочный.
Обрати внимание на это, я в свое время потратил пару дней на разбор полетов.



Добавлено через 4 минуты и 31 секунду:
ps - а что, пакеты сыплются как из рога изобилия ?
тем более, тебе для прослушки канала потребуется 2 порта.
Соответственно, т.к. пакеты идут попеременно - принял-обработал-ответил,
у тебя будут паузы намного больше чем эти 3.5
Это такая гипотенуза 
В общем, что гадать - делай прототип на 1 канал и .....
.... да поможет нам Бог

[RXL]

Я пока ничего не собираюсь слушать. Топик стартер - avp94.

Если используется не полнодуплексный RS232, а полудуплексный RS485, то в нем пакеты вполне могут идти вплотную, с минимальными паузами.

[DneprSMV]

RXL
Извиняй, не в тот адрес наплел 
по 485 согласен.