ОК, с этим ясно. По сути своей нормальный Modbus или Profibus. Теперь по параметрам, у меня уже есть кое-какие вопросы... так как не все гладко... Смотрим: "4 канала быстрых -частота опроса 1 КГц , при этом повторный запрос при ошибке CRC
через 50 микросекунд , время обратного ответа с вычислительной обработкой - 250 микросекунд".
То есть датчики опрашиваются с частотой 1 КГц = 1 мс, и при этом мы хотим получить ответ датчика через 50 мкс. Хорошо! Примем на веру, что есть такой быстродействующий датчик, и зададимся вопросом: почему частота поллинга датчиков выбрана меньшей, чем время ответа? Какой резон? Никакого. Датчик будет простаивать 90% времени - это раз, а два, как раз тут и начинаются подводные камни с синхронизацией низкой частоты поллинга с быстродействующими датчиками. Почему камни или грабли? Очень просто: простая ситуация - на момент времени Т0 производится чтение данных датчика 20 бит + CRC, при этом время на чтение, согласно спецификации - 50 мкс. А у нас цикл в 1 мс. То есть на момент времени Т0 + 50мкс по логике, мы должны иметь уже готовый ответ от датчика и далее система должна с ним что-то сделать, скажем вычисления или вывод на дисплей. Моменты тут такие:
а) Любой датчик, а у нас RS-485 - имеет handshake. Это время нигде не учитывается. Почему? Даже, если мы будем оперировать с датчиком при скорости 8 kbps (самой низкой), то время для handshake будет значительно выше, чем 50 мкс. И практикой докзано.
б) У нас не один датчик, а много. Соответственно наш 1 КГц или 1 мс надо поделить на их количество для одного канала (все остальные каналы идентичны), то есть имеем 1 мс / N датчиков и получаем реальное Т для поллинга по всем датчикам. Это и есть наш основной цикл. При этом учитываем, что время сбора данных Т2 со всех N датчиков равно N * 50 мкс. Плюс учет самого handshake также принимаем во внимание.
в) Также отсюда мы находим время Т1 для реакции самой системы, ввод/вывод, вычисления и так далее. Это надеюсь понятно. Вот это время и есть наш камень преткновения.
Попробуйте, смоделировав вашу временную диаграмму (sequence diagram) в любом бесплатном редакторе UML-RT, подсчитать реальное время и вы сами все это увидите. Если пришлете мне такую диаграмму, готов разобрать ее по "косточкам" и дать рекомендации. Ссылки на редакторы:
www.magicdraw.com
www.visual-paradigm.com
Под вашу задачу могу рекомендовать несколько устройств, которые мы сами тоже используем, подумайте, может не стоит слишком заморачиваться и взять готовое решение, а к нему лишь дописать весь графический интерфейсный с выводом данных по мониторингу? Ссылки я привожу ниже:
а)
www.infocon-technology.com - EasyIO-30Р контроллер сбора по RS-485. Мы его используем именно под СЕ .NET 6.0. Нужен будет готовый написанный стек под Modbus для СЕ - пришлю на приватный е-майл.
б)
http://www.exar.com/Common/Content/P...ils.aspx?ID=18 - Exar XR19L400 или XR16L580 может вас заинтересует, так на сегодняшний день эта фирма лидер по таким решениям. Для СЕ у них есть (да и у меня тоже) весь SDK.