[dr. F.I.N.]

Добрый день, коллеги.
Прошу навести на мысль.
Пишу эмулятор некоторых приборов, которые висят на одной шине RS-485. Работа идет через COM-порт.
Суть: от главного контроллера приходит запрос. На запрос нужно послать ответ с задержкой (у разных "приборов" разная).
Моя реализация выглядит так:
1. Виртуальная шина данных, к которой аттачатся виртуальные "приборы".
2. Шина открывает COM-порт и получая с него данные бродкастит на все приаттаченные виртуальные устройства (вызов функции обработки сообщения всех "приборов" в цикле).
3. "Прибор" получив запрос формирует ответ и отправляет в шину.
4. Шина перенаправляет ответ в COM-порт.
Как я уже сказал, ответ должен улетать с задержкой. И эта задержка не должна влиять на "работу" других виртуальных приборов.

Ломаю голову, как сделать эту временную задержку (для каждого прибора свою) на одной шине. Использовать по окну и таймеру для каждого виртуального устройства как-то расточительно.
Есть идеи?

[Alegun]

А что, sleep() не помогает? Можно ведь в одном обработчике таймера задать разный период задержки для разных "приборов"

[Guaho]

Всего один таймер + софтовые счётчики по числу необходимых каналов.

[NumLock]

Один queue таймер CreateTimerQueue и несколько CreateTimerQueueTimer() со своими задержками и параметрами для идентификации в callback-процедуре.

[dr. F.I.N.]

Решил попробовать так:
1. Отсортировать "приборы" по времени задержки ответа.
2. Передавать прибору в обработку данные со штампом времени получения
3. Прибор обрабатывает данные и Sleep() на необходимое кол-во мс.
4. Следующий прибор поступает аналогично, но его пауза ожидания будет рассчитываться с учетом прошедшего времени с момента получения данных из порта.
Вариант с очередями таймеров очень интересен, но думаю с максимальной задержкой в 200-300мс это будут лишние заморочки. Будем посмотреть.

Спасибо за идеи.

[Alegun]

Да с таймером тоже вариант хороший, он может использоваться как независимый от основного приложения заменитель цикла опроса, стабильности будет больше

[dr. F.I.N.]

Сообщение от Alegun

Да с таймером тоже вариант хороший, он может использоваться как независимый от основного приложения заменитель цикла опроса, стабильности будет больше

Да циклы опроса меня особо не интересуют. У меня стоит задача реализовать slave-устройства. т.е. наоборот отвечать на опросы. Что же касается в принципе работы с таймером, то на текущий момент достаточно банального sleep с коррекцией на время прошедшее с момента принятия опроса. Тут еще дело в том, что за время выдерживания паузы ответа может прилететь следующий запрос. Короче надо еще подумать как реализовать буфер ответов с задержкой относительно поступившего опроса.

[Aristarh Dark]

Тут еще дело в том, что за время выдерживания паузы ответа может прилететь следующий запрос.

485 так не работает. Мастер шлет запрос, слэйв должен на него ответить за определенный таймаут. Если таймаут вышел - все заткнулись и ждут, что скажет мастер.

[dr. F.I.N.]

Сообщение от Aristarh Dark

485 так не работает. Мастер шлет запрос, слэйв должен на него ответить за определенный таймаут. Если таймаут вышел - все заткнулись и ждут, что скажет мастер.

К сожалению реализация со стороны устройств диктует иначе. Поэтому я и говорю о разных задержках ответа от периферии. Выглядит это примерно так:
1. От Мастера - бродкаст- рассчитайсь!
2. От Слейва 1 - (зажержка 10мс от рассылки) - Я!
3. От Слейва 2 (другое устройство) - задержка 20мс от рассылки - Я!
4. и т.д.
Устройства в сети все разные, задержка соответственно тоже. Почему такую реализацию выбрал производитель - мне не ясно.