потеря байтов в ответной посылке с периодом 4-5 с.

Уважаемые. Кто нибудь сталкивался с таким эффектом:
При чтении данных из 485 порта 4-5 секунд все нормально, затем начинают теряться первых один-два байта в течение 3-4 секунд. Причем этот период не зависит от установленной скорости обмена и времени цикла задач. пробовал цикл от 20 мс до 1 с. :mad: Похоже на биение частот приемника-передатчика
на линии все нормально. Пакеты идут все без ошибок.
Только есть один нюанс. Порт открыт постоянно так как слейв отвечает настолько быстро что при закрытии-открытии порта всегда теряется начало ответа. Можно ли очистить буфер порта по другому?

Потерь в буфере не может быть (его размер 512 байт).
А что вы имеете в виду под циклом? раз в 20 мс читаете из буфера? А почему так редко?
1. Какой протокол у Вас? Через сколько отвечает slave? Если за 100мкс и быстрее - возможны проблемы, т.к. прерывание RS в ПЛК не единственное.
2. Какой таймаут вы ставили при настройках порта?

Здравствуйте, Владислав.
Протокол Тензо-М. Они как и почти все Российские производители изобрели свой протокол... Вот и приходиться писать.

Читаю раз в 20 мс постольку чаще нет смысла. Скорость АЦП макс 50 Гц. Данные выдает по запросу.

Формат запроса FF ADR COP CRC FF FF
Ответ FF ADR COP W0 W1 W2 CRC FF FF
W0,W1,W2- упакованный BCD
CRC тоже считают по своему алгоритму. полином 69H

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

А как собственно получить данные из буфера напрямую
напр sz:=SysComRead(com_handle,ADR(RD_BUFFER),16,0) Так?

Попробую посмотреть осциллографом интервал между запросом и ответом

Уважаемые производители! Сделайте что-нибудь с Вашим 485 портом!:mad:
Подключив внешний конвертер 485/232 ошибки пропали напрочь.:)

уважаемый роман. зачем так кричать?
резистор терминальный в 485 есть? поставьте.

так я ж не кричу. просто выделил.
ставил и 100 ом и 120 ом и 330 ом ...
бестолку.
да и работает все на столе длины кабеля 0,1-0,3м.
на расстоянии 10 см подключен I7563, которым смотрю линию.

были бы помехи и отражения то ошибки были бы распределены более менее равномерно, а так имею чистый период повторения. как будто переключение прием передача программно организованы и все это накладывается в виде биений частот опрос задачи и пр. в итоге - то попали в окно то не попали...
на 232 работает вне зависимости от времени и количества задач, вот.

у меня на столе подключен мдвв, 100 опросов в секунду, сбоев нет вообще. и с др. приборами тоже. переключение происходит аппаратно,возможно проблема в другом? поэтому прошу, пришлите ваш проект, чтобы мы его опытным глазом просмотрели.

Подниму тему, т.к. она наиболее близка к ситуации.
Клиент приобрел наш прибор, подключает его к ПЛК Овен по RS485.

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

Наш (и Ваш) клиент написал какую-то программу на ПЛК-100, называет
ее "драйвер". Обратился с такой жалобой.
--------- Выдержка из письма клиента -----------------------------
"В ПЛК-100 медленный драйвер и быстро выданные байты через раз пропадают и очень трудно расшифрововать полезную информацию."
--------------------------------------------------------------------

При разговоре по телефону выяснилось, что при чтении ответа от прибора
функцией SysComRead() теряется либо первый символ пакета 0xFF, либо
большее колличество первых байтов пакета.

Разработчики ПЛК-100, пожалуйста, прокомметируйте ситуацию!
Заранее спасибо!
Андрей.

Трудно что-либо сказать, не видя кода "драйвера".