МВА 8. Максимальная задержка ответа?
Кирилл, названная Вами цифра 50мс в теме http://www.owen.ru/forum/showpost.ph...87&postcount=9 требует более официального исследования и уточнения. Я прекрасно понимаю, что не Вы сами её придумали, а Вам она была названа специалистами. Но звучили её Вы и поэтому к Вам я и обращаюсь персонально. Неточность этой цифры привела к интересному подводному камню при эксплуатации системы.
Далее очень долго и нудно. Сорри, по-короче не удалось.
Состав системы: контроллер собственного производства, два МВА8, два МВУ8. Шина RS-485, скорость 19200, Modbus RTU. Датчики давления и термосопротивления тоже ОВЕН. Контроллер - мастер, остальные - слейвы. С МВУ8 проблем нет. А вот о входах чуть подробнее. Контроллер циклически опрашивает входные модули по-канально, т.е. в одном запросе к МВА8 читаются 4 байта (2 байта результата и 2 байта код ошибки). Внутри одного модуля каналы читаются последовательно. Модули опрашиваются поочерёдно. Приём посылок в программе контроллера обвешал контролем максимально: контроль CRC пакета, контроль количества байт в пакете ответе, сравнение адреса модуля в ответе с адресом из запроса, сравнение значения регистра "Число байт" в информационной части самой посылки. Только после прохождения всех проверок результат измерения канала признаётся достоверным и переписыается из приёмного буфера во внутренние регистры программы. Для каждого канала заведён счётчик ошибок связи, при возникновении ошибки счётчик инкрементируется, при положительном результате декрементируется. При превышении определенного числа ошибок генерится авария по связи. Т.е. однократные нерегулярные ошибки не приводят к затыканию системы.
Смонтировали систему, запускаем, отлаживаемся, всё хорошо, модули работают исправно, датчики давления и температур тоже. Но, эпизодически система стала сваливаться в аварию при проверке диапазонов рабочих параметров, т.е. в алгоритме верхнего уровня. При этом реально со "сбойными" параметрами всё в порядке - стоят визуальные приборы, манометры и термометры, и мы тут же кидались к ним при аварии автоматики. В статистике ошибок связи, которую ведёт программа, 0 ошибок.
В момент аварии система фиксирует код ошибки и величину параметра, вышедшего за диапазон.
Собрал статистику "аварийных" случаев и стал анализировать. Результат анализа: значения "сбойных" параметров равны результату соседнего канала. Естественно, первым делом проверил саму программу контроллера, контроль приёма пакетов - всё чисто. А потом осенило: алгоритм общения с модулями у меня построен так: запрос, ожидание ответа 3.5Т + 60мс (я сознательно увеличил названную мне цифру), если нет ответа, счётчик ошибок +1, и после паузы 3.5Т делается следующий запрос и т.д. И теперь подводный камень: в структуре ответа слейва на команду 03 и 04 в Modbus RTU нет информации об адресе регистра присланных данных, а только адрес модуля. Поэтому при "перехлёстывании" ответов при опросе соседних каналов в пределах одного модуля проблем не будет никогда: число байт ответа сходится, CRC сходится, адрес модуля в запросе и ответе одинаков. Как этот "перехлёст" может происходить? Прихожу к заключению, что если величина задержки ответа от слейва составляет более 50мс и этот задержавшийся ответ попадает во временной слот ожидания ответа от уже запрошенного следующего канала, то вот тут-то и происходит этот "перехлёст".
Я переделал последовательность опроса модулей, т.е. поочерёдно опрашиваю канал с одного модуля МВА8, отсылаю данные в канал на МВУ8 и т.д., чтоб в соседних ответах принципиально были разные адреса модулей и разное число байт в пакетах. И если описанный "перехлёст" произойдёт, то при проверке пакета это должно не сойтись по двум критериям. Вроде зажило, "аварии" перестали появлятся.
Так что вот... очень жажду ответа от фирмы ОВЕН :) Вопрос, а почему этот довольно принципиальный для построения канала связи параметр отсутствует в документации прибора?
