Ха! Не удивляюсь. Даже разработчики модбаса такую хну несут, а что делать с эксплуатационщиками? Я руководству сразу сказал, что в подавляющем числе случаев на любой вопрос потребителей ответить будет нечего, только взять и все за них сделать. А протокол-то несложный и документ очень сжатый, там только десяток страниц просмотреть и все, это не USB.

Помочь тут вам не смогу

Вообще говоря, все на самом деле идет к числу тразакций в секунду. Я исхожу из максимально возможного числа 8 в секунду вне зависимости от скорости обмена, коллеги настаивают на максимум 5 в секунду.. А чего хотят от вас? Это вообще чего такое будет? Может лучше не вы*** и делать сразу TCP ( и может вообще свой протокол, я сталкивался с тем, как пендосы просили в авиационном стенде сделать TCP, пофиг какой, только чтобы успевал) просто результат будет гарантированный, а тут, похоже, на ни к чему не проиводящее эстетство.

Прога будет стоять на мониторе, где крутится Windows XP Embedded. Вся система подключается к двум ком портам. Нужно опрашивать оба параллельно и объединять информацию, потом её обрабатывать и отображать. Период опроса по одному каналу всех устройств не должен превышать 100 мсек.
Хотят - сделаю. А то что может не получится, я уже объяснял, но доводам моим не вняли

Сообщение отредактировал Timofey - Dec 16 2010, 07:42

Смотрите. Прежде всего устройство должно уметь в одном кадре говорить о текущем состоянии измерения всё. Т е за один запрос мы должны получить результат измерения всех каналов из одного прибора (если он многоканальный) и всех вспомогательных переменных (состояние реле , уставок, кнопок, достоверность измерения по каждому каналу прибора и т п; это называется групповым запросом, в обычных скадах это делать не умеют, только если на устройство есть специфический драйвер), а в скада любят по одному или по два регистра выспрашивать из прибора.

В этой системе уже стоят 20 устройств, одно из которых уже является мастером. Наш монитор должен прослушивать линии обмена и анализировать данные из всех посылок, но при этом отвечать только на свою. У каждого устройства разный размер посылок, минимум 8 на запрос и ответ, у другого 11 байт есть в ответе. Сейчас сделано так, что в мониторе программа в отдельных потоках принимает по одному байту, накапливает данные, пока не поймет, где начало посылки и дальше уже обрабатывает её, то есть никаких проверок на таймауты. Но такой подход не нравится. Было решено написать отдельный драйвер, чем я и занимаюсь )
Практически закончил, осталось докупить железа и проверить, думаю к новому году отлажу и получу первые результаты )

Что характерно - метод, реально работающий без шума и пыли - не нравится. Можно довесок к ком-порту прицепить, чтоб анализировал паузы и по DCD сигналил.

Да там такую хрень замутили, что все чихать потом год будет и, самое противное, отладить, скорее всего, не удастся никогда. Уж написали, что винда не реал тайм и любой поток будет время от времени при ширкании мышой или там еще чего тормозить и ессно будет обмен падать. Глубоко и долго. У меня на штатных API как винамп запускаешь - падал.

ИМХО для такого чуда внешняя приблуда была бы самым тем.

В принципе на уровне драйвера можно обеспечить требуемые времянки, но путем глухого блокирования всей жизнедеятельности Windows на время обмена. Так что при запуске WinAmpа ничего падать не будет, а вот при обмене по ModBus'у WinAmp'у будет долго и сильно икаться

Так мне и рекламация такая была: а чё музыку низзя слушать при обмене?

Че-то Вы модбас совсем не вкурили...
3.5байта тишины это всего лишь конец посылки, т.е. по наличию не менее чем такой паузы
принимающая сторона понимает что посылка закончилась.

Slave на PC(16550A), ну-ну...
RS-485 ? если да, то RTS хотя бы аппаратный ?

В модбасе конец посылки обозначает пауза 1,5 байта. А 3,5 байта тишины должно быть выдержано перед началом передачи следующей посылки.
RS-485 с аппаратным RTS

В модбасе конец посылки обозначает перерыв в течении времени не менее чем 3.5 времени передачи символа (почувствуйте разницу формулировки), а если в кадре встретилась пауза 1.5 - то кадр плохой. На практике это означает, что в контроллере, когда мы сами хозяева положения, мы начинаем анализировать приемный буфер тогда, когда в течение времени не менее чем 3.5 ничего больше не пришло.

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

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

Про 16650 я уже не смеюсь даже, там еще и времена чудесатые им понаписали. Мужики запорят тему на ровном месте или что хуже - чихать все это будет долго долго у заказчика, пока все не плюнут.

Покажите всю эту писанину руководству.

Если с аппаратным RTS то может быть прорветесь... хотя пакеты будете терять на приеме постоянно.
Читайте внимательнее...