M и C в SDI-12: как проверить расписание нескольких датчиков
Рассмотреть схему крупнее
Регистратор хозяйства обслуживает несколько датчиков на общей SDI-12 шине. Попытка ускорить цикл простой заменой команды может нарушить порядок обмена и привязку результатов. Сначала проверьте поддерживаемые режимы и состояние каждого запущенного измерения. Цель испытания — получить правильный набор от нужного источника, а затем оценить длительность полного обхода. Само уменьшение времени выполнения программы не доказывает, что она перестала читать старые или неполные результаты полевых сенсоров.
Разделить режимы запуска
M и concurrent C имеют разные правила ожидания и обмена с несколькими датчиками; поддержка проверяется по конкретным приборам. (SDI-12 Support Group — measurement scheduling) Не переносите логику ожидания одной команды на другую только из-за похожего формата ответа. Для каждого адреса сохраните фактически заявленные время и количество данных, выбранный режим и последующие операции чтения. Общий таймер обхода не заменяет отдельное состояние незавершённого измерения каждого участвующего датчика.
Нарисуйте последовательность действий регистратора: запуск, ожидание, обращение к другому адресу и получение результата. Укажите, где программа хранит связь результата с исходным запуском. Если используется библиотечная инструкция, проверьте её документированную семантику, а не только название параметра. Внутренний кэш библиотеки может скрывать несколько этапов. В отчёте должно быть понятно, какие действия выполняет сама программа и какие остаются внутри применённого драйвера сборщика хозяйства.
Сравнить обходы на стенде
Подготовьте два тестовых источника с различимыми рядами и разными подтверждёнными длительностями измерения. Сначала выполните штатный последовательный сценарий, затем отдельный поддерживаемый concurrent сценарий. Сравните полный состав данных, их принадлежность и наблюдаемое время получения. Не используйте одинаковые постоянные значения: они плохо выявляют перестановку ответов между адресами. Для каждого запуска оставляйте независимую запись, позволяющую отличить полученный новый набор от повторного чтения ранее подготовленного результата.
Отдельно воспроизведите согласованное замедление одного датчика. Остальные данные должны обрабатываться по проектной политике без потери идентичности и без выдуманной общей одновременности. Если программа завершает цикл с неполным набором, это должно быть видно потребителю. Не назначайте универсальное ускорение по числу датчиков: реальные интервалы зависят от поддерживаемого режима, длительности измерений и работы конкретного регистратора. Испытание не должно менять производственное расписание чтения без подтверждённого результата стендовой проверки.
Закрепить поддерживаемый план
В акте сохраните обе последовательности, версии устройств и сверку всех результатов. Приёмка подтверждает правильный обход выбранных адресов в заданном режиме. Для хозяйства это даёт обоснованное расписание опроса, которое можно повторить после обслуживания. Ускорение оценивается вместе с полнотой и принадлежностью данных, а не отдельно от них: быстрый цикл с неверным источником остаётся ошибкой, даже когда каждое принятое число выглядит правдоподобно на итоговом графике удалённой телеметрии.
Запросы отправляются на наш e-mail из вашей почтовой программы.
